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:
pgpbf4XnJyj6s.pgp
Description: PGP signature
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
