On Sep 12, 2006, at 9:17 AM, Christian Theune wrote:

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.

Right, that's why none of these blocked the release just because they were old.

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.

That's fine, but they didn't block the release.

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.

Yup. I think you and I agree that this was a critical bug that should have blocked the release.

There was also a ZODB test failure on Mac OS X that I felt was critical. I spent weeks on this. In retrospect,we should have shipped Zope 3.3 using ZODB 3.6, although that too had Mac OS X problems.

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.

I don't know what this has to do with commit access. I agree that a lot of knowledge is often needed, although I worked on a lot of shallow bugs that others could have worked on.

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.

Sure.  I don't agree that the process is that complicated.

No, but it will halve the work for the small existing group of volunteers.

Only if the volunteers are qualified enough.

The volunteers we have now are obviously qualified enough. If we don't get more, we have to give them less work.

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

Sure, OTOH, it's easy to ask for clarification and to reject the issue if a clarification is not forthcoming. If we did this continually, rather than waiting until just before the release, this would be very easy.

- if decisions that need to be done are put in there immediately

Volunteers are needed to make that decision.

Sometimes it feels to me that when Stephan or you prioritize a bug that
you have a rough understanding of the solution,

You are mistaken. Stephan should speak up on his criteria, but I have the impression that it is "guilty until proven innocent". That is, I think he marks everything new as critical and relies on people working on bugs to downgrade them.

For myself, I consider the effect of the bug, not the solution. If I have an idea what the solution is, I either note it or assign it to myself.

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

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?

Or maybe it should be a 3.3.x release and we don't allow any more feature work until the collector is cleaned out. We're actually not that far from that as we did make a lot of progress during this last cycle.

I do think we should schedule 3.4 for May, not November.

And I think we need to start the beta cycle earlier. I think the beta cycle for a May release should start March 1. I really think we're already too late to make a November release.

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.

Cool, get them started now. We don't have to wait until November to get a 3,3,1 release that includes resolution of all the old bugs.

At least for Zope 3.

Right. That's what I'm taking about.

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.

Um, depends on who's doing it. It's not a big effort at all if you're not doing it.

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

OK, consider a red alert so triggered.

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?

Um, there's something wrong with this. So the more someone contributes, the more they'll be asked to contribute more?

Anyway, I have a script that I used to determine foundation committer nominees. I'd be happy to share this with anyone who wants to nag people who already contribute a lot to ask them to contribute more.

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

Isn't that what bug-fix releases are for? Why not make that the goal of 3.3.1? Or better yet, let's make this time based! Let's say that all of the bugs in the collector reported as of the final release have to be fixed in 3.3.1 one month after the final release.

- I think we want a release manager.

You're a genius!  I'll just snap my fingers.

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

+1 MakingARelease spells it out pretty clearly. There are a lot of issues here that I don't want to bring into this thread.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to