Fedora Extras packaging beta software into production repos, why?

[Michael Schwendt]

On Sun, 29 Oct 2006 08:37:06 +0100, Hans de Goede wrote:

> > It's not that easy to say "packagers know best". If that were the case, we
> > could kill the reviewing. The question is whether we want to open the
> > flood-gates by setting precedence and letting in many other pre-release
> > versions, effectively moving closer to the bleeding edge?
> 
> Sure it is that easy, because the packager should now best, can we please
> leave some (plenty of room actually) in all our procedures for the packagers
> discretion. Sometimes a beta release is better, because for example it fixes
> a few big bugs in the latest stable, but upstream wants to fix a last bug (which
> is also in the latest stable) before releasing a new stable.
> 
> I've even had BZ requests requesting an update to the beta. Or the beta is the only
> version which works with the latest stable version of libfoo, where as the latest stable
> requires an older version of libfoo which isn't in core/extras.

Splitting-hairs. Can we please leave corner-cases out of this?
We are interested in the _general guidelines_, NOT in corner-cases.

When you see me using the plural instead of the singular this still is
because _we_ at the Fedora Extras project should have many common
interests. And not landing in guinea-pig hell (and API/ABI breakage hell)
because of too many pre-release packages should be one of our interest.

[Sure, with some upstream projects you can often check out a product from
VCS which is nothing else than last stable release plus a few minor fixes
applied on the road to a future stable update. I've been there before,
too.  I've even skipped a new stable release, because my package including
various patches offered exactly the same than another stable release,
except for the increase minor version.]

> > When some people ask whether anything is wrong with a beta, it is equally
> > valid to ask what's wrong with the last official stable release? Where are
> > the answers to both questions?
> > 
> 
> Exactly who says that the beta has more bugs / problems then the latest stable, since its
> newer its supposed to be an improvement, this can be in features but also in bugcount.
> 
> For example I would expect a 1.0.1 RC to be better then 1.0.0 for most products, so which
> do I package?

In general? Stick to 1.0.0 unless you give good reason as why the RC is
superior.

It depends on the size and contents of the diff between 1.0.0 and 1.0.1 RC
and also depends on the reasons why upstream finds it necessary to publish
the code as a RC instead of simply declaring it gold.

> > I'd rather be more rigorous and require packagers and reviewers to explain
> > why a pre-release version or VCS snapshot is preferred over a stable
> > release.
> > 
> 
> During initial review sure!

Aha. Can this be counted as a  +1  then? ;)

After approval the reviewing is not over. The package maintainer becomes
the primary reviewer, often the only reviewer until a package is built and
users start testing it. 

This must not mean that a stable release is used to pass the review
process only to upgrade to a beta afterwards without giving good
reason. Right?

> Its quite simple: motivated and educated packagers good, bureaucracy bad!

Motivation is a rather vague term here. Too much "wrong motivation" can
easily lead to over-ambitious packaging and then is bad, too.