On Wed, Jan 02, 2008 at 07:43:52PM -0600, Josh Boyer wrote: > > Entirely too large of a deal is being made on this "veto" power. It's > not really a "veto", as they have no mechanism to enforce it anyway. That'ds true for all the guidelines. No packager has special power to enforce anything (there are the acl, but it may only be for his own package). But guidelines are still giving more power to those who ask other packagers to comply. > The proposal doesn't even have the word "veto" in it. It has: "and the primary package maintainer is not against the idea" which is essentially the same. > Just change this: > > "...and the primary package maintainer is not against the idea." > > to this: > > "...and there are no objections from the primary packager (or any > other packager knowledgeable about the package)." Not exactly. For all the packages this clause is also here (every packager can 'block' a review and escalate to FESCo if another packager is ready to accept the package), but it doesn't need to be stated. In my opinion it would be much better to say something along (it is not much shorter, but at least it doesn't appear special anymore): In cases where this isn't possible, a compatibility package _may_ be introduced if there is someone who is willing to maintain the compatibility package. Other packagers, especially the primary maintainer, should have time to express their dissent about adding the package (just like in any other review). The primary maintainers should be especially cautious, since even if they are not maintaining the compatibility package, chances are that they will have to be involved in the maintenance due to passing along security problems, helping out with things and redirecting misfiled bugs. > and it's fine. Escalations all go to FESCo, regardless. Indeed, so this part is not needed. > You are both saying the same thing, just with different flavors. > Realize this, and move on. Maybe. But it is nevertheless important to avoid unneeded guidelines and added bureaucracy, even if the end result is the same. The guidelines are already very big. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
