2.18 release plans (again).

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

2.18 release plans (again).

David Kastrup

Ok, after looking at the current situation and the current patches in
review/countdown, I've decided that I'll fork off the stable release
branch 2.18 after the current batch in countdown is in master.  After
that point of time, I'll only cherry-pick patches into the stable branch
after having convinces myself that they are no trouble.

What does this imply for other branches?

a) master branch

The master branch should not receive merge nuisances.  Those are, for
example, large reformattings and other cosmetic changes.  Also code
refactoring with non-trivial extent should be postponed.  No syntax
changes requiring convert-ly rules should be performed since we want to
be able to release multiple 2.17 releases while 2.18.0 has not yet been
released, without messing up the order of convert-ly changes.
Documentation changes should restrict themselves to corrections, and
those should be done _fast_ so that translators have a chance to catch
up.

b) translation branch

The translation branch will stop getting merged with master.  Some
documentation changes from master might get cherry-picked into
translation (I will do that myself), and translation will get merged
into the stable branch periodically, also by myself.  Translators are
urged to start bringing the translation branch into releasable state
_now_.  There will only be few changes from now on until the release of
2.18.

We might get one or two unstable releases before 2.18 gets out.
Personally, I'd prefer if they used numbering starting with 2.17.95 to
make it very clear to people that we are in the final stages of shaping
2.18 up and that any release-relevant testing, reports, and fixes have
to come in _fast_.

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: 2.18 release plans (again).

Jean-Charles MALAHIEUDE
Le 22/10/2013 20:06, David Kastrup disait :

>
> Ok, after looking at the current situation and the current patches in
> review/countdown, I've decided that I'll fork off the stable release
> branch 2.18 after the current batch in countdown is in master.  After
> that point of time, I'll only cherry-pick patches into the stable branch
> after having convinces myself that they are no trouble.
>
> What does this imply for other branches?
>
> a) master branch
>
> The master branch should not receive merge nuisances.  […]
> Documentation changes should restrict themselves to corrections, and
> those should be done _fast_ so that translators have a chance to catch
> up.
>

OK with me

> b) translation branch
>
> The translation branch will stop getting merged with master.  Some
> documentation changes from master might get cherry-picked into
> translation (I will do that myself), and translation will get merged
> into the stable branch periodically, also by myself.

Since nothing has changed on "translation" since Monday (too many other
things to deal with), I just merged _locally_ "master" into it. Would
you mind me pushing this before setting the freeze?

Cheers,
Jean-Charles




Reply | Threaded
Open this post in threaded view
|

Re: 2.18 release plans (again).

David Kastrup
Jean-Charles Malahieude <[hidden email]> writes:

> Le 22/10/2013 20:06, David Kastrup disait :
>
>> b) translation branch
>>
>> The translation branch will stop getting merged with master.  Some
>> documentation changes from master might get cherry-picked into
>> translation (I will do that myself), and translation will get merged
>> into the stable branch periodically, also by myself.
>
> Since nothing has changed on "translation" since Monday (too many
> other things to deal with), I just merged _locally_ "master" into
> it. Would you mind me pushing this before setting the freeze?

Yes, that's fine.  It would save me the work.

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: 2.18 release plans (again).

Jean-Charles MALAHIEUDE
Le 26/10/2013 19:17, David Kastrup disait :
> Jean-Charles Malahieude <[hidden email]> writes:
>>
>> Since nothing has changed on "translation" since Monday (too many
>> other things to deal with), I just merged _locally_ "master" into
>> it. Would you mind me pushing this before setting the freeze?
>
> Yes, that's fine.  It would save me the work.
>

Done and pushed.

By the way, I'll send an updated lilypond.pot (as of latest devel
version) to the FTP.

Cheers,
Jean-Charles


Reply | Threaded
Open this post in threaded view
|

Re: 2.18 release plans (again).

David Kastrup
In reply to this post by David Kastrup
David Kastrup <[hidden email]> writes:

> Jean-Charles Malahieude <[hidden email]> writes:
>
>> Le 22/10/2013 20:06, David Kastrup disait :
>>
>>> b) translation branch
>>>
>>> The translation branch will stop getting merged with master.  Some
>>> documentation changes from master might get cherry-picked into
>>> translation (I will do that myself), and translation will get merged
>>> into the stable branch periodically, also by myself.
>>
>> Since nothing has changed on "translation" since Monday (too many
>> other things to deal with), I just merged _locally_ "master" into
>> it. Would you mind me pushing this before setting the freeze?
>
> Yes, that's fine.  It would save me the work.

Oh, that's what you meant with "merge".  A fast forward.  That would
have been the work of about 5 seconds it saved me.  Looks like I did not
think about what "nothing has changed" meant.

Wel, at least I don't need to think about it right now.  I'll take a
look at current countdowns and reviews, but I'll probably go ahead
soonish, possibly pushing trivial stuff previously.

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: 2.18 release plans (again).

Francisco Vila
2013/10/26 David Kastrup <[hidden email]>:
> David Kastrup <[hidden email]> writes:
>>>> b) translation branch
>>>>
>>>> The translation branch will stop getting merged with master.  Some
>>>> documentation changes from master might get cherry-picked into
>>>> translation (I will do that myself), and translation will get merged
>>>> into the stable branch periodically, also by myself.

I missed this. Well, I didn't actually miss it but starred it and then
forgot about it. Sorry!
I'm fine with the plan. Last time I looked at, my folder was in a
releasable state. Will take another look to be sure and make it to be
if not.

--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: 2.18 release plans (again).

David Kastrup
Francisco Vila <[hidden email]> writes:

> 2013/10/26 David Kastrup <[hidden email]>:
>> David Kastrup <[hidden email]> writes:
>>>>> b) translation branch
>>>>>
>>>>> The translation branch will stop getting merged with master.  Some
>>>>> documentation changes from master might get cherry-picked into
>>>>> translation (I will do that myself), and translation will get merged
>>>>> into the stable branch periodically, also by myself.
>
> I missed this. Well, I didn't actually miss it but starred it and then
> forgot about it. Sorry!
> I'm fine with the plan. Last time I looked at, my folder was in a
> releasable state. Will take another look to be sure and make it to be
> if not.

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, done enough for today.  Heck, I even worked on issue 34...  But that
one's unlikely to reach 2.18.

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: 2.18 release plans (again).

David Kastrup
Janek Warchoł <[hidden email]> writes:

> 2013/10/26 David Kastrup <[hidden email]>:
>> 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).

Anything requiring extensive documentation changes (except the
English-only CG) will be a nuisance when translation is moved back to
master.  Extensive changes (like replacing data types with something
else in a non-blackbox manner or refactoring modules/files) are also not
commendable.

There is a lot that would be desirable in the course of finishing the
release: proofreading the manual for accuracy, going through all the
Fixed_2_17_* tags and checking that all major important features and
changes are covered in Documentation/changes.tely.

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: 2.18 release plans (again).

David Kastrup
Janek Warchoł <[hidden email]> writes:

> 2013/10/27 David Kastrup <[hidden email]>:
>> Janek Warchoł <[hidden email]> writes:
>>
>>> 2013/10/26 David Kastrup <[hidden email]>:
>>>> 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