Changing port maintainership rules (was: Re: [70103] trunk/dports/lang/parrot/Portfile)

[Eric Hall]

On Fri, Jul 30, 2010 at 06:15:05PM +0200, Rainer M?ller wrote:
> On 07/30/2010 12:24 PM, Thomas Keller wrote:
> > Am 30.07.10 07:53, schrieb Rainer M?ller:
> >> As the ticket was sitting 6 months without attention should we call port
> >> abandonement for parrot?
> > 
> > I'd vote for a less bureaucratic way to handle all this, i.e. less
> > ticket work and less restrictions. One simple rule could be to make a
> > port automatically nomaintainer or at least openmaintainer if no updates
> > happened for so and so long.
> 
> I agree that the process is complicated.
> 
> But how do we make sure that "no updates happened" means that the
> maintainer lost interest? Upstream might not have released updates for
> years and therefore the port wasn't changed...
> 
> At the moment the rule is that a ticket must be unacknowledged for three
> weeks before filing a abandonment ticket. Should we change this to make
> a port nomaintainer after this timeout without filing another ticket?
> 
> > While all the processes are well defined, they sometimes just prevent
> > quick, good and needed updates. In my particular use case I needed an
> > updated parrot because I wanted to package rakudo whose current release
> > expects parrot 2.6.0. And the main drive for having a rakudo package was
> > that I had some spare time last night and wanted to get my hands dirty
> > on Perl 6. If I'd have followed the "official" protocol, the spare time
> > last night would have been taken by creating tickets, writing emails and
> > waiting for answers from the void.
> > 
> > Personally, if somebody would make an NMU of one of my ports he'd be
> > very welcome. Thats why I mark all of them as openmaintainer and I think
> > a general rule which would enforce this for most (if not all) ports
> > would greatly improve the collaboration and general quality of
> > individual ports.
> 
> If I understand you correctly, this is a request to drop the exclusive
> maintainership for all ports.
> 
> PRO:
> * Faster updates of ports
>   Anyone would be allowed to commit updates.
> 
> CON:
> * Some patches have to be verified before being committed
>   You need someone feeling responsible for the port if they are
>   non-trivial. Such patches might also require enough insight into the
>   software itself to understand them.
> 
> * Coordinated updates might fail
>   Take the autoconf 2.66 disaster as an example. It introduced
>   regressions breaking other ports, therefore it was reverted. Without
>   a designed maintainer who would have decided to downgrade? Who would
>   have prevented others from committing the update again?
>   Some could happen if updating port X breaks library dependent Y.
> 
> But maybe we would just need to change our behavior to solve this
> problems by adding more ticket references and documentation to Portfiles.
> 
> What do others think?

	I think keeping the (no)openmaintainer bits we have now
is the right approach.  For example, for ports that have wide-spread
impact (like autoconf as mentioned above), we don't want anyone to
just go "ooh, look, new version, let's commit that" - those that 
maintain the port and/or understand what it does may well be
holding back on doing an update for good reasons, and that
needs to be respected.


		-eric