I agree that Gabor has done a great job for these latest months and also with the need of some kind of 'subsystem maintainers/targetted committers'. But the thing is to have 'targetted committers' we firs need to have something: goals and targets. And not individual ones, like it seems to be now for each developer, but team goals/targets, so we can work as a -big- team towards some common goals, and better focus time and energy. So how about moving from this current time-based release cycles to something at least a bit more 'feature driven'. How about having a roadmap? And by 'a bit more' I mean we don't need to go with the same 'hardcoded' roadmap from beginning to end, but we could go through some development/review cycles, addapting the roadmap as time passes and having a time frame to fit the roadmap in. For what we've seen these latest months, and for each previous release too, but the issue gets bigger as Drupal grows, most of us have been fighting some patches/features till the last minute before the code freeze with better luck for some and worse for others. Wouldn't have been much better if we had known before which ones were getting in and which ones not so we could have better focused the huge amount of time and energy? So it could go like this: 0. We start with the big list of what everyone plans to do 1. Some time to get started with new patches/features and maybe for some new ideas 2. Sometime towards the middle of the realease cycle we stop for a minute and see which of the initial ideas are really in progress, what we've got and what would be possible and also on which ones everybody has more interest. 3. Then we put together a reduced list based on: - Progress - Interest - Time left 4. More development and discussion on the issue queue, but just around the features left in the previous step 5. Time? Progress? (Back to 3, new 'reduced list'.) We can go through one or more of this coding/review/restating targets cycles till the end of the process (Drupal 7?). But the main idea is that we won't be fighting our patches till the last minute, but we are periodically re-aligning our attention and effort around just a few issues left. I don't know exactly which kind of tools we'd need to support such a process, maybe a rating system for patches or features or how it will work for many small -maybe depending on each other patches-. But I really think we can better focus our efforts and try to avoid so much time and work spent on things that finally didn't get in. There are really some more things I wanted in Drupal 6, but had I known in advance they weren't finally getting in maybe I could have worked on someone else's patchs which I liked too.... Jose Robert Douglass wrote:
The link[1] Thomas Barregren posted was quite interesting. Indeed, Drupal seems to be experiencing some of the issues the Linux kernel faced some years ago, albeit not nearly as drastically. Reading through that post and the rest of the comments on the mailing list here bring me to some observations.
1. Gabor has done a great job. In particular, he has led the drive for i18n features in core. That's awesome. 2. Gabor came in almost as if he had a mandate to focus on #1, and indeed, he has focused nearly exclusively on #1. 3. Whether this was by accident or design, it worked well and would seem to be scalable and repeatable. 4. Dries could "scale" his vision of Drupal architecture by assigning more such targeted committers. He could say "Jeff Eaton... for D7, your job is to make sure the Data API gets in, and that it rocks." Or "KarenS, for D7, your job is to make sure CCK hits core, and that it rocks." Or "Earl Miles, get your query builder into core and integrated at a deep level, and make sure it rocks." 5. Whether or not the people in #4 get core commit privileges is nearly irrelevant (though I'd opt for them having commit privs, with the understanding that they were to be exercised on a limited domain of applicability only.) The important part would be that one person was understood to be "in charge" of the features. Any other developers wishing to see those features into core would have to work with the target committer, and the target committer would be responsible for tracking and coordinating the effort.
We do this in a way now, so codifying it would only be a reinforcement of current patterns. Yet by making it formal we'd be enhancing the efficiency and scale of the operation. Such an approach may be the way in which we get high quality features into core while Dries maintains the overview and flexibility to do what he's been doing so well.
-Robert