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

[Cameron Eagans]

Why would you want views in core?

You put views in core and it is frozen. Nobody can do anything with it (as
far as changing it: adding new features, reworking existing code, etc). As a
contrib module, the Views maintainers can decide how they want to run the
release process for Views, and I personally would like to keep it that way
-- it allows for a LOT more flexibility and a much faster development
lifecycle.

Plus, core is already weighing in at around 9.5 MB. Adding another 4.5 MB of
code to maintain doesn't seem like a good idea to me.

Just my $0.02
-----
Cameron Eagans
Owner, Black Storms Studios, LLC
http://www.blackstormsstudios.com


On Mon, Aug 10, 2009 at 11: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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090810/afaa02fd/attachment-0001.htm>