Re: Freezing for 2.18

[Janek Warchoł]

Hi,

On Mon, Mar 11, 2013 at 3:06 PM, David Kastrup <address@hidden> wrote:
> Janek Warchoł <address@hidden> writes:
>
>> On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup <address@hidden> wrote:
>>> So I see us at a crossroads here: either we decide we want to have a
>>> stable release in a reasonable point of time in the near future, or we
>>> decide we don't want to plan for a stable release anytime soon.
>>>
>>> If we decide we want a stable release at some point in the foreseeable
>>> future, it means to stop adding destabilizing work to master and focus
>>> on stabilizing work instead.
>>
>> Agreed.  Nevertheless, stabilizing master doesn't have to mean pausing
>> "unstable" work.  I think it can be done in a branch.
>
> That's exactly what the disagreement is about.  Quoting from
> <URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/53128>:
>
>     > What's it good for with regard to the current feature set?  It
>     > does not matter how good it is going to be for future tasks for
>     > the question of whether one wants to see it in 2.18.  What ends up
>     > in 2.18 is something that people can expect to depend on in 2.20
>     > as well.  If it is preparation for future work, it is unlikely
>     > that it will stay identical once the future work is getting
>     > tackled.
>
>     I _completely_ agree with you that it is high time for 2.18.  I also
>     think it is important to not start big projects after a freeze date
>     is announced.
>
>     Given that the translate_axis patch is fresh on my and other's minds
>     (i.e. the reviewers on Rietveld, the most recent being Keith), I'd
>     rather push it in the next couple weeks and then fix any bugs in the
>     next 4-6 weeks rather than waiting.  Not only will it save time for
>     me and reviewers, but it will also help me start doing the brainwork
>     for the next big thing.  Perfect timing, for me, would be like what
>     we did for 2.16 in Waltorp.  If I know when a freeze is arriving, I
>     can coordinate my work so that, again, I can make my next large
>     change ready right after the stable release comes out.
>
> --
> David Kastrup

I don't understand what do you mean, David.  I don't quite see a
disagreement (maybe i'm reading your emails wrong).  My understanding
is that:
- you point out that we need to stop adding unstable/experimental code
to master (or whatever branch will become the 2.18 release)
- Mike doesn't want to wait with his work until 2.18 is released.

these two things don't contradict each other.  From what i understand,
Mike didn't say that he absolutely wants his patch in 2.18 - he just
wants to push it to some public, actively developed branch where other
devs will interact with it, and continue working on next thing that
depends on this one.  Similarly, you didn't say "no unstable code can
be pushed anywhere" - you said that no unstable code should be pushed
to the branch that will become the 2.18 release.  We can have two
branches and have both of you satisfied:
- accept only "stable" patches to master and continue releasing 2.17.x
from master until it will be ready to become 2.18,
- make a 2.19 branch (now, before 2.18 is out) and put all
unstable/experimental changes there (along with "stable" patches as
well).

All this requires is that developers will handle two main branches of
development.  That shouldn't be too hard.
Anyway, maybe it would be good to wait a moment until Mike explains
what he meant in his emails.  I cannot guarantee that i got his
intentions right.

best,
Janek