Re: Release process for 2.18 cancelled

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> David Kastrup Monday, March 18, 2013 8:52 AM
>> 
>> It turns out that the pent-up pressure to get forward-looking changes
>> into the master branch that have transitory user interfaces or extensive
>> changes of internals not exposed to sufficient testing is already too
>> high to permit a prerelease phase focused on arriving at stable release
>> quality.
>> 
>> So a release process of 2.18 managed by me is off.  In the current
>> situation, I don't consider it realistic that we will be able to make a
>> stable release with sufficient reliability in the next four months at
>> least, likely longer.
>
> It's a pity, but I think you're right.  But during that four months or
> longer we need to be vigilant to prevent any potentially disruptive
> changes entering master.  Encouraging or requiring developers to use
> branches for anything other than tidying up or bugfixes from now
> onwards seems desirable to me.

Well, that's presuming a process between consenting adults, but I am
afraid that's something we have to do without: it is obvious that we
have severe disagreement of what is and what is not going to lead to a
stable release.  So we need a process that is going to work out even
with severely divergent opinion about what can be made stable in due
time and what not.

The way to do that is to bind people to their predictions of what can
and cannot be achieved in a certain amount of time by agreeing on a
timeline in advance and putting in deadlines for certain kinds of
changes.

I am notoriously bad at organizing such processes, but I am even worse
at convincing people that I have a clue what I am talking about.  So if
we can't arrive at a process where people are prepared to swallow what I
(or any other single person) have to say, we have to revert to a process
letting everyone eat his own words.

That means agreeing on a policy in advance rather than making decisions
on the fly, based on the best currently available information.

Personally, I very much prefer the latter approach, but since we cannot
agree on an interpretation of the currently available information and
since the currently active set of developers is too small for arriving
at a reasonably representative decision for dictatorship (or whatever
one would want to call placing the responsibility for making some calls
into a single hand), it's the best we can do.

So probably after my climbing trip I'll prepare something akin to
Graham's GOP proposals that will spell out time frames that most
developers will feel comfortable agreeing with.  Now.

It's not my style of working, but it is obvious that my style of working
does not work in this case.

-- 
David Kastrup