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 <[email protected]> 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. >
