On Tue, 2009-01-13 at 16:10 -0800, Jesse Keating wrote: > 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: > > > > > 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). OK fine. This is news that hasn't been communicated before. > > 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. Well, at least we can find some agreement here. Within a release, you absolutely have to draw a line in some places. Things that directly impact core function would be a good example. Next time people yell at you over this, let me know and I'll join your chorus of yelling back. But since we know there is always going to be an extremely high rate of change, the question remains about if core packages can be readily adapted to handle it well. So far, the example given was about the software that anaconda uses as opposed to anaconda itself. > > 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. This is a scary answer. So what you're saying here means changes to software components could potentially go out completely untested between releases. Yet at the same time, if someone has a problem, the first question almost always is, "Have you installed all of the updates?" That means the moment I run updates on a Fedora release, I have what equates to a not fully tested and certified system that isn't much better in quality than rawhide itself. At least from a software change management discipline perspective that's what I have. And I have to move to this configuration before most in the community will help. Meanwhile, the people deploying these changes have new features for the next release as a higher priority. The only saving grace is a similar priority for better and automated testing / maintainer tools exists. And all because we're going to start anew in 6 months or less. Might as well run rawhide all the time. > 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. ...Which is why you might not understand the rationale behind Fedora Unity respin effort. I disagree that the solution is to slow down the update process. The solution is to optimize a process whereby an updated respin is easy to do. I and others have already demonstrated this is closer than you may realize. And, given the previous statements about patches, the support / certification / QA arguments about respins go out the window. Just leave the "gold" media as the only officially certified, make it easy to do updated respins, and make sure people who use them understand they do so on their own. Of course, an alternate solution for speedy updates is also now apparently in the works. That would be making Presto the default mechanism. > > > > ...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. ...Ahhh, but you DID reply to it didn't you. Must have struck a nerve. Look, I admit this was in part a barb - placed there in rebuttal to other barbs where people were clearly passing the buck. The "it can't be done" argument was getting pretty old. The call for people to start looking for solutions instead of complaining how something couldn't be done is absolutely valid given the context and history of this thread. Isn't thinking outside of the box and asking how we would be able to do something how we drive innovations and new features in Fedora? The same kinds of new features and capabilities you yourself stated are a high priority? -- ==================================== "Behind every double standard lies a single hidden agenda." --G. K. Chesterton -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
