[Fedora-packaging] Summary/Minutes from today's FPC Meeting (2013-06-20 16:00 - 17:15 UTC)

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20130621/be75c4cf/attachment.sig>