Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 09/04/13 17:54, Bernd Zeimetz wrote:
> On 02.04.2013 22:48, Thomas Goirand wrote:
>> On 04/02/2013 12:16 AM, Luca Falavigna wrote:
>>> In a perfect world there wouldn't be any need for a NEW queue at all.
>>> But we have to face with the reality.
>>> We try to do our best to improve things where we can. From the FTP
>>> Team side, we always try to be quick and helpful with our fellow
>>> developers, and are happy to hear about suggestions how to improve
>>> further.
>> I got a bunch of suggestions...
>>
>> Suggestion #1: if a package stays more than a month in the NEW
>> queue, then it gets automatically approved, and may be
>> reviewed later on. My reasoning is that more than a month,
>> it can become really problematic and blocks development.
>
> No. Go back to start and learn why there is a NEW queue.
>
>> Suggestion #2: get rid of the new binary queue (not new source
>> package, that's different). There's no reason why the licensing
>> of a package changes just because the maintainer decides to add
>> a new binary, so it makes no sense. This would save a lot of
>> time for the FTP team.
>
> No. Go back to start and learn why there is a NEW queue.
That answer is not so clear
Plenty of packages have evolved with new upstream releases over many
years without any ongoing review by the FTP masters. I'm sure I could
find one that has subsequently and inadvertently become non-free if I
really looked hard enough.
Why should review only take place on those packages that the maintainer
chooses to modularise?
Isn't it the content of the source package that needs review? Maybe the
review should be triggered by some other factor? For example, every
time a new upstream major release number increment occurs, the upload
goes into NEW?
>> Suggestion #3: have a system where any other DD can review
>> a package in the NEW queue, not only the FTP masters or the
>> FTP assistants.
>
> That would include publishing the contents of the NEW queue,
> at least to all Debian Developers - so we might violate
> licenses already.
That is not a watertight argument either - it would be quite feasible to
publicize the source package without making the upstream tarball public.
Just make sure that other DDs can see a link to the upstream tarball on
the upstream web site, and the hash from the changes file
This would actually be a very good way of helping to distribute the
workload of FTP masters as all DDs could presumably practice rejecting
things, while the decision to accept something would remain with the FTP
master.
I also value the work of the FTP masters and everybody who scrutinizes
packages to make sure they really are free and open. Just look at the
Android market for an example of what would evolve without such efforts.
Reply to: