Mark says:
I have little optimism that the internal code dynamics of Gnome can be fixed – I have seen too many cases where a patch which implements something needed by Unity is dissed, then reimplemented differently, or simply left to rot…
I’m presuming here that he’s referring to e.g. this bug, or maybe others. What Mark apparently isn’t understanding here is that this is a totally normal process for all patches to a competently run project, even if the patch is originated by a “maintainer”. It’s called code review.
Let’s take an example from just the “gnome-shell” module. Look at this bug, where I propose a change, and it gets marked “rejected”. I don’t have my feelings hurt – even though I really think my change is right and keep fighting for it (and eventually Dan does fix it in an even better way). You will find many, many examples of this kind of thing if you search Bugzilla. And this isn’t unique to GNOME – this is a large part of what is on say the Linux kernel mailing list.
What’s even more interesting is that anyone from the world can sign up to watch bugs for e.g. GLib, and review patches. By doing this, one can choose to take a stake in the future success of GLib, and not just see it as a code dump. While there is technically a MAINTAINERS file in each module, it’s just an imperfect reflection, not a hard line.
Could someone else show up today and just mark a patch accepted-commit-now? That would be frowned upon – it’s easy to just mark a patch as OK. But if one shows up and gain some history of pointing out issues or problems, that’s all it takes to gain the credibility to become a “maintainer”. Again, anyone can do it; there is no cabal.
Colin Walters 
I have a favorite quote for this mess:
“Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope.”
William Penn 1644-1718
I see and manage very similar disputes every week at work. What I have realized is this:
1) Information/communication is important
2) A clear, communicated and accepted procedure is necessary
3) When 2 is debated 1 has failed
Since Canonical /clearly/ is not on board with 2 GNOME has failed. I want to stress that GNOME is not wrong – but GNOME has failed. You can try and fight that but you will only wear yourself out.
At work I sometimes tell people that they have not followed the proper procedure. In the past I would spend most of my time telling a customer (in house or external) that they have not followed procedure and then dealing with blame games and sometimes even harassment. Then I started questioning how we were doing things and started to attach a question to the standard discussion: “How can we improve this process”?
Mind you, we still have to disappoint people occasionally. But having the discussion on how to soften/avoid the blow next time (and, if possible, apply it) really has helped.
As a long time GNOME fan it is heartbreaking for me to watch this.
I’m agree with you, but a bit depressed by my last report.
For start, I have propose a mackup. Don’t really good, but don’t really bad. I read review, modify my mockup, read review, modify, etc…
But now? An officiel dev say, in public mailling list, that I never considered criticals change my mockup. What? I have always do that! And the last two patch was just ignored.
How want to continue with this?
“this is a large part of what is on say the Linux kernel mailing list.”
How should Canonical know? :p
People have personal preferences and biases that factors into this, making the process seem less perfect than it sounds…
I’m not sure they are talking about that bug. But I do think it’s contains great examples of what the issue here is.
You have actually ready-to-go stuff like Zeitgeist (and, say Unity) that just needs a little patch.
The patch itself is not dicussed. The bug is just hijacked to develop a use-case a developer is interested in, that no current app is requesting.
At a certain point a XFCE developer jumps in, protecticely, to make sure you aren’t screwing them too much.
I’m just a nobody. Not related to anything. But kind of curious what’s going on with this gnome/ubuntu debate.
I don’t think there is true malice. But come on, the bug report linked is a huge fail on the part of gnome.
And this whole brainstorm session for a gnome specific app-launching deamon doesn’t belong in the bug report, and sounds more like a long-term in-progress ‘blueprint’ that affects core gnome architecture.
What the __beep__ does that blueprint-type dicussion have to do with a simple, small patch that actual applications need.
Sure the discussions are linked. But thats a long term thing. Your app laucher deamon isn’t here now. The patch could have been included.
Or at the very least, it could have been debated on its own merits. But the next gnome release is up, and the functionality needed by Zeitgeist (which is up there with Gnome-shell as a revolution, imho) isn’t there.
The gnome devs weren’t behaving as maintainers, that collaborate. They were just being selfish, chasing tails they prefer. The priorities were neither gnome’s nor canonicals priorities.
Perhaps the real solution for Gnome is to disconnect the maintainers (those who decide what patches go in and which do not) from the brain-storming creative developers.
Then again, isn’t that what most professional organisations do, anyways?
All the harsh words going around werent’ needed, but this bug report is good example of just how badly the gnome project is managed.
Perhaps interesting to add.
The main question Gnome needs to ask themselves is: are you a platform or a product?
Because people (XFCE, Canonical, Zeitgeist, app developers) are treating you as a platform. This inherently suggests a moderately serving attitude.
But the gnome devs are acting like it’s a finished problem. They don’t care about the gnome platform.
Which is fine. That’s a choice. Go announce it! So XFCE, Canonical, Zeitgeist, Mozilla, KDE, a zillion gnome/gtk based apps not part of the gnome-product can go together and fork the core gnome architecture.
Because if want XFCE devs to help out debugging and patching GTK, you better not make GTK dependent on GNOME. If you want Canonical to do the same, you better not make Gnome core libs to only serve the gnome-shell usecase. etc. etc.
This isn’t a competition between Gnome & Canonical. Nor between gnome-shell or unity. Its between gnome the platform and gnome the product.
I think, if Gnome stops being a platform, you will stop being relevant.
This whole gnome should be a finished, clearly branded product methodology is a disease.
It just screws ‘dear community, fork us’.
>It’s called code review.
No, nothing in the bug report is anywhere near what you would call a code review.
It’s called a brainstorm, what is going on there. The bug was hijacked to do a perhaps usefull brainstorm. It wasn’t the right place for it, and it really wasn’t related enough, at least in timeframes to act like the suggested patch and brainstorm were mutually exclusive.
Meener: the Canonical / Ubuntu devs who submitted the request Colin uses as an example are perfectly happy with the eventual re-implementation and are adjusting / have already adjusted bamf to use it.
(I would note that that bug sat unattended to for six months until I started making noise about it, but that’s as susceptible to the cock-up theory as to the conspiracy theory; as a general rule all F/OSS projects are under-resourced and have far more bug reports than they can usefully attend to at any given time.)