Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Santiago Vila <sanvila@unex.es> writes:
> I think there are several wrong assumptions here:
Hmm, maybe so. Or at least arguable points. But these were all in
the preamble, not in the proposal itself. The proposal was a pretty
simple statement. :-)
> 1. "Today is not long before a release".
> The fact is that *nobody* knows when we will get rid of the 200
> important bugs, so saying "at this point" is not very meaningful.
Yes, very true, I frequently use this argument myself. That doesn't
mean I can't *hope*! :-)
> 2. We would have to delay a release to meet a "release goal".
This was followed by an "or" clause. I know we don't have release
goals, but the alterative, if we do nothing now, is to have an
inconsistent system.
> 3. A system having packages using /usr/doc and /usr/share/doc is
> "inconsistent" and this should be avoided by all means.
Not "by all means". I prefer an inconsistent system to the mandatory
symlink scheme (though not by a lot). Remember, you and I were formal
objectors one and two to the symlink proposal. :-)
> This mix of /usr/share/doc and /usr/doc will happen sooner or
> later.
But not necessarily in a stable system, if we do it right. We may not
achieve that goal. We may not get all the packages updated before
Woody's release. Ok, we'll burn that bridge as we cross it. But
we've managed to get nearly every package rebuilt in both of the
*last* two release cycles, I don't see why we would suddenly lose that
ability.
I'm not offering any guarantees here, but I think this is our best
shot to do it right.
> If we delay the move to potato+1 it is almost sure that it will
> not be finished at release time either, because there are too
> many packages in the distribution.
We managed to get hamm and slink out the door, despite a need to
recompile all the binaries. I don't see why this would suddenly
change now.
> > Unlike most other FHS-mandated changes, an inconsistency here will be
> > *highly* visible,
> So what? "less" and "cd" support both dirs.
Which makes it less visible how? No, it's not a showstopper, I never
said it was.
> > and probably very annoying to our users.
> How can you measure the annoyance?
> [ I'm curious about this ].
I can't make a hard and fast measurement, obviously, which is why I
said "probably", but I know that several users have *already* objected
to the idea of leaving things they are now (some have even made idle
threats to switch distros, not that I care about such "threats", but
still...). And *speaking as a user*, I can say that I already find it
annoying.
> Are we going to take a step back because of something we can't measure?
I can measure my own personal annoyance with this inconsistency, and
it's fairly high. I think that many other people agree, judging by
the posts I've seen.
I confess, yes there is a chance that this may end up delaying things
in the long run. Yes, it's bit a gamble, and I don't want to hide
that. I think it may also be our best shot, possibly our only one, at
producing clean *stable* distributions both now and in the long run.
I think it's a gamble well worth taking.
I am not going to fib and tell you that this is the best of all
solutions in this best of all possible worlds. Personally, I think
all the proposals, including sticking with what we have, have
advantages and disadvantages. So it's more a matter of picking which
disadvantages we're willing to live with.
Perhaps we should poll the users....
And hey, when it comes down to it, this is just a proposal. My
*primary* goal is to give the tech committee something else to
consider if Manoj *does* send his proposal to them! :-)
I think that with the number of seconds I've recieved (thanks guys!),
this proposal is now too strong to ignore, even if it doesn't make it
through the debates here. Which is really what I wanted. Formally
object if you must -- I don't think it'll win you any friends, but it
won't stop this proposal from filling *my* goals for it! :-)
cheers
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: