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
> <[EMAIL PROTECTED]>", 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
