Re: Tracking RFSs as bugs
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
Reply to: