[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Q to all candidates: NEW queue



Le 27/03/2020 à 10:03, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-03-27 09:38:54)
>> Le 27/03/2020 à 09:22, Ulrike Uhlig a écrit :
>>> Hi!
>>>
>>> On 26.03.20 15:05, Lucas Nussbaum wrote:
>>>> On 26/03/20 at 14:42 +0100, Jonas Smedegaard wrote:
> 
> For the avoidance of doubt, I wrote none of below quoted text.
> 
>>>> A/
>>>> - package is uploaded
>>>> - package waits in NEW
>>>> - package gets reviewed, gets accepted in unstable with a bug filed
>>>> - bug gets fixed
>>>>
>>>> B/
>>>> - package is uploaded
>>>> - package gets accepted in unstable
>>>> - package gets reviewed, a bug is filed
>>>> - bug gets fixed
>>>>
>>>> Except that with (B), we avoid the wait in NEW.
>>>
>>> In scenario B, the wait is shorter, but there is no guarantee that the
>>> bug gets fixed in an appropriate time frame.
>>>
>>>> One important question is: how often does the FTP team run into a
>>>> package that is so problematic that accepting it in Debian with an RC
>>>> bug is not an option?
>>>
>>> Another question is: what other things are reviewed by the FTP team?
>>> Like, is there some sort of basic security review, are there packages
>>> that are not appropriate to be uploaded to the archive for some reason
>>> or another? And then this would not just result in an RC bug, I guess?
>>>
>>> Ulrike
>>
>> Hi
>>
>> And what about creating "pre-ftp-master" in teams ? They could fix team
>> policy and do a technical review. This will avoid common errors and may
>> decrease ftp-master work.
>>
>> This proposition is based on JS-Team experience: some people pushed JS
>> packages without knowing JS tools and practices. These packages often
>> contains pre-build objects and a few other common errors. Sadly some DD
>> push such packages with JS-Team as maintainer without being member of
>> this team, neither asking for help/review from JS team!
>>
>> Then scenario C:
>>  - package is uploaded
>>  - ftp-master redirects package to pre-ftp-master(s) [using BTS?] who
>>    are concerned
>>  - package gets pre-ftp-master(s) review [BTS(s) closed]
>>  - package gets ftp-master's review
>>  - package is released
> 
> Sorry, maybe just me, but is above a question to DPL candidates?
> 
> I mean, teams certainly do not need DPL to permit them to packaging 
> prepare packages before bothering ftp-master with them, or...?
> 
>  - Jonas

This change a little actual process. Example if a package contains
plural languages, ftp-master ask for review to the different
pre-ftp-masters of concerned teams. Example: a Perl package that
contains JS is pre-reviewed by 2 pre-ftp-masters. This may decrease
ftp-master work since new packages may have better quality before
ftp-master review.


Reply to: