On Tue, 05 May 2015 23:36:32 +0100 peter green <plugwash@p10link.net> wrote: > > > > > Perhaps we need a political decision here? When considering maintainers not directly involved in the port, motivation for doing work which only helps a particular port tends to be easier to find when the objective of that port is to either get into a stable release or to scratch their own itch. Therefore, ports like arm64 and pp64el had the best of the input because there were a large number of active people actively working on the port, a lot of people generally interested in the port and a high probability that the port would make the next stable release, jessie. Ports which were in release state but which have lost support will struggle. Ports which take so long to develop that a stable release is deemed unlikely will also struggle. That is a problem caused by that port, not by the project or other maintainers. Proponents of such ports cannot blame others for the failure of their favourite port to attract interest. In some ways, ports which are not "on track" for a stable release are the second-class ports. arm64 and pp64el were not much of a problem in terms of getting fixes uploaded. That's not to say either arm64 or pp64el was trivial - a lot of people put in a lot of work - but neither was ever in serious doubt either. > What should the expectations of maintainers of second class ports be? Essentially (and hopefully not stating the obvious too much): 0: That maintainers not involved in the port will struggle to find the motivation to work on changes which do not benefit a stable release or their own self-interest. 1: That volunteers will find something else to do if there is a (relative) lack of motivation for a particular piece of work. 2: That the focus of most maintainers is split between their own itches and the next stable release. Work which doesn't help either of those is going to be lower priority. 3: Nagging maintainers who lack motivation for a particular piece of work is generally counter-productive. (This includes but is not limited to severity ping-pong.) 4: NMUs have to be done with care - especially if the change is solely for the second-class port. It's much easier to get changes in which will help other ports or general code quality on all ports (like dh-autoreconf et al.) Under no circumstances can a porter NMU cause a regression on a more actively supported port - and it would be the porter who would end up checking that. 4: Ports which are not going to be considered for release are, by definition, toy ports and cannot expect the same support as release ports. Decisions made regarding a release port do not create a precedent for, or necessarily have any applicability for, non-release ports. 5: All non-release architecture ports are unofficial and the decision on release architectures is down to the release team. How does that sound? -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpADbHFfYVu6.pgp
Description: OpenPGP digital signature