[Fedora-packaging] Summary/Minutes from today's FPC Meeting (2013-06-20 16:00 - 17:15 UTC)
a.badger at gmail.com
Fri Jun 21 16:21:27 UTC 2013
On Thu, Jun 20, 2013 at 02:07:59PM -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 06/20/2013 01:15 PM, James Antill wrote:
> > * Policy around packagers not getting an exception for a library
> > or refusing to comply with an unbundling ruling -
> > https://fedorahosted.org/fpc/ticket/301 (spot, 16:41:10) * ACTION:
> > policy draft approved (+1:6, 0:0, -1:0) (spot, 16:43:46)
> According to the proposal, the way to deal with a maintainer not
> dealing with a bundling problem is to kick it to FESCo. What do you
> see as FESCo's responsibility here?
> I see the following possibilities:
> 1) FESCo orders the package blocked from the distro (may be hard to
> enforce for packages with many children.
> 2) FESCo takes away package-ownership and finds a new caretaker for it
> (Hard to accomplish since FESCo has no resources to direct)
> 3) FESCo sends a sternly-worded email to the maintainer
> 4) ???
Note: This is the way things work currently. the only change is that we've
written it down. Enforcement of any guidelines has always been FESCo's
Step 1 -- analyze:
* Is the reporter just being impatient?
* If a patch was supplied, is there a reason that the patch is unacceptable
(the guidelines note that we'll unbundle even if upstream doesn't accept
such a patch so that's not a valid reason. But there could be other
reasons like: patch only links against the new version of the library.
There are still major runtime bugs with this that aren't worked out.)
* Is the package a core dependency? This could be considered under both
volume and importance. A package blocking anaconda may be "more core"
than a package that blocks five games.
* What methods exist to reprimand the maintainer -- in the past, RH
employees have had their manager contacted in cases where they were
clearly violating packaging guidelines for no reason. Some package
maintainers will respond to a sternly worded email (for instance, they may
just need to be told by an official body that "Upstream!" does not trump
fixing this issue.)
Step 2 -- do something
I'd always start with the email:
* It may be that the maintainer has a good reason for needing the patch
modified before applying. In that case, their problem is communication
rather than unwillingness to apply the guidelines. Help train them to
report their specific concerns back to the patch provider so that the
patch provider can aid in coding the fix.
* It may be that the maintainer just needs prodding from someone official to
deviate from upstream.
* It may be that the maintainer just doesn't have time to care for their
package, perhaps it's time to invoke the non-responsive maintainer policy
or add a comaintainer.
If the maintainer is trucelent about not unbundling then you'll need to take
* If FESCo blesses the change, any provenpackager can apply the change to
* Taking away package ownership is a possibility. FESCo has done that for
Non-Responsive Maintainers and has taken other actions that have lead to
maintainers orhpaning their packages. That has always resolved itself
with people who depend on the package stepping up to take them.
* Blocking a package is probably something that would shake out of taking
the package away from its maintainer and no one stepped up to take it.
This may be a natural extension of the per-release blocking and
deprecation of orphaned packages.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the packaging