Re: Freezing for 2.18

[David Kastrup]

address@hidden writes:

> On 10 mars 2013, at 18:54, David Kastrup <address@hidden> wrote:
>
>> "address@hidden" <address@hidden> writes:
>> 
>>> On 10 mars 2013, at 18:32, David Kastrup <address@hidden> wrote:
>>> 
>>>   Ok folks, it is this time of the year again: I am trying to make
>>>   myself
>>>   unpopular.
>>> 
>>> There's a time of the year for that?
>>> 
>>>   It also means that commits of the "this really does nothing, but
>>>   it prepares the ground for $xxx, and I don't know just where this
>>>   is going, so quite a bit of it might be changed into something
>>>   different yet" should happen in a branch. Actually, I am of the
>>>   opinion that most of these changes should happen in a branch
>>>   anyway. A "commit" implies commitment, and if one has taken a bad
>>>   path, redoing it is much harder if the dead end has already ended
>>>   in the main code base.
>>> 
>>> As the world champion of this style of coding, I can conclusively say
>>> that I have no problem freezing all my experiments except the large
>>> translate_axis call patch, as I am sure that I know where its going
>>> and I almost have it wrapped up after many rounds of revision and
>>> review.
>> 
>> 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.

Mike, a bit more realism would be nice.  We have not yet fixed all the
bugs from the skyline patches in 2.17.  And we won't fix all of the
until 2.18, but we got a good amount of them under control, and we have
a balance of benefits and problems that is reasonable.  You have not
addressed at _all_ my paragraph above.  So I repeat:

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.

> Not only will it save time for me and reviewers,

Sure, it saves time not to permit anything to stabilize.  But it does
not help with getting a stable release out ever.  At some point of time
we need to ask ourselves the question "will it help with getting 2.18
into sound shape in a timely manner?" and if the answer is "no", then it
does not go into 2.18.  It either goes into a branch, or the developers
focus on 2.18 work instead and return to it afterwards.

> but it will also help me start doing the brainwork for the next big
> thing.

The next big thing is the release of 2.18.  2.18 is _not_ where we want
to start off the next destabilizing work period: that is 2.19.

> 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.
>
> So, to resume, I agree that a freeze is important.  When the freeze
> kicks in, I'd rather that we say something like "no new big projects
> starting on date X will be part of 2.18" so that developers can plan
> out their next few months accordingly.


-- 
David Kastrup