Re: notable Debian contributions in 2006
On 3/24/07, Josip Rodin [EMAIL PROTECTED] wrote: On Sat, Mar 24, 2007 at 02:08:10PM +0200, Tshepang Lekhonkhobe wrote: Distors are often viewed as mere packagers, but they tend to drive upstream development in variety of ways. Here's just a few of Debian's contributions to the world of FLOSS during 2006: * creation of cdrkit, a fork of cdrtools, due to a change of licence which happened to be DFSG-incompatible * rebranding of Firefox to Iceweasel due to trademark issues * rebranding of Seamonkey to Iceape due to trademark issues * rebranding of Thunderbird to Icedove due to trademark issues There must be so much more, in which case I hope you may add to this list, and if there's enough contributions, maybe a wiki page could be set up and advertised. You have your priorities wrong. A fork and three rebrandings are more like nuisances compared to for example the bug reports that Debian maintainers forwarded to upstream, without or with fixes. Sure, maybe those aren't PR-friendly, but they count, and they are the heart of our contribution IMO. I'm pretty aware that there's plenty of these reports and patches. But the point of the mail is 'notable' stuff, EG. the contributions to GTKFB by the d-i team for the graphical-installer (who is actually mentioned in the README file of that backend in GTK+2.10 release). This is the kind of example I was hoping this mail would trigger. Please note that 'notable' doesn't necessarily mean more important. A major refactoring is more likely to be more notable than a year-long patch submission exercise, for example. NB: The GTKFB example inspired this mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google SoC - Bug Triaging and Forwarding Tool
On Mon, Mar 19, 2007 at 09:12:40AM -0300, Gustavo R. Montesino wrote: 1. Query BTS according to paramaters given by the user. It could filter the bugs by maintaner, uploader, package, usertags, tags, etc. Display a list with bug number, title and tags to the user. 2. The user may select one of the bugs. The user would be then able to do the following on the selected report: * See the full bug report, followups, etc * Follow-up to the bug (launch the mail client with the right headers) reportbug-ng already does something like this. Have you looked at that program? * Change the bug tags (generate and send a control mail with the choices made by the user) * Search the upstream BTS for similar bugs [...] Philip Kern worked on this for last year's SoC, but I'm not sure if the code actually ended up working and I can't remember where it was now. :-/ The best I can find is some mock-up screenshots at: http://lists.alioth.debian.org/pipermail/soc-coordination/2006-August/58.html Personally, I find triaging mostly involves grouping rather than followup -- ie, the process is look at all the bugs, group related ones together into a bloc (by what area of the code they impact, how important they are, whether there's anything that can be done about them yet, etc), and then choose a group and do detailed followup/resolution on those bugs. Would it make sense to focus on the tagging aspect (either with the standard tags or usertags) so that your program just makes it really easy to set tags so maintainers can get a good idea of the state of their package (and share that idea through the use of tags), and fire off reportbug or a web browser for following up or reading bug logs? Cheers, aj signature.asc Description: Digital signature
Re: Google SoC - Bug Triaging and Forwarding Tool
On Wed, Mar 28, 2007, Anthony Towns wrote: reportbug-ng already does something like this. Have you looked at that program? FYI, I've already pointed at reportbug-ng in [EMAIL PROTECTED] and in the comments of the GSoC entry. I also pointed at bts-link which has some BugZilla (BZ) logic, but Pierre commented that it was not worth using. * Change the bug tags (generate and send a control mail with the choices made by the user) * Search the upstream BTS for similar bugs [...] Philip Kern worked on this for last year's SoC, but I'm not sure if the code actually ended up working and I can't remember where it was now. :-/ The best I can find is some mock-up screenshots at: http://lists.alioth.debian.org/pipermail/soc-coordination/2006-August/58.html IMO, tag manipulation would not be the main goal of this program; I would mostly see it as a nice addition when using such a tool -- instead of switching back and forth to the bts command and copying bug # around. I think the real value is in the Forwarding part and how to automate it. Personally, I find triaging mostly involves grouping rather than followup -- ie, the process is look at all the bugs, group related ones together into a bloc (by what area of the code they impact, how important they are, whether there's anything that can be done about them yet, etc), and then choose a group and do detailed followup/resolution on those bugs. It's not really like this in the GNOME packages. Sure, you can have duplicates, but most of the time it's a lot of different bugs, and even when they touch the same area, they get reported separately upstream because they are separate bugs after all. Would it make sense to focus on the tagging aspect (either with the standard tags or usertags) so that your program just makes it really easy to set tags so maintainers can get a good idea of the state of their package (and share that idea through the use of tags), and fire off reportbug or a web browser for following up or reading bug logs? I wouldn't find a GUI to set tags very interesting, even if usertags might not be very easy to set. I think the big big value would be to automate the upstream matching and submission. Some examples of things we could do: - search for bugs with the same long words in the bug title - search for a backtrace in the Debian bug matching an upstream comment - have an input field to manually research upstream bugs with some sensible defaults (the upstream web page does not allow saving default query settings AFAICT) and permit connecting them - one click bug forwarding which extracts the Debian bug report and wraps it in an upstream bug Debian user $x reported in Debian bug http://... that ..., using the correct upstream module and setting the correct upstream version I'm sure you can imagine the time saving advantages when we need to go through hundreds of bugs across different packages and need to repeat searches, bug reports, and various settings in the queries and reports (such as Cc:ing the GNOME team for updates). Beside, there are other big upstream projects relying a lot on BZ such as KDE and Mozilla which would directly benefit from the tool. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google SoC - Bug Triaging and Forwarding Tool
Em Qua, 2007-03-28 às 04:59 +1000, Anthony Towns escreveu: On Mon, Mar 19, 2007 at 09:12:40AM -0300, Gustavo R. Montesino wrote: [...] * Change the bug tags (generate and send a control mail with the choices made by the user) * Search the upstream BTS for similar bugs [...] Philip Kern worked on this for last year's SoC, but I'm not sure if the code actually ended up working and I can't remember where it was now. :-/ The best I can find is some mock-up screenshots at: I've found some svn urls at wiki.d.o, their development seems to have stoped, more likely on the end of SoC 2006... There is also a experimental Debian package, gnome-reportbug. Anyway, I will take a look on the code later. http://svn.debian.org/wsvn/soc/reportbug-gnome2/trunk/?rev=0sc=0 http://svn.debian.org/wsvn/soc/bts-frontend/branches/first-steps/?rev=0sc=0 Personally, I find triaging mostly involves grouping rather than followup -- ie, the process is look at all the bugs, group related ones together into a bloc (by what area of the code they impact, how important they are, whether there's anything that can be done about them yet, etc), and then choose a group and do detailed followup/resolution on those bugs. Would it make sense to focus on the tagging aspect (either with the standard tags or usertags) so that your program just makes it really easy to set tags so maintainers can get a good idea of the state of their package (and share that idea through the use of tags), I intend to allow easy tagging and complex queries, so I believe it will meet what you want. and fire off reportbug or a web browser for following up or reading bug logs? Using a browser (or MUA) to read the bug logs is ok, but I believe that forwarding is worth some work, as it can be made a lot more friendly and less time-consuming than the manual way. Regards, Gustavo R. Montesino
