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

[Jeremy Epstein]

It would be a great accomplishment to get Views in core for D8. But
there are major challenges to getting there:

1. Get core ready for Views. By this, I'm mainly referring to
finishing the CCK in core effort, which is itself still far from
complete. In particular, I don't think we should even consider
starting to put Views in core until the CCK UI hits core in some shape
or form. The low-level Field API also still has plenty of issues to be
resolved (although these are largely on track for being done by D7
release).

2. Get Views ready for core. Let's face it, the current Views contrib
module is not suitable core material. Views in core needs to be much
leaner, it needs significant usability re-working (according to recent
D7UX commentary), and it needs to be much more themer-friendly
(according to recent Design 4 Drupal commentary, and my own
experience). Of course, this isn't exactly groundbreaking news - we
should all know that moving a module / API from contrib to core is
never simply a matter of copying and pasting.

As for "we do not do anything else for Drupal 8"... hahaha!! You're dreaming.

Cheers,
Jaza.

On Tue, Aug 11, 2009 at 3:13 AM, Karoly Negyesi<karoly at negyesi.net> wrote:
> 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.
>