On Wed, 6 May 2015 18:18:34 +0800 Paul Wise <pabs@debian.org> wrote: > On Wed, May 6, 2015 at 6:11 PM, Neil Williams wrote: > > > You've admitted that the port cannot keep pace because it needs > > changes to be made by maintainers who do not see the port as a > > particular priority and that this blocks or impedes further > > changes. You've tried and failed to increase the level of interest > > in the port which would have changed those priorities and the port > > has failed to gain more manpower. That is a failed port. > > Sounds like you're saying hurd-i386 has failed because of lazy > maintainers? I have certainly merged Hurd and kFreeBSD patches that > were submitted and even written patches when they were needed even if > I am not currently running these ports. Other maintainers are likely to have done the same too. However, *not enough* maintainers have considered similar patches to be of sufficient priority for their workload - because the port has failed to gain sufficient interest. It's not at all that the maintainers are "lazy" or that those maintainers could have done anything differently. Those maintainers have their workloads and have made an assessment of their priorities. If those changes ended up lower down that list of priorities than the porters can manage to support, then that would be the time for those interested in the port to do that work themselves, as a fully tested NMU. It is at this stage that the port could be considered to have failed if the port fails to attract enough people (maintainers or not) to do the work that the port requires. Then the port may regain some interest and some support if the work is done and that can change how maintainers assess the priority of the changes requested by the port. When it works, it is a snowball effect - however once the ball slows down, it can be very difficult to make progress and without progress, there is no point continuing. Working ports are at the crest of a wave - if the wave crashes down, it's easy to spot that it's failed. If the wave simply moves on, leaving the port behind, it is harder to accept, very hard to regain momentum and high time that the porters ask themselves the hard question of whether it is worthwhile to continue, as the crest of the wave rushes off ahead of them. We're all aware of how this works with applications and upstreams - it applies to ports too. Restarting upstream maintenance of a package is hard and often pointless - it can be exactly the same with ports which have stalled due to lack of manpower (itself due to lack of widespread interest). -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpCWXIBibwOQ.pgp
Description: OpenPGP digital signature