Re: Tracking RFSs as bugs
On Mon, 5 Sep 2011 22:46:11 +0200 Jakub Wilk wrote:
> This is not a new idea:
After reading through that old discussion, I conclude that the highly
confrontational approach chosen by Raphael at that time lead to people
basically tuning him out, and eventually leading to the death of the
That's unfortunate since that pursuit eliminated the BTS as a
solution for the past 9 years, which could have greatly improved the
mentors situation a long time ago. Anyway that's all in the past, and
not worth worrying about anymore :)
So, the two quantified issues back then were that RFS bugs would be
large in number and that there would be BTS "spam" on the mentors ML.
Given that there are over 600,000 debian bugs now, I don't thing the
large number argument holds water any more. As for BTS "spam", I've
followed the debian-release ML for a long time, and have had no problem
basically ignoring it. So I think the quantifiable/technical
opposition doesn't really exist anymore; although some of the
personalities that originally opposed the idea are still around.
Also, while I'm thinking about it, there really good benefits of
reportbug integration. For example, scripts could be built to
automatically CC the relevant teams (i.e. games, java, etc.). I see
this is also part of the debexpo plan . Also, for example I help
with the security team, and it would be helpful to have a "Security NMU"
category that CC's the security team. Also, an "RC NMU" category could
be created for RFSs fixing release-critical bugs (this would help
newbies contribute to the release process). And of course the BTS
has MUA integration (also in the debexpo plan).
So, I feel like I could update reportbugs' debbugs.py script relatively
quickly to be able to support these things (given some free time, which
I should be able to find in the next couple weeks). So, anyway, I'll
plan on looking into that.