On Wed, Feb 20, 2002 at 10:15:03AM -0500, Stuart Anderson wrote: > On Thu, 21 Feb 2002, Anthony Towns wrote: > > You know, if no one can think of the reason in the months since this > > was first brought up in response to the "1.0" spec release, it quite > > simply can't have been a remotely good one. > The words in question were written well over a year ago, which is why it > is hard to recall the details. Well, it's over half a year since this was first brought up as a problem (4 July 2001, http://lists.debian.org/lsb-spec/2001/lsb-spec-200107/msg00002.html at the very least). > I don't mind removing it, but I do mind making random, uncontrolled changes > to a document that is supposed to be stable and "controlled". My point in this > is that we need to follow a proper process in making changes like this. Well, it'd have been nice if that had happened in the first place, with, say, some reasonable opportunity to comment on things like this *before* they were specified. But since that didn't happen, the LSB simply has to fix it now, however galling that may be. > > Specifying the uid of the bin > > user does not make it easier to write software for Linux systems, and > > it limits the number of systems on which LSB-compliant software can run. > As I said above, I don't mind removing the uids, I just want to make sure that > proper diligence is used when doing so. What, exactly, is "proper diligence" ? It would seem to me that due diligence would involve contacting key distribution vendors (Red Hat, Debian, Mandrake, SuSE) and ensuring there are no issues with a change. This clearly was *not* done before the bin uid was added to the 1.0 spec (the change wasn't even mentioned on the list before the 1.0 spec was released); and it clearly *has* been done now (there are developers from all of those distributions on the LSB specs, and developers from at least two of them have commented in favour of the change). By contrast, where was the due diligence in response to 496591 ("LSB packages should be named ".lsb")? The only response I've seen to that (and since I raised the issue, I'd assume I'd see what response there is), was the thread beginning at: http://lists.debian.org/lsb-discuss/2001/lsb-discuss-200112/msg00035.html and a "discussed and rejected" response to the sourceforge bug report, and in one of the conference call minutes. If you look back through the thread, you'll see absolutely no consensus or meeting of minds was achieved. There are a host of other issues that I and others have raised which have been dealt with in a similarly haphazard way (hardcoding Red Hat's interpretation of runlevels into the init script spec, the useless "local mounts" and "remote mount" system services, to name a couple of examples). These aren't things that kill the spec (unlike a number of the details in the user/group spec), but they are detrimental. The LSB group is doing a fine job of ignoring them all out of existance, though. > > The standard is recognised to be buggy and there is no existing userbase. > > What better time do you think there'll be to remove it? > I'm not resisting the removal of it, just that a proper process be followed. So forgive me if these words ring completely hollow. [0] > > Enough with going around in circles about pointless nonsense. There are > > a handful of simple changes that are needed right now for the LSB to > > achieve its goals. It's time to make them. > > Who has commit access to version 1.2 of the spec? > Myself and a few others, but I have been tasked with ensuring that changes are > made in a consistant manner. That's all I am trying to do. Well, I'm not sure I can dispute the consistency of the change policy ("Oh, it's from Debian, eh? Ignore it."), but ensuring necessary or useful changes are made quickly and correctly seems like a much more worthy goal. It's not really fun watching a project that seems like it could be fairly important to the Linux community falling into all the usual traps of non-bazaar development [0]. Cheers, aj [0] Process over functionality. Unresponsiveness to comments. Closed channels of communication between the core developers instead of regular use of mailing lists. Worrying more about releasing at LinuxWorld than getting something useful, or at least, not actively harmful, out. -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey
Attachment:
pgplzJyIacRht.pgp
Description: PGP signature