On Fri, 2006-07-14 at 21:53 +0200, Nicolas Mailhot wrote: > Le vendredi 14 juillet 2006 à 12:22 -0700, Toshio Kuratomi a écrit : > > On Fri, 2006-07-14 at 20:21 +0200, Nicolas Mailhot wrote: > > > and > > > all the posts about technicalities vs æsthetics would have make all this > > > clean. > > > > > > > If interleaving is not a goal, then I don't see a reason to change the > > guidelines. > > Then ask Fernando if he needs interleaving. > ...and gbenson and Tom Fitzsimmons and... Some people interleave upstream rpm with the distro. That doesn't make it the right choice for Red Hat to support that. The java team as a whole needs to make this decision and tell us, "Interleaving with jpackage is important to us. Please ratify a naming scheme that allows that." or "Interleaving causes the same problems here as elsewhere. We don't support it." That's why lutter is emailing the java team. > > > (and BTW these people don't _need_ the guidelines, they were doing > > > inter-repo multi-package-updater updates when Fedora Core was still > > > thinking "the next anaconda run will clean it all") > > > > _We_ need the guidelines. Look at the proliferation of ways that > > snapshot dates are added to the release field in jpackage. Now imagine > > how many new packagers and package reviewers are going to build packages > > that break the upgrade path if we allow all of that into naming. > > Sure; JPackage releases use lots of "dangerous" constructs because they > have experienced packages who won't abuse them to the point things > break, but this is not the case in Extras. So it's be probably safer is > JPP changed its own releases to pure FC conventions (I mean upstream > release before they're stacked and interleaved at Fedora). But you need > to realise it's a lot of work for them with zero technical benefit, and > there are many nicer ways to ask than make them some sort of scapegoat > Yep. That's why I emphasized "We". Most of what I wrote was written with the status quo in mind. If JPackage is willing to change their guidelines it could make things easier. If a flaw in the Naming Guidelines is discovered we'd have to discuss it here and with JPackage to get it changed... probably not a big deal as (Hopefully) we'd only have small changes that concerned corener cases from now on. > > > > It's also bad for a reviewer when we have two different sets of > > guidelines for naming. If this is a JPackage derived package, you have > > to check that NEVR fits into the JPackage rules for naming followed by a > > proper Fedora Named tag. Otherwise use the Fedora Naming Guidelines to > > decide if NEVR is correct. > > In this particular case it's more release = jpp release + fedora > release, but Fedora has clearly a voice on what jpp release is, if only > via all the fc packagers which are also jpp members. > > However when the fedora jpp members explain to their mandrake or suse > friends what changes need to be made, they need better arguments than > "because" > That's a given. We have to explain to the rest of Extras why we make changes to the present rules as well. > > Or do we just assume that jpackage has always caught bad naming? So > > we're left holding the bag when something goes wrong? > > (cryptix-asn1-20011119) > > I think this one is already fixed in JPP 1.7 and 5.0. > But anyway: no you're not left holding the bag, you report the problem > either to the fedora java team or directly to jpp, and as responsible > maintainers they'll fix up their stuff. > Maybe it was replaced (Or I'm looking in the wrong jpackage trees). It's in the 1.6 repo but I couldn't find it in the 1.7. > They're not packager newbies you need to herd through draconian rules, > and they'll react better to a technical analysis than to a "just do it, > we don"t need to explain" (been hurt before by the fedora.us epoch > policy changes for example) No they aren't. But we have lots that are. So new packager comes along and proposes a new java package in our bugzilla. Now what? A) We send new packager up to get the package into jpackage first which increases the work he has to do and rules he has to learn but hopefully makes him a better packager and then he'll come back and resubmit the new package to us. B) We let someone try their hand at reviewing the package. They apply the Fedora Guidelines to it because it's not based on a JPackage package. It's approved. Later JPackage adds the package to their repository and we have a version within Fedora space that's different from the JPackage one but that happens with any other package as well. C) We let someone try their hand at reviewing. They're a newly sponsored packager they stumble over different sets of rules from us and jpackage and approve something with problematic versions and releases because the jpackage rules allow it and neither the packager nor the reviewer had the experience to see the problems. Changes to the NEVR require an epoch bump. Packages for jpackage, when they appear, have to know that Fedora Extras has a package with epochs otherwise they will never upgrade the Fedora Package. I think A & B are fine (although I think A is going to be troublesome if we want to encourage more people to become packagers -- people say the complexity of getting a package into just Fedora Extras is bad enough.) C is what I want to avoid by keeping the naming guidelines as strict as possible. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
