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