On 05/09/11 at 15:12 -0400, Michael Gilbert wrote: > Hi, > > I've been thinking about how mentors works lately (after watching > Asheesh's debconf11 talk). It seems like the 4 day response effort > worked somewhat well for a while, but kind of tailed off, and I've been > pondering what could be done instead that would have some staying power. > > I've noticed that the release team has a lot of success addressing their > issues in a rather timely manner. I think that this success comes from > the fact that they treat all of the items they need to accomplish as > bugs [0]. So, as requests get old, they notice that and do something > about it (or they just close it out if the submitter isn't responsive). > > Anyway, I think mentors could greatly benefit from a similar work flow. > So, I was wondering if there were any thoughts on setting up a > mentors.debian.net pseudo-package [1]? It seems like all of the > existing ones are debian.org features, so I'm not sure if that would > require mentors becoming an "official" .org service first or not? > > Anyway, I think this could be a really significant improvement to the > mentors culture.
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) - ... 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.) 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? Lucas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
