[Zope3-dev] Roadmap for Zope 3.4

[Jim Fulton]

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:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org