Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...
Hi Steve,
Steve Langasek wrote:
> On Thu, Oct 23, 2008 at 09:44:33AM +0200, Thomas Viehmann wrote:
>> Raphael Hertzog wrote:
>>> Every kernel upload changing the ABI goes through NEW.
>
>> The typical situation here is that code that has the same set of DFSG
>> bugs is already in place and so it is questionable of what a reject
>> really achieves (i.e. does the archive become more DFSG-compliant or
>> not) and quite typically fixes some RC bugs (not always trashing
>> people's hardware).
>
> This does not seem to be a position universally held by the ftp team, given
> that a library I uploaded to binary NEW ths summer for a
> release-team-approved transition was rejected over a source-only issue of
> not mentioning in debian/copyright a pre-existing user guide not shipped in
> any of the binary packages. Or is it only kernel DFSG-compliance bugs that
> get ignored in binary NEW, while all the other nitpicky checks are grounds
> for a package reject?
Thank you for voicing your concern about inconsistencies you perceive in
the processing of NEW (note that "binary NEW" is not a separate location
to upload to). As with any manual process, particularly when handled by
several individuals, NEW processing will quite probably not be as
deterministic as one might wish, if only in the style of reject
messages, but probably also in cases that are not entirely clear. As you
may know, the ftp team is split into roles of ftp-master and
ftp-assistant, with myself being listed as assistant[1]. I have to
balance my (felt[2]) obligation to provide the project with information
about my work in that position with the fact that my this work
necessarily involves assessments that are neither necessarily uniform
nor binding for other members of the ftp team.
My comment you quote above gives some rationale of why I did choose to
add overrides for certain binaries added by linux-2.6, as Raphaël
pointed out I had. If you disagree with the descision of letting these
pass through NEW, I would be very happy to learn why I should not have
done so in your opinion.
Unfortunately, you do not give a reference, but if the upload of yours
that you have in mind is freetds[3], let me venture that perhaps the
considerations[4] I offered in the thread you started about it in July
might actually help to put both things into more context. I am sorry to
hear that these explanations were not satisfactory to you but must admit
that I may have overlooked previous indication of how they fall short.
Note that I do not agree with you on the issues you raise in[3], but you
surely have more information to add when you bring it up here.
If just did not want to pass the excellent chance of someone on the ftp
team actually posting something to add some flames about the pet grudge
you hold when I was trying to provide information to enable the project
at large to take into account the rationale of actions when deciding
whether to instruct the people to make better decisions than they do by
their own, that is very valuable to me, too. You could be even more
effective by CCing the DPL as surely he will be happy to correct
appointments his predecessor made precisely eight months ago on this
day[5] when they do not work out as expected.
Again, thank you for helping to improve Debian's processes by providing
your critique.
Kind regards
T.
1. http://www.debian.org/intro/organization
2. I had the impression that sometimes the ftp team is criticized as not
operating transparently enough and think that it is reasonable that
the project deserves explanations when they feel that a decision
needs scrutiny.
3. http://lists.debian.org/debian-project/2008/07/msg00017.html
4. http://lists.debian.org/debian-project/2008/07/msg00032.html
5. http://lists.debian.org/debian-devel-announce/2008/02/msg00009.html
--
Thomas Viehmann, http://thomas.viehmann.net/
Reply to: