A respected Amarok developer Ralf Engels made an amazing bug-fixing spree in weeks and months following the Amarok 2.7 release. Unfortunately, Ralf sometimes forgot to add ChangeLog entries for bugs he fixed. ChangeLog is important for us because it serves as a basis for release announcement message. This task involves going through Ralf's commits from 2.7.0 tag till now, checking that every commit that has BUG: or FEATURE: tags in the commit message also adds a line into ChangeLog. If not, a meaningful user-understandable entry should be added, for format see [1]. To make it a bit harder, the each entry should be added *on top* of the appropriate FEATURES/CHANGES/BUGFIXES section of the Amarok 2.8-Beta header *at the time the commit was made*. :-) I propose you use a git history visualization tool such as gitk to see how ChangeLog looked at given time. (you'll still be editing the most current ChangeLog) This task is suitable for future Amarok GSoC applicants who want to show they're able to work with git history. [1] http://quickgit.kde.org/?p=amarok.git&a=commit&h=6a4bebbe80c8237588cf2dbed1c6f329aa58f537
Actually I think that we shouldn't blow up our changelog with every single small change. We have the git log for that. The git log is for the user to get a human readable fast overview about the changes. That's why the functionality change of the dynamic playlist is there but not the internal and mostly invisible (but quite substantial) change to the collection delegate. Myriam, your opinion?
Argh. The second line should of course read "The ChangeLog is for the user to get a ..."
(In reply to comment #1) > Actually I think that we shouldn't blow up our changelog with every single > small change. We have the git log for that. > > The ChangeLog is for the user to get a human readable fast overview about the > changes. Hmmm, that's true. In past we used the "if it was reported as a bug, it is user-visible and should be mentioned in the ChangeLog" assumption. This is however redundant with the BUG: 123456 commit field and "Latest Commit", "Version Fixed In" bug properties. Setting as NEEDSINFO and remobing JJ tags until we have more imput, mainly for Myriam.
We need a minimal ChangeLog for bugfixes, new features and major changes, as it is listed in the release article and it is the basis to actually be able to write the release notes. Don't expect non-developers to dive into git logs for that, with hundreds of commits between releases this is not very realistic. Also the KDE Commit Digest needs decent commit messages to feed their weekly digest, so using the Changelog and the "DIGEST:" hook is a very good idea, btw.
No discussion about important stuff from my side. But there is a lot of small fry like the "normalize all SIGNAL" stuff. It even has a review board entry but it's clearly nothing that is interesting for a user. A quick hacked script shows me 1329 bugs in the changelog but 2597 in git log (plus minus some). Should I extend the script a little bit to automatically show the discrepancies? What about reviews?
(In reply to comment #5) > No discussion about important stuff from my side. > > But there is a lot of small fry like the "normalize all SIGNAL" stuff. It > even has a review board entry but it's clearly nothing that is interesting > for a user. Of course that doesn't belong in the Changelog. > A quick hacked script shows me 1329 bugs in the changelog but 2597 in git > log (plus minus some). > Should I extend the script a little bit to automatically show the > discrepancies? The idea is not to extend the changelog for already released versions, but to make sure the current one is accurate. What does your script say for the relevant time period since the last release? > What about reviews? If those are important changes or bugfixes they belong in the Changelog, but trivial stuff like signal-slot normalization that are merely done by script don't need to be in the Changelog, IMHO
For 2.8 beta we have ChangeLog: 21 vs. git log : 60 If the history counts we are below the long time ratio of approx. 1:2 in ChangeLog vs. git log. On the other hand; the HACKING/commitchecklist.txt states that we should have a ChangeLog message for every commit.
(In reply to comment #7) > For 2.8 beta we have > ChangeLog: 21 vs. git log: 60 Do you really talk about *commits with BUG: 123456 tags* or *all commits*? This task is (hopefully obviously) just about commits that actually solved user-reported bugs. > If the history counts we are below the long time ratio of approx. 1:2 in > ChangeLog vs. git log. I suppose you talk about *all commits* here? (as opposed to commits that solve user-reported bugs) > On the other hand; the HACKING/commitchecklist.txt states that we should > have a ChangeLog message for every commit. Oh, that's nonsense. ;) Anybody please feel free to remove that line.
(In reply to comment #8) > (In reply to comment #7) > > For 2.8 beta we have > > ChangeLog: 21 vs. git log: 60 > > Do you really talk about *commits with BUG: 123456 tags* or *all commits*? > This task is (hopefully obviously) just about commits that actually solved > user-reported bugs. Those are lines in the logs that have BR or BUG followed by six digits. There might be counting issues when two bugs are mentioned in one line and quite old bugs with only five digits, but for a fast hack the numbers should do for now. > > > If the history counts we are below the long time ratio of approx. 1:2 in > > ChangeLog vs. git log. > > I suppose you talk about *all commits* here? (as opposed to commits that > solve user-reported bugs) Those are the numbers I mentioned before: 1329 vs. 2597 in ChangeLog vs. git log I think Myriam should just make it clear what she want's to see in the ChangeLog and we do it. On the other hand slavishly adding every fixed Bug to the ChangeLog is just information duplication and does not give additional value. A script could do that :)
(In reply to comment #9) > I think Myriam should just make it clear what she want's to see in the > ChangeLog and we do it. Agreed. > On the other hand slavishly adding every fixed Bug to the ChangeLog is just > information duplication and does not give additional value. > A script could do that :) Agreed.
(In reply to comment #10) > (In reply to comment #9) > > I think Myriam should just make it clear what she want's to see in the > > ChangeLog and we do it. > > Agreed. Hm, I think all bugfixes should be in the changelog, some are actual bug fixes, others are granted wishes and should be in the features section. I have some difficulty to see what type of bugfix (those with a clear bug report) should not be in the Changelog TBH. > > > On the other hand slavishly adding every fixed Bug to the ChangeLog is just > > information duplication and does not give additional value. > > A script could do that :) > > Agreed. Yes, so who makes that script? Tied to the BUG: hook I presume?
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > On the other hand slavishly adding every fixed Bug to the ChangeLog is just > > > information duplication and does not give additional value. > > > A script could do that :) > > > > Agreed. > > Yes, so who makes that script? Tied to the BUG: hook I presume? Me, if you give me a week or so. Basic functionality is obvious, it would go through git commits from tag v2.N to git tag v2.(N+1), scanning FEATURE: and BUG: tags. Potential problems: * where to get the human-readable description from? At least I tend to be a bit too technical in the commit summary * ChangeLog can be easily corrected once a mistake happens, commit messages cannot * FEATURE: and BUG: tags map fine, but CHANGES is not covered by any existing tag ....therefore I propose we generate ChangeLog (at least partially) from .. Bugzilla! Advantages: * bug titles should be already human-readable * mistakes can be easily corrected even after the commit * thanks to Myriam, our bug db is one of the cleanest out there * Martin Graesslin from kwin seems to already have some kind of a script to do that, see for example [1] and [2] * bugs have nice severity and priority fields, we can use these to further categorize the fixes * should promote developer use of bugzilla Disadvantages: * sometimes a non-reported bug/feature is fixed/implemented. Can we bother devs to create an extra one just to close it a minute after? * CHANGES category maps very badly to bugs. Suggestion: keep adding the CHANGES to ChangeLog, but make it clear that only *important* changes to *existing* behaviour should be mentioned, like Qt 4.6 -> 4.8 dependency update etc. I'm gonna bring this up to amarok-devel later unless Myriam says "no-go". [1] http://blog.martin-graesslin.com/blog/2013/02/this-week-in-kwin-2013-week-7/ [2] http://blog.martin-graesslin.com/blog/2013/02/this-week-in-kwin-2013-week-8/
Perfect for me :)
Should I mark this as a Junior Job?
On Tuesday 12 of August 2014 08:07:58 you wrote: > --- Comment #14 from Myriam Schweingruber <myriam@kde.org> --- > Should I mark this as a Junior Job? Please do, thanks.
An interesting discussion took place here 10 years ago. Many releases have taken place since, some with barely any ChangeLog entries at all. Closing as not relevant anymore.