I vote in favor of this resolution. -- Raul
On Wed, Sep 15, 2004 at 11:32:01AM +0100, Ian Jackson wrote: > (I accidentally failed to send my last message to the committee list. > My apologies! Here is a slightly edited version, taking into account > a correction from Steinar.) > > It looks like informal discussions aren't doing the job here. I > hereby propose the resolution below. If anyone disagrees with any of > the facts I claim are undisputed, or I seem to have missed something, > then please let me know and I'll withdraw and amend it. > > 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. If the rpvm maintainer is of the opinion that there is no change > needed to rpvm to fix the problem - ie, that the problem will be > fixed automatically when the missing library is provided by pvm - > then the rpvm maintainer may, if they wish, close their bug or > merge it with the pvm bug. During this process the severity > settings of bug(s) against pvm should be retained, so that bugs > against each package have the severity assigned by the maintainer > of that package. > > 17. 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. > > 18. 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. > > 19. 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. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]