IMHO, we'd have to have a different stance on backward compatibility if we were planning on shortening release cycles much. The linux Kernel does not require significant refactoring of code built on top of it every 6 months. I'm still not sure if I have a migration path identified for my universities drupal sites with D6, even though I've already ported all of my modules to D6. It is possible that much of the interesting work about extending drupal really is properly in contrib and not in Core. The fact that most of what I hear being touted as new features for drupal 6/7 are the movement of contrib support into core is not necessarily a bad thing. It''s pretty proven code after all. I think finding a pathway to move old stuff out of core is not necessarily a bad idea either. Strikes me as the pathway for evolution of drupal. I think think the right answer about drupal stagnating was really about having Views, Panels, and WYSIWG api all going through major refactoring on D6, all lagging significantly the D6 release. I know it's why I'm not using my own D6 ported modules in any production sites yet. Dave On Apr 20, 2009, at 2:19 PM, Dries Buytaert wrote:
Something else which is worth to discuss.
In private conversations, various people have expressed concerns that our release cycles are too long, and that, as a result, they are not interested in working on core. If they have a problem, and they fix it in core, they have to wait 1-2 years before they can actual use their own improvement in a production environment. In a lot of cases, people don't bother with it because they can't wait that long.
We see evidence of that around code freeze time, when people actually do start to bother and patches tend to move through the review cycle quite a bit faster -- creating it own set of frustrations.
In other words, moving to shorter release cycles could help. Not only does it increase the incentive for people to work on core, it could also provide additional focus. Because we have been working on Drupal 6 so long, people might have lost some of their incentive and motivation. There is a certain engery-cycle/rhythm that we might have broken with the longer Drupal 6 development cycle.
In fact, a lot of big projects, like the Linux kernel, Gnome, KDE, Ubuntu, Fedora and Wordpress all switched to 6 month release cycles. Mark Shuttleworth posted some good insights about that in a recent blog post: http://www.markshuttleworth.com/archives/288. I'm not suggesting that we should switch to 6 month release cycles, I'm merely bringing it up to get feedback on the idea.
On Mon, Apr 20, 2009 at 11:03 PM, Dries Buytaert <dries.buytaert@gmail.com> wrote:
I think catch hits a lot of good points about how our reward and trust system could be improved. I'm all for better profile pages, giving credit where credit is due, and providing better visibility into who is working on what. It might be useful to provide a "Reviewer rating" or "Reviewer score" -- something which could be an incentive for more people to review patches. Maybe this can be accomplished through some project module extensions? I'm not sure what the best approach would be, but it is worthy of a discussion.
-- Dries Buytaert :: http://buytaert.net/