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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
