Re: about volatile.d.o/n
Thomas,
On Sun, Oct 17, 2004 at 11:53:03PM -0700, Thomas Bushnell BSG wrote:
> paddy <paddy@panici.net> writes:
>
> > 'stable even for users who are "misusing" the system.' sounds like it
> > could turn out to be a tall order, if it is intended to have wider
> > application.
>
> It is a tall order. It is also one that Debian has done fairly well,
> by having very strict policies about stable.
Indeed. Kudos to the many developers who work so hard to do this.
Stable seems to achieve this by long timescales and restricting updates
to a minimum. There will clearly be more pressure on such mechanisms
for volatile. Perhaps it is possible, desirable and the will of the
interested parties to pursue the same lofty standards, but that it is
not as trivial as saying "these same things should apply" is, I feel,
worth pointing out. After all it is the existing situation that leads
us here today: these values can sometimes be at odds with other
worthwhile values.
Indeed, if you change these parameters, can you credibly claim to be
applying the same standards?
> > I think there need to be good reasons to depart from stable, and
> > clearly, in some areas at least, there are. This may or may not
> > be one of those areas, I don't see into it that deeply.
>
> I want to hear the *exact* reasons. So far, it has been things like:
>
> "Virus scanners must be updated in order to remain useful."
> "And so, we must be able to change locale information, add new command
> line args, or fix spelling errors in output sometimes."
>
> The first may be true. The second does not follow.
Agreed. It doesn't necessarily follow.
But that won't stop the policy cart being put in front of the purpose horse.
WRT spelling errors, etc: The real case seems to me less trivial than
the simplifications that have followed, but as a general rule I'd be happy
to agree to not fixing spellings: as part of a _coherent_ policy going
in the same direction, it makes perfect sense.
I see no reason why, in principle, a volatile modelled on stable with
just a shorter release cycle shouldn't be viable, and to some degree
effective. I'm happy that there seems to be a rough concensus that
volatile should have a purpose beyond "a shorter release cycle", and
that updates into volatile could be gated (in part) by consideration
of their relevance to that purpose: that seems better to me. I imagine
we're all a little curious or even nervous to find out what 'sufficiently
relevant to purpose' will turn out to be.
That really strikes me, it gets to the heart of things:
the purpose of stable is ...
the purpose of volatile is ...
In the end we will have a good answer and all will be right in the world.
Form will follow from function.
It could easily be that blindly applying all of the expectations that
people bring with them from stable could hobble volatile unduly,
but I hope I'm just imagining that.
But I'm floating away ...
I can't yet see what puts "new command line args" in the same category
as "fixing spelling errors", except if that by the former you mean
gratuitously incompatible changes to the command line interface, in which
case we are in total agreement, but that is not clear given your
previous phrasing: (IIRC) "new command line features".
But, it's a long way by the rules, but quicker by example, so ...
Imagine a hypothetical virus scanner, let's call it foo.
foo v.1 has no command line arguments in normal use: it takes stdin,
it outputs on stdout/stderr. It scans for windows viruses only.
Then, just suppose, foo takes on a capability to scan for a new
Mac virus that is so resource intensive to scan for that the upstream
wisely decide to make it an option: foo -m
(in this particular case it could be argued that a separate name to call
'mfoo', might be better, but is that good answer to the generic problem?)
Question: Can foo v.2 take its '-m' into volatile with it ?
(I intend this as an example of a compatible command line change)
> I do not object to saying that some things must be updated to remain
> useful, and exempting them from the normal stable procedures. But we
> should not exempt the whole *package*, but specific *changes to the
> package*. Only those changes which "must happen for the package to
> remain useful" should be permitted. Other ones should not.
I have considerable sympathy for what I perceive as your point of view,
as I've said elsewhere.
I'm still concerned that this area is considerably less black & white
than, for example, security fixes. Most likely individual maintainers
will arrive at categorisations that in some way parallel those seen
in security: remote hole, local hole, etc. and the whole thing will
look less woolly. Perhaps some generalisation of these categories
across volatile will be possible. No doubt, something
like this already exists of which I am unaware. (I am not unaware
of the grading of bugs for release management, I just can't see how
it will play out).
On a similar note, you seem to advocate 'changes only beyond reasonable
doubt'. I think this may well be the wisest course. After all the
maintainers will be able to answer for such changes from a strong position.
I wonder how the resulting utility would compare to 'changes on the balance
of probabilities' or even 'changes are innocent until proven guilty'.
But then, that's just me.
Actually I take that last paragraph back. Isn't more like 'changes without
any doubt, because a Real Programmer has read the code'. Nothing to worry
about then, maintainer decides.
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: