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: > >> 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 Cheers, Xavier
