Re: Policy proposal for compatibility packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux