[Zope3-dev] Roadmap for Zope 3.4

[Martijn Faassen]

Jim Fulton wrote:
> 
> On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote:
[snip]
>> Anyway, if the Gnome project can do time-based releases *on the date* 
>> we should be able to do it too.
> 
> Maybe they have more volunteers.  

Yes. They also have a *lot* more to release. Their release story is also 
massively more complicated than ours. And they release, on the day they 
say they will release. It's too easy to say they do this because they 
had sufficient amounts of volunteers.

> I don't think our problem has been 
> perfectionism.  I think our problem has been a lack of will to fix 
> things in a timely manner.

> One problem we have is getting things to be tested.  It hardly motivates 
> people to test for and report bugs if their reports don't affect he 
> release.
> 
> I think we have a serious problem that needs to be addressed.  I don't 
> think the right way to address it is to release despite known serious 
> bugs.  Note that some judgement goes into considering whether a bug is 
> serious enough to block a release.  We don't block a release for just 
> any bug.

Before a release, bug triaging needs to take place. I recall you saying 
we defer bugs too often and bugs never get fixed, so we should stop 
doing any feature work until all bugs are fixed, etc. I call that 
perfectionistic.

I think we have been blocking this release with a selection of bugs that 
included quite a few that weren't absolutely critical. I would suggest 
we triage bugs a lot more aggressively instead. I say this as someone 
who spent a few afternoons staring at Zope 3 bugs trying to get them out 
of the way.

> I can think of a number of ways to approach this problem:
> 
> 1. Do less frequent releases.

I do not believe this helps a lot for bug fixes. If we have twice the 
release period, people won't start fixing bugs twice the amount of time 
in advance, and we won't get twice the volunteers either. I think the 
same amount of people will start fixing bugs the same amount of time 
before the release. You could say we get less overhead with more 
releases so people would be able to free up more time to work on the 
release, but on the other hand if a release cycle takes longer the more 
chance is that people will get out of the habit of fixing bugs.

A longer release cycle may help a bit for complicated feature work, but 
I don't think it'll help there a lot too, because if a new feature 
cannot be written and mature in the space of 6 months, it has no 
business being in the core yet anyway.

> 2. Feature freeze the trunk until the previous release has made it to 
> release candidate status

You mean don't branch the trunk (and thus let it be the release branch) 
until the release has made it to release candidate status?

+1. Keep things focused on the release during the release cycle is useful.

> 3. Release less.  I think it's time to start thinking of some sort of 
> "core" Zope 3 that we can manage with the very limited number of 
> volunteers we have now.

+1, though I wonder how much this has been blocking the release - 
important bugs that could block releases don't tend to be in out of the 
way components, one would think.

> 4. Get more volunteers.

Getting a release out is *difficult* and the amount of volunteers 
available, while important, is only partially related. More volunteers 
won't speed it up tremendously much and can even slow things down. Plone 
has many volunteers and has had much problems in the past doing timely 
releases. Silva has had far less volunteers and can do more agile 
releases, because there's less people to manage.

> These are just some ideas. But something has to give and I don't think 
> it should be responsible bug fixing prior to release.

Large Zope 3 projects have been working against 3.3 for many months now. 
If there was any absolute showstopper in Zope 3.3, why have these 
projects successfully transitioned?

Who or what would have been hurt exactly had Zope 3.3 been released in 
june? I don't think it's Zope 3's reputation that would've been hurt, as 
Zope 3.3 in june was not *that* buggy. Bugfix releases are also a 
completely accepted practice.

I still think our quality standards for a release have been too high. 
Getting people to fix more bugs is good, sure, but perhaps we should 
separate this at least somewhat from the release itself.

If we're going to do timebased releases, we should have a button 
somewhere that says 'make a release', and a date on which the button is 
pressed. If the release is botched, we can press the button again for 
bugfix releases, and we have 6 months in which to do a better job next time.

Regards,

Martijn