[...] > > The BTS provides a good way to track requests. But mentors.d.n does, > too. On the other hand, the BTS doesn't have a useful interface to > search, filter and sort RFSes based on various criterias, such as: > - is the package already in Debian? (sponsoring a second upload is > easier) > - did I sponsor the previous upload? > - is the package related to Ruby (easy to determine by grepping > build-depends and depends) > - ... > What about usertags and usercategories? I believe the BTS could do a really good job here if used in the right way. > all of this can easily be implemented on mentors.debian.net, but cannot > be added to a BTS pseudo-package. So I don't see the point of using a > BTS pseudo-package instead of mentors.d.n. (I also don't see the point of > using mentors.d.n together with a BTS pseudo-package.) > In my opinion the BTS and mentors.d.n could serve two somewhat distinct parts of the process: clearly we need a space that packages can be uploaded to. Indeed the BTS would do poor job if source packages got uploaded as attachments to the BTS. On the other hand, the BTS is an excellent platform to track sponsoring progress, making all the comments over time available in a single bug log. > Additionally, it's very important to note that not all packages should > eventually be uploaded, so the fact that some packages never get > sponsored is a feature. Debian doesn't want to contain every piece of > free software ever written, because some of them have better > alternatives already in Debian, for example. How would you deal with > that with a BTS pseudo-package? After some time, there will be a few > hundred RFSes that should never ever be uploaded to Debian, but are > still open. Who gets to decide that they can be closed? > As Arno outlined before, all we would see here is an improvement (if any change) - who is it that gets to decide now? Its the community and the decision is communicated by not responding to (possibly repeated) RFS. With the BTS, this could be tagged as wontfix. In some earlier email I stated that we should probably come up with a dedicated sponsoring team that gets to handle the bureaucratic bits. It would, IMHO, then be this team's work to close such bugs from time to time. Best regards, Michael
Attachment:
pgpV3_rTaqiZJ.pgp
Description: PGP signature