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.