On Thu, 2022-04-28 at 09:36 +0200, Andreas Tille wrote: > What about WNPP bug? When I asked ftpmaster to kindly CC their > rejects to the WNPP bug I was told that not all packages in new have WNPP > bugs. If we want to formalise this it could probably be enforced that new > packages really need to have such a bug and we only need to decide > for existing packages that need to pass NEW. 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. 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. > (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. If the BTS for NEW proposal gets implemented it would no longer be needed. 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. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part