[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’



Le Wed, Aug 18, 2010 at 08:11:08AM +1200, Lars Wirzenius a écrit :
> On su, 2010-08-15 at 06:25 +1200, Lars Wirzenius wrote:
> > So we have at least three suggestions on the table now:
> > 
> > 1. Rename Maintainer: to Contact:
> > 2. Rename Maintainer: to Upstream-Contact: and Name: to Upstream-Name:
> > 3. Drop both Maintainer: and Name: completely, even as optional fields
> > 
> > All three seem to have reasonable justifications. I'd like to see if we
> > have a rough consensus favoring one of them. Can we see a show of hands,
> > please? (If we don't, I'll have choose myself, and then it'll be 3.)
> 
> It's my assessment that the rough consensus is in favor of either 2 or
> 3, with 3 getting more explicit votes, but 2 not getting any resistance,
> and having the justification that it's useful to a number of people.
> Thus, I will modify the spec to implement option 2.

Hi Lars,

my presonal point of view about fields in this DEP is that they should be
required only if they are strictly necessary, and mentionned as optional only
if there is a reasonable plan to parse and exploit the data. 

I am not aware of a requirement from the Policy or Joerg's message on
debian-devel-announce in March 2006 for listing the package name in
debian/copyright. Similarly, although it is required to list all authors of a
packaged work, there is no requirement to list the upstream maintainer.
Therefore, I think that the fields should be optional if they are not removed.

In my understanding, there was only one request for a machine-parseable
field in debian/copyright to identify an upstream work by its name or maintainer:

20100814151824.GM4335@nerys.comodo.priv.at">http://lists.debian.org/20100814151824.GM4335@nerys.comodo.priv.at
20100815003336.GP4335@nerys.comodo.priv.at">http://lists.debian.org/20100815003336.GP4335@nerys.comodo.priv.at

If the Perl team will parse the Upstream-Maintainer and Upstream-Name fields,
then I agree to keep them as optional fields. If only one would be parsed, I
would still recommend to remove the other one.

If the Upstream-Maintainer and Upstream-Name fields are kept, I would
nevertheless recommend to not use them in examples which purpose is not
directly related to these fields, and to not use them in general-purpose
templates like the one in dh_make.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


Reply to: