Re: Tracking RFSs as bugs
Hi, I do not sponsor very much, but I am a bit unhappy about having comment possibilities on both mentors.d.n and the mailing list with information not forwarded. 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). 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). 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). - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. It may also automatically close inactive bugs. - Packages tagged both moreinfo and confirmed get the confirmed tag removed automatically. 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. Regards, Ansgar [1] http://wiki.debian.org/PackageReview -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s2svcsm447s@bistromathics.mathi.uni-heidelberg.de
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 ans...@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
Re: Tracking RFSs as bugs
Hi, Gergely Nagy alger...@balabit.hu writes: Ansgar Burchardt ans...@debian.org writes: - 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). That will make the pseudo-package accummulate lots of open bug reports that never see any attention. So I think inactive requests need to be dealt with one way or another, closing them automatically after a longer term of no activity does seem as easy way to do so (ie. after 4-8 weeks of no new comments). For reviews that take a longer time, the sponsor could set himself as the owner of the bug -- bugs with an owner would then not be closed. This maybe can also be extended to bugs tagged confirmed. An other idea I had when discussing this on IRC would be using the summary field of the bug report to link to the current source package and (optionally) also the page on mentors.d.n for the package. For this to be easily set automatically, we might however need to add a new command to debbugs (as the current summary command has to refer to an already existing message). 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. Sure, I don't mind either way. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s2sd3eu10oq@bistromathics.mathi.uni-heidelberg.de
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
Re: Tracking RFSs as bugs
Ansgar Burchardt ans...@debian.org writes: Gergely Nagy alger...@balabit.hu writes: Ansgar Burchardt ans...@debian.org writes: - 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). That will make the pseudo-package accummulate lots of open bug reports that never see any attention. So I think inactive requests need to be dealt with one way or another, closing them automatically after a longer term of no activity does seem as easy way to do so (ie. after 4-8 weeks of no new comments). In my opinion, RFS bugs that see no attention, but get uploaded can be closed automatically: if the version in unstable is = than on mentors, and the bug did not see any activity in a while (~4-8 weeks, as you said), then it can be safely closed. If it was never uploaded, then I would still opt for manual handling. Perhaps a monthly report could be made, where inactive bugs can be listed, and volunteers could glance over the list, and deal with said bug reports. (And I hereby volunteer to do that, and help setting up such a monthly report, in the very desired case of RFS's moving to the BTS) The reason behind this, is that RFS with no feedback is something that should not happen, as it's a big discouragement for the requestor, for one. Keeping them open, with a monthly report would make it easier to see what needs urgent attention. For reviews that take a longer time, the sponsor could set himself as the owner of the bug -- bugs with an owner would then not be closed. This maybe can also be extended to bugs tagged confirmed. ACK, sounds good! -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqiu56qj@balabit.hu
Re: Tracking RFSs as bugs
* Ansgar Burchardt ans...@debian.org, 2011-09-21, 11:47: I do not sponsor very much, but I am a bit unhappy about having comment possibilities on both mentors.d.n and the mailing list with information not forwarded. Same here. - 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). Agreed. - 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.) Let me bikeshed a little here. ;) I'd use confirmed merely to indicate that either: a) the package is already in the archive or b) it's a new package and a DD believes it would be a good addition to the archive. Note that the latter option is not necessarily a declaration of willingness to sponsor the package - I'd use owner for that purpose. - pending (closing the bug): Somebody will (did) upload the package (no further changes required). I'm not sure if pending would be ever useful (except maybe for uploads to DELAYED). - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. I think I'd prefer this to be done manually. Sending an Uploaded, thanks! mail to nnn-d...@bugs.debian.org shouldn't be a big effort for sponsors... It may also automatically close inactive bugs. Yes, this is quite important, or else we'll drown in bugs. Of course, we would have to define what is inactive. One of my packages was sponsored 8 months after I sent the RFS... - Packages tagged both moreinfo and confirmed get the confirmed tag removed automatically. With my proposal on how to use confirmed this won't be needed. In fact, it'd very typical for an RFS to be tagged both confirmed (= the package is welcome) and moreinfo (= needs more work). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110921173002.ga2...@jwilk.net
Re: Tracking RFSs as bugs
Hi, Jakub Wilk jw...@debian.org writes: - 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.) Let me bikeshed a little here. ;) I'd use confirmed merely to indicate that either: a) the package is already in the archive or b) it's a new package and a DD believes it would be a good addition to the archive. Note that the latter option is not necessarily a declaration of willingness to sponsor the package - I'd use owner for that purpose. I discussed this with Jakub on IRC and we came to the conclusion that (experienced) reviewers or DDs who believe the package is not totally insane. It does not need to have gone through a thorough review, though it certainly would not hurt either. - pending (closing the bug): Somebody will (did) upload the package (no further changes required). I'm not sure if pending would be ever useful (except maybe for uploads to DELAYED). Hmm, I thought about using it in case the sponsor did review the package, but will only upload later (for whatever reasons). But I guess he could just close the bug right away as well. I do not think uploads to DELAYED should be handled differently as the sponsor will just forget to close the bug later. - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. I think I'd prefer this to be done manually. Sending an Uploaded, thanks! mail to nnn-d...@bugs.debian.org shouldn't be a big effort for sponsors... Agreed, but having mentors.d.n cleaning up (semi-)automatically in case the mail went to nnn@bugs.d.o instead of nnn-done@bugs.d.o should not hurt. - Packages tagged both moreinfo and confirmed get the confirmed tag removed automatically. With my proposal on how to use confirmed this won't be needed. In fact, it'd very typical for an RFS to be tagged both confirmed (= the package is welcome) and moreinfo (= needs more work). Agreed. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uv9zlro@deep-thought.43-1.org
Re: Tracking RFSs as bugs
Ansgar Burchardt ans...@debian.org writes: - pending (closing the bug): Somebody will (did) upload the package (no further changes required). I'm not sure if pending would be ever useful (except maybe for uploads to DELAYED). Hmm, I thought about using it in case the sponsor did review the package, but will only upload later (for whatever reasons). But I guess he could just close the bug right away as well. I do not think uploads to DELAYED should be handled differently as the sponsor will just forget to close the bug later. Wouldn't the fixed tag work for cases where the package is reviewed, and will be uploaded VerySoon(tm)? -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwjpr3qh@luthien.mhp
Re: Tracking RFSs as bugs
Gergely Nagy alger...@madhouse-project.org writes: Wouldn't the fixed tag work for cases where the package is reviewed, and will be uploaded VerySoon(tm)? Please disregard that, I had a brainfart. Apologies for the noise. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877h51r36s@luthien.mhp
Re: Tracking RFSs as bugs
Hello, I've just got a thought... We already have ITP bugs. Why not just retitle them into RFS when someone wants their package to be sponsored? -- WBR, Andrew signature.asc Description: PGP signature
Re: Tracking RFSs as bugs
* Andrew O. Shadura bugzi...@tut.by, 2011-09-08, 23:54: We already have ITP bugs. Why not just retitle them into RFS when someone wants their package to be sponsored? Not all sponsored packages are new. I'd hope most of them are not! -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110908210327.ga1...@jwilk.net
Re: Tracking RFSs as bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. - -- 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/ iQIcBAEBAgAGBQJOZ3dDAAoJEMcrUe6dgPNtMnMP/3pqdRQb30iEfB3/vTBjPQXl B8ORKdRHGFs+5gEgXdeUBRBz6hTKGu62xIChcnsm3FadJiHmH9IgfKo12kBLtq/A nhutsFoONGW1hJKs45BzqWXKRMtMXqjP/c1Ek4Evq75T69KQ+dSIrU03dinUVEqg nyEgRs1tWnDoKl6klID3IEdtJZUS6oDnuiOQy7iF/Aodxq7OrMygLnaM5/P2MUOX 95cIsNAxA9LGrFi/Yw3uV3Xr0DVcqWkkZd/wdchaMvHJWX0EHn+tJKkoZk8HJOfU I8bOAyrWv15eSnn36e/0FIJkBGTKJkS/EsRGkaFIsV8kxPmKZIKpJHqWp7QKDimM 7/xp2v3kYsLs3AXt5P1uaHt90/IlKjj1wEbLSmg3/YkzvMEdU2jtFHMLAxfvL7Yb ee/1F84cvROxnv6xE1l+76pxI6rWEDGqzFtWznL3gi8uTzQA5UTk9lwRVXgtLla/ t3taet8jhhQMEfbkM7bJDxSXbMEUED+8yk0IbSKnLEh6XvkKDJaFyROFk332iMT2 AEjLRBGb8uq3We/GSpYc7q18kjGyLkC6F7Hjfpux86MYeHK5x/Nji75ViLH5l1/0 c4IiY3TvvBxo/RsZ7CFyK8qUzD9b/7fjxoy4UQEWh16GzWxkyAFb0yi/P3a09F/Z FRLT3JftDjmm1bEY2+/W =o+0W -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e677743.3090...@toell.net
Re: Tracking RFSs as bugs
On 05/09/11 at 15:12 -0400, Michael Gilbert wrote: Hi, I've been thinking about how mentors works lately (after watching Asheesh's debconf11 talk). It seems like the 4 day response effort worked somewhat well for a while, but kind of tailed off, and I've been pondering what could be done instead that would have some staying power. I've noticed that the release team has a lot of success addressing their issues in a rather timely manner. I think that this success comes from the fact that they treat all of the items they need to accomplish as bugs [0]. So, as requests get old, they notice that and do something about it (or they just close it out if the submitter isn't responsive). Anyway, I think mentors could greatly benefit from a similar work flow. So, I was wondering if there were any thoughts on setting up a mentors.debian.net pseudo-package [1]? It seems like all of the existing ones are debian.org features, so I'm not sure if that would require mentors becoming an official .org service first or not? Anyway, I think this could be a really significant improvement to the mentors culture. The BTS provides a good way to track requests. But mentors.d.n does, too. On the other hand, the BTS doesn't have a useful interface to search, filter and sort RFSes based on various criterias, such as: - is the package already in Debian? (sponsoring a second upload is easier) - did I sponsor the previous upload? - is the package related to Ruby (easy to determine by grepping build-depends and depends) - ... all of this can easily be implemented on mentors.debian.net, but cannot be added to a BTS pseudo-package. So I don't see the point of using a BTS pseudo-package instead of mentors.d.n. (I also don't see the point of using mentors.d.n together with a BTS pseudo-package.) Additionally, it's very important to note that not all packages should eventually be uploaded, so the fact that some packages never get sponsored is a feature. Debian doesn't want to contain every piece of free software ever written, because some of them have better alternatives already in Debian, for example. How would you deal with that with a BTS pseudo-package? After some time, there will be a few hundred RFSes that should never ever be uploaded to Debian, but are still open. Who gets to decide that they can be closed? Lucas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110907173901.ga23...@xanadu.blop.info
Re: Tracking RFSs as bugs
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.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Re: Tracking RFSs as bugs
[...] The BTS provides a good way to track requests. But mentors.d.n does, too. On the other hand, the BTS doesn't have a useful interface to search, filter and sort RFSes based on various criterias, such as: - is the package already in Debian? (sponsoring a second upload is easier) - did I sponsor the previous upload? - is the package related to Ruby (easy to determine by grepping build-depends and depends) - ... What about usertags and usercategories? I believe the BTS could do a really good job here if used in the right way. all of this can easily be implemented on mentors.debian.net, but cannot be added to a BTS pseudo-package. So I don't see the point of using a BTS pseudo-package instead of mentors.d.n. (I also don't see the point of using mentors.d.n together with a BTS pseudo-package.) In my opinion the BTS and mentors.d.n could serve two somewhat distinct parts of the process: clearly we need a space that packages can be uploaded to. Indeed the BTS would do poor job if source packages got uploaded as attachments to the BTS. On the other hand, the BTS is an excellent platform to track sponsoring progress, making all the comments over time available in a single bug log. Additionally, it's very important to note that not all packages should eventually be uploaded, so the fact that some packages never get sponsored is a feature. Debian doesn't want to contain every piece of free software ever written, because some of them have better alternatives already in Debian, for example. How would you deal with that with a BTS pseudo-package? After some time, there will be a few hundred RFSes that should never ever be uploaded to Debian, but are still open. Who gets to decide that they can be closed? As Arno outlined before, all we would see here is an improvement (if any change) - who is it that gets to decide now? Its the community and the decision is communicated by not responding to (possibly repeated) RFS. With the BTS, this could be tagged as wontfix. In some earlier email I stated that we should probably come up with a dedicated sponsoring team that gets to handle the bureaucratic bits. It would, IMHO, then be this team's work to close such bugs from time to time. Best regards, Michael pgpQBxF11mPlr.pgp Description: PGP signature
Re: Becoming DM [was: Re: Tracking RFSs as bugs]
On 06/09/2011 23:47, Michael Tautschnig wrote: Hi Chris, [...] As said above: I for one would be perfectly fine to offer this kind of mentoring to you. I'm not sure whether you had ever had a negative answer to such a request for mentorship - have you ever asked for it (before)? I had a mentor for about a year when I first started packaging. His responses to my occasional emails were invaluable, but we lost touch last year when he moved jobs/email addresses. There is a huge difference between reading debian-policy (or the wiki, or whatever other resource), and having someone bring it to life applied to your own work. At the start of this year I asked for a new mentor, on both debian-mentors[1] and (after nobody replied) on debian-devel-games[2]. I have 'joined' the games team on IRC, and have been told that the way to get a sponsor is to do outstanding packaging tasks on other games. Since I'm not yet good enough at packaging to do this, I have tried to contribute to the wiki instead[3], though this has been stalled by RL over the summer. I would very much appreciate your help. May I email you? Regards, Chris -- [1]http://lists.debian.org/debian-mentors/2011/01/msg00249.html [2]http://lists.debian.org/debian-devel-games/2011/02/msg00053.html [3]http://wiki.debian.org/Games/IntoDebian -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e67d201.9040...@gmail.com
Re: Becoming DM [was: Re: Tracking RFSs as bugs]
Hi Chris, [...] I would very much appreciate your help. May I email you? I wouldn't claim I could answer all your questions, especially when it comes to games-specific ones, but at least I'll try my best to help. So yes, please go ahead. Best, Michael pgp6wMMNMscgR.pgp Description: PGP signature
Re: Becoming DM [was: Re: Tracking RFSs as bugs]
On Mon, Sep 5, 2011 at 11:09 PM, Michael Tautschnig m...@debian.org wrote: Could you please be more precise about that last bit? What exactly is hard about becoming DM? I really wish more people applied for DM. Sponsoring the same package more than a few times makes little sense in most cases (there are exceptions, and I for one are regularly sponsoring at least one such exception). I think that he really wants to say: it is hard to get a (first) package into debian. That is not a problem which is solved by becoming a DM. I have never faced problems finding sponsors for updates of my package, and I don't have the impression that it are those packages which don't find a sponsor. Apart from that: I haven't applied for DM yet because I still found it useful that someone reviews my package prior to uploading. Although one can also argue that that is partly the role of 'unstable'. Johan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJOp35=chmkx0pbq1d3o4daunefrmyxojybwvd6_rehvy_h...@mail.gmail.com
Re: Becoming DM [was: Re: Tracking RFSs as bugs]
Le Tue, Sep 06, 2011 at 10:29:34AM +0200, Johan Van de Wauw a écrit : Apart from that: I haven't applied for DM yet because I still found it useful that someone reviews my package prior to uploading. Although one can also argue that that is partly the role of 'unstable'. Dear Johan, DM and DDs can also ask for comments on debian-mentors. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110906083639.ga7...@merveille.plessy.net
Re: Tracking RFSs as bugs
Il giorno mar, 06/09/2011 alle 08.12 +0900, Charles Plessy ha scritto: Le Mon, Sep 05, 2011 at 10:46:11PM +0200, Jakub Wilk a écrit : * Michael Tautschnig m...@debian.org, 2011-09-05, 20:51: I've noticed that the release team has a lot of success addressing their issues in a rather timely manner. I think that this success comes from the fact that they treat all of the items they need to accomplish as bugs [0]. So, as requests get old, they notice that and do something about it (or they just close it out if the submitter isn't responsive). This is not a new idea: http://lists.debian.org/debian-mentors/2002/08/msg00262.html And http://wiki.debian.org/PackageReview :) I'm really not much active in sponsoring/reviewing, neither in asking for sponsorship/reviews, but my very humble opinion is that _this_ is the right approach, the only systemic one that can change things. Except that I would require at least 2 reviews of other packages, not just one. Pietro Battiston -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1315303707.2494.41.ca...@demporaneo.pietrobattiston.it
Re: Tracking RFSs as bugs
I'm concerned that this might turn out about as useful as filing an RFP bug against wnpp; not very useful at all. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GGWEk28=WKHq7kXq6os7H=ymcoydvvbvqym0bzfke...@mail.gmail.com
Re: Tracking RFSs as bugs
I'm concerned that this might turn out about as useful as filing an RFP bug against wnpp; not very useful at all. Hmm, not sure - after all, people are still free to remind potential sponsors about outstanding RFS via debian-mentors. Well, and with such a new tracking possibility, e.g., sprints could be organized from time to time. We'd definitively need some more formal assignment of responsibilities for sponsoring. People assigned those responsibilities are required to ask for help from time to time, organize such sprints, send pings for open RFS tagged more-info (or close them), work closely with the authors of debexpo, and probably some other tasks that go beyond the basic step of sponsoring uploads. Best, Michael pgpyEJzCB5alJ.pgp Description: PGP signature
Re: Tracking RFSs as bugs
On Mon, Sep 05, 2011 at 04:49:59PM -0400, Michael Gilbert wrote: Also, a very useful thing (I think) would be reportbug integration. Thus submitters would be able to reference their existing ITP submission and not have to re-enter the same information in their RFS (this duplication has always irked me about the mentors process). FWIW, debexpo lists the bugs that are closed by the package upload on the package detail page, which should include the ITA/ITP. Since this page should be linked to in your RFS email, this duplication is probably unnecessary. Thanks - Kyle Willmon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110906175502.gs31...@mail.tuxags.com
Re: Tracking RFSs as bugs
On Mon, Sep 05, 2011 at 01:51:46PM -0700, Don Armstrong wrote: (I expect it would have debian-mentors@lists.debian.org as its maintainer, with mentors.debian.org as the pseudopackage name) Is mentors.debian.org here suggesting that it should be added to the official infrastructure or is this just a typo? Thanks -- Kyle Willmon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110906175815.gt31...@mail.tuxags.com
Re: Becoming DM [was: Re: Tracking RFSs as bugs]
On 06/09/2011 09:29, Johan Van de Wauw wrote: On Mon, Sep 5, 2011 at 11:09 PM, Michael Tautschnigm...@debian.org wrote: Could you please be more precise about that last bit? What exactly is hard about becoming DM? I really wish more people applied for DM. Sponsoring the same package more than a few times makes little sense in most cases (there are exceptions, and I for one are regularly sponsoring at least one such exception). I think that he really wants to say: it is hard to get a (first) package into debian. That is not a problem which is solved by becoming a DM. I don't think that is what I wanted to say (though I agree that it is hard to get one's first package into Debian). I think what I meant was that part of the social contract, if I understand correctly, is that we're all here to become DMs/DDs, not just to get our packages uploaded by someone else and walk away. So why is it that DDs sponsor packages and not people? Debian has a steep learning curve - I've been running several Debian systems for ~9 years, packaging for ~2.5 years and still have tons to learn. I would greatly appreciate the ability to correspond with someone about issues which arise for me *before* I have a package ready for review - or even which are only tangentially related to my package(s) but relevant to my broader understanding of Debian and the journey towards DM. FWIW I'd support the use of the BTS for tracking RFSs. For new packages, couldn't it be as simple as tagging ITP bugs as packaged, uploaded and awaiting review? (Not sure about upgrades.) Cheers, CC -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e669ea9.4090...@gmail.com
Re: Becoming DM [was: Re: Tracking RFSs as bugs]
Hi Chris, [...] I think what I meant was that part of the social contract, if I understand correctly, is that we're all here to become DMs/DDs, not just to get our packages uploaded by someone else and walk away. So why is it that DDs sponsor packages and not people? In the ideal case, and this is largely where I started my sponsoring activities from, I'd only mentor a few people. Indeed I used to have (and sometimes still have) a lot more interaction with the people behind those packages than just the occasional uploaded. email. I used to ask people what their long-term intentions were, tried to understand their background, etc. It was around the 4-days-proposal that I decided to trade quality for quantity. Sadly, this trade off had to be made. I'd still be happy to mentor (more) people if someone were interested in getting into this mentoring relationship; but so far most people seemed just happy with getting their package uploaded, apparently not caring about more than that. Debian has a steep learning curve - I've been running several Debian systems for ~9 years, packaging for ~2.5 years and still have tons to learn. I would greatly appreciate the ability to correspond with someone about issues which arise for me *before* I have a package ready for review - or even which are only tangentially related to my package(s) but relevant to my broader understanding of Debian and the journey towards DM. As said above: I for one would be perfectly fine to offer this kind of mentoring to you. I'm not sure whether you had ever had a negative answer to such a request for mentorship - have you ever asked for it (before)? FWIW I'd support the use of the BTS for tracking RFSs. For new packages, couldn't it be as simple as tagging ITP bugs as packaged, uploaded and awaiting review? (Not sure about upgrades.) I believe the workflow could be implemented as simply reassigning the ITP to the proposed mentors.debian.(org|net) pseudo-package. No need for extra tagging, it would all come for free. Best, Michael pgpsmfcOmc95i.pgp Description: PGP signature
Tracking RFSs as bugs
Hi, I've been thinking about how mentors works lately (after watching Asheesh's debconf11 talk). It seems like the 4 day response effort worked somewhat well for a while, but kind of tailed off, and I've been pondering what could be done instead that would have some staying power. I've noticed that the release team has a lot of success addressing their issues in a rather timely manner. I think that this success comes from the fact that they treat all of the items they need to accomplish as bugs [0]. So, as requests get old, they notice that and do something about it (or they just close it out if the submitter isn't responsive). Anyway, I think mentors could greatly benefit from a similar work flow. So, I was wondering if there were any thoughts on setting up a mentors.debian.net pseudo-package [1]? It seems like all of the existing ones are debian.org features, so I'm not sure if that would require mentors becoming an official .org service first or not? Anyway, I think this could be a really significant improvement to the mentors culture. Best wishes, Mike [0] http://bugs.debian.org/release.debian.org [1] http://www.debian.org/Bugs/pseudo-packages -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110905151209.05edc47147b9d5355c42c...@gmail.com
Re: Tracking RFSs as bugs
Hi Michael, hi all, (keeping Don CC'ed) [...] I've noticed that the release team has a lot of success addressing their issues in a rather timely manner. I think that this success comes from the fact that they treat all of the items they need to accomplish as bugs [0]. So, as requests get old, they notice that and do something about it (or they just close it out if the submitter isn't responsive). [...] I'm all for tracking RFS in some more formal way, it would quite a bit reduce the load on my inbox (which I'm currently using for tracking). There is one fundamental difference, however, to, e.g, the release team: there is no *team*. Who are they in case of sponsoring? What makes the situation worse is that the number of people filing RFS is unbounded, this process is open to everyone (don't get me wrong, this is a good thing in general). I don't think technical infrastructure alone will solve those problems. In fact, mentors.debian.net would already have all the necessary infrastructure: packages are uploaded there and hence tracked. It is possible to leave comments, and maybe this whole RFS business should just move over to mentors.debian.net. Oh, and with all this moaning about RFS not being dealt with in a timely manner: true, we don't manage to get packages reviewed and sponsored within 4 days, but is the situation really that bad at the moment? Are there any packages older than one month still waiting for sponsorship? Best, Michael pgpThnq9RAMkD.pgp Description: PGP signature
Re: Tracking RFSs as bugs
* Michael Tautschnig m...@debian.org, 2011-09-05, 20:51: I've noticed that the release team has a lot of success addressing their issues in a rather timely manner. I think that this success comes from the fact that they treat all of the items they need to accomplish as bugs [0]. So, as requests get old, they notice that and do something about it (or they just close it out if the submitter isn't responsive). This is not a new idea: http://lists.debian.org/debian-mentors/2002/08/msg00262.html I'm all for tracking RFS in some more formal way, it would quite a bit reduce the load on my inbox (which I'm currently using for tracking). Same here. There is one fundamental difference, however, to, e.g, the release team: there is no *team*. Who are they in case of sponsoring? What makes the situation worse is that the number of people filing RFS is unbounded, this process is open to everyone (don't get me wrong, this is a good thing in general). I don't think technical infrastructure alone will solve those problems. Of course it won't, but that's not a reason not to think about improvements. In fact, mentors.debian.net would already have all the necessary infrastructure: packages are uploaded there and hence tracked. It is possible to leave comments, and maybe this whole RFS business should just move over to mentors.debian.net. I can't talk to debexpo using my MUA. This is a big no-go for me. Oh, and with all this moaning about RFS not being dealt with in a timely manner: true, we don't manage to get packages reviewed and sponsored within 4 days, but is the situation really that bad at the moment? Are there any packages older than one month still waiting for sponsorship? Probably dozens of them... -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110905204611.ga...@jwilk.net
Re: Tracking RFSs as bugs
On 05/09/2011 20:51, Michael Tautschnig wrote: Oh, and with all this moaning about RFS not being dealt with in a timely manner: true, we don't manage to get packages reviewed and sponsored within 4 days, but is the situation really that bad at the moment? Are there any packages older than one month still waiting for sponsorship? I was going to reply to this and say that my angband-audio package has been waiting for six months (it was uploaded on 27 Feb) - but I went to check on it and I see it has disappeared! I did not receive any email about this - are old packages deleted from m.d.n after a certain time? Not to worry, I'll re-upload it and make another RFS. No moaning from me btw - I am sure there are many more RFSs than there are sponsors. I just wish it wasn't so hard to reach DM. CC -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e6535ed.3060...@gmail.com
Re: Tracking RFSs as bugs
On Mon, 5 Sep 2011 20:51:47 +0100 Michael Tautschnig wrote: I'm all for tracking RFS in some more formal way, it would quite a bit reduce the load on my inbox (which I'm currently using for tracking). There is one fundamental difference, however, to, e.g, the release team: there is no *team*. Who are they in case of sponsoring? Well, perhaps its time to formalize that? Let's make mentors a .org and get the DPL to do some official appointments. I'm willing to volunteer for that (I'm only a DM now, but I've run into enough limitations with my DM status lately that I'm starting to feel like I should really be going for DD now). Who else is willing to volunteer? What makes the situation worse is that the number of people filing RFS is unbounded, this process is open to everyone (don't get me wrong, this is a good thing in general). I agree, this is a very good thing. I'm hoping this approach will make supporting so many people a more tractable thing. I don't think technical infrastructure alone will solve those problems. In fact, mentors.debian.net would already have all the necessary infrastructure: packages are uploaded there and hence tracked. It is possible to leave comments, and maybe this whole RFS business should just move over to mentors.debian.net. Yes, the new infrastructure really is an improvement, but it does have some issues, which of course may be easily fixable with the current framework. For example, discussion on the mentor's package pages isn't reproduced on the mentors ML and vice versa; as would be done with a BTS package and associated mailing list. There is no email-based option to the web interface. Also, aestetically, the new mentors system reproduces functionality already available via the bug system. Finally, and maybe this is because the oldness only goes back to July now, there isn't really as sense of what's old and thus a candidate to close out; and even so it's not possible to close out other's packages (with an option to reopen) like on the BTS. Also, a very useful thing (I think) would be reportbug integration. Thus submitters would be able to reference their existing ITP submission and not have to re-enter the same information in their RFS (this duplication has always irked me about the mentors process). Oh, and with all this moaning about RFS not being dealt with in a timely manner: true, we don't manage to get packages reviewed and sponsored within 4 days, but is the situation really that bad at the moment? I'm not trying to bemoan the situation; just trying to be proactive and thoughtful about finding ways to make it better. Are there any packages older than one month still waiting for sponsorship? You can see all of the packages currently in limbo at [0]; although it's not currently possible to select only those older than a month (although that too could probably be implemented relatively easily with the new expo framework). I for example have a set of old packages awaiting further review [1]. Admittedly a lot of those are back in my court to fix some issues, and its my fault for forgetting about them; although I feel like I would be less inclined to do that if they were tracked as bugs and tagged with moreinfo (although then again something similar could be implemented on mentors), and with someone poking me every now and then saying this is really old and you haven't worked on it, so we're going to close it. So, anway it boils down to the fact that the BTS already has all of these wonderful features, and mentors could get them, but if they're already available why go though the duplicative process? If I could choose, my approach would be to go the BTS route and better integrate the mentors pages with that and vice versa. Best wishes, Mike [0] http://mentors.debian.net/packages/index [1] http://mentors.debian.net/packages/uploader/michael.s.gilbert%40gmail.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110905164959.82ca09ae.michael.s.gilb...@gmail.com
Re: Tracking RFSs as bugs
On Mon, 05 Sep 2011, Michael Gilbert wrote: I was wondering if there were any thoughts on setting up a mentors.debian.net pseudo-package [1]? The real question is whether a number of people who are responding to RFS are willing to participate in a pseudopackage like that. I personally don't have a problem with creating one (I expect it would have debian-mentors@lists.debian.org as its maintainer, with mentors.debian.org as the pseudopackage name) if there is significant buy-in from people doing sponsoring that this would assist them in finding and tracking packages that they are interested in sponsoring. Don Armstrong BTW: there's no need to keep me CC'ed, as I'm subscribed to -mentors (and in general, ow...@bugs.debian.org is the right role address to e-mail for these things.) -- It was a very familiar voice. [...] It was a voice you could have used to open a bottle of whine. -- Terry Pratchett _The Last Continent_ p270 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110905205146.gn10...@teltox.donarmstrong.com
Becoming DM [was: Re: Tracking RFSs as bugs]
Hi, [...] No moaning from me btw - I am sure there are many more RFSs than there are sponsors. I just wish it wasn't so hard to reach DM. [...] Could you please be more precise about that last bit? What exactly is hard about becoming DM? I really wish more people applied for DM. Sponsoring the same package more than a few times makes little sense in most cases (there are exceptions, and I for one are regularly sponsoring at least one such exception). Best, Michael pgpYNApHKtMWq.pgp Description: PGP signature
Re: Tracking RFSs as bugs
Hi, [...] This is not a new idea: http://lists.debian.org/debian-mentors/2002/08/msg00262.html Thanks a lot for the pointer, indeed this is an interesting read (well, the technical part of that). [...] I can't talk to debexpo using my MUA. This is a big no-go for me. Fully agreed. [...] I'll continue in another subthread, just wanted to note those bits here. Best, Michael pgpnFqr7gxeM6.pgp Description: PGP signature
Re: Tracking RFSs as bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone, as I see this discussion going on, I think I should inform you about some things going on on mentors.d.n right now: * Asheesh and we are steadily improving features on Debexpo (the software behind mentors.d.n). Its not finished yet, and misses some features we would like to add. * I was thinking to implement a debian-mentors - Debexpo bridge to import comments made on the mailing list to Expo. There are some stub functions available, if you are interested have a look to our devel branch [1]. This is something to come in future. Basically I will grab RFS comments made on the mailing list, and import them to the package history on Debexpo. More advanced plans include to keep track of the entire package history. If someone else is willing to assist me here: any help is appreciated. That would not change the workflow for MUA fans out there. * As a result on the dc11 sponsorship BoF, I think, one of the most useful additions to Expo would be sponsor metrics [2]. I prepared a newsletter together with David Bremner which is in the pipeline and we will probably send it out very soon, as I get my stuff on Expo regarding that done. * Lucas Nussbaum made a very interesting proposal to make a social peer-to-peer review platform out of Debexpo. Basically his idea was to have some karma / teams. Have a look to [3][4] get the idea. * Debexpo did not lose packages being uploaded to the old Mentors infrastructure before we switched. For technical reasons we don't have the precise upload date and/or package description available. So I gave those uploads a random legacy upload date. Besides they are fully functional. * We need more contributors to Debexpo. We have a lot of (wishlist) bugs. Let me hear if anyone is interested to step in. On 05.09.2011 23:09, Michael Tautschnig wrote: Could you please be more precise about that last bit? What exactly is hard about becoming DM? The fact, you won't find sponsors easily which makes it pretty hard to find someone who advocates you. Here is more to come on the newsletter I announced above. [1] http://anonscm.debian.org/gitweb/?p=debexpo/debexpo.git;a=shortlog;h=refs/heads/devel [2] http://wiki.debian.org/DebianMentorsNet#Metrics [3] https://alioth.debian.org/tracker/index.php?func=detailaid=313252group_id=100127atid=413115 [4] https://alioth.debian.org/tracker/index.php?func=detailaid=313253group_id=100127atid=413115 - -- 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/ iQIcBAEBAgAGBQJOZT6pAAoJEMcrUe6dgPNtxAcQAKuPnlmV+XSNuUUtXDeHWZ72 pNnoh3iURW7u8a+Cgtz7q8Oi+Y/WDl+X1MbQRQWs/F1tmm0W7aG8k42DHT2sOFFn 85aG+Rh3qlzjsEW98ahw0VtYo00Lm3BA2OdxWNnxlL3RgYeeh/JF54oqCvuLAypo Sh5UFw910Mz0F/7PuN6Obma3cVL82OShUE/lNDitvKZi1OXQ6+9ZFd5YIMd7mDYM jo2IWbwG80+qiM4q/pQDj1jUAs+H4esYHw51Ji3JiHa5AFU1/pQb8CoENlZsuntr mImwrmxwvHzL2wPtW3SdVIhPix/5Z+Bif4t1/C8NR+pzXEhkE0hIfMDEbdK3UcQa NrS6nizpcRG6LkIru79guOfRZZiXOCSEV4RrGyv745jH9L7KZiNhjYJMn/1E4Th4 LG9ilK6QrM7r/cdxd7Vl7tgh45jI5RXJQeAvXom4tZWuuS5gfMJnEPk3lkrOTAz0 XeGUzAblbOcoyvod40MrStEhQ11JgH48hRE3zjk+w8xFCVJOoPV0BVROGrFpy6DR usERHjSvnNErzVMqcEtIYHULEGT/EBr4ViMUtcG4r9yoC7eijasc7Z4ICb+vUgFJ UlACoaQcQlrjDXqsvr8jceG1qI3gQWz4BVc4IKgr+RWivBeggnR31xeBQZTC5Gcc LMD9K/nv3lQbFNpwky2U =skHm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e653eaa.7080...@toell.net
Re: Tracking RFSs as bugs
Le Mon, Sep 05, 2011 at 10:46:11PM +0200, Jakub Wilk a écrit : * Michael Tautschnig m...@debian.org, 2011-09-05, 20:51: I've noticed that the release team has a lot of success addressing their issues in a rather timely manner. I think that this success comes from the fact that they treat all of the items they need to accomplish as bugs [0]. So, as requests get old, they notice that and do something about it (or they just close it out if the submitter isn't responsive). This is not a new idea: http://lists.debian.org/debian-mentors/2002/08/msg00262.html And http://wiki.debian.org/PackageReview :) By the way, I find it also a bit strange that while a lot of developement in Debian is now done in version control systems, the paradigm of sponsoring is still centered on source packages instead of checkouts… This may also be one reason why some RFS take some time to be transformed in uploads. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110905231257.ga6...@merveille.plessy.net
Re: Tracking RFSs as bugs
On Mon, 5 Sep 2011 22:46:11 +0200 Jakub Wilk wrote: This is not a new idea: http://lists.debian.org/debian-mentors/2002/08/msg00262.html 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 idea. 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 [0]. 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. [0] https://alioth.debian.org/tracker/index.php?func=detailaid=313253group_id=100127atid=413115 Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110905200304.bc515ba7.michael.s.gilb...@gmail.com
