Re: Tracking RFSs as bugs
I wanted to comment on this thread, but for some reason, it always fell
off my radar. No more!
Ansgar Burchardt <ansgar@debian.org> writes:
> I do not sponsor very much,
While I don't sponsor at all at the moment, because I'm not a DD right
now, if and when I become one, I do wish to sponsor from time to
time. And until then, I wish to occassionally contribute with package
reviews.
Hopefully my input, despite these shortcomings, will be useful.
> but I am a bit unhappy about having comment possibilities on both
> mentors.d.n and the mailing list with information not forwarded.
Whatever happens, the end result should be that comments would be
visible on all commonly used places: on this list, and on mentors.d.n
(possibly including the BTS, my personal preference).
> This results in duplicate work (for example I reviewed a package that
> already had a review on mentors.d.n pointing out the same issues).
Even worse is the case where issues are pointed out in one place, and
the package gets uploaded nevertheless, because another sponsor did not
spot the same mistake, and didn't check
$ThisOtherPlaceSomePeopleUseToComment.
> Which system we end up using, I do not really care about, but I would
> prefer if it was accessible by mail (for both reading and writing
> comments).
Same opinions here. Mail allows me to tag, mark and otherwise sort the
stuff I want to review, or find interesting. Doing the same on the web
is far more painful (and for that reason, I don't even attempt to do
it).
> For a BTS-based workflow as proposed I had these ideas (based on [1],
> but without using usertags to keep things a bit simpler):
>
> - A new pseudo-package mentors.debian.org (or whatever) is created; the
> maintainer is set to debian-mentors@l.d.o so all bug mail is sent to
> there.
>
> - New requests should use "RFS: <package>/<version>"; maybe with
> "[NEW]" appended for packages not yet in the archive.
> It might be helpful to have mentors.d.n be able to file them (on
> manual request).
>
> - Comments are sent to the BTS. Tags are used as follows:
> - moreinfo: Open questions or changes are required before an upload.
> - confirmed: Somebody did review the package and thinks it is okay.
> (Not needed when the package is directly uploaded.)
> - pending (closing the bug): Somebody will (did) upload the package
> (no further changes required).
I like this.
> - mentors.d.n automatically closes RFS bugs for uploaded packages or
> packages that were removed from there. It may also automatically
> close inactive bugs.
Apart from closing inactive bugs automatically, I believe this is a good
idea.
Some non-trivial packages might take some time to review, especially if
it turns out there are some issues that need to be solved upstream
before an upload can happen (ie, packaging is spot-on, and perfect, but
upstream needs to clarify a license, for example).
I think it's worth having that RFS bug still open, and pinging it once
in a while only adds noise. Closing it, and opening a new one (or
reopening the same) would only be noise, in my opinion.
Instead, I'd propose using the "pending" tag for this case. Packages
that get uploaded can be closed with mailing -done@ (and if the
sponsoring process involves fixing a few issues, the bug can even be
closed with the changelog).
With using 'pending', it would be possible to filter out uninteresting
requests, and everyone's staisfied.
> It would still be possible to provide a web interface for comments on
> mentors.d.n: it would just create a mail to the BTS and also set the
> appropriate tags.
Instead of mentors.d.n automatically doing the mail (which would be a
dumbed-down web interface to the BTS), it would in my opinion, be better
if it had the appropriate mailto: links instead, and provide a read-only
interface to the comments only.
But all in all, once I'm a DD again, I'd love to have sponsoring support
in the BTS. I know and love that thing, and use it daily anyway, it
would be a huge improvement over the current status quo, even if
mentors.d.n would not have explicit support for it at first:
* The BTS provides a familiar interface for DDs, one that can be easily
archived, tagged and otherwise sorted.
* It provides a web interface, ability to download full RFS 'sessions'
as mbox.
* One can subscribe to specific RFS bugs, and collaborate with other
reviewers easily, as it all ends up in the same place.
* This latter feature also makes it easier to notice replies. When one
has a huge volume of mail to go through daily (hi lkml, bugs-dist,
devel, mentors, devel-changes and a whole lot of other lists.. ;), it
helps if I could subscribe to RFS requests I reviewed, so I
immediately see if I get a response, without having to write specific
filters for this case, or look into my mentors folder.
...and I don't see a downside of using the BTS, apart from making some
minor noise on -devel-changes and -bugs-dist perhaps. But the amount of
RFS traffic is going to be very minor noise, compared to the volume
those lists have now.
Being subscribed to both -bugs-dist and -devel-changes among other high
volume lists, I wouldn't mind the extra "noise" to be honest. Probably
wouldn't even notice the difference in volume.
--
|8]
Reply to: