Re: request for Technical Committee ruling on Bug #109436
On Thu, Aug 23, 2001 at 03:25:09PM -0400, Raul Miller wrote:
> You do understand that this isn't a technical issue?
It is, however, an issue upon which the Technical Committee is empowered
to rule:
Constitution 6.1.2 says the Technical Committee may:
Decide any technical matter where Developers' jurisdictions
overlap.
In cases where Developers need to implement compatible technical
policies or stances (for example, if they disagree about the
priorities of conflicting packages, or about ownership of a
command name, or about which package is responsible for a bug
that both maintainers agree is a bug, or about who should be the
maintainer for a package) the technical committee may decide the
matter.
Constitution 6.1.3 says the Technical Committee may:
Make a decision when asked to do so.
Any person or body may delegate a decision of their own to the
Technical Committee, or seek advice from it.
> There may be other technical issues here, as well.
>
> > It's my package, and I like the name and upstream version number as
> > they are -- clear and unambiguous.
>
> I'd think it's pretty clear that 4.1.0. is the same version as
> 4.1.0
"What does the extra dot mean?" I'm not making changes to XFree86 here
that are going to be obvious to the end user. Again, the non-DFSG
source was dead code and not used for anything. If that's not an
inconsequential change to a source package from a functional aspect,
please describe to me what is.
> Ok, so don't say that you've forked it, because you haven't.
In that case the package is already named in the most obvious possible
way. The upstream distribution is called "XFree86". It has been
downcased to comply with Debian Policy 2.1.3.
> We're talking about a new version of the source tarball.
Correct, if you are referring to file contents.
> You're saying that the new version isn't very different from
> the old one, and that the old one should never have existed.
If I'd been aware of xc/util/patch's licensing before I released
4.1.0-1, I would not have included it. The same goes for every previous
release of XFree86 I have made.
> On the other hand, the old one does exist. The admin folks are
> saying: if you don't want the old version, use a new version.
I hesitate to speak for the archive maintainers, but I don't think
they're saying exactly that. They're saying "if you want a new version,
rename the file."
That, or you're using the word "version" to refer to two different
things in this sentence (the content of the file on one hand, and part
of its filename on the other).
> Um.. but putting your package out on the archives is the work
> of the admin folks, isn't it?
Yes. This is why I'm invoking clause 6.1.2 of the Constiution. My
prerogative to name my package as I see fit within the strictures of
Policy is conflicting with the archive maintainers' prerogative to
administrative the archives as they see fit.
It is not obvious to me that the archive maintainers' decisions should
always trump those of the package maintainers', or vice versa. We have
Policy to demarcate these regions of authority -- and where we don't
have Policy, we have informal consensus. Where we don't have informal
consensus or Policy, we have the Technical Committee.
> We need explicit policy that says "any change to the source
> tarball requires a new version number"?
Such a Policy is neither present, implicit, nor precedented, since in
the past it was perfectly possible to change an .orig.tar.gz by simply
uploading a new one and referencing it accurately in a .dsc file.
So, yes. If that's how the Technical Committee rules, that's what we
need. I would argue that the new policy should not be categorical about
it.
> "I don't want to change the version number", while literally accurate,
> doesn't help me understand why you think we should use same file name for
> "corrected" and "uncorrected" source tarball. Call me stupid if you want,
> but please spell this out.
The current naming and versioning of the .orig.tar.gz are, in my
opinion, optimal within the constraints of existing Debian Policy, and I
do not want to sacrifice that. Furthermore, the only reason I am
changing the .orig.tar.gz at all is because Policy tells me I have to.
The name "xfree86" and the version "4.1.0" are accurate, clean, and
correct.
I do not think Policy should compel me to both change my .orig.tar.gz
ASAP and at the same time compel me to perpetrate some kludge upon its
name and/or version, when such a change is not otherwise pending.
To further elaborate, I would be satisfied with a Policy that said
maintainers are not allowed to change an .orig.tar.gz that exists in the
archive *unless* they're compelled to do so by some other aspect of
Debian Policy. I think it quite reasonable for the archive maintainers
to not want developers to go changing .orig.tar.gz's on a whim (because
it can cause problems, as they have pointed out). I do not think it is
reasonable for the archive maintainers to have an urwritten policy that
effectively attributes all changes to .orig.tar.gz's to developer whims,
meriting rejection of the change.
--
G. Branden Robinson | The first thing the communists do
Debian GNU/Linux | when they take over a country is to
branden@deadbeast.net | outlaw cockfighting.
http://www.deadbeast.net/~branden/ | -- Oklahoma State Senator John Monks
Reply to: