Re: Supporting Gtk+ Maintenance
Yeah, that was me. I've since stopped, and I'm talking with Tor Lindqvist about how I could be more useful. He's suggesting I go through the list of unloved patches and review them, which sounds fair enough. Philip On Sun, 2007-05-27 at 12:39 -0400, Matthias Clasen wrote: On 3/15/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: Your mission, should you decide to accept it, is to do this: - Get the latest GTK+ from svn trunk. - Go through each of the unreviewed patches and classify them informally: - obsolete patch which does not apply as-is to the sources (you can use patch --dry-run to test this easily without screwing up your source tree) - big patch which needs detailed testing/review - small patch which could be tested/reviewed in a few minutes I see that somebody took up this task now. While I appreciate the effort, I don't think that a mere applies/doesn't apply small/big classification of patches helps _that_ much with the patch review. I have started a small patch review checklist in http://live.gnome.org/GtkTasks#P1 that should help people who want to bring patches in good shape. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Supporting Gtk+ Maintenance
Le lundi 26 mars 2007, à 14:12, Quim Gil a écrit : On 3/14/07, Tim Janik wrote: Hello Foundation Board. Hello GTK+ team. The Gtk+ project is in dire lack of new maintainers, mostly to review (...) Thanks for this report, and actually thanks for the first report you sent back in Christmas. On thaty time the board was in transition, but we already took your points and since then this has been one of the main points in our agenda. This is why GTK+ was one of the 2 main issues presented to the advisory board members this week, together with Documentation. There are lots of aspects to fix and improve in the GNOME project, but the board has decided to put these two on top of the agenda. A practical conclusion of the discussion this week was that we need a space for discussion where the GTK+ team, the board, the advisory board companies and probably any other key GTK+ contributor / stakeholder / user can share this discussion. An official channel where we can hold a discussion from these different perspectives in order to solve the main issues and push GTK+ to the bright horizon it deserves. This channel might be online+offline, something like a combination of a specific mailing list + meetings in relevant conferences + ... The GTK+ core team has the initiative proposing the space and the bootstrapping process of collaboration. Let's use this list to decide the new channel. I'm wondering if gtk-devel-list is the place where the discussion about collaboration should be happening: I don't know if having a mix of technical discussions and collaboration discussions is good or not. Having a separate mailing list might help, but it might also be a stupid idea :-) What does the GTK+ team think? Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Supporting Gtk+ Maintenance
On Thu, 2007-03-29 at 21:25 +0200, Vincent Untz wrote: Le lundi 26 mars 2007, à 14:12, Quim Gil a écrit : On 3/14/07, Tim Janik wrote: Hello Foundation Board. Hello GTK+ team. The Gtk+ project is in dire lack of new maintainers, mostly to review (...) Thanks for this report, and actually thanks for the first report you sent back in Christmas. On thaty time the board was in transition, but we already took your points and since then this has been one of the main points in our agenda. This is why GTK+ was one of the 2 main issues presented to the advisory board members this week, together with Documentation. There are lots of aspects to fix and improve in the GNOME project, but the board has decided to put these two on top of the agenda. A practical conclusion of the discussion this week was that we need a space for discussion where the GTK+ team, the board, the advisory board companies and probably any other key GTK+ contributor / stakeholder / user can share this discussion. An official channel where we can hold a discussion from these different perspectives in order to solve the main issues and push GTK+ to the bright horizon it deserves. This channel might be online+offline, something like a combination of a specific mailing list + meetings in relevant conferences + ... The GTK+ core team has the initiative proposing the space and the bootstrapping process of collaboration. Let's use this list to decide the new channel. I'm wondering if gtk-devel-list is the place where the discussion about collaboration should be happening: I don't know if having a mix of technical discussions and collaboration discussions is good or not. Having a separate mailing list might help, but it might also be a stupid idea :-) What does the GTK+ team think? If it's going to be a public discussion then it should be on gtk-devel-list. It would be silly to create a new mailing list just to discuss this one subject. If it's meant to be a private discussion then a CC list will probably do it, with the advisory and board lists in it. You might also want to arrange an extra conference call with the advisory board if that's more to their liking. But that will probably take 2 or 3 months to arrange. I'm disappointed that this has been turned into a discussion about discussing. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Supporting Gtk+ Maintenance
Hi Murray, Le jeudi 29 mars 2007, à 23:27, Murray Cumming a écrit : On Thu, 2007-03-29 at 21:25 +0200, Vincent Untz wrote: I'm wondering if gtk-devel-list is the place where the discussion about collaboration should be happening: I don't know if having a mix of technical discussions and collaboration discussions is good or not. Having a separate mailing list might help, but it might also be a stupid idea :-) What does the GTK+ team think? If it's going to be a public discussion then it should be on gtk-devel-list. It would be silly to create a new mailing list just to discuss this one subject. If it's meant to be a private discussion then a CC list will probably do it, with the advisory and board lists in it. My point is: this is up to the GTK+ team to decide. I personnally don't think there'll be anything private. You might also want to arrange an extra conference call with the advisory board if that's more to their liking. But that will probably take 2 or 3 months to arrange. This is definitely something we'll do if people feel it's necessary. I'm disappointed that this has been turned into a discussion about discussing. We're only trying to know how the GTK+ team wants to work. This is only a first step :-) Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
On Tue, Mar 27, 2007, Behdad Esfahbod wrote: Is there a way to check programatically (scripts/patch-command/etc) that if a patch is applicable to be applied with p0 or p1? patch --dry-run [ And the preferred order to try patch level is probably 1 0 2; at least that's what Debian tools do since bugs such as http://bugs.debian.org/365524. The logic is in the cdbs package: /usr/share/cdbs/1/rules/simple-patchsys.mk ] -- Loïc Minier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
On Tue, 2007-03-27 at 11:27 -0400, मयंक जैन (makuchaku) wrote: On 3/16/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: Your mission, should you decide to accept it, is to do this: - Get the latest GTK+ from svn trunk. - Go through each of the unreviewed patches and classify them informally: - obsolete patch which does not apply as-is to the sources (you can use patch --dry-run to test this easily without screwing up your source tree) - big patch which needs detailed testing/review - small patch which could be tested/reviewed in a few minutes 29 patches were categorized. More to go... Is there a way to check programatically (scripts/patch-command/etc) that if a patch is applicable to be applied with p0 or p1? patch --dry-run $ cat gnome-patch #!/bin/bash if test $# '!=' 1; then echo usage: $0 attachmentid exit 2 fi ID=$1 FILE=attachment.cgi?id=$ID OUT=attachment-$ID.patch wget http://bugzilla.gnome.org/$FILE; -O $OUT patch --dry-run -p0 $OUT patch -p0 $OUT echo Patch $OUT applied cleanly. If so, then this process of categorizing patches can be automated i suppose. ...any comments, suggestions :) -- Makuchaku http://www.makuchaku.info/blog ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
On 3/23/07, Behdad Esfahbod [EMAIL PROTECTED] wrote: Setting bugs with outdated patches to needinfo may be a bit problematic as the bugsquad team has a tendency to close needinfo bugs after some time... Also they won't show in some default search queries.. Just removing the patch keyword, or marking the patch as needs-work may be better, but that's just my idea. Obviously the objective it to get this anomoly to the patch submitter's attention. But as Behdad you just said.. then whats the best way to go about it? One option I see is to re-assign the bug to this patch submitter once he resubmits a working patch, re-assign it to the gtk-bugs list. Would that be good enough? :) Makuchaku ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
On Fri, 2007-03-23 at 15:42 +0530, मयंक जैन (makuchaku) wrote: On 3/23/07, Behdad Esfahbod [EMAIL PROTECTED] wrote: Setting bugs with outdated patches to needinfo may be a bit problematic as the bugsquad team has a tendency to close needinfo bugs after some time... Also they won't show in some default search queries.. Just removing the patch keyword, or marking the patch as needs-work may be better, but that's just my idea. Obviously the objective it to get this anomoly to the patch submitter's attention. But as Behdad you just said.. then whats the best way to go about it? One option I see is to re-assign the bug to this patch submitter once he resubmits a working patch, re-assign it to the gtk-bugs list. Would that be good enough? The submitters gets mail about all changes to the bug (by default). So no real need to do anything specific. Just marking as needs-work and a two line comment about the patch status should be enough. Assigning to him may work better as he will see it in his bug page, but note that other people can update an outdated patch too, and many times do. :) Makuchaku -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
On 3/16/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: - Go through each of the unreviewed patches and classify them informally: - obsolete patch which does not apply as-is to the sources (you can use patch --dry-run to test this easily without screwing up your source tree) - big patch which needs detailed testing/review - small patch which could be tested/reviewed in a few minutes I've triaged the first 5 bugs for combobox category. Now ehn a patch fails, I create a needinfo in the bug. But can this needinfo be directed to a particular user? In bugzilla.redhat.com, one can create a needinfo for a particular user then it becomes his responsibility to cancel that info. This assures speedier responses. Is it somehow possible to do the same with Gnome BZ? Work is on... :) Makuchaku http://www.makuchaku.info/blog ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
On Thu, 2007-03-22 at 12:25 -0400, मयंक जैन (makuchaku) wrote: On 3/16/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: - Go through each of the unreviewed patches and classify them informally: - obsolete patch which does not apply as-is to the sources (you can use patch --dry-run to test this easily without screwing up your source tree) - big patch which needs detailed testing/review - small patch which could be tested/reviewed in a few minutes I've triaged the first 5 bugs for combobox category. Now ehn a patch fails, I create a needinfo in the bug. But can this needinfo be directed to a particular user? In bugzilla.redhat.com, one can create a needinfo for a particular user then it becomes his responsibility to cancel that info. This assures speedier responses. Is it somehow possible to do the same with Gnome BZ? Work is on... :) Thanks for all the work! Setting bugs with outdated patches to needinfo may be a bit problematic as the bugsquad team has a tendency to close needinfo bugs after some time... Also they won't show in some default search queries.. Just removing the patch keyword, or marking the patch as needs-work may be better, but that's just my idea. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
El vie, 16-03-2007 a las 20:44 +0530, मयंक जैन (makuchaku) escribió: Here's a task for you to get started. It will take you several days, but hopefully it will be fun :) Sure... onto it! That's the spirit! :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
On 3/16/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: El jue, 15-03-2007 a las 14:20 +0530, मयंक जैन (makuchaku) escribió: I would be happy to volunteer towards maintainence of GTK+. Wow, thanks! Here's a task for you to get started. It will take you several days, but hopefully it will be fun :) Sure... onto it! Regards, Makuchaku ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Supporting Gtk+ Maintenance
Hello Foundation Board. The Gtk+ project is in dire lack of new maintainers, mostly to review patches, so that bugs can be fixed and new features can be introduced. We need suggestions for candidates, probably for particular sub-sections of Gtk+. Ideally, these candidates would be employed to work on Gtk+. To avoid any misunderstandings, the project is not in lack of more patches or code contributions, what it lacks is the human resources to handle the flow of incoming patches and bug reports, and do code maintenance work. A more in-depth description of this situation can be found here: http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00074.html In response to that write up, various people have made suggestions to improve the situation and asked for opportunities or ways to help. Some of these suggestions involve the Gnome foundation board and Gnome advisory board, which is why I'm writing you. A lot of companies are involved in Gnome and Gtk+ at this point, and probably can be expected to have a vivid self interest in our core technologies to stay reliable and properly maintained. In order to help to achieve this, this can be done: * Companies (especially those on the advisory board) can submit names of developers (employees) who can be put on the task of Gtk+ maintenance. Ideally, the developers should already have experience with Gtk+ project contributions, and they should be team-oriented and communicative to be able to develop a good work relationship with the existing Gtk+ community. * The Gtk+ project would like to see those people work full time if possible, but regular part time assistance can also help a lot. * These positions must not be limited to work on constrained feature sets only. There are enough limited scope/feature bound contributions already. As a consequence, there is a strong need for more general involvement and maintenance work like cleanups, regression fixes, refactorings and similar things. So for the foundation board, there are two things that can be done to improve the current situation: 1) Please present the issue at hand (this email and the email linked to above) to the advisory board members, to make sure the companies involved are aware of the situation. And if possible, spread the word to other involved parties or (non advisory) companies. 2) Please investigate if the hiring/sponsoring of a full time Gtk+ maintainer position by the Gnome foundation is also a possibility. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
quote who=Tim Janik So for the foundation board, there are two things that can be done to improve the current situation: 1) Please present the issue at hand (this email and the email linked to above) to the advisory board members, to make sure the companies involved are aware of the situation. And if possible, spread the word to other involved parties or (non advisory) companies. Your timing is fantastic -- we're having an Advisory Board meeting tomorrow morning. I will bring it up then. :-) 2) Please investigate if the hiring/sponsoring of a full time Gtk+ maintainer position by the Gnome foundation is also a possibility. Current and previous boards have been very cautious about the idea of hiring developers. We'd prefer to hire people who can support the work of hackers. That's not to say it's completely off the table, but there's more we can do with contributing companies beforehand. Just for the record, I'm taking this issue very seriously. It's one of the reasons I brought up GTK+ collaboration with the GNOME Foundation (and the other project mentioned during the GTK+ meeting at GUADEC). Thanks, - Jeff -- Open CeBIT 2007: Sydney, Australia http://www.opencebit.com.au/ Blessed are the cracked, for they let in the light. - Spike Milligan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
