Michael Schwendt wrote: > 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. > General guidelines are easy, corner cases are the problem and thus must be discussed! I've no problem with general guidelines as long as there is room for exceptions in those guidelines, and package owners are trusted to judge when such an exception is necessary. IOW I don't want to have to ask permission if I find such an exception necessary (for wathever reason). If people dislike my decision they can file a bug and if my reponse isn't good they can start complaining on the mailinglist. If I get lots of complaints and don't want to change may ways my CVS access may be pulled. That is enough of a mechanism which works well. We don't need tons and tons and tons of rules and procedures! > 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. > Yes we do have many common interest that is why we are a group, perhaps even a team. And this all starts with trusting fellow team members, and trust is something which, excuse me for saying so, you seem to have a serious lack of! >>> 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? ;) > For an initial review yes, also usually packages which tend to need a beta / CVS already do so when reviewed, the need for a beta happening later is rare. > 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. > ?? The review is over, sure the package maintainer has to stick to the guidelines and do its best not to introduce any (packaging) errors, but there is no formal review anymore. Going of topic I always run rpmlint before the final commit and make tag build, perhaps we can make running rpmlint part of Makefile.common so that say "make x86_64" will run rpmlint on the resulting rpms? > 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? > That depends on the afterwards, 2 days later no that is seriously abusing the process, but 6 months later if the packager finds he has a good reason yes, once again we have to trust each other! >> 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. > Once again this all boils down to trust, and we can't trust each other we might as well stop FE right here and now! Regards, Hans -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
