On Wed, May 06, 2015 at 11:39:29AM +0100, Neil Williams wrote: > 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 hard to gain sufficient interest if doing so requires you to have sufficient interest first. You need a number of patches to be applied for your port to gain a critical level of usefulness. Maintainers ignore your patches because it's a minority port anyway. But *because* they ignore your patches, your port will never leave the "minority" label. That's a vicious cycle; you can't get useful until things improve, and you can't improve until you get useful. This is why unreleased can be really useful, as it allows people to break out of the vicious cycle and get things to a working state. Having said that, I think it *should* be important for maintainers to consider "not ignoring other people's work" as an important part of their workload. Yes, our constitution says it does not "(...) impose an obligation on anyone to do work for the Project." However, it immediately goes on to *also* say that you "(...) must not actively work against these rules and decisions properly made under them". I've always interpreted that particular requirement as "you should not stand in the way of people doing work if you're not willing or able to do it yourself," and I don't think that's too far-fetched. I mean, sure, nobody's asking anyone to write a porter patch. However, if such a patch is written by someone else, I think it *should* be your requirement as a maintainer to either do an upload which includes it, or explain why you won't do that (e.g., because the patch introduces a bug of some sort). I'd even go a step further, and would like to suggest that we should treat "bug severity important, tagged patch" as RC, especially if it's also tagged to be "RC for a non-release architecture". -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Attachment:
signature.asc
Description: Digital signature