Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package
Stuart Anderson writes...
> On Wed, 20 Feb 2002, Andrew Pimlott wrote:
>
> > I guess this will come off as smart, but if it is "controlled", I
> > would have expected someone to write down why this section was
> > written in the first place.
>
> Good point. In fact, how to maintain a rational as part of the document
> was discussed. At the time, it didn't seem critical to include the rational
> in the standards document. (You can have a good debate about wether rational
> is appropriate for the normative parts of a standards).
I agreee. While the FHS has done a good job including rationale in their spec,
I think the rationale for the LSB will be much longer and warants a separate
document.
> Anyway, because we
> all learn from what we do, it now seems that having the rational would be
> helpful.
So where should the rationale live? Can this document be created now and
people record what they remember so it's not lost forever?
> > It sounds like the early versions were hastily slapped together
> > (this is not the only section that gives me this impression),
>
> There were fewer people contributing back then, so some section probably were
> hastily written.
I have added a "rationale" requirement to the (in development) lsb-futures
"Selection Criteria" document,
http://www.linuxbase.org/futures/criteria/index.html#rationale
So all new additions to the LSB will be required to document their rationale
before being recommended for addition to the LSB.
> It doesn't have to be a painful process. I didn't mean to imply that it shoul
> be, or even that is has to be a heavy process, only that some process must
> be followed. Changing the document simply because write access is available
> is not an appropriate process.
>
> I think we've demonstrated that there is concensus that the change should be
> made. I agree with that.
>
> I do think that before removing or deprecating something we should make sure
> we understand why it was added in the first place. If the answer is that it
> was rushed and overlooked in the beginning, then that's fine. If there is som
> other reason, then we need to be sure that we have considered it.
>
> Once this is done, then we can change the wording in the spec to indicate tha
> is is deprecated.
How will this be done, by editing the spec or issuing some sort of errata
document?
Is this particular issue (UID of "bin" and "daemon") now understood enough to
make these changes? Can we stop testing for it and not require it for
certification? This is holding up Debian compliance and certification.
Thanks,
--
Matt Taggart Linux Development Lab
taggart@fc.hp.com HP Linux Systems Operation
Reply to: