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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
