On Tue, 2009-01-13 at 18:41 -0700, Christopher A. Williams wrote: > 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: > > > > > > 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. That's because in a typical release, anaconda doesn't change. We generally don't do updates to anaconda, for the same reasons we don't do respins. It would require a lot of effort if we were to be comfortable with updating anaconda and having it be used in respins for the purpose of installation. > > > > 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. Yes, if the maintainer chooses to push it that way. > 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. It depends on the packages, and the maintainers, but there is potential for that doomsday scenario, yes. > 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. You don't have to update every package, you could just update the package in question that you're having difficulty with. > > 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. Rawhide doesn't have an updates-testing where a wider audience than the maintainer him/herself where updates can be validated before being released to the rest of the Fedora userbase. Making better use of updates-testing is an ongoing goal, one that can improve the stability of a release and prevent rawhideish feelings of the release. > > > > 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. How have you demonstrated this? You've done a compose. That's great, that's the tiniest part of the equation. That proves little more than that the deps of the repo haven't been broken. > And, given the previous statements about > patches, the support / certification / QA arguments about respins go out > the window. Pardon? > 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. How is that not what Fedora Unity is doing? It's extremely difficult to get people to realize that something hosted on Fedora Infrastructure and called Fedora isn't something official. People having to go to Fedora Unity have a bit more concept that the respins aren't official, and if they have problems with them, they should contact the Unity folks who are doing the spins, or else retry with the official ones and file bugs if they happen both places. > > Of course, an alternate solution for speedy updates is also now > apparently in the works. That would be making Presto the default > mechanism. Presto has nothing to do with the rate of change. All it does is make it even /easier/ to push more updates more often, which means more potential to break stability in a release. Then again, I suppose with updates taking less bandwidth, one wouldn't necessarily be so eager to seek out a huge respin to download. > > > > > > ...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? *shrug* it's an entirely uninteresting problem scope to me. Others are free to work and think on it and try to come up with solutions. I haven't the time nor the interest. -- 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
