We have written some very frustrated blog posts. Time to reflect on them and outline some causes and plans to move forward.
1. Why are we so frustrated?
There have been a small number of people consistently fighting the major/critical bug queue for a long time. We got Drupal 7 released (through patching and reviewing some 8000 issues) but after that we needed to continue the bug fighting and this really got on people's nerves. For example the upgrade path has been critically broken for two years without a break.
We went through a hellish period in Drupal 7 where we had hundreds of critical bugs - both from letting the queue get out of hand, and actually having a lot of bugs in core. To try to stop this happening again for Drupal 8, and to limit what can happen there while so many outstanding bugs are in D7, we put thresholds in place. But this comes at a cost: people like writing cool new features a lot more than fixing these radioactive, ugly bugs and core development have been stuck fixing the bugs for a couple of years already (or bowed out while that happens and not come back yet). Although if you want a gold star on your resume, fix some of these :)
So what we really need here are two things: get more new people into the bugfighting trenches, and unblock day-to-day development of core for non-bugfixes. We already started office hours, we have just started the core announcement feed, we will announce specific bugs we will work on a given day (week?) and mentor people to work on them. Getting more people involved in bugfixing is definitely not a pipe dream, boobaa fixed a very gnarly upgrade critical as his first core contribution, this needs to be sustainable though so people don't leave as quickly as others get involved.
Second, once we are down to something like 70 instead of 100 majors, and Drupal 8 progress quits being blocked every other day, and Drupal 8 advances and becomes more discernible from Drupal 7, more people will come. See 3. for more on this.
Finally, webchick is going to write a blog post about some other some efforts to rope in more core contributors. Stay tuned! But also please share your ideas about how to get more.
2. Dries was unavailable for a long time, unable to commit sufficient time to core and meta issues like process you read a lot about in this blog post (like the tresholds above). However, Dries is actively working on this, and his availability will sharply increase as he is done with reorganizing the Drupal Association and also he is hiring people (like webchick and Moshe) to take over some of his Acquia responsibilities.
3. There's little doubt that Drupal needs some major refactoring, most importantly we want to change the extremely tightly coupled nature of Drupal.
We think that even the most drastic refactoring can happen within the current process without a ground-up rewrite. Major changes happened in Drupal 7 such as DBTNG without starting again from scratch. However core processes need to be updated to incorporate refactoring as well.
We discussed such drastic use cases as changing the API and internals for module_invoke_all() and drupal_alter() -- even that can be done step by step by introducing first a module_invoke2, converting core hook by hook and at the end rename. Once an API change is agreed, if it's possible to add a backwards compatibility layer temporarily, it allows work to be done in manageable chunks. This worked for the database API in Drupal 7 - which was committed around 18 months before the bc layer was removed. It needs be very clear such things are temporary -- we still dont want to be bloated permanently by being backwards compatible -- some ideas include throwing deprecated errors from the old implementation and adding doxygen indicated the deprecated state.
We may also need to allow for some breakage when major changes are committed, but the issue thresholds will allow us to do that without things getting completely out of hand. If thresholds are breached unintentionally then it will hopefully lead to an 'all hands on deck' situation.
To avoid months of reroll hell we started scheduling big changes -- once we have agreed on a given API, a given change there is a specific date when it will get in.
4. We do not want to move many modules into contrib because it's unclear who would maintain them there. Of course, it's a burden on core developers but keeping API consumers around is a good way to verify whether our APIs work. However, we will evaluate modules like php, profile and trigger. But, we want the new D7UX modules to stay because we are a product and not a framework. Drupal actually is a sucky framework, Zend, Symfony 2 etc. are much better frameworks. Our strength is we are a product and we need to focus on that. Right now these modules are a burden but we hope that as outlined in 1. the core team (whatever that means) will work hard to find maintainers for them. We might want to spin them off in the future but only when we know who is going to maintain them because we need them for the product to succeed. Success is a multi facet issue: also it's easier to suck people into core development by getting them fix user facing bugs. webchick just called these gateway drugs.
Also, look at Linux on the desktop! If you do not focus on having a convincing product for end users, guess what? Technical prowess wont impress them. The year of Desktop Linux never happened. Not even when Windows Vista appeared after so many years and it was crap. This a big warning for us. (Yes, the Linux kernel is a success but I am talking of the desktop.) Also note that while the previous points were a result of a community discussion, this paragraph is mine only.
Commenting on this Story is closed.