On Fri, Sep 17, 2004 at 11:26:36PM +0100, Ian Jackson wrote: >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: This vote call is 7 weeks old. May the debian-ctte members vote Ian's proposal, please. I've read http://lists.debian.org/debian-ctte/2004/09/msg00006.html already. I think, we need the debian-ctte's opinion on this matter. >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. Kind regards, Anibal Monsalve Salazar -- .''`. Debian GNU/Linux | : :' : Free Operating System | http://www.debiancolombia.org/ `. `' http://debian.org/ | http://www-personal.monash.edu/~anibal `-
Attachment:
signature.asc
Description: Digital signature