[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Release Engineering Meeting Recap - 2009-05-04

On Thu, 2009-05-07 at 13:56 -0700, Jesse Keating wrote:
> > 
> > How will we measure--not assert or subjectively decide as we are
> doing 
> > here and have done in the past--whether a change we have made helps
> our 
> > releases or if time is better spent somewhere else?
> We just have to go on gut feeling, like just about everything else in
> Fedora.  We have to listen to maintainer feedback, and our QA team
> feedback and make a judgment call.  If you have better ideas, I'm all
> ears.  The message I've consistently gotten from our developers is
> less
> freeze points, and the non-blocking freeze of alpha wasn't good
> enough.
> QA has expressed that Alpha isn't really helpful too.  

From a QA perspective, I don't know if I would say that the Alpha isn't
helpful.  I do think that each milestone puts a stake in the ground and
provides project-wide focus around a shared goal that daily rawhide
doesn't demand now.

> So now we're
> talking about dropping it, both to save some downtime in F12 schedule
> and to evaluate if we really need an Alpha snapshot.

I'm uncertain as to whether removing the Alpha milestone will result in
improved quality without some thinking/planning on how we should invest
the extra time.

One thought was ... in the absence of an Alpha, QA can schedule several
test days.  However, experience shows that not all test days have the
same starting conditions.  During F10 and F11, several test days
experienced 'launch failure'.  That is, we either couldn't generate a
usable live image, or the steps required to prepare the test environment
required enough forks in the road that it became a barrier to

Another investment for QA would be to provide more data on the health of
rawhide.  This doesn't directly influence quality, but more a foot in
the door when it comes to measuring quality.

Without the Alpha, how do we entice the distro to come together?  How do
we ensure that we aren't shifting the bugs we find in an Alpha now, to
the Beta?  Should we hold the F12 beta to the same/higher/lower
standards that we hold the current Beta?


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]