As Bluefish developer I’m not really tightly involved with gnome and gtk development. However, it is our platform, and although we ship OSX and Windows binaries, most of our users are on Linux, many of them using Gnome. We are as much affected by a gtk bug than any other gnome part. So if we find any, we try to contribute.
However, for some reason it feels that our “outside” contributions are not so welcome. I believe this is not intentional, but still this is not a good thing. So what makes me feel that these contributions are not so welcome? The lack of feedback and results.
An example: In 2012-09-05 I filed a bugreport https://bugzilla.gnome.org/show_bug.cgi?id=683388 with a patch to improve the GList documentation. I noticed that new developers often make trivial mistakes (for example appending in a loop). I got some feedback and reworked the patch, submitted on 2012-09-12. And then nothing happened anymore. For 1 year and 4 months there was a total silence. I was originally planning to work trough all of the glib documentation to make it easier for novice programmers to work with, but this result was not really motivating me to do any more work on glib. Until on 2014-01-20 the bug was closed with “fixed”. A tiny bit of documentation was added, but the majority of the patch was not committed. Perhaps it was considered low quality, but at least tell the contributer! And tell how to improve it!
A second example: Early this year a reproducible way to crash Bluefish was reported. We realized the bug was not in Bluefish but in Gtk, GtkTreeModelFilter to be more specific. Instead of just filing a bugreport with the problem, we tracked down the problem and found how to fix it, and filed that in bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=722058 For us this is a critical bug. It makes Bluefish crash. It’s now three months later, and nothing has happened. I’m afraid that the next major gtk release will still have this bug, and Bluefish will remain a crappy application because it crashes because of this bug in gtk.
We should improve this! This is not the way to attract new developers! On the contrary, this does discourage new developers!
End note: I realize that I am not heavily involved with gtk or gnome. So there might be many valid reasons why the above two examples are completely wrong. Perhaps my complete feeling about the feedback and results is wrong. Perhaps my expectations are completely unrealistic. But if I have this feeling, there might be more occasional contributing developers that have this feeling. So we could at least then try to explain the true situation.
End note 2: I’m not a native English writer. So if my language was blunt or rude in any way to any person: this was really not intentional and I apologize. I don’t want to attack anyone. I don’t want to complain. I just want to send a signal that we can do better and should do better.
Olivier's Blog 
I am truly sorry for dropping the ball on the first bug: it totally went off my radar. for 2.40 there has been a big push to move the documentation from docbook to markdown, so a bunch of patches got applied. if you want to get your examples in, you may want to re-open the bug: I’ll be happy to re-review it.
I also just reviewed the TreeModelFilter patch.
it’s true: we leave a lot of patches on Bugzilla for a long time (years, in some cases); there are thousands of bugs related to glib and gtk+ on bugzilla.gnome.org, and we’re but a few. so, your criticism is entirely correct, and we need to get better at this, especially when it comes to quickly triaging bugs and reviewing patches.
now, I *have* to make a criticism to you, tho. you *cannot* treat the G* platform as a black box just because you’re maintaining an application. you cannot drop a patch and then just wait around to see if somebody reviews it, or applies it, and then wait two years until you write a blog post saying that we don’t engage “third party developers”. engagement, especially in volunteer-driven projects like glib, gtk+, and gnome, is a two way street; if you want your patch to land in a reasonable time frame you should contact the maintainers. you should send emails to the gtk-devel-list, for instance; you should come on IRC and ping the maintainers.
the G* platform is not a commercially-driven project: we don’t have people being paid to work full time on it, and we don’t have customer support that escalates issues to engineering. we try and treat everybody exactly in the same way, and one of the reasons why GNOME applications seem to get a “preferential treatment” is not just because most of the people working on glib and gtk+ also use GNOME: it’s because GNOME application developers constantly engage the maintainers, push for their patches, and get them in the platform.
we’re all trying to get stuff done, in the end; we’re all busy: our day jobs, our families, our own projects. we have all things we care about. if you care about something, you have to help me caring about it as well.
Emmanuele,
please don’t feel attacked. I’m not trying to make a point that gtk developers do a lousy job; on the contrary: you do a terrific job. But as you say yourself: there is just a few developers that work on gtk or glib. And I think we should try to get more developers into G* development. And by actively working with them, giving feedback on patches and bugreports, we can get more developers involved. That was the point I was trying to make. So my apologies I you felt attacked in any way.
I don’t think Emmanuele’s point is to defend himself or other maintainers. He is just saying out that, realistically, the way to improve the experience is for contributors to be willing to escalate their efforts suitably when bugs/patches are not looked at.
It helps massively if you also try to decrease the maintainers workload, for instance by triaging old bugs. It gives the maintainer more time/energy, and the goodwill you get from him or her for helping out usually gets your patches through faster.
In an ideal world, maybe this is not the way things ‘should’ be. But I think this will, to some extent, always be the reality in volunteer driven open source projects.
oh, don’t worry: I understood you weren’t “attacking” anybody. that is why I wanted to reply to you (something that I wouldn’t have done if I felt attacked), to ensure that you understand that the people hacking on the G* platform libraries completely sympathise with your issues, but that if you want to get more traction on them then you’ll have to engage on a fairly different level than just opening a bug and/or attaching a patch. that’s the way it is.
even if we want to get third party developers engaged in fixing the platform (which is truly what we want, honest), we simply don’t have the throughput to go through the thousands issues in Bugzilla and give them equal weight: it would require many more full time developers than we ever had. thus, we triage bugs, and we decide which ones have our attention, and which ones can wait.
I usually end picking up docs patches because they are quick and easy to review and push; some components, like the TreeView, the TextView, and the FileChooser widgets require domain specific knowledge, and not everyone can easily do a review. they are, not incidentally, the most complicated pieces of machinery we currently have inside GTK+. this means that the maintainers for those specific components (if they still have a maintainer) are swamped, mostly because they also have other duties. getting other people up to speed on those components requires time, and not many step up to the plate of learning how the platform works.
again: your pain is understood, and we want (and we’re trying) to get better that dealing with the bug queue. it’s not an easy task, and it gets harder if people don’t engage with us.
I’ve reopened the first bug. Looking at the patch, I’d like to see the rest of it applied as well.
I think though that there’s a difference between simply opening a bug report, and attaching a patch. As you say, it’s a two-way street, and if someone takes the time not only to report a bug, but tracking/debugging it, coming up with a fix and submitting the patch, one could say they’ve done their part/the first move, no?
I also probably have the bad luck of working with treeviews a lot (and most of patches I have submitted revolve around it), but sometimes even mentionning bugs on ML/IRC doesn’t get them reviewed… it’s easy to feel like the work done is ignored/useless, and more contributions not welcomed.
It’s easy to say this from the contributor perspective, but believe me being a maintainer is hard because work always piles up.
When someone pings me about their patch posted on a bug, I feel very grateful because it makes me able to give back (I’m also a maintainer). But I’m only human and I cannot ping/remind myself of all the things I haven’t done.
Sadly, this feels quite familiar indeed. Working with GTK myself I have reported a few bugs (often with patches) only to see them ignored… Doesn’t encourage to try and keep contributing.
Hello Olivier. I used to use Bluefish on few projects and it did good job. In my opinion, GTK 3.10+ have many new really nice widgets(GtkHeaderBar, GtkPopover, …) and it opens new evolution in desktop app designing. Look new app in coming GNOME 3.12 as Gedit, Totem,…really excited. It be motivation for new developers like me on GNOME app development. Hope you will keep loving on GNOME contribution and Bluefish will be more better in future. Thank you.
Part of the problem is the very high amount of bug reports (most of which are probably obsolete or invalid in some way now) on the GTK product on bugzilla.gnome.org: currently around four thousands!
I’d love bring that number down to manageable levels, but for this to happen I think we’d need a hackfest to have a team of 5-10 bug triagers sitting right next to GTK maintainers for a few days to do a massive cleanup sprint. Otherwise, gtk maintainers have a hard time relying on bugzilla to track what’s important.
It goes with what I presented at GUADEC 2013 😉
Of course it’s not the be-all-end-all magical solution, but it would certainly help.
The problem is that the gnome team don’t care about patches. There are so many bugs with patches, it stopped being funny anymore.
I can understand they cannot solve all the bug immediately, but I cannot understand how can they ignore patches for years. It’s people who care enough to wrote patches that the gnome team ignored.
Hey, I found a 2012 regression bug with a patch! And it effect me too. please review the PATCH. Actually, please review all the patches in the bugzilla! PLEASE.
https://bugzilla.gnome.org/show_bug.cgi?id=674215
I don’t think the gnome team doesn’t care. They are with too few people. Thus they do not have the time to look at the patches. Thus the new developer’s don’t get any feedback. And so they stop sending new patches and become more experienced. And that leads to a vicious circle.
Often, simply going through your forgotten bug reports with patches and commenting “Ping?” is enough to get some action happening.
As an application (Rawstudio) developer I agree 100%. My feeling is that if your’re not under the “protective Gnome umbrella”, you’re on your own and insignificant.
I don’t think so. there are plenty of projects with high visibility outside of the GNOME “umbrella”, and yet they do get patches in.
the actual question is: how do I get the GTK maintainers invested in my issues, given the fact that there is a limited amount of resources going around? the answer is, and should be obvious at this point: communication.
join IRC. ask on the gtk-devel-list mailing list. come at conferences and hackfests. get to know the GTK developers.
do not treat GTK as a black box, where patches go in and releases come out. GTK is an open source project, fully volunteer driven.
this is very much similar to how the Linux kernel development community works.
I just read claudio’s blog answer and because he does not admit comments, i just came here to grab that exact same setence:
“join IRC. ask on the gtk-devel-list mailing list. come at conferences and hackfests. get to know the GTK developers.”
The conclusion i make (and claudio’s point of view just says that) is that the gtk/gnome developers live more on their umbrellas.
There are a number of communication channels: IRC, conferences, mailling-lists, bugzilla.
Each must have a purpose.
If you have detect a bug and you want to submit a patch, i think the better communication option is clear.
Maybe the gtk/gnome developers are looking too much for the reported patches, because it envolves alot of work, and the work efforts must go in other ways.
I think that this blog post can help to improve this situation.
Cheers and keep up the good work!
I agree with this. When I have GTK+ patches that seems to go unnoticed, I usually send a message to the mailing list to ask for feedback. If it doesn’t work, I ask in IRC. Then they usually checks them and have my patches committed between a day (mailing list) to within some minutes (IRC). This happened before I joined any projects in GNOME.
It is usually not easy to commit patches, because you have to check them first thoroughly to make sure there are no regressions (even with small patches – I have accepted one before that changed only a singe line and it introduced a new bug). Even we in GNOME Music Team have problems with this, even though we don’t have much bug reports, so some patches usually takes days before they get committed. Sometimes we wait for more people to test the patches and see if it works for them too.
Though if you are an active contributor, the maintainers will usually trust you and commit your patches even without much testing. They expect that you would clean it up if it introduced some regressions.
As the one who reported the bug #722058 I am glad that it finally got some attention 🙂
I would like to suggest few things that should improve things… First, probably it would make sense to write somewhere how G* project collaboration works. For newcomers is not that obvious that after reporting the bug one also needs to register on IRC or ML and continue pinging developers to get bug reviewed. Second, I think it would make sense to allow more people to make commits… maybe this would reduce the number of not fixed bugs. I think fixing regressions, for example in 3.6.x branch, can be allowed for more broader circle… Again, there is no information (or information is hard to find) how request and get possibility to fix bugs…