On Thu, Aug 19, 1999 at 12:54:35AM -0700, Chris Waters wrote:
> > [1 <text/plain; us-ascii (7bit)>]
> > On Wed, Aug 18, 1999 at 04:25:48PM -0700, Chris Waters wrote:
> > > First of all, I'm still not convinced that this is a technical issue,
> > > as I mentioned in my objection to Manoj's proposal.
> > "How do we keep all the documentation `together' while we physically move
> > it from /usr/doc to /usr/share/doc?"
> Is only an issue if we can't move it all at once *as far as our users
> are concerned*. Let us not lose sight of the real goal here: to
> produce the best *stable* systems!
Yes, making "package uses FSSTND (or /usr/doc)" a release critical bug is
a definite possibility.
> As long as all the docs are in the
> same place in a stable release, who *cares* what kind of ugliness was
> involved in moving them? Unstable is *supposed* to be, er, unstable.
Most of us have a certain selfish interest it keeping unstable as pleasant
as possible, I suspect. So that's who cares.
> > It may well not be possible, but so far at least, the symlinks idea
> > (Bug#40706) seems to have no major problems.
> *None* of the proposals (I think we're up to four now) seem to have
> *major* problems. However, the symlinks seem unnecessary to me,
> *unless* we want to make unstable more consistent,
...or if we don't want to have to change every package before releasing
potato. That's what, an average of 6 packages per maintainer or something
now?
It's a significant amount of work you're committing everyone else
to doing.
> > > Oh, and I did point out a couple of very minor, but still ACTUALLY
> > > TECHNICAL objections to Manoj's proposal. Executive summary: symlinks
> > > have limitations, and if we add an extra layer of symlinks, we
> > > increase the (admittedly minor) risk of bumping up against those
> > > limitations.
> I'm not a huge fan of the symlink proposal, no, but this is not why.
> I'm not a fan, because it seems to consider unstable to be more
> important than stable.
>
> (Detailed and irrelevent analysis of the symlink technical limitations
> elided.)
Then if this ACTUALLY TECHNICAL objection is so completely irrelevant as
to not even warrant discussion, why bring it up?
Seriously, why?
> I think we're losing sight of the real goals here. I think we need to
> get back to focusing on the *stable* systems, and how to make them the
> best they possibly can be.
Erm, what gives you the idea that we're not trying to improve stable?
"Hmmm. Changing all packages is going to a fair bit of time -- it has in
the past, for libc6 and stuff. That means potato probably will be held up
by a few packages that nobody gets around to NMUing. Gawd, another delayed
release. That'd be great. Hmmm. It might be a better idea to make it so we
don't have to do all of this at once... I wonder how we can manage that?"
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpcojbSZEFbo.pgp
Description: PGP signature