On May 7, 2013, at 8:56 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Tue, 07 May 2013 20:51:07 +0200, Krinkle krinklemail@gmail.com wrote:
It is the duty of repository co-owners to make wise decisions beyond just code quality. About what changes go in what release (if at all), whether the introduced features are in the best interest of the users and that we can maintain them and are willing to support them. And to be aware of whether a change is breaking or not, and if so if whether the change should still go in the current release or a the next (e.g. don't remove/break without deprecation first, if possible).
So in other words, this puts more burden on reviewers, making it harder to get changes merged, especially for new users?
Because that's what this sounds like. Changes are already rotting in gerrit for a year (see the recent watchlist thread), and this certainly will not help.
The current process for release notes is fine; we just need someone to write a custom merge driver for JGit to avoid the merge conflicts. This is a technical issue, not a policy one.
How does this make anything harder for new users? If anything, it makes it easier by not having to worry about which file to edit, what to put in it etc.
As for more burden on reviewers, I disagree. It might inspire them to give more care to proper commit subjects (and edit them liberally as needed) because if you leave it in bad shape, it needs to be fixed later in the notes.
And here again, it simplifies things by maintaining release notes centrally and away from inside the tight development loop. Some of the same people will be doing both, but in the right frame of mind, instead of when you don't want to.
The current process for release notes is not fine. It hasn't been fine for at least 2 or 3 releases. It is missing a lot, and what's there is (imho) poor quality (my own notes included).
Improving that doesn't require moving the process, but I think this is an opportunity to fix a mess the right way at once.
-- Krinkle