Re: [translations] Re: 2.18 release plans (again).

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> 2013/10/27 David Kastrup <address@hidden>:
>> Janek Warchoł <address@hidden> writes:
>>
>>> 2013/10/26 David Kastrup <address@hidden>:
>>>> I've now pushed stable/2.18 and synchronized translations to it.
>>>> I hereby declare the stable/2.18 branch my sole property, to be ruled
>>>> over dictatorially.  As long as nobody else pushes to it without my
>>>> permission, I pledge to keep and lead it to releasable state to the best
>>>> of my conscience and abilities.  Translations may merge from it (and
>>>> should not be merged from master until stated otherwise).
>>>
>>> Ok, thanks!
>>> So, we can slowly get back to discussing unstable material unless it's
>>> not very disruptive, or would you like us to wait a moment?
>>
>> Discussion is never a problem.  Anything requiring convert-ly changes is
>> on hold to master for practical reasons (version number monotonicity).
>
> So, would it be possible to get issue 3239 reviewed?  It's waiting for
> half a year, and solving merge conflicts when i rebase it gets
> irritating.

I don't tell people what they are supposed to review.

> It's a rewrite of Self_alignment_interface, making it easier to align
> grobs in various ways.  I think that it's self-contained, shouldn't
> introduce regressions (as it doesn't change the logic of calculating
> alignment) and it can be written in a way that doesn't require
> convert-ly.

>From what I remember from the time we tested it, it changed enough
things invasively enough (and "shouldn't introduce regressions" was not
quite convincing) that it does not make sense committing it now.  You
say yourself that it gives you a sizeable number of merge conflicts, and
naturally a commensurate number of merge conflicts would be caused when
master and stable diverge by including it before stable has really
stabilized and cherry-picks become infrequent.

It will also mean that problems in the version of
Self_alignment_interface in stable may not be visible in master.

> And a few other issues depend on it, as you can see.
> http://code.google.com/p/lilypond/issues/detail?id=3239 (please don't
> look at the tracker description, it's outdated and i cannot change
> it. Look at the Rietveld description
> https://codereview.appspot.com/7768043/ or commit messages).
>
> Note that i don't ask you to review it *now* - i just want to know if
> there is a possibility of getting it reviewed soon.

I don't tell people what they are supposed to review.  If by "review"
you actually mean "committed", then the answer right now is "no".  Not
before 2.18.0 is out, certainly, and preferably not for a while after
that so that the bugs uncovered after 2.18.0 is out have a chance to get
addressed in master in a manner where it is reasonably doable to
cherry-pick them into the stable branch.

> If so, i'd first review it myself, but if it won't get reviewed for
> another 3 months, there'd be no point in me wasting time for working
> on it.

It's pretty safe to say that I would not be happy if it were _committed_
in the next month.  After that, it gets more fuzzy.  With regard to
reviews, the same rules about keeping master as rebaseable as possible
for a while also apply to other contributions, so if you rebase now,
chances are that not much of a further rebase will be needed by the time
including it makes sense.

-- 
David Kastrup