[Zope3-dev] Roadmap for Zope 3.4

Tue Sep 12 09:17:15 EDT 2006

Hi,

Jim Fulton wrote:
> 
> On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote:
> 
>> 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.
> 
> All I know is that we don't have enough volunteers.  Too few of us do
> way too much of the work,

Do we have a list of all (semi-)active committers that we might
brainwash to be a little bit more active? :)

>> I call that perfectionistic.
> 
> Then your idea of perfection and mine are far apart. Letting bugs
> languish for months or even years is not acceptable.  Ignoreing bugs
> reported during beta testing, when we get too little testing to begin
> with is unacceptable.

I agree on that. However, we have a bad history lurking in the collector
and I think we should be a bit more forgiving about not fixing old bugs
immediately (obviously they can't be that urgent) but apply more care to
the new bugs from testing periods. That narrows the area of focus a bit
and makes it easier for us to massage them.

>> I think we have been blocking this release with a selection of bugs
>> that included quite a few that weren't absolutely critical.
> 
> Name a few.

I know a few bugs that weren't important but fixed by me, because I
wanted to spend some bugfixing time but didn't find any higher priority
bugs that I could tackle.

I know that I have been delaying one fix that took me weeks because I
underestimated the effort. Probably, I should have given a heads-up on
me beeing stuck there earlier.

>>> 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've spent way more than a few afternoons.

As a contributor, you have the luck to be able to make decisions about
pretty much everything regarding the code base, where others need to
rely on comments on the mailinglist because intricate knowledge is missing.

This would mean the requirement for volunteers might need rephrasing:
We need a sufficient number of volunteers that are familiar enough with
our process and Zope to make maintenance easier for everybody.

>>> 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,
> 
> Right. This, alone is not a solution.

Me too. Seems like an agreed point.

>> and we won't get twice the volunteers either.
> 
> No, but it will halve the work for the small existing group of volunteers.

Only if the volunteers are qualified enough. On the other hand, a lot of
the bugs in the collector would be easier to fix if the

- descriptions and reproducability would be better
- if decisions that need to be done are put in there immediately

Sometimes it feels to me that when Stephan or you prioritize a bug that
you have a rough understanding of the solution, and it would be really
great if you could put in a small draft of the solution you imagine. I
think that would be helpful to bugfixers.

>>> 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?
> 
> Yes.  I think it is a shame to have to do this, but I think this is now
> necessary.
> 
> I would go further.  I would not unfreeze the trunk until until we've
> cleaned up all open bugs, either by fixing them or rejecting them.

See my statement on our bug history. This might be a large but very cool
one-time effort to get our history cleaned up. We could have one large
release that is targeted at getting rid of all open bugs. Maybe we
should do this for 3.4 and put eggification to 3.5?

I really can imaging having more gocept developers fixing a bug here and
there if we do that. Weird motivation, but it's easier to communicate.

>>> 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.
> 
> I spent a lot of time on crap that wasn't core at all.

Can't remember exactly, but I think I did too.

>>> 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.
> 
> And because it is much smaller.  I think we're far from having too many
> volunteers on Zope 3 maintenance.  I'm
> not optimistic that we'll get more volunteers, which is why I'm inclined
> to release less.

I'm with you.

>>> 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?
> 
> It all depends on how large you want the audience to Zope 3 to be.  A
> small community on a limited number of platforms can work around
> well-known problems.
> 
>> Who or what would have been hurt exactly had Zope 3.3 been released in
>> june?
> 
> Well, we would have been hurt badly as the first beta release, the one
> made at around that time was badly broken.
> 
> There were some serious bugs.
> 
> We would have demonstrated pretty clearly that we don't care about quality.
> 
>> 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.
> 
> Except that we don't do much of those and we put little effort into the
> ones we do do.

At least for Zope 3. I think Zope 2 has a good history of bugfixing
releases. And we should be able to adopt that. It doesn't seem to be a
terrible complicated and huge task to release a Zope 2 bugfix release as
Andreas is doing it all the time.

>> 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.
> 
> Sorry, I agree very much.  I'd be willing to defer to a Zope 3 release
> manager, if there was one.

I think this should trigger a *red alert*. IIRC Plone had those problems
until they had started having a rigid release manager. (Which would also
solve part of the problem of information visibility because that would
be one obvious person to talk to about process and guidance.)

>> 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.
> 
> IMO, that would be a disaster.
> 
> If we're going ti do time-based releases, we need to have a realistic
> schedule and the necessary commitment to meet that schedule.  Right now,
> we have neither.

Ack. We didn't even have a road map written down nor a set of features
we committed on.

I'm trying to summarize some of the ideas and open ends from my posting:

- What about having a list of all  (semi-)active committers so we can
  ping them and ask for their assistance?

- What about making the point in Zope 3.4 about fixing up our bug
  history?

- I think we want a release manager.

- Make it easier (or make it better understood how) to make releases.

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/12c255b7/signature.bin