On May 7, 2013, at 8:56 PM, Bartosz Dziewoński matma@gmail.com wrote:
On Tue, 07 May 2013 20:51:07 +0200, Krinkle krinklem...@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),
On Wed, 08 May 2013 19:24:48 +0200, Krinkle krinklem...@gmail.com wrote:
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.
You're either not reading what I wrote or intentionally pulling
On Mon, May 6, 2013 at 10:09 PM, Krinkle krinklem...@gmail.com wrote:
On May 3, 2013, at 9:33 PM, Anomie wrote:
Taking a recent example[1], please tell me how to compress the
following into 62 characters:
(in the New features section)
* (bug 45535) introduced the new 'LanguageLinks' hook
On 7 May 2013 08:52, Brad Jorsch bjor...@wikimedia.org wrote:
Oh, so not mentioning the breaking API change at all? Definitely not good.
I think you're missing the bit of Timo's proposal where all breaking
changes have to *additionally* have a Breaking change: Foo bar baz in the
Breaking
On May 7, 2013, at 5:52 PM, Brad Jorsch bjor...@wikimedia.org wrote:
On Mon, May 6, 2013 at 10:09 PM, Krinkle krinklem...@gmail.com wrote:
On May 3, 2013, at 9:33 PM, Anomie wrote:
Taking a recent example[1], please tell me how to compress the
following into 62 characters:
(in the New
On Tue, 07 May 2013 20:51:07 +0200, Krinkle krinklem...@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
On Tue, May 7, 2013 at 2:56 PM, Bartosz Dziewoński matma@gmail.com wrote:
On Tue, 07 May 2013 20:51:07 +0200, Krinkle krinklem...@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),
On Tue, 07 May 2013 21:00:05 +0200, Chad innocentkil...@gmail.com wrote:
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.
As I said many times before, this
On Tue, May 7, 2013 at 3:07 PM, Bartosz Dziewoński matma@gmail.com wrote:
On Tue, 07 May 2013 21:00:05 +0200, Chad innocentkil...@gmail.com wrote:
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
On May 3, 2013, at 9:33 PM, Anomie wrote:
On Fri, May 3, 2013 at 1:02 PM, Krinkle wrote:
First of all, I think a lot of our commit subjects are poorly written,
even for a commit message. Having said that, a good commit subject is
also a good release note (that is, if the change itself is
On May 2, 2013, at 7:41 PM, Brad Jorsch bjor...@wikimedia.org wrote:
I like the idea of not having to mess with RELEASE-NOTES-#.## merge
conflicts. But I'm not entirely sure about everything in the proposal.
On Thu, May 2, 2013 at 12:30 PM, Krinkle krinklem...@gmail.com wrote:
For more
On Fri, May 3, 2013 at 1:02 PM, Krinkle krinklem...@gmail.com wrote:
First of all, I think a lot of our commit subjects are poorly written,
even for a commit message. Having said that, a good commit subject is
also a good release note (that is, if the change itself is notable for
release
Hi all,
Our current release note strategy is clearly not working.
Too many times do people omit it. Either because they consider the
commit not important enough for release notes or because it is a pain
to do due to the continuous merge conflicts. Not to mention fix-ups
and small clarifications
I like the idea of not having to mess with RELEASE-NOTES-#.## merge
conflicts. But I'm not entirely sure about everything in the proposal.
On Thu, May 2, 2013 at 12:30 PM, Krinkle krinklem...@gmail.com wrote:
For more details see Proposal 2 on this page:
14 matches
Mail list logo
