Re: mass bug gnustep programs: policy violation
On Thu, Jun 24, 2004 at 10:35:34AM +0200, Andreas Barth wrote: [Adding d-release because of the last question; please drop it on replies as d-release is not a discussion list.] Do you really and honestly believe that this bug means that gnustep is not of release quality. (a) the policy needs to be reviewed as to whether it's impractical, or (b) the non-compliant packages need to be removed. So far, all I've seen is people saying that GNUstep doesn't need to follow Policy, which I cannot agree with. No, I didn't say that. I just said that this behaviour is 1. an important, but not serious bug 2. that changing this behaviour at the given moment of time would do the package and the release a dis-favour, and the changing itself would constitute a serious bug. Placing executables under /usr/lib/package/ is not a violation of the FHS; it's often sufficient for the author to assert that the binaries are not intended to be executed directly by the user for us to accept that this is the case. The fact that there is an openapp helper utility that's the recommended way to invoke these programs is further evidence of this; this is quite different than if the recommended invocation involved adding /usr/lib/GNUStep/.../.../ to your PATH or calling the binary with an absolute path. If you wish to argue that certain apps *should* be directly executable by the user, you may, but this does not constitute a serious bug. OTOH, expecting users to source a script to set up the GNUStep environment before being able to invoke *any* of these apps is a policy violation; as is placing arch-independent data under /usr/lib/GNUStep. Per http://people.debian.org/~ajt/sarge_rc_policy.txt, these sorts of bugs are considered RC for sarge. I would not say that an exemption for these pre-existing bugs is impossible, but I also would not advise the maintainers to expect such an exemption in the absence of evidence that they have first put forth an effort to resolve this problem in the time remaining before sarge's release. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: mass bug gnustep programs: policy violation
[Adding d-release because of the last question; please drop it on replies as d-release is not a discussion list.] * Matthew Palmer ([EMAIL PROTECTED]) [040624 09:55]: On Thu, Jun 24, 2004 at 09:01:43AM +0200, Andreas Barth wrote: * Matthew Palmer ([EMAIL PROTECTED]) [040624 05:55]: On Wed, Jun 23, 2004 at 09:15:43PM +0200, Andreas Barth wrote: * Chris Cheney ([EMAIL PROTECTED]) [040623 20:55]: They could just be removed from sarge and be released again with sarge+1... Not every package with a RC bug has to be fixed and released with sarge, it is common practice to pull them if they don't get fixed in time. You're not really suggesting to not release gnustep in sarge? That's what we do with packages that aren't of release quality. Do you really and honestly believe that this bug means that gnustep is not of release quality. (a) the policy needs to be reviewed as to whether it's impractical, or (b) the non-compliant packages need to be removed. So far, all I've seen is people saying that GNUstep doesn't need to follow Policy, which I cannot agree with. No, I didn't say that. I just said that this behaviour is 1. an important, but not serious bug 2. that changing this behaviour at the given moment of time would do the package and the release a dis-favour, and the changing itself would constitute a serious bug. In my opinion, these bugs are non-blockers for sarge, and one of the issues that should be fixed for sarge+1. Ultimately, of course, the only opinion that matters for this is the RM and his cohort of happy hackers. That's neither of us. You say it's non-RC RC, I say it's RC RC. We'll probably have to agree to differ. Good. We seem to agree on that. Please, can someone of the RMs say whether this bug should be solved before or after release of sarge? (Or do you want to wait with a statement on this until the GR is decided?) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
