Re: Freezing for 2.18

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Sunday, March 10, 2013 5:32 PM
>  
>> At any rate, I'd like to aim for 2.18 at about the end of May, and
>> getting into serious freeze at the end of April.  A focus on bug
>> fixes, in particular bugs introduced in the 2.17 development cycle,
>> should take priority.  Fixing long-standing bugs hard to address
>> should likely be left for early 2.19 and/or be done in a branch.
>
> Why not freeze sooner?  The current state is sufficiently different
> from 2.16 to justify a new stable.

Well, I said "serious freeze" above since we really did not have any
previous discussion, but if we are being realistic, that is just code
for "I want a freeze now even though we have never talked about it
before or I'll throw a tantrum".

Ok, let me put this a bit differently: "serious freeze" for me is more
or less the point of branching off the release branch, meaning that the
unstable branch is considered and kept feature-complete with regard to
the stable branch until the first stable release can be made probably
something like three weeks afterwards.

I don't think it makes sense to do this split before there has been a
period focusing on reaching release quality.  If we split before such a
period, there will be more duplicate work and cherry-picking than
desirable for keeping a good correlation between the test results on the
stable and unstable branches.

> I'd also like to propose we adopt the same controls as we did for
> 2.16, if David is willing, since that also worked well.  That way
> we'll get a clear plan - what must be fixed, what must be documented,
> what is permitted to go into master, etc.  Otherwise we'll simply
> disagree for ever.

Well, I am not really renowned for agreeing a lot.  At any rate, I am
currently most nervous about the translate_axis changes on countdown,
but Keith has already voiced concerns about changes in behavior he wants
to analyze better.  So I don't expect this particular patch set to go
into "push" state right now but it certainly will not stay in Limbo for
long.  There are also other patches where I am in disagreement with Mike
regarding how much sense they make with regard to arriving at a
maintainable and user-accessible behavior.  Now I am not a gatekeeper
but rather a single reviewer.  I don't have any vetoing power, and it is
clear that Mike and myself are applying different metrics.

Now that's nothing new, and I usually just tried not looking closely.
Which is lazy and not helpful.  However, in the last months the
necessity for getting a release out has been increasingly on my mind and
so I tried reviewing the quality of patches based on how much I saw them
in conflict with arriving at stable code.  Now by far most of the work
in the last months has been done by Mike and myself.  It is certainly
not wrong that Mike's patches got quite more review than our usual
(appalling) level, but it also ended up in significantly impeding his
productivity.  And while we could agree on a lot of things being an
improvement (I hope), we are somewhat at an impasse regarding our
opinions and priorities.

So I'd like to get into "stable release" mode as fast as possible, to
get this conflict of interest dealt with as soon as reasonably possible,
and come to a state (namely having a new stable release), where I am no
longer tearing my hairs (and being a complete nuisance) at the prospect
of changes that will likely take half a year or longer to shake out well
and integrate into a coherent design.

-- 
David Kastrup