On Wednesday, September 07, 2011 09:53:07 AM, Arno Töll wrote:
> Hi Paul,
>
> On 06.09.2011 16:49, Paul Wise wrote:
> > I'm concerned that this might turn out about as useful as filing an
> > RFP bug against wnpp; not very useful at all.
>
> I am not sure, a mailing list is better suited. I was not thrilled to
> use the BTS when I heard about that idea first, but the more I think
> about, the more attractive it gets.
>
> To be honest, the current procedure does not work very well either. Some
> RFS mails are lost in space due to the high volume of requests. The same
> happens for some comments when the maintainer files a new RFS thread
> instead of replying to existing reviews and so on. Finally, nobody knows
> simple things as "how many packages are out there which are seeking an
> uploader", or "what's the status of a particular RFS", without digging
> mailing list archives.
>
> By using the BTS all those features come for free:
>
> * We can merge, retitle, reassign bugs.
>
> * We can tag and categorize bugs ("pending", "reviewed", ...)
>
> * We can easily see which packages are awaiting a sponsor (ok, that
> could be seen on Debexpo as well - but I don't think the "Needs a
> sponsor" flag ever helped to find one.)
>
> * You can finally close bugs with "wontfix" i.e. wontupload instead of
> politely hoping the requester goes away.
>
> * We can track the entire history of an upload easily at one sight. Just
> open the bug.
>
> * Its easy to tell Debexpo about the status of a package - it can just
> use SOAP to query the BTS, instead of guessing/parsing mails from
> mentors and devel-changes ...
>
> * No more broken/incomplete RFS mails anymore (reportbug could take
> care, or even Debexpo could be filing the bug)
>
> * Its convenient and controllable through a handy mail interface to
> sponsors
>
> * Having the debian-mentors mailing list as pseudo package owner still
> discloses every RFS mail to the public easily.
>
>
> I can live to keep things as is, but please let's decide NOW, BEFORE I
> spent a lot of time for writing interfaces in Debexpo to either solution.
After reading all of the above I see that there are a lot of benefits to
having RFS mails in the BTS. And it's interesting in that new packages
already get started via ITP reports to the BTS, so this would basically be an
extension of normal procedure.
The only concern I have is BTS performance from all of the extra "devel"
traffic, which I suspect would be more significant than for normal bug
reports. So the logical thought is whether it would make sense to have a
separate BTS for ITP/RFS/etc tracking rather than the normal BTS or not, since
these wouldn't necessarily need to be handled in the same way that normal bug
reports do. On the other hand setting up another BTS would be a lot of work
and require infrastructure, so this then goes back to the expected performance
hit of devel traffic using the standard BTS would cause.
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
Attachment:
signature.asc
Description: This is a digitally signed message part.