Changing port maintainership rules

[Thomas Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 30.07.10 18:15, schrieb 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.

I know I'm asking for something which might sound like "anarchism", but
actually I think most if not all MacPorts committer are smart and
cautious enough to not break other people's ports, i.e. I for example
would never touch autoconf or anything related without deep
understanding of what I'm doing. When I'm unsure if a specific patch is
good or bad for a specific port then I of course ask the maintainer or
other people, either on the list, on IRC or elsewhere, if and how to
continue.

(The changed port in question by the way, parrot, was a "leave" in the
port tree, i.e. no other port depend on it at the time of the update, so
it was reasonably easy and save to just upgrade it after I confirmed
that it installed and worked properly locally.)

I don't say that the complete port ticketing mechanism should be
abandoned, I just wish that the rules (and the "guards" which follow
them) would not be so strict in applying them. Lets use the appropriate
form of communication for the appropriate problem we're trying to solve.

See port submission / patch requests as another example - they're used
to be tracked through tickets, but then again people still need to
announce the individual ticket / patch request on the list, and most of
the time they do this because they feel their particular request hasn't
been noted for a rather long time. I doubt too many first timers will
actually be so stubborn and do that, but many are just scared away if
their submissions are ignored or won't get noticed.

I don't mind to follow some rules and its naturally for me to respect
the work for others, but I had, have and probably will have a very hard
time to restrict myself to every tiny rule of the current "setup".

Thanks for reading,
Thomas.

- -- 
GPG-Key 0x160D1092 | tommyd3mdi at jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTUR0ACgkQaf7NlBYNEJK6qwCgkR+f2REuQZicfQjK6ispBgQF
NIIAoPdNK2TbDySmC+BUfwLTZ/YFnbQq
=MVTa
-----END PGP SIGNATURE-----