Re: Debian Maintainers GR Proposal

[Felipe Sateler <fsateler@gmail.com>]

Anthony Towns wrote:

> On Mon, Jun 25, 2007 at 05:13:35PM +0200, Bernhard R. Link wrote:
>> To the DM proposers: Does the suggestion in the current form mean that I
>> will no longer be allowed to sponser anyone out of fear he might become
>> DM and thus said he is capable enough to maintain this type of package.
> 
> If you upload a package marked "Maintainer: J Random Hacker
> <jrh@example.com>", then you're asserting J Random Hacker is capable of
> maintaining that package. You're already doing that in the sense that
> uploading such a package already instructs the BTS to forwards filed
> bugs to that person.

But you don't assert that J Random Hacker is able to maintain it _on his/her
own_, or that when (s)he can't (s)he will act appropriately (find a team,
co-maintainer, whatever). That assertion is made only when JRH passes NM.

> 
> If you don't want to do that, you can still sponsor an upload from J
> Random Hacker by having J only be mentioned in the changelog (and/or
> README, etc), and not the control file.

This seems somewhat untrue: the maintainer /is/ J Random Hacker, not the
sponsor or some other ID created for the purpose.

> 
>> Or does the advocate imply that the DM is capable of maintaining all
>> types of packages.
> 
> DMs upload priveleges are on a per-source-package basis as per the
> proposal.

The proposal says the following must be met for the upload to be accepted.

 * none of the uploaded packages are NEW
 * the Maintainer: field of the uploaded .changes file matches the
   key used (ie, maintainers may not sponsor uploads)
 * none of the packages are being taken over from other source packages
 * the most recent version of the package uploaded to unstable
 or experimental lists the uploader in the Maintainer: or Uploaders:
 fields (ie, cannot NMU or hijack packages)
 * the usual checks applied to uploads from Debian developers pass

This effectively makes a DM able to upload on his own any package, provided
that he gets *one* version uploaded. I would suggest the following:

1)  Change the first rule cited above to:
     * none of the uploaded source packages are NEW 
    (AFAIU, if an existing source package builds a new binary one (say a
    package split), then it is NEW. Please correct me if I'm wrong).
    Rationale: supposedly the DM is capable of handling this package, so
    there is no reason to make a difference between a DM and a DD in this
    context.
2) Make advocations package-based: add a key<->source package mapping, so
   that J Random Hacker gets upload privileges only for those packages that
   he/she has been deemed capable of maintaining. 
   Rationale: something similar to Bernhard's fear: That a particular DM is
   capable of maintaining one type of package doesn't make him/her capable
   of handling any kind of package.
   Sample scenario under the original proposal made:

  JRH maintains a couple of simple packages. His/her sponsors are happy with
  the work JRH is doing, so they advocate his/her DMship. JRH is now able to
  upload the pacakges on his/her own. A few days later, JRH finds $cool_app
  that needs $library which is not in Debian. Thus, (s)he packages both and
  gets a sponsored upload. This means that JRH now can upload both $cool_app
  and $library on his/her own. But now $library's new version makes some
  weird stuff that needs to be taken care of by the maintainer (API/ABI 
  incompatibility, or anything that makes library maintaining not suitable
  for most new maintainers). Can JRH be trusted that (s)he makes a good job
  regarding the library?


Disclaimer: not a DD, just the maintainer of a single package.

-- 

  Felipe Sateler