Why would you want views in core?<br><br>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.<br>
<br>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.<br><br>Just my $0.02<br clear="all">-----<br>Cameron Eagans<br>Owner, Black Storms Studios, LLC<br>
<a href="http://www.blackstormsstudios.com">http://www.blackstormsstudios.com</a><br>
<br><br><div class="gmail_quote">On Mon, Aug 10, 2009 at 11:13 AM, Karoly Negyesi <span dir="ltr"><<a href="mailto:karoly@negyesi.net">karoly@negyesi.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I (that means I. Disclaimer: this is my idea. blame me.) would like to see<br>
<br>
-- Views in core. Without Merlin burning out.<br>
-- more shops contributing to core. The biggest deterrent currently<br>
IMO is that their work might or might not be accepted and even if gets<br>
in, it might be two years before they can use on a client site.<br>
-- the security team to only deal with releases that have automated<br>
testing so they have a good chance of their patches not breaking core.<br>
<br>
To achieve all this in one plan, I would like first to ask everybody<br>
who wants to contribute core to go to the Views queue and help out!<br>
Support requests, bug reports, many things are doable without being<br>
the Grand Master of Views. This has immediate returns in fixed bugs,<br>
or just a little bit less immediate with less load on Merlin resulting<br>
in better Views. But it does not take two years to get deployable<br>
results, not at all.<br>
<br>
And then, if we have brought down the Views queue to a managable size,<br>
then we should write tests for Views. Again, this is something a lot<br>
of people should be capable of even without knowing the innards of<br>
Views and usable right now even with Drupal 6 -- simpletest is<br>
backported.<br>
<br>
Once we have a lot of tests, we should commit them to core along with<br>
skeleton code that makes the tests pass. This is a radical but logical<br>
change to our core development model. Hopefully this can lead to many<br>
smaller patches striving to replace smaller pieces of skeleton code<br>
with real instead of few gigantic patches trying to get some major<br>
part of Views in core.<br>
<br>
We do not do anything else for Drupal 8. No other major API changes<br>
just tests for Views which are immediately and easily backportable to<br>
Drupal 7, once again allowing for immediately deployable code.<br>
Obviously there will be changes as our old and hardwired modules get<br>
partially replaced by Views. However, this plan would hopefully allow<br>
for a short Drupal 8 cycle instead of a year plus long one and when<br>
Drupal 8 gets released, the security team has an easier work.<br>
<br>
Another side benefit is that I can see people jumping over Drupal 6<br>
completely with the D7CX movement quickly putting a deployable (I seem<br>
to like that word) Drupal 7 on the table. So relatively quickly (but<br>
still it gets more than two years) deprecating D6 wont be as bad.<br>
Also, as Drupal 8 won't break APIs as bad as usual, the contrib<br>
authors will have an easier job of maintaing D7 and D8 branches.<br>
<br>
Another benefit is that the usability folks can work on a stable<br>
platform so Drupal 8 can be even more usable than Drupal 7.<br>
<br>
I should list the drawbacks here but aside from a few crazy core<br>
developers (like little me) being a bit frustrated for being in a soft<br>
API freeze for Drupal 8, I can't see any. I will certainly be less<br>
frustrated over not being able to overhaul everything than I would be<br>
to being able to but working almost in isolation. There is a huge<br>
chasm between real world sites and core development and this would<br>
allow us to bridge.<br>
</blockquote></div><br>