![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
This is an answer to Jimmy Berry's blog post (disclaimer: we both are employed by NowPublic but neither his nor mine has anything to do with the company). I just reiterate my idea -- can't remember where I posted it if I did or whether it was just a chat with Dries. Many a people suggested handing out commit access to people in MAINTAINERS.txt and I agree with that but with a twist: subsystem maintainers can not commit patches written by subsystem maintainers! So if pwolanin and I get commit access to the menu subsystem then I can't commit Peter's or mine patches. Only branch maintainers can do that. Who wins? Ordinary core developers win because their patches get in much faster because there are a small army of committers and the workload spreads. The subsystem maintainers win because the branch maintainers can deal with their patches much quicker because they only need to deal with those, much fewer patches. The branch maintainers need to deal with less patches. The community wins because we created a huge incentive for the subsystem maintainers to nurture their own little community, people who work on their subsystem because that's the way their little realm can grow quick.
Commenting on this Story is closed.
Brilliant.
Although we like to dream of agile development, distributed version control and a world where we are all equals, on the same playing field – sometimes a hierarchical chain of command just makes the most sense.
I should add as well, that anyone who's deployed large Drupal sites knows that the answer to scaling is neither "just horizontal" or "just vertical" but both are needed to scale efficiently. Too many chains of command and you still have bottlenecks, but letting each maintainer commit wherever whenever could still lead to chaos. This is the most sane suggestion that I've seen yet.
...And I definitely agree that putting subsystem maintainers in a position to actually maintain their code is a good thing. The problem right now is that Drupal has a lot of crosstalk between modules, APIs, and other components. An example is a Menu API change that affects other modules. Do the maintainers for those modules need to weigh in, or can their code be changed because it's "just" the menu code?
Ironing out those boundaries is where the complication lies, I think.
That said, I agree that a larger pool of committers is ultimately a good thing. Even having 'advisors and reviewers' as Webchick does requires someone with the superhuman energy of Webchick doing the actual wrangling for every single patch.
That's I think clear. Outside of that, let's say we were to add a change like the recent big theme change which required a change to every function, you can always say "too big a change. Let the branch maintainer deal with it".
The comments @ that post were closed, so I'm commenting here.
Nice video, I embeded it on my blog alexanderallen.name
I have a question, don't know if you know the answer:
Does D7 DB API suppport database functions, procedures and transactions?
I am writing a module that uses the transaction support available in PHP5 because the current state of Drupal 6 doesn't support this. The bad thing is that you need to create a separate mysql object instance and connection.
The upside is that loading a page using a stored procedure seems faster to me.
These all are good advices.
p90x workout schedule, p90x dvd,moncler jackets, moncler coats, moncler