On Mon, 18 Jun 2007, Marc Espie wrote:

> >       MAINTAINER currently has two meanings:
> > 
> >         "Here is someone you can talk to about changes to this package"
> > 
> >           or
> > 
> >         "Consult this person before you make any changes to this package"
>
> This does boggle me, a bit.
>
> In my world, over in OpenBSD, the MAINTAINER variable means the person
> feels at least partly responsible for the package.  Enough so that they
> need to be consulted for any non-trivial changes that may break stuff
> (you can't be responsible for something if anybody can change it under
> your feet). As a guideline, we still allow two kinds of changes without
> consulting the maintainer:
> - infrastructure sweeps, where we adjust to recent features of the tree
> (in some of these cases, it's too costly to wait for every maintainer to
> say okay... it's assumed that the person doing the change has performed
> a build, and it's not done by a lot of people).
> - to fix some obvious breakage in a hurry (and then, it's still preferable
> to have an okay from another developer, be him maintainer or not).
>
> Your first case doesn't look like a maintainer to me. It looks like a handle
> to someone who maybe ported the software, and maybe has some insight into
> how it works. But no responsibility.
>
> The thing is, if you still appoint such a person as MAINTAINER (with no
> actual responsibility), you hinder other people from taking charge.
>
> My personal definition of MAINTAINER is:
>
> person, or group of persons, that feel responsible for the working of
> this package, and should be consulted for any important change to the
> package.
>
> If people don't want to assume responsibility, and ports are `maintained'
> by the `default' address, then so be it.
>
> Adding more definitions and variables will only mean that people will get
> more confused and know less about what to do (I assume NetBSD people are
> as smart as OpenBSD people, we know that people sometimes already get
> confused over our simple definition of MAINTAINERship)...
>
> Treat this as just a comment from the sideline. Just my two cents about
> what your point of view implies...

 	For virtually all, if not all, of my packages I am happy
 	for people to update them to new versions without having
 	to contact me first. I'm available to be contacted if people
 	have any questions or want to check something before
 	updating, but I do not mind if they don't.

 	So the options we have are:

 	a) 'consult before update' (Marc's suggestion above)

 	b) defaults to 'consult before update', and have some other
 	   value to indicate its 'available for questions'

 	c) 'available for questions'

 	d) defaults to 'available for questions', and have some
 	   other value to indicate its 'consult before update'

 	Its more important to me that we pick one, so it has a well
 	defined meaning, than which one. (My preference would be
 	d, b, a, c)

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --