The slip down memory lane

Nathaniel McCallum nathaniel at natemccallum.com
Thu Aug 12 18:50:38 UTC 2010


On 08/12/2010 02: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?

I'm not sure that an increased cycle would really help.

One thing I am curious about is why, when slipping for an Alpha target,
the whole schedule slips.  Can't we just take a week out of the Beta
cycle?  The amount of testing time is roughly the same.

The other general thing is to utilize http://repos.fedorapeople.org to
get wider testing for new features before merging them.  Perhaps we
could have a 6mo release schedule but a 12mo feature schedule.  Thus, I
would propose features *now* for F15, get them conditionally accepted
and work on them in repos.fp.org (or rawhide if that is not possible).
Then, we fork F15 from F14+updates and only merge in features that have
proven stable enough for wider testing.

The only way to make schedules more predictable is to keep "trunk" from
breaking as much as possible.  Breakage should occur as much as possible
in private repos.

Just some thoughts, hope they're helpful.

Nathaniel



More information about the devel mailing list