[development] How could everyone win and get Views in Drupal 8?

Karoly Negyesi karoly at negyesi.net
Mon Aug 10 17:13:32 UTC 2009


I (that means I. Disclaimer: this is my idea. blame me.) would like to see

-- Views in core. Without Merlin burning out.
-- more shops contributing to core. The biggest deterrent currently
IMO is that their work might or might not be accepted and even if gets
in, it might be two years before they can use on a client site.
-- the security team to only deal with releases that have automated
testing so they have a good chance of their patches not breaking core.

To achieve all this in one plan, I would like first to ask everybody
who wants to contribute core to go to the Views queue and help out!
Support requests, bug reports, many things are doable without being
the Grand Master of Views. This has immediate returns in fixed bugs,
or just a little bit less immediate with less load on Merlin resulting
in better Views. But it does not take two years to get deployable
results, not at all.

And then, if we have brought down the Views queue to a managable size,
then we should write tests for Views. Again, this is something a lot
of people should be capable of even without knowing the innards of
Views and usable right now even with Drupal 6 -- simpletest is
backported.

Once we have a lot of tests, we should commit them to core along with
skeleton code that makes the tests pass. This is a radical but logical
change to our core development model. Hopefully this can lead to many
smaller patches striving to replace smaller pieces of skeleton code
with real instead of few gigantic patches trying to get some major
part of Views in core.

We do not do anything else for Drupal 8. No other major API changes
just tests for Views which are immediately and easily backportable to
Drupal 7, once again allowing for immediately deployable code.
Obviously there will be changes as our old and hardwired modules get
partially replaced by Views. However, this plan would hopefully allow
for a short Drupal 8 cycle instead of a year plus long one and when
Drupal 8 gets released, the security team has an easier work.

Another side benefit is that I can see people jumping over Drupal 6
completely with the D7CX movement quickly putting a deployable (I seem
to like that word) Drupal 7 on the table. So relatively quickly (but
still it gets more than two years) deprecating D6 wont be as bad.
Also, as Drupal 8 won't break APIs as bad as usual, the contrib
authors will have an easier job of maintaing D7 and D8 branches.

Another benefit is that the usability folks can work on a stable
platform so Drupal 8 can be even more usable than Drupal 7.

I should list the drawbacks here but aside from a few crazy core
developers (like little me) being a bit frustrated for being in a soft
API freeze for Drupal 8, I can't see any. I will certainly be less
frustrated over not being able to overhaul everything than I would be
to being able to but working almost in isolation. There is a huge
chasm between real world sites and core development and this would
allow us to bridge.


More information about the development mailing list