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

Re: [RFC] Anaconda Maintenance Releases



On Tue, Nov 09, 2010 at 04:50:32PM -0500, Chris Lumens wrote:
> > A problem that we are running into more often with the livecd and spins
> > projects is that after a release things can break due to anaconda being
> > frozen and the packages it depends on moving on.
> 
> I am not quite so enthusiastic about these proposals, seeing as how
> often they have come and gone.  The previous attempt was to do some
> limited maintainence by Fedora Unity, but I haven't seen anything happen
> there for quite a while now.
> 
> But if you are more enthusiastic, maybe there is hope.

I think it is necessary given both the increasing dependence on other
packages in Anaconda and the emphasis on LiveCD and Spins.

> 
> > eg. NetworkManager or udev changes something, and since Anaconda isn't
> > updated after the release it breaks for people trying to spin new,
> > updated media. rhbz#624028 is one example of this. I expect it to become
> > more of a problem as we move forward.
> 
> For some of these changes, I think the fix is to stop throwing crud into
> updates that breaks the release.  But then, no one wants to hear that.

I agree, but I don't see that happening.

> 
> > They
> > would field bugs related to Anaconda and changes in dependent packages.
> 
> Are you interested in fixes that allow rebuilds to continue, or also
> fixes to handle anaconda bugs?  By that I mean, does a partitioning bug
> get fixed in an update or not?  If so, you need established criteria for
> what patches are eligible.  Otherwise you are going to have people
> clamoring for every little thing.
> 
> Perhaps being listed as a CommonBug is a good bar to meet, assuming
> you'd even want to take these sorts of patches.  Also, being on master
> first would be good.

I think limiting the changes is the key to making this successful.
Existing fixes or community patches would make sure that we aren't
spending a bunch of time dealing with the old versions. CommonBugs I'm
not so sure about, unless there is an exist patch.

> 
> > The goal would be to make the minimum amount of change needed to
> > maintain creation of the official media using the base+updates repos and
> > the official kickstart files.
> 
> I think this answers a bit of what I was getting at on the previous
> point.  Still, I think people are going to want other fixes included so
> we should either think that through or come up with why we're saying no.
> 
> > Hopefully the changes would amount to cherry-picking fixes/changes from
> > a newer release or from master and applying it.
> 
> I think you'll find the cherry-picking gets more difficult over time as
> master diverges from fXX-branch.
> 

That's very true. My hope, which is likely overly optimistic, is that
the fixes will usually come from the next release's branch.

> > Given the popularity of LiveCD's and Spins I think this is a reasonable
> > change to how things are being done right now. And I volunteer myself as
> > the Anaconda maintenance manager.
> 
> What happens when you get sick of it?

I rope someone else into doing it, or it dies. Hopefully it has a high
enough effort to value ratio that someone else will be willing to take
it over.

> 
> Also, how do we test this?  Can we rely on the existing updates testing
> procedure?

Tested by using the official kickstart files with the official base and
update repo. I don't want to spend time chasing errors in non-standard
kickstarts or user's repositories. Success is if the generted iso boots
and can be used to do an install.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

Attachment: pgpQ0r0Z37Fs2.pgp
Description: PGP signature


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