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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
