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

Re: f7 images for mass production



On Sat, Jun 09, 2007 at 08:20:24AM -0400, Jesse Keating wrote:
> On Saturday 09 June 2007 03:14:22 Axel Thimm wrote:
> > I think every golden release will start with some more or less severe
> > set of bugs which will shortly after be squashed and the updated
> > release will be far more reliable than the golden one. People talk
> > about QA, but during maintenance mode (e.g. after a release) we have a
> > couple of million users that are forced to do QA anyway, so it's not
> > the same as QA'ing a rawhide cut.
> >
> > Let me propose the following, not only for this specific release:
> > Since we have the tools (which we want to promote anyway) and since
> > every Fedora release had starter bugs that are more severe than
> > anything that creeps up during maintenance mode, let's always do an
> > official respin 3-4 weeks after a golden release. The need is there as
> > well (e.g. check with the fedora-unity guys, people want to have these
> > respins). And I'm sure there will be a lot of community testers (more
> > than during test4->GA) available if a respin is done.
> 
> How is this any different from always having a Test4, or a Test5?

It is infinitely different, test4/5/6 are per definition before the GA
and therefore are expected to break. Call it marketing, if you like,
but the fact is that people will "buy" GA and not "test5".

> Nobody is going to look at the first release because it's not good
> enough, a more tested one will always come later, and then we're in
> a vicious cycle.  It's the Red Hat Linux days all over again where
> nobody uses a .0, they wait for a .1 or a .2.

That isn't comparable at all and also not true, either. For example
the 7.0/7.1/7.2/7.3 release cycles were in total more than *two
years*, RHL had the same Halloween/May Day release targets as Fedora
has today (in fcat that's been the case since about rhl 4.2). The
7.0/... release versioning was just marketing, they could had been
called 7, 8, 9, 10 as well, just like 8.0 and 9 continued w/o minor
releases.

So it's really a different beast and the people around that remember
the 6.x/7.x days know that this was different. There were people that
hesitated to use 7.0 from 6.2 (and later anything but 7.3), but these
people are the ones running RHEL or a clone thereof today. The
"parents" of today's Fedora users jumped right onto 7.0 on day
one. Same for 8.0 and 9.

> that would mean doing another /release/ of what is in F7 + updates,
> which would mean another freeze period, another round of QA, public
> RCs, blocker bugs, etc..

Why the overcomplicated view? Where you had say 20 people looking at a
feature/bug before GA you now have 20.000. By definition you can say
that any snapshot of any F7+updates after the dust settles is already
in QA by more people than you would like.

Not to say that you don't need to look at what you collated, but it
isn't any near the excessive QA you need to do before GA. And no
freezing is needed either - you make a snapshot, which is your frozen
collection of packages, rampage on it with QA to see if there is
anything that falls out and in the worst case you either pull a later
update or do a static fix.

> And then were do we stick it on the mirrors?  7.1?  Do we do an 8.0
> then?  And an 8.1?  wait a year to do 9 so that we can do our 8.X
> releases?  Maybe we could do quarterly respins and push our release
> cycle out to 18 months, that'll be Enterprisy right?  Maybe we could
> sell subscriptions to the updates and respin service!  I sense real
> opportunity here.

Someone needs to pull you back to earth ;)

Yes, I know that's sarcasm by hyperbole, but no one implied any of the
above. This is not about changing anything in Fedora's release model.

Anyway, as Max said you're one of the people that needs to give the
go, and since this is not the case, let's wrap up the idea for F7 and
perhaps someone will pick up the idea at F8/9/10 timeframe where there
will be more confidence and experience at instant respins.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpasFQAFD4gr.pgp
Description: PGP signature


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