Re: RFD: Draft for a volatile.d.o policy
On Tue, Oct 12, 2004 at 07:57:06AM -0500, John Hasler wrote:
> Sven Mueller writes:
> > Say a new open source network security scanner enters the world...
Yes, I neglected this half of the scenario, but see below.
> I wrote:
> > Those things belong in the non-existent backports.debian.org, not in
> > volatile.debian.org.
> paddy writes:
> > define 'breaks compatibilty'.
> > As long as it _is_ still the same package...
> If a package changes enough to require a new name it is a new package.
Does the converse apply? If not then you have a problem.
> > Basing policy on an implementation detail that should be used for
> > technical reasons, simply for lack of doing the work to arrive at a
> > proper description, would be a mistake.
> I don't understand what you mean by this. Descriptions have nothing to do
> with it.
Yes I wasn't happy with the word decription either but I had hoped it would
My point is this:
I would oppose a policy that said
'packages under new names must not enter volatile'
because I strongly suspect that 'packages under new names' is a poor proxy
for whatever it is you want. In particular it might create a pressure in
a marginal situation on the otherwise technical decision of naming a package.
I hope you will agree that this would be undesirable, even if you contend
that it does not invalidate the use of 'packages under new names' in this
I've suffered the breakage that comes with such naming, and I gave you a
good example. I wouldn't wish to see more pressure on this device.
I would like to know what you want. Because we appear to disagree on the
more fundamental issue of whether new packages *should* ever enter volatile.
I'm hoping we can get to a 'proper description', at which point I would
hope that the whole 'packages under new names' would fall by the wayside,
although I hope I am open-minded enough to be persuaded otherwise.
Let me articulate my opposition to closing down the possibility of new
packages in volatile.
We don't need just another backports.
Nor do we need just another stable.
Packages entering volatile should do so for a good reason.
I would support your position modified to 'should not _automatically_ enter'
for new major versions of packages already in volatile. There should be
a good reason.
Volatile must be free to package software that is not in stable, this is
its reason to exist.
Being too rigid about this could result in packages in stable have dependencies
across stable, volatile and backports, or not being able to fulfill the
purpose of being usefull.
If you want a clone of stable, you might as well say 'nothing can enter after
stable is released', which is mighty close to what you are saying, only
noone is saying that because it _so_ obviously ridiculous.
I hope that volatile will play very nicely with stable. For me that is the
whole point. But I don't expect it to have a two to three year release cycle.
That is also the point. But most of all it should exist for a purpose,
and I would not see that purpose hobbled by knee-jerk reactions, although
I _am_ keen to try to understand what your point is.
Perl 6 will give you the big knob. -- Larry Wall