Include actual changes in Announcements topics



Continue discussion from [Testing Update] 2018-05-06 - Pamac, Jade, Linux v4.17:
I beg for some mercy from @philm and the team, but this is really frustrating to me.
It is really difficult to follow the specific changes made on each UP in Testing, when very often subsequent announcements contain almost exactly the same opening text. The only way to pinpoint the real changes is to go through the attached lists of differences.
I can’t understand why there should be a copy/paste on the intro, when the only way to see the changes is to analyze carefully the diffs, watching for version numbers and point updates.
I can see the same tactic “viable/acceptable” for the Stable Updates, because they might be followed by journalists or bloggers, so they get a nice intro to raise to the crowds, but in Testing there is a debugging task by definition for the relevant users and this just comes in the way.
I once more state that I 'm not so fluent in English, so please try to get what I try to state and not misunderstand my intentions.
Any comments from fellow testers would be helpful, IMHO, to narrow down the extend of this request.
Thanks for watching :stuck_out_tongue_winking_eye:.


Meh, all I look for is kernel updates, because that’s my clue I have to reboot.
I’m not going to compare that list of packages to last update’s list. Thats for people bisecting a problem after the fact.

I read the part about known problems, seeing if there is anything to look out for, but other than that I ignore the details till I need them.


Most of the changes are upstream packages, packaged by Arch & synced directly from Arch Stable, but developed further upstream.

To expect a detailed description of all this, included what has changed is ridiculous. Pretty much all Manjaro packages are developed by others, tracking down specific version changes simply to include in a thread OP is a waste of time. Manjaro team members work also, their time needs to be spent effectively to keep everything “rolling” along.

The announcement text gives a brief summary of changes to more prominent areas, combined with a list of all the packages that updated, listing their previous and new version numbers. This is enough, and for those coming from Arch is a luxury.

I always peruse the package list before updating, so I know what is being applied to my system. IMO all users should too. If a major version bump to a major package is in there I’ll try to find out what changes have been introduced and if any related major issues experienced in Arch.

I also look for important updates that could effect the bootability of my system (ie systemd updated, video card driver updates, xorg updates, etc). This could effect how I apply the update (ie systemd updates I perform from tty2).

If you want more detail the onus is on you to research it … to expect @philm to do it is unreasonable and a waste of time, particularly given the high velocity of upstream updates flowing into a rolling release like Arch.

If you feel strongly enough about this though and want to help out you could always do some research yourself and add to this to an unstable / testing update thread. These could be included in stable update threads.


That’s how I do it, too. If I have an issue I try to find out from pacman.log with which version it got introduced. Then I search the Announcements category and post (a report or a reference to my troubleshooting topic) in the update topic.

However I would appreciate some automation with hyperlinks, not just plain text output of package versions. But that would require an improved system for managing branches.


I think the point here is that each Testing update contains the same text in the OP.

I can see that the text being “prepared” for the stable roll-up is useful, though for anyone reading the announcements it doesn’t help identify changes for that particular testing update set.

I don’t know how best that could be handled. My #announcements:manjaro32 testing update threads take a different approach, but then there’s very few (though very valuable :wink:) people feeding back issues etc. so a single thread works fine.

I suppose each new testing thread should be an evolution of the previous one, maybe with a line to delineate text being prepared for the stable announcement from any updates specific to this testing set?


Exactly and thank you @jonathon for the interpretation.
In fact I went to this topic while trying to find at what point (UP) was my system updated to, since I dropped off the race condition to try being on the latest update and just wait for my mirror to come in-sync. Then I had an update showing up and I didn’t know which one was it, to do some preview of the relative Announcement wiki. And they were all (3 or 4) looking the same and only a package version comparison might give a clue.
I think this is a part of the general issue/discussion on mirror syncing, version naming, major/minor update, manjaro-system/manjaro-release.
Maybe manjaro-testing-release would be an option. As it is said by few, Testing is more round rolling than Stable, so there is some difference in behavior and troubleshooting.
Just thinking out loud.
Thanks for the responses, anyway.
Peace :heart_eyes: