On Tue, 31 Oct 2006 18:07:31 -0500, Christopher Aillon wrote: > Michael Schwendt wrote: > > On Tue, 31 Oct 2006 10:29:57 -0500, Christopher Aillon wrote: > > > >> So > >> once it's approved and built, it is the package owner's discretion to > >> build a different version of a package, which may include so-called beta > >> software. > >> > > > > Yes, which is questionable and asks for adjusted guidelines. > > > wireless-tools-28-0.pre13.5.1 shipped in FC5 final because there was no > other version that would work with the shipped kernel + NM combination > and a "release" hadn't yet been made. Firefox in FC3 GOLD was shipped > as a beta (firefox-0.10.1-1.0PR1.20), as the default web browser even > when there were other web browsers which were not beta in the > distribution. NetworkManager in FC4 shipped as a beta > (NetworkManager-0.4-15.cvs20050404) because it worked better in Fedora > than the latest release. And those are just a small set of the packages > I own. Do you realise what you did here in all three examples? You tried to state the reason _why_ each pre-release was preferred over an older official release. This is very different from jumping to a new version without a comment. Never before have I asked for anything that would forbid beta releases in Fedora Extras. All I've asked for is that packagers ought to explain the rationale for choosing a pre-release (or snapshot) over an official release. Apart from that, we don't want to argue about how many of the Fedora Extras packagers are package maintainers and not just packagers. Maybe with a few polls we could analyse this a bit and get a picture of how many of the packagers believe they are familiar enough with an upstream project as to decide for their own whether a snapshot is "better" than the latest official release. We would find out that many rely on upstream decisions as well as upstream fixes. And, of course, there are counter-examples where work-in-progress code is more broken than a last official release and where even minor updates (which are advertised as "better") introduce serious regression. So, overall, you cannot avoid evaluating upstream products painstakingly. > I think this entire thread is tackling the wrong problem. It has drifted away from the original problem, unfortunately. > So, how do you address the real problem of making sure the software > isn't broken before it goes out? A single reviewer, who doesn't run any mandatory set of run-time tests, won't be able to assure that the software isn't broken. The Fedora Extras Review Process does only cover packaging issues. Reviewers (and packagers) are encouraged to evaluate the run-time readiness of the software, but none of that is mandatory. For instance, we've even had programs entering FE, which crashed immediately either during start or upon selecting popular menu items. In general, FE packages are affected by a variety of issues, which apparently have not been noticed during review and not by the package maintainer either. Just query bugzilla. This is enough reason to suggest that extra care ought to be applied when choosing "stuff that seems to work". > How about a Fedora QA/QE initiative? Would you like to expand on that? I mean, it's not the first time the words have been thrown in without any details. > Maybe build some automated tools to help. Like developing test suites for arbitrary libraries which crash when certain parts of an API are used? ;) -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
