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

[Rainer Müller]

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?

Rainer