The slip down memory lane

[Nathaniel McCallum]

On 08/12/2010 03:08 PM, Jon Ciesla wrote:
>   On 08/12/2010 01:39 PM, Mike McGrath wrote:
>> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>>
>>>>>>>> "BN" == Bill Nottingham<notting at redhat.com>  writes:
>>> BN>  I can't help but note that the slips have become more frequent as we
>>> BN>  started to actually *have* release criteria to test against. We
>>> BN>  didn't slip nearly as much when we weren't testing it.
>>>
>>> To me this implies that we should begin testing earlier (or, perhaps,
>>> never stop testing) and treat any new failure as an event of
>>> significance.  It's tough to meet a six month cycle if we spend half of
>>> it telling people to expect everything to be broken.
>>>
>> Possibly also stop changing earlier?  It's hard to test a moving target.
>>
>> Would an 8[1] month cycle cause fewer slips per release?  Fewer bugs?
>>
>> 	-Mike
>>
>> [1] Just picked some number slightly longer then the current cycle for
>> purposes of discussion, not suggesting it.
> I think that will turn into 10 quickly.  I advocate rigorous testing, 
> and sticking as close to 6 as we can.  I mean, if we have to slip 
> because of a nasty blocker, yeah, slip, of course.  But I don't see how 
> a slip decreases the user experience.  Quite the opposite.

If slips are occasional, than this is correct.  If slips are so routine
that schedules become unpredictable, than you shift the schedules of
everyone who builds something on top of Fedora.  Doing this too much
results in decreased technical users who provide development and
testing.  The end result is decreased quality.

In short, predictable, regular releases increase quality.  Occasional
slips happen, regular slips should not.

Nathaniel