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

Re: first proposal for a new maintainer policy



Christian Schwarz <schwarz@monet.m.isar.de> writes:

> I don't see how this conflicts with the proposed constitution. Please give
> me more info on that.

The constitution places no limitations on the developer's authority
with regard to their own work.  Your version says that the maintainers
must follow policy.

> This solution is fine with me too, but that should be documented in the
> policy manual too then

It's a bad idea to document things in both the policy manual and the
constitution.  If they conflict it might not be clear to everyone
which is in the right.

> (If the tech-ctte overrules
> developers too often, I expect that some developers will give up and
> leave. Hope that this will never happen.) 

I do think that the right way to resolve a disagreement between joint
maintainers of a package is with the tech committee, and not by
letting the head maintainer decide.


> > The name part should be the name of the maintainer if it is an
> > individual, or otherwise a descriptive string.
> 
> I strongly disagree! It's important to know which people are maintaining a
> package--that's important for the project, for the maintainers, and for
> the users.

What if half a dozen people are maintaining?  What if people drop out
and come in?  Wouldn't a string like "Foo maintainance group" make
more sense?

> > >  In addition, this field must represent a valid email address (as
> > >  defined by RFC ????).
> > 
> > No, this is not the case.  See the dpkg documentation.
> 
> A lot of people cut-n-paste the contents of the Maintainer field into
> their mail client to send mails to the maintainers. What's the problem
> with this requirement?

See 4.2.4.  Some mechanical changes may be needed in order to use the
field as an email address.

>  owner@bugs, These are not _packages_!

Yet you can file bugs against it, it has maintainers, etc.

>  `&c &c &c': AFAIK, there are no other multi-maintainer packages yet.

Why are we stressing so much over these multi-maintainer packages if
there are so few and there will very likely remain so few?  Why not
just be permissive and let people maintain packages in a fashion
convenient to themselves?


Guy


--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: