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
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?
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
history?
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
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
