Thanks to Raul, Bdale and Steinar for comments and suggestions. At Bdale's request I have deleted the old paragraph 17 (which contemplated the rpvm maintainer closing their bug). So ...
I hereby propose the following resolution and call for an immediate vote: It appears that everyone agrees on the following set of facts: 1. rpvm, an extension for integrating GNU R with PVM, uses a library libgpvm3 from pvm. 2. This library is currently in pvm's .deb only as a .a containing non-PIC code. This is a historical accident and not intended to be the permanent behaviour; it should be changed eventually. 3. R expects extensions to be shared libraries and rpvm should not be an exception to this. 4. On architectures other than i386 and ARM, shared libraries cannot contain non-PIC code. 5. For the reasons above, rpvm has never worked properly (upstream, or Debian) on architectures other than i386 and ARM. Disputed questions include: 6. Should pvm be changed to ship libgpvm3_pic.a or a suitable .so, for sarge, so that a working rpvm can be made available in sarge on all architectures ? 7. What should be done with the bug reports ? We note that: 8. While the Technical Committee is not the official arbiter of process questions such as the proper use of the bug system, we have been asked for our opinion and it would be helpful of us to give guideance. 9. It is not clear how difficult or risky the change would be to make pvm build a suitable library. It is difficult for the Committee to evaluate this, without a suitable patch to review. 10. The pvm maintainer is a volunteer is not obliged to do the technical work necessary to support rpvm. 11. Nothing in the release policy requires or forbid the relevant changes to pvm or rpvm at this stage of the release process. We therefore conclude that: 12. There are (perhaps) two distinct sets of changes required to fix this problem; the changes to pvm to supply a suitable library, and any changes to rpvm to make use of the new library. And, of course, there are two packages which have some kind of defect. Therefore it is not inappropriate for there to be two bug reports open. 13. Since rpvm has never been supported other than on i386 and ARM we believe that the current release policy would make the problem non-release-critical for rpvm. We believe the problem is non-release-critical for pvm. 14. As the maintainer of each package is a volunteer, they have the freedom to direct their effort as they see fit. Additionally it is proper for the maintainer to have a strong influence on the perceptions of other developers regarding the best use of effort spent on the package. The bug system severities provide a suitable way to manage this process. For non-release-critical bugs, the severity should therefore usually be assigned with free discretion by the maintainer. We therefore recommend that: 15. There should be two open bugs regarding this issue, as follows: #266837 against rpvm regarding the missing architectures, and #266762 against pvm regarding the missing library. These bugs should have whatever severity the respective package maintainer assigns from time to time. 16. The rpvm maintainer should (if they see fit and are able) prepare a suitable patch to pvm to arrange for the supply of the necessary library. Such a patch should be reported to the pvm maintainer via the existing bug. 17. If such a patch is made available the pvm maintainer should evaluate its suitability for inclusion in sarge. If the pvm maintainer decides not to include the patch in sarge, or does not respond in a timely manner, then the Committee encourages the rpvm maintainer to bring the matter to our attention, and we will consider whether to overrule the maintainer and direct that the patch should be included in sarge. 18. We do not rule out alternative technical solutions which the rpvm maintainer may choose to implement. Nevertheless, no such solution entitles the rpvm maintainer to /mandate/ any change in pvm, or to fight with the pvm maintainer over the severities of pvm bugs. However: 19. The Committee's decisions here regarding the releasability of various packages are not to be construed as overruling or directing the Release Team. 20. The Committee's decisions here regarding the proper use of the bug system are not to be construed as overruling the BTS maintainers. 21. Therefore, if the Release Team or BTS maintainers disagree with the Committee's decisions here we encourage them to contact us immediately, and the Release Team's or BTS maintainers' instructions will stand during any subsequent discussion. Ian.