Fedora Extras packaging beta software into production repos, why?

[Michael Schwendt]

On Sat, 28 Oct 2006 22:54:41 +0200, Gianluca Sforna wrote:

> > Theoretically, the maintainers of the packages know best as to how
> > stable the software they are packaging is, what the timeline for said
> > beta is to reach production, etc.  If another maintainer questions this,
> > then open a bug report against the package explaining 
>
> I agree. It's not FESCO's call to decide if a given package is OK even if beta.

Almost funny, given that we don't do any mandatory run-time testing during
the review process.

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?

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?

> > That being said, my personal opinion is that "beta" or pre-release
> > packages should only be done in the devel branch, and only if that beta
> > has a really good chance of becoming an actual release before the devel
> > branch is forked for the next Extras release.
> 
> This seems sane, and IMHO could be formalized in the packaging
> guidelines, at least as a SHOULD item.

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.

This ought to be part of the approval process and also be required during
package maintenance.

It would not be the first time somebody wanted to package a beta release
way too early and without good reason. One example from the top of my head
is Audacity. It even segfaulted reproducibly when built without mp3
support.

Back in time, where did most repository mixing problems come from?
Correct. Not just from providing the same packages in different
repositories. Packaging conflicting ABIs and APIs lead to the most repo
mixing problems.

> Axel made clear he was not seeking for any kind of "preference" for
> its own repo.
> 
> However, he raised another interesting topic, stating that he felt the
> package was "blitz reviewed":

Do you disagree? I don't. Less than 24 hours between a sudden upgrade
to a beta version and its approval. Plus the worst fact: The other
packages in the dependency-chain are not ready yet.