On Sep 12, 2006, at 9:50 AM, Martijn Faassen wrote:

Jim Fulton wrote:
On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote:
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.
Which we do.

I know, but perhaps we need to be a bit more aggressive. Christian
Theune's point about empowerment to defer a bug may be useful. We may be
a bit too fearful sometimes to defer bugs right now.

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.
We should. We have yet to do this.  As I mentioned in another note,
we should prevent new features at the beginning of a release cycle
until we've caught up on past bugs.
Trying to address old bugs was not responsible for the delays in the
3.3 release.

I think it contributed, though fully agreed it isn't the only source of
the delay.

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.

*Ignoring* bugs is unacceptable. Explicitly deferring a bug for months is acceptable, as there are always more bugs than we can fix, and we should fix the bugs of the highest priority. A low- priority bug may therefore languish. I'm not saying we are doing this correctly *now*, but such would be a reasonable process.

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.

Good point. Going through the bugs fixed over the last period makes them seem all important to me or alternatively, lesser important bugs fixed by the reporter themselves. Perhaps a hard-headed release manager who will say "important schrimportant" and defers the issues anyway would've been useful.









None of these blocked the release.

Some issues were only discovered way after we should've done the release. We've been fixing these as part of the release process. All of these issues appear to be reported after mid-july or later, though. I think those are good bugfix release candidates, and shouldn't have been blocking our 3.3 release (not all of them are marked critical, but these all have been fixed):


Since these all were reported in july or later, we couldn't possibly have fixed them if we'd have released in june. :)

But these didn't cause us not to have a release in June. These were reported by beta testers. Why should people test betas if we aren't going to address the problems they report. If you aren't going to fix problems reported in beta releases, then you shouldn't have beta releases. If you don't have beta releases then the .0 releases are beta releases and the ,1 (hopefully) become the closest thing to final releases and we barely do those. In any case, the final release is delayed.

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

I do not believe this to be necessarily the case. The list of bugs fixed that were reported after our supposed june release is one reason why I think that. The other reason is that there'd be two times as much space between bugfixing rounds, which will make bugs languish and people get out of the habit of fixing them.

Well, if we slow down the number of features introduced, then, hopefully, the software will stabilize and there will be fewer bugs to fix.

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.


Why, do you think we should allow old bugs to languish forever?

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.

So why were these critical issues? What happened during triaging?

They weren't critical issues. There weren't on the critical path and were dealt with early in the release process. It could be argued that they slowed things down some in that, if I hadn't worked on them, I might have resolved other issues sooner. But they were legitimate bugs in stuff we were, releasing.

I think such a larger audience needs to grow organically and has fairly little to do with the bugfixing issues.

We disagree.

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.

Who is we? Why would we have been hurt?

Because the first beta release wasn't even tested by the person who made it. Critical bits were missing. If we had released it as a final release, we would have looked like fools.

Even if such a badly broken beta would've gone out (which I was not suggesting, obviously we do *some* testing), we could've done a bugfix release.

It would have been a major embarrassment. I don't know if you've noticed some recent threads, but Zope 3 has some serious credibility issues in the larger world.

We would have demonstrated pretty clearly that we don't care about

To whom?

To pretty much everyone who pays any attention to what we're doing.

What if we'd have followed up with bugfix releases?

And what makes you think we'd to that well. If we can get the first release so badly botched, what makes you think people will evenbother with later releases.

What about demonstrating we can release when we say we will?

Releasing crap on time is not acceptable to me.

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.

Let's do more bugfix releases. I don't think they can be avoided anyway.

Agreed.  Who's going to do it?  Who's going to fix the bugs?

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'm not sure what 'sorry, I agree very much' means.

"agree"? What do you mean? I clearly said "disagree"! ;)

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.

In what way?

It would destroy our credibility.

To whom?

It would be a disaster to us.


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