Fedora Extras packaging beta software into production repos, why?

[Michael Schwendt]

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? ;)