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

Re: f7 images for mass production

On Fri, 2007-06-08 at 13:02 -0400, Jesse Keating wrote:
> On Friday 08 June 2007 12:25:04 Max Spevack wrote:
> > I wanted to throw a question out to devel-list and Will Woods.
> >
> > We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs.
> >
> > I would like to know if the conventional wisdom is that we should use
> > the GOLD images, or if it is worthwhile to use an updated image (either
> > of the LiveCD or of the DVD), in order to pull in any of the updates
> > that have already been published.
> >
> I hate questions like this (:  If we don't, we'll just see more bug reports 
> and badness from the bugs we have.  If we do, we'll get slammed for our 
> release being nothing but a Beta and /this/ one is the real release (although 
> I'm sure we'll find some bugs in this one too)

Wait, I thought Fedora is one big beta!?   /me ducks...   ;-)

> I think one part of the question can be answered by the distinct lack of an 
> updated F7 kernel as of yet, at least not released.  There is 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=8282 but I haven't seen 
> any update requests come through bodhi for it.  So it's not like we know that 
> this solves the issues you'd want to say are fixed with a respin.
> Also, if we're going to respin, that's a lot more QA to toss in the mix to 
> make sure that our included fixes don't introduce regressions, and that the 
> compose processes itself was successful.  This is just more work, nothing 
> more, nothing less.  However we have limited time before Test1 is due, so 
> it's a balance we have to talk about.
> My personal opinion is that we make use of updates.img to fix any serious 
> anaconda bugs we've found.  I don't recall any /serious/ ones though, we 
> snuck those in for the last rebuild.  Adding updates.img is a simple call to 
> mkisofs, it doesn't involve pungi, or anaconda-runtime, or anything else.  
> It's just adding a file and recalling mkisofs.  Anything more (like replacing 
> packages) is far more risky.  If possible, we could have an insert into the 
> DVD sleeve with a print out of the known issues so that we give users a 
> fighting chance of working around the known issues.  There are going to be 
> updates that people download after the fact, just given the sheer number of 
> updates already available, and I really don't think we have time to suck in 
> every existing update and give that a proper qa that a final release would 
> get.  There are already 200+ megs of i386 updates, 500+megs of 
> updates-testing.  That is a /lot/ of churn to try and stabilize again.

I know it's from my vantage point as a docs-monkey, but I consider the
non-localizing release-notes bug (#241975) pretty awful.  So I'm in
favor of the updates.img fix at least, which should minimize drag on QA.
Our volunteer translators jump through hoops very quickly to get these
done timely for a release and having the work be used is a big plus. ;-)

Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
      Fedora Project:  http://fedoraproject.org/wiki/PaulWFrields
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

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]