Hi Paul, Am Thu, Apr 28, 2022 at 06:46:43PM +0800 schrieb Paul Wise: > There are two main categories of NEW packages; source and binary. > Packages adding an new source should have an ITP bug, but don't > always, for eg the Rust/Golang teams don't file them for every > library. Packages adding a new binary package often have a transition > bug, but those are usually filed after the upload is accepted. > > Filing a new WNPP bug for every NEW package upload seems a bit tedious > and I think lots of people aren't going to bother/remember to do it.
But filing an ITP bug is cheap. The R-pkg team has a script itp_from_debian_dir[1] which creates this bug automatically once the packaging work is done. > The proposal I make would mean that the manual bug filing for every > upload wouldn't be needed, instead the BTS would know about packages > in NEW and ftpmasters and others could file bugs against them, which > would mainly only be needed when there are REJECTable issues present. > > In addition there could be separate bugs for each individual issue, > rather than one long discussion about multiple different issues. > This is probably especially important for low severity issues. I'm fine with this suggestion as well. > > (BTW, I usually bounce any reject to the according WNPP bug to have > > the issue documented in a publicly visible place where any interested > > person should look.) > > That seems reasonable if the ftpmasters are fine with that. Ftpmaster did not agreed with my suggestion so far. > If the > BTS for NEW proposal gets implemented it would no longer be needed. That's true. I just wanted to mention that some of your ideas are in a way used even now. > Am Thu, Apr 28, 2022 at 08:54:05AM +0800 schrieb Paul Wise: > > > > The changes that are needed to make this happen include: > > I guess tracker.d.o would also need to show NEW packages. This would be extremely helpful. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/scripts/itp_from_debian_dir -- http://fam-tille.de