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: GTK+ maintenance
On Wed, 2007-05-23 at 14:57 +0200, Vincent Untz wrote: [...] I'm not exactly sure what you want the board to consider. The plan is not let companies develop GTK+ and hope everything will go well, but tell companies that if they want a better GTK+, this is what they should do. Maybe your point is that we shouldn't just dismiss the Foundation should hire someone option. The board is exploring various ways to help the GTK+ developer community, and we're not rejecting this option. It is still on the list, but, as it was already pointed out, it comes with some issues. Also note that it's not clear to me if most GTK+ developers want the Foundation to hire someone or not. Hi Vincent, None of that is clear to me either, I was really just trying to bring some points that struck me as relevent to light, and yes I dont think that the possibility of hiring somebody should be dissmissed (and thankyou for clarifying that you are taking it into consideration). The simple fact, outlined clearly by Tim's mail[1] (which originally caught my attention), is that more secondary contributors and patch flood is not really going to help the state of affairs; we need more people playing central roles in gtk+ development and maintainership. The GtkTasks[2] initiative is a great start IMO, its yet to be seen if that initiative alone will give us the structure needed to get gtk+ properly refactored and new features properly reviewed in reasonable timeframes. Cheers, -Tristan [1]http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00122.html [2]http://live.gnome.org/GtkTasks ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
On Wed, 2007-05-16 at 09:06 +0100, Martyn Russell wrote: So, right now, the Board is not considering the option of hiring people to hack/do technical things. I'm not saying we'll never do this, but doing this has a lot of implications (managing the employees wouldn't be easy, people could start thinking that there's no need to contribute to GTK+ since the GNOME Foundation has developers for this, etc.), and we'd prefer to explore other ways to fix the issue first. I doubt that. Imendio (among other companies) have slowly been putting more resources into GTK+, is there any evidence that shows people are contributing any less? I think that's what he says: hiring GTK+ hackers by the board = bad, but hiring GTK+ hackers by companies = good. Xav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
On Thu, Apr 26, 2007 at 01:08:10AM +0200, Vincent Untz wrote: It'd be useful to know how many more people are needed to have things working more smoothly. Let's talk about full-time people: would 2 people be enough? Or do we need much more than 2, like 8 full-time developers? This is the kind of information that will help us convince companies to put more manpower into GTK+. Some comparison... http://www.trolltech.com/company Trolltech is a software company with two product lines: Qt and Qtopia. We currently have 200 employees working at offices worldwide. This includes a lot of other things (you only want Qt devs), but still... 200 vs 2 / 8? -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
On Tue, 2007-05-15 at 22:29 +0200, Olav Vitters wrote: On Thu, Apr 26, 2007 at 01:08:10AM +0200, Vincent Untz wrote: [...] Some comparison... http://www.trolltech.com/company Trolltech is a software company with two product lines: Qt and Qtopia. We currently have 200 employees working at offices worldwide. This includes a lot of other things (you only want Qt devs), but still... 200 vs 2 / 8? This is not representative of anything. Before I go running my trap I'll note that I am not a gtk+ maintainer so I am not qualified to answer Vincent's query, but it should be noted that people writing patches for gtk+ are in no way lacking - this is a very popular project and has attracted alot of attention. Its been clearly stated that core maintainers are whats lacking, people that can be trusted to review large patches, do refactoring work and call shots so to speak, in my own personal opinion I think gtk+ could do fine with 2 extra Mattias Clasens or 2 more Tim Janiks, the question is; where are these experienced people to be found ? Will the foundation be considering hiring people from the gnome community ? (I would suppose so...) will there be location constraints (will developers have to move) ? will developers have to well known and trusted or will they have to be highly decorated ? (a healty mix of either/or/both I suppose...) Those kind of answers will also narrow down the possibilities of finding qualified people to be core maintainers of gtk+. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
Hi, Le mardi 15 mai 2007, à 16:53 -0400, Tristan Van Berkom a écrit : Its been clearly stated that core maintainers are whats lacking, people that can be trusted to review large patches, do refactoring work and call shots so to speak, in my own personal opinion I think gtk+ could do fine with 2 extra Mattias Clasens or 2 more Tim Janiks, the question is; where are these experienced people to be found ? Well, if they don't exist, we can try to grow some of them :-) Will the foundation be considering hiring people from the gnome community ? (I would suppose so...) will there be location constraints (will developers have to move) ? will developers have to well known and trusted or will they have to be highly decorated ? (a healty mix of either/or/both I suppose...) So, right now, the Board is not considering the option of hiring people to hack/do technical things. I'm not saying we'll never do this, but doing this has a lot of implications (managing the employees wouldn't be easy, people could start thinking that there's no need to contribute to GTK+ since the GNOME Foundation has developers for this, etc.), and we'd prefer to explore other ways to fix the issue first. For example, a lot of companies do have an interest in GTK+ but are not actively participating upstream. I've been in contact with some of them to see if they could get some of their developers to freely work on upstream as part of their job. People have been open about this idea, but I'm sure we could come with better arguments to really convince them. 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: GTK+ maintenance
Hi, Vincent Untz wrote: For example, a lot of companies do have an interest in GTK+ but are not actively participating upstream. I've been in contact with some of them to see if they could get some of their developers to freely work on upstream as part of their job. People have been open about this idea, but I'm sure we could come with better arguments to really convince them. Two good angles might be: - bugzilla stats (number of bugs, response time to new bugs, etc.) - details on specific great new features / enhancements a maintainer could implement (and point out how these benefit the company in question's products, as well as the whole ecosystem) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ maintenance
Hi, Tim has been doing a fantastic job at creating a list of tasks where people can help [1]. I really believe this is a good first step to get more people involved. Having more non-permanent tasks would probably be great, but well, that's not the goal of this mail :-) In the past few weeks, I've talked a bit with the Foundation advisory board members. This is not something that's finished and I'll continue with this, but this already gave me a rough idea of how things work in companies wrt GTK+. Among the AB members, there are basically small and big companies. Small companies are already quite involved within the community and contribute as much as possible (since, well, they also need to find some money). It's (not surpsisingly) a bit easier for big companies to put more manpower, although there's no hard guarantee for this to happen. And it might not be easy for people who've not been involved before to contribute to upstream GTK+. For example, it seems that a lack of documentation about GTK+ internals doesn't help here (is this something that could be added to the list of tasks for volunteers?). Of course, another essential aspect is that experienced GTK+ developers/maintainers will need to make time to help get joining developers feel at home. It'd be useful to know how many more people are needed to have things working more smoothly. Let's talk about full-time people: would 2 people be enough? Or do we need much more than 2, like 8 full-time developers? This is the kind of information that will help us convince companies to put more manpower into GTK+. Obviously, this not an issue that will get fixed within the next week, but I do hope that we can start to see more people starting to join in the next few weeks. Thanks, Vincent [1] http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00058.html -- 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
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
Re : State of the Gtk+ Maintenance
Hello, The information you've provided is interesting, and it raises complementary questions : - currently, how many people work for Gtk+ developpment and/or maintenance a significant part of their work time ? what is the current yearly amount of man-hours for Gtk+ ? - by which companies are they employed / how are they financed for their work ? - can you evaluate in terms of yearly man-hours the extra man work you are calling for ? Thanks Even ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
