On Fri, 2009-01-02 at 22:01 -0700, Christopher A. Williams wrote: > On Fri, 2009-01-02 at 14:05 -0800, Jesse Keating wrote: > > > Do you really not have any idea how much work gets put into the snapshot > > releases? Let alone something that wouldn't be "snapshot, if it breaks, > > you keep the pieces" quality, but instead something high enough quality > > to put the Fedora name and official release stamp on it. > > > > You seriously seriously underestimate the amount of work that goes into > > these things, particularly the QA side. > > > > Lets not even talk about how many of the tools that Anaconda uses to > > install systems change within a release enough to require modifications > > to Anaconda to work with the new versions. > > > > There is a good reason why the "Fedora Project" doesn't spend time on > > respins. 6 months is a very short cycle between major releases, > > especially when you consider all the developmental releases done from > > Rawhide. Adding more compose targets to that mix greatly stretches the > > already small handful of volunteers and employees who spend their time > > trying to make these things show up, try to improve the software used > > for making them, and try to improve the software used for building and > > testing Fedora. > > OK - So if that's true, they why did the Fedora Project make such a > hoopla about being able to do custom spins and respins in the first > place? You can't have this both ways. Custom spins is what we were advertising, taking the GOLD package set and mixing it up in different ways to accomplish different goals. This doesn't include adding newer versions of software that is very much not tested in this scenario (ie the install environment). > > This sounds like more excuses to cover for that we haven't really gone > back and looked into what it would take to optimize a set of very > important processes so people don't have to be overworked in the first > place. > > Why are we not questioning Anaconda as something that isn't capable of > handling the current and likely to accelerate rate of change? We do question the various pieces of software that anaconda uses very time they change. ABI/API changes happen, sometimes more frequently than we'd like, especially when they happen in a "stable" release tree. I've brought this up many times and I always get yelled at for trying to stifle Fedora's freedom to change things in a stable release. Fedora maintainers/users can't have it both ways either. > Why is the testing procedure so complex and daunting? And if it's such a > big deal, why then are updates that come out post-spin NOT considered to > be in need of the same degree of testing? After all, they get the > official Fedora Project seal of quality too. The updates get as much testing as the community of users for those packages provide. Some get a lot, some get none. Fedora is what the maintainers and users make of it. Hardly any of this testing covers usage of that software in the scenario of the anaconda environment, that's just not a use case that many of us aren't really interested in outside of rawhide preparing for the next release. We'd rather be working on new features, infrastructure for automated testing, faster compose tools, better maintainer tools, etc... instead of spending our time worrying about updated spins of a distribution that will only be the "newest" for 6 short months. > > Just to check it out, I just reloaded a system with a fresh copy of > 32-bit F10 Live from the CD. This is an older system that was running > F8, but it has 1GB RAM and a 2.4GHz Pentium processor. Time to install, > including updates and not including adding any additional packages, was > just over 2 hours, and more than half of that time was devoted to > downloading and installing the updates. Adding the extra custom packages > after the updates is faster than installing everything I need from DVD > and then running updates on all of it. I'd be here all night. Instead, I > can queue up the extra packages I want from Yum Extender and let it run > all night. > > ...And that, by the way, is exactly why this is an issue many people > have. > > If this is too hard, change review and optimize the process and improve > the tools - and do it before we add even more features and complexity to > Fedora lest the problem get even bigger. I don't see how respinning an updated install tree really helps. No matter how late you get on the Fedora train, for these people the updates will be too fast and too numerous. The only way to fix that is to slow down the updates, and well I wish you good luck in convincing the Fedora contributors at large to agree to that one. > > ...And please stop it with the "Let Fedora Unity" do it tripe. Unless > and until Fedora Unity is an officially sanctioned and supported part of > the Fedora Project, this is the Fedora Project's issue. Fedora Unity is > doing the Fedora Project a favor by trying to help solve a problem that > the Fedora Project, to date, has only made excuses about as opposed to > thinking outside of the box and looking for solutions. > This is not even worth replying to. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
