Re: Tracking RFSs as bugs
On Mon, 5 Sep 2011 20:51:47 +0100 Michael Tautschnig wrote:
> I'm all for tracking RFS in some more formal way, it would quite a bit reduce
> the load on my inbox (which I'm currently using for tracking).
>
> There is one fundamental difference, however, to, e.g, the release team: there
> is no *team*. Who are "they" in case of sponsoring?
Well, perhaps its time to formalize that? Let's make mentors a .org
and get the DPL to do some "official" appointments. I'm willing to
volunteer for that (I'm only a DM now, but I've run into enough
limitations with my DM status lately that I'm starting to feel like I
should really be going for DD now). Who else is willing to volunteer?
> What makes the situation
> worse is that the number of people filing RFS is unbounded, this process is open
> to everyone (don't get me wrong, this is a good thing in general).
I agree, this is a very good thing. I'm hoping this approach will make
supporting so many people a more tractable thing.
> I don't think technical infrastructure alone will solve those problems. In fact,
> mentors.debian.net would already have all the necessary infrastructure: packages
> are uploaded there and hence tracked. It is possible to leave comments, and
> maybe this whole RFS business should just move over to mentors.debian.net.
Yes, the new infrastructure really is an improvement, but it does have
some issues, which of course may be easily fixable with the current
framework. For example, discussion on the mentor's package pages isn't
reproduced on the mentors ML and vice versa; as would be done with a
BTS package and associated mailing list. There is no email-based option
to the web interface. Also, aestetically, the new mentors system
reproduces functionality already available via the bug system. Finally,
and maybe this is because the oldness only goes back to July now, there
isn't really as sense of what's old and thus a candidate to close out;
and even so it's not possible to close out other's packages (with an
option to reopen) like on the BTS.
Also, a very useful thing (I think) would be reportbug integration.
Thus submitters would be able to reference their existing ITP
submission and not have to re-enter the same information in their RFS
(this duplication has always irked me about the mentors process).
> Oh, and with all this moaning about RFS not being dealt with in a timely manner:
> true, we don't manage to get packages reviewed and sponsored within 4 days, but
> is the situation really that bad at the moment?
I'm not trying to bemoan the situation; just trying to be proactive and
thoughtful about finding ways to make it better.
> Are there any packages older than one month still waiting for sponsorship?
You can see all of the packages currently in limbo at [0]; although
it's not currently possible to select only those older than a month
(although that too could probably be implemented relatively easily with
the new expo framework). I for example have a set of old packages
awaiting further review [1]. Admittedly a lot of those are back in my
court to fix some issues, and its my fault for forgetting about them;
although I feel like I would be less inclined to do that if they were
tracked as bugs and tagged with moreinfo (although then again something
similar could be implemented on mentors), and with someone poking me
every now and then saying this is really old and you haven't worked on
it, so we're going to close it.
So, anway it boils down to the fact that the BTS already has all of these
wonderful features, and mentors could get them, but if they're already
available why go though the duplicative process? If I could choose, my
approach would be to go the BTS route and better integrate the mentors
pages with that and vice versa.
Best wishes,
Mike
[0] http://mentors.debian.net/packages/index
[1] http://mentors.debian.net/packages/uploader/michael.s.gilbert%40gmail.com
Reply to: