Re: Tracking RFSs as bugs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
aside from my comments below I fully agree to both of your mails.
On 21.09.2011 14:33, Gergely Nagy wrote:
>> 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).
that's pretty much the reason why I am picky to get people to comment in
this thread. I am aware of this problem and I am exploring possibilities
to solve it.
On whatever solution we may agree (or not), Debexpo will need to follow.
That said, I don't want to find a solution in Debexpo the mailing list
has to follow, but the other way around.
I am not sure what the original intention of the author regarding the
comment function was - I didn't implement it. Its clear its not really
usable as is.
On the other hand I know from several people they like the web comment
function, opposing us old, grumpy MUA die-hards and consider it a
worthwhile addition.
Hence my idea was and is to merge the web review part of Expo with our
current or future review solution. So, people using either solution
would be aware of comments from the "other world".
>> - 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.
We would probably need in addition:
- - wontfix: Somebody claims the package is not distributable by Debian
and/or does not belong to Debian. The last point is hard to judge, but
developers should be brave enough to use it by making clear its a vote
on the package, not a personal level. If a developer disagrees he can
still retag and taking over ownership of the bug.
This is to not have many bugs more or less forever in the BTS being
tagged "moreinfo". A wontfix bug would be closed automatically after a
while, say 8 weeks or so.
>> - 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.
> [..]
>
> 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.
As Ansgar says (in his next reply) we should avoid carrying old cruft
forever with us. The inactivity period may be very long, though. I
wouldn't close it based on the date it was filed, but based on the last
activity. That would be conform to your idea I think.
> sponsoring process involves fixing a few issues, the bug can even be
> closed with the changelog).
Quoting myself from IRC for a wider audience: That's semantically wrong,
as its not the maintainer, but the sponsor to fix the bug. It should be
closed by mentors.d.n or/and and by an explicit -done from the sponsor.
> 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.
While I personally wouldn't mind, I know people who disagree here. I
tried to honor their opinion a bit above.
> 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.
>
Frankly, I don't see anything wrong even if we would draw attraction to
sponsor requests by that way as a side effect. Mentoring needs more
attraction among developers.
I truly doubt the amount of sponsor requests is /that/ notable, though.
Its about two fresh requests per day (citation needed).
- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOee4hAAoJEMcrUe6dgPNtTKYQALTqQz1ttKTBuDWO6Ktg/E6l
6lSeZauZnyYj5jqC3j5eF27j72wwSd6/817zYcmulJqzjTBUEe+Lexqd46n3vX1H
xM0CE1yIkE5cCJtuSun0+7uHsHrnA9Z0GmI+3D6nsxx1j8BUlpdh1HiHpsg3SJ8S
lpJOeNDjcdYq2QROHEbNTs7vvgPSsMCtWXmFoPBsjeVsiTlXqXKiaAO4hzQizBD8
XrQbz3NHnCTspqLFqXBoP2DPHbi9P20Pv0aohOIqGPOtk3uwJ2pWUqJF/S/yU0zP
KVVS0pkdDH82vkavj+gl89//HyrbA++bpquek8hULzn46UR7BpTLO+He5eSoJlFF
tJkIgBLZR6JHsQmISVCIvcQ+FvJB+k5cRZsITwtLy8sDeDaSa0qrbhj8Rg3Np/I3
ymVCHaWMgiG0GNuSfrCFUqlQbbFjBGkE2PiDHJ2ZB1W8JVfFAvmgnBxpBaHTer6k
M64tkbapHepZYLHIcCi2r54wb/t+gK7QGtHanU2lxInJobhuqhTBpDzEzy1eglXN
76U+wYHq+2bodqzx9w/qg8haiAi6X1mpL02tubfd7hQaxTR8Uhax3GoZ+cTvvTOS
iY5Vmtc6FB9Jlt8ruoB0pNJ09KPftUtXyW2/JwzuGuaSQ87ZfAJ6CtwxtfyzfFNu
UhQO/0wED1Hp1bqo6iL7
=ZJHZ
-----END PGP SIGNATURE-----
Reply to: