-----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----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
