On Wed, 6 May 2015 10:11:02 +0200 Samuel Thibault <sthiba...@debian.org> wrote:
> Neil Williams, le Wed 06 May 2015 08:56:38 +0100, a écrit : > > 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. > > Not only. A typical scenario that does happen and can really hinder > porting is when an upstream source often introduces non-portable > changes. The package needs to be ported, the porter team thus > provides a patch. The patch lingers in the BTS until the maintainer > makes a new upload for a new upstream release. He integrates the > proposed patch, but the new upstream release introduces another > non-portability issue, and thus another patch is needed. The porter > team provides a patch, which lingers in the BTS until etc. In the > end the package never gets to build on the port. That is still a problem of that port - when working with volunteers, if proponents of the port cannot engender enough enthusiasm for that particular itch then you will struggle to get other people to do work which only benefits that itch. You cannot blame the maintainers for finding something more interesting upon which to spend their limited and valuable volunteer time - in Debian or upstream. The problem - and the fix - lie within the realms of that port, not the project. Something which is important to a small number of people does not put any obligation on the rest of the project - it is a toy, a sideline, a curiosity or a diversion, depending on viewpoint. The project has teams and methods to agree on what is important to the project and it has methods to ensure that those priorities have costs if maintainers ignore those priorities. Like it or not, work which does not actually benefit any of those established priorities will *not* get priority and will likely languish in the vague hope that some day there might be enough spare time to get everything else done which is of higher priority. Portable vs non-portable changes is itself a project decision - code is considered portable if it builds successfully on all release architectures. Code in Debian doesn't need to be portable to non-release architectures. It's nice if it can be done and it is done if the maintainer/upstream has an interest but it is not and cannot be required or expected. Projects can choose to support Amiga or RiscOS or BeOS or OS/2 or CP/M or Ming or Android if they want - doesn't mean that changes in other packages which do not support those are "non-portable". Portability is a movable feast and in Debian, it relates to release architectures. If a particular port wants that kind of support, it needs to enthuse enough people to make it relevant to the masses. Lack of widespread interest in any particular port is a problem with that port not having widespread appeal. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgp_w5XaE4C9b.pgp
Description: OpenPGP digital signature
