Fedora Extras packaging beta software into production repos, why?

[Hans de Goede]

Michael Schwendt 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.

> 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?
 
> 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!

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

NO, we currently trust the packages todo the right thing wants a package has passed
review and in case of grave error / unfixed bugs we have the AWOL policy, that should
be enough.

> 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.
> 

Yes, so we need high quality packagers, we need to educate them, no system is 100% error free,
adding layer upon layer of procedures in practice hardly makes any difference in quality, in
many cases it actually makes things worse, since people are spending time fighting procedures
instead of fixing / improving things. Trust me on this I work for a Dutch university and
bureaucracy is killing our educational system!

And worse bureaucracy allows disfunctional teachers to hide behind it and blame all the procedures,
leaving them in place where in the old days they would have lost there jobs and be replaced with
a better teacher. We need motivated packagers with an awereness of these issues. If you put
everything in procedures, you are asking for packagers which will hide behind those procedures they
will say: "I followed the procedure for beta software so I did nothing wrong", even though there
way to bleeding edge package caused major havoc!

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

Regards,

Hans