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:
[snip]
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.
Still:
http://www.zope.org/Collectors/Zope3-dev/553
http://www.zope.org/Collectors/Zope3-dev/576
http://www.zope.org/Collectors/Zope3-dev/540
http://www.zope.org/Collectors/Zope3-dev/530
http://www.zope.org/Collectors/Zope3-dev/537
http://www.zope.org/Collectors/Zope3-dev/583
http://www.zope.org/Collectors/Zope3-dev/534
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
volunteers.
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.
-1
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
quality.
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
--
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
