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 duty.

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 further steps.

* If FESCo blesses the change, any provenpackager can apply the change to the package. * 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.

-Toshio