On May 7, 2013, at 8:56 PM, Bartosz DziewoĆski <matma.rex(a)gmail.com> wrote:
On Tue, 07 May 2013 20:51:07 +0200, Krinkle
<krinklemail(a)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