[Zope3-dev] Roadmap for Zope 3.4

[Christian Theune]

Morning,

Martijn Faassen wrote:
>> 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.

Ack. One thing that bothers me (and it's totally possible that I'm
missing some documentation from zope.org) is that the overall process
isn't well documented, so it's hard for me (and probably other people)
to jump in and do stuff.

Right now I *feel* like only Stephan and Jim know how to triage bugs and
that I'll do something that won't be right. I probably could just go
forward, but I have a bad feeling about my knowledge about the process,
and I don't want to feel bad, so I don't do it. (Which makes me feel
just slightly bad because I didn't do anything. ;) )

>> 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.

I agree on this reasoning.

>> 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.

Right. In addition to that, I'd love to have a single "status" page (a
bit like Mozilla has) that says:

- Zope 3.2 is in maintenance mode, please make sure bugs are ported
  to this release.
- Zope 3.3 is in release mode (beta).
  Please fix bugs until XXX. No features allowed.
- The trunk is frozen.

(Or whatever information is appropriate at a given point in time)

>> 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.

Jup. And I share the hopes that eggification will make that easier.
Together with this, I think that our roadmap should layout not only the
dates when releases happen, but what we *think* will be part of the
feature set.

I'm very split about doing releases on a timely manner without any
features in it. There seems no point.

On the other side I do agree to favor smaller releases instead of
extending the feature develepment period.

E.g. does it make any sense to release Zope 3.4 without the
eggification? It seems to be the only major feature except from bug
fixes, minor features and restructuring.

>> 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.

We had a product that absolutely didn't work with the *release* of 3.2
beta 1 and I think a couple of bug fixes were needed too. *But*: We
could have had a 3.3.1 by now which would have enabled our product to
function.

> 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.

+100 for the button. (A huge wiki page on how to do a release does *not*
account for a button)

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20060912/d057fe4f/signature-0001.bin