Hi, What is the latest news about the D7 code freeze. I haven't seen any announcement on this list. Do we have a date for the code freeze, or at least a better estimate than what was offered at the beginning of the thaw? thanks, Augustin.
The latest news (unless there's an update I'm not aware of) is still http://buytaert.net/drupal-7-timeline So I guess it depends on what Dries means by "fully embrace testing" and whether we've done that or not. See also: http://drupal.org/node/254640 Nat On Tue, Jun 24, 2008 at 9:36 AM, Augustin (Beginner) wrote:
Hi,
What is the latest news about the D7 code freeze. I haven't seen any announcement on this list. Do we have a date for the code freeze, or at least a better estimate than what was offered at the beginning of the thaw?
thanks,
Augustin.
On Tuesday 24 June 2008 17:03:35 Nathaniel Catchpole wrote:
The latest news (unless there's an update I'm not aware of) is still http://buytaert.net/drupal-7-timeline
So I guess it depends on what Dries means by "fully embrace testing" and whether we've done that or not.
See also: http://drupal.org/node/254640
Thanks for the links. I was not aware of the second. The former is precisely why I'm asking. July 15th is approaching quickly, and it'd be nice to have a more precise estimate, now. Thanks, Augustin.
I've been thinking about this some. While we have made incredible progress with the test infrastructure as well as implemented a dozen of usability improvements, we're still light on feature improvements (such as fields in core). Combined with the late arrival of CCK and Views, and the many Drupal 6 books that are currently being written, it sounds best to postpone the code freeze a little longer. Given the current state of things, the proposed July 15 deadline seems a bit too aggressive to my liking. If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement. Thanks, On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote:
Hi,
What is the latest news about the D7 code freeze. I haven't seen any announcement on this list. Do we have a date for the code freeze, or at least a better estimate than what was offered at the beginning of the thaw?
thanks,
Augustin.
-- Dries Buytaert :: http://buytaert.net
Dries and all, Great news! I think it is only natural that Drupal's success will lead to slower development cycles. Most Drupal shops will only begin creating Drupal 6 production sites this summer. There will be so much learned from creating productrion sites in 6. That learning should be taken into account when coding for 7. In my opinion, what is key for Drupal to stay true to its core values is that major upgrades remain open to significantly changing APIs where they lead to improvements in the platform. That will keep Drupal fresh and compelling. There don't need to be yearly major releases to keep Drupal fresh. I can also imagine that it might be in Acquia's interest to slow down development cycles. Though Acquia's interests may not always be the same as Drupal's, I think often they are. I don't think there is anything wrong with adjusting development cycles or other plans based on Acquia's interests. I know you didn't a mention a date for the code freeze. I'd vote for Spring of '09. Shai On Thu, Jun 26, 2008 at 3:08 AM, Dries Buytaert <dries.buytaert@gmail.com> wrote:
I've been thinking about this some. While we have made incredible progress with the test infrastructure as well as implemented a dozen of usability improvements, we're still light on feature improvements (such as fields in core).
Combined with the late arrival of CCK and Views, and the many Drupal 6 books that are currently being written, it sounds best to postpone the code freeze a little longer. Given the current state of things, the proposed July 15 deadline seems a bit too aggressive to my liking.
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
Thanks,
On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote:
Hi,
What is the latest news about the D7 code freeze. I haven't seen any announcement on this list. Do we have a date for the code freeze, or at least a better estimate than what was offered at the beginning of the thaw?
thanks,
Augustin.
-- Dries Buytaert :: http://buytaert.net
+1 for postpone code freeze D7 Thanks, Folkert Hielema Dries Buytaert wrote:
I've been thinking about this some. While we have made incredible progress with the test infrastructure as well as implemented a dozen of usability improvements, we're still light on feature improvements (such as fields in core).
Combined with the late arrival of CCK and Views, and the many Drupal 6 books that are currently being written, it sounds best to postpone the code freeze a little longer. Given the current state of things, the proposed July 15 deadline seems a bit too aggressive to my liking.
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
Thanks,
On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote:
Hi,
What is the latest news about the D7 code freeze. I haven't seen any announcement on this list. Do we have a date for the code freeze, or at least a better estimate than what was offered at the beginning of the thaw?
thanks,
Augustin.
-- Dries Buytaert :: http://buytaert.net
I haven't even caught up to D6.... D7 can totally wait on freeze... no need to put the cart in front of the horse as the saying goes. On Thu, Jun 26, 2008 at 3:52 AM, Folkert Hielema <hielema@gmail.com> wrote:
+1 for postpone code freeze D7
Thanks,
Folkert Hielema
Dries Buytaert wrote:
I've been thinking about this some. While we have made incredible progress with the test infrastructure as well as implemented a dozen of usability improvements, we're still light on feature improvements (such as fields in core).
Combined with the late arrival of CCK and Views, and the many Drupal 6 books that are currently being written, it sounds best to postpone the code freeze a little longer. Given the current state of things, the proposed July 15 deadline seems a bit too aggressive to my liking.
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
Thanks,
On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote:
Hi,
What is the latest news about the D7 code freeze. I haven't seen any announcement on this list. Do we have a date for the code freeze, or at least a better estimate than what was offered at the beginning of the thaw?
thanks,
Augustin.
-- Dries Buytaert :: http://buytaert.net
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
http://buytaert.net/drupal-7-timeline has a later November 15, 2008 freeze date if we are doing good in testing. We do! And during DrupalCon http://szeged2008.drupalcon.org/sessions/testing-part-2-awesome-testing-part... we shall have a testing writing party for more awesomeness. However, I would like to suggest an even later freeze. The need for supporting Drupal 5 longer than usual has been raised and it would be a simple solution if we simply would push the projected release to next summer. There is no rush: Drupal 5 and Drupal 6 are fine releases, much more so than anything before, they perfectly can carry the Druplicon flag proudly for another year. This was less so with earlier releases, unlike with previous Drupals I feel no pressing need of dropping support as soon as feasible. While one could say this is just hubris on my side because I am more deeply involved with these releases, I hope this is not so, my involvement in Drupal 4.7 was also quite significant (I think more so than Drupal 5) and yet I was very happy when the support for that got dropped... I recommend adding some usability enhancements to Drupal 6 meanwhile. It can be said that some of these are bugfixes, as in, UI bugs :) and the usual argument against backports is that people will be less eager to up to the next release -- I would like to see Drupal 7 be so much faster (because so much less code is loaded) that people will rush to it. Regards Karoly Negyesi
I'd also like to see a much later code freeze. At least November 15th - but the first half of next year also sounds good. Testing has come a long way, but time spent on that has slowed down development of features (and in my own case time spent using D6 and helping get modules upgraded for that) - on my part this is betting on a longer D7 release cycle, so there'll be a longer period to get these things in later - so I really hope that plays off... There are also Summer of Code projects which directly impact quite neglected parts of core (new help system, new aggregator etc.) - delaying the code freeze might give these a chance to develop into core patches - but it'll be a long wait to get them into Drupal 8. Since testing is generally working to keep things pretty stable, we should be able to have a much, much shorter freeze/beta/rc period - and much less incentive for people to try to push patches in at the last minute. And there's no D7 maintainer yet - wouldn't be fair to only let them commit patches during code freeze would it? Nat
Just to confirm what seems like an overwhelmingly unified sentiment: a later D7 seems like a good thing. We started a bunch of work on the search system at the search sprint in Minnesota and I'd really like to see the bulk of it get finished. Yet I'm still sitting on relatively popular modules that I have to upgrade to D6 and I can't help but think that they are a bigger priority for me at the moment. Delaying the date of the code freeze just seems like the right thing. - Robert On Jun 26, 2008, at 11:36 AM, Nathaniel Catchpole wrote:
I'd also like to see a much later code freeze. At least November 15th - but the first half of next year also sounds good.
Testing has come a long way, but time spent on that has slowed down development of features (and in my own case time spent using D6 and helping get modules upgraded for that) - on my part this is betting on a longer D7 release cycle, so there'll be a longer period to get these things in later - so I really hope that plays off...
There are also Summer of Code projects which directly impact quite neglected parts of core (new help system, new aggregator etc.) - delaying the code freeze might give these a chance to develop into core patches - but it'll be a long wait to get them into Drupal 8.
Since testing is generally working to keep things pretty stable, we should be able to have a much, much shorter freeze/beta/rc period - and much less incentive for people to try to push patches in at the last minute.
And there's no D7 maintainer yet - wouldn't be fair to only let them commit patches during code freeze would it?
Nat
Here's another confirmation of that seemingly unified sentiment. It seems to me nobody has had enough time to *really* start working with D6. I also still have to port several relatively popular modules, and for me too, they are a higher priority than contributing to D7. So, I'm also for a delay of the code freeze. Wim Leers ~ http://wimleers.com/work On Jun 26, 2008, at 12:04 , Robert Douglass wrote:
Just to confirm what seems like an overwhelmingly unified sentiment: a later D7 seems like a good thing. We started a bunch of work on the search system at the search sprint in Minnesota and I'd really like to see the bulk of it get finished. Yet I'm still sitting on relatively popular modules that I have to upgrade to D6 and I can't help but think that they are a bigger priority for me at the moment. Delaying the date of the code freeze just seems like the right thing.
- Robert
Yes, this is great news. I feel like all I'm doing is trying to catch up with module upgrades, and was worried I'd miss out on really diving into d7 before its code freeze. The only sadness I feel is the inevitable wait on hook_file. On the flip side, it would give some time for some experimentation with hook_file on the contrib side, which would hopefully allow contributors to make use of that feature and others closer to its launch. Drupal 6 will have time to mature, and Drupal 7 will be a more solid launch for it. Wim Leers wrote:
Here's another confirmation of that seemingly unified sentiment. It seems to me nobody has had enough time to *really* start working with D6. I also still have to port several relatively popular modules, and for me too, they are a higher priority than contributing to D7. So, I'm also for a delay of the code freeze.
Wim Leers ~ http://wimleers.com/work
On Jun 26, 2008, at 12:04 , Robert Douglass wrote:
Just to confirm what seems like an overwhelmingly unified sentiment: a later D7 seems like a good thing. We started a bunch of work on the search system at the search sprint in Minnesota and I'd really like to see the bulk of it get finished. Yet I'm still sitting on relatively popular modules that I have to upgrade to D6 and I can't help but think that they are a bigger priority for me at the moment. Delaying the date of the code freeze just seems like the right thing.
- Robert
Agreed on the later code freeze, and I definitely think next summer is not unreasonable. Coming from an in-house shop with large installations who are struggling to get a D6 upgrade still in the works almost solely because D5 might not be supported (okay the cooler features of the framework are a huge incentive to the devs) it's slightly intimidating to think that there already be a code freeze on the next version of Drupa when we *might* have D6 upgrades done by the end of October. Many modules have still not caught up (mine being some of them) making it very hard to get full platforms up to speed with D6. So yes, many reasons from an in-house perspective to have longer development periods. +3 (taking into account my colleages aren't on this list but feel the same). On Thu, Jun 26, 2008 at 8:03 AM, Wim Leers <work@wimleers.com> wrote:
Here's another confirmation of that seemingly unified sentiment. It seems to me nobody has had enough time to *really* start working with D6. I also still have to port several relatively popular modules, and for me too, they are a higher priority than contributing to D7. So, I'm also for a delay of the code freeze.
Wim Leers ~ http://wimleers.com/work
On Jun 26, 2008, at 12:04 , Robert Douglass wrote:
Just to confirm what seems like an overwhelmingly unified sentiment: a
later D7 seems like a good thing. We started a bunch of work on the search system at the search sprint in Minnesota and I'd really like to see the bulk of it get finished. Yet I'm still sitting on relatively popular modules that I have to upgrade to D6 and I can't help but think that they are a bigger priority for me at the moment. Delaying the date of the code freeze just seems like the right thing.
- Robert
Since chx is in favor of a delay, I can support that idea, too. ;-) Seriously, how about a freeze date of January 15, 2009? -- ..chris
On Thu, 2008-06-26 at 14:03 +0200, Wim Leers wrote:
Here's another confirmation of that seemingly unified sentiment. It seems to me nobody has had enough time to *really* start working with D6. I also still have to port several relatively popular modules, and for me too, they are a higher priority than contributing to D7. So, I'm also for a delay of the code freeze.
Likewise for me. I've been so busy converting my company's internal-use modules (customized for our accounting environment, not useful to the community) that I'm behind schedule on my GPL modules. They're in work, but not yet done. Luckily once I'm done with the internal ones, my boss says I can do the GPL ones on company time as "independent R&D work". I've found Drupal 6 to be a really terrific release, and would be happy to see it remain current for a while as we work on an equally terrific and compelling D7 behind the scenes. Better a fantastic release in 18 months than a pretty-good release in 12, in my opinion. +1 for delaying the freeze. Scott -- Syscrusher <syscrusher@4th.com>
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
http://buytaert.net/drupal-7-timeline has a later November 15, 2008 freeze date if we are doing good in testing. We do! And during DrupalCon http://szeged2008.drupalcon.org/sessions/testing-part-2-awesome-testing-part... we shall have a testing writing party for more awesomeness. However, I would like to suggest an even later freeze. The need for supporting Drupal 5 longer than usual has been raised and it would be a simple solution if we simply would push the projected release to next summer. There is no rush: Drupal 5 and Drupal 6 are fine releases, much more so than anything before, they perfectly can carry the Druplicon flag proudly for another year. This was less so with earlier releases, unlike with previous Drupals I feel no pressing need of dropping support as soon as feasible. While one could say this is just hubris on my side because I am more deeply involved with these releases, I hope this is not so, my involvement in Drupal 4.7 was also quite significant (I think more so than Drupal 5) and yet I was very happy when the support for that got dropped... I recommend adding some usability enhancements to Drupal 6 meanwhile. It can be said that some of these are bugfixes, as in, UI bugs :) and the usual argument against backports is that people will be less eager to up to the next release -- I would like to see Drupal 7 be so much faster (because so much less code is loaded) that people will rush to it. Regards Karoly Negyesi
On 26 Jun 2008, at 12:48, Karoly Negyesi wrote:
http://buytaert.net/drupal-7-timeline has a later November 15, 2008 freeze date if we are doing good in testing. We do! And during DrupalCon http://szeged2008.drupalcon.org/sessions/testing-part-2-awesome-testing-part... we shall have a testing writing party for more awesomeness.
I do think we're doing great work on testing. I've been committing testing related patches on a (almost) daily basis. That's pretty sweet. That said, we aren't able to measure our test coverage yet. In other words, it's really hard to tell how well we actually do. Any updates on that? -- Dries Buytaert :: http://buytaert.net
Dries Buytaert wrote:
I do think we're doing great work on testing. I've been committing testing related patches on a (almost) daily basis. That's pretty sweet.
Like catch and others, I've been dumping basically all the time I have available to work on D7 on testing stuff, in the hopes that it will help extend the code freeze out to when I will have much MORE time to dump into D7 in the fall. ;)
That said, we aren't able to measure our test coverage yet. In other words, it's really hard to tell how well we actually do. Any updates on that?
I think that our current test coverage by conventional tools is going to be close to 0%. It's also clear that the community has not in fact "embraced testing." Instead, a hardcore group of around 15-20 people (the "testing brigade" ;)) have, and are driving this effort forward on behalf of the rest of the development team. I also think that both of these situations are okay right now. Because what the "testing brigade" has been focusing on is: 1. Improvement of testing tools. For example, that Batch API patch that was just committed I think is the *key* turning point that will make testing something that can be done by normal humans rather than just the "testing brigade." 2. Fixing of existing tests. Back when I wrote http://webchick.net/itch-of-the-week/fix-testing-crisis, we were in pretty sorry shape in this regard. I remember growing the critical bug queue by at least 20 in one night documenting all the tests that didn't pass. Now, we're down to 3 failing tests as of this morning. 3. Improving coverage of tests that run through the end-user experience via the browser. This helps save our reviewers from getting carpal tunnel clicking on forms to ensure that the basic system is running properly while they're testing a patch. 4. Developing testing guidelines, best practices. We're not totally there yet, but a fairly large amount of time has been spent on things like documentation, clean-up of tests so that they all follow basically the same conventions, etc. This type of work is important to getting new developers on the testing train. However, all of this "clean-up" work has come at the expense of dramatically increasing our testing coverage. But I actually think that it would've been way too premature to dump a bunch of time into increasing our test coverage while the above 4 points were outstanding. My goal is for the "Awesome Testing Party" at Drupalcon Szeged (if it gets accepted) to help a lot in this regard. -Angie
I think that our current test coverage by conventional tools is going to be close to 0%. It's also clear that the community has not in fact "embraced testing." Instead, a hardcore group of around 15-20 people (the "testing brigade" ;)) have, and are driving this effort forward on behalf of the rest of the development team.
I am quite certain that you will not see any "embrace" until testing.drupal.org is up and integrated into our workflow. When the TestingBot starts posting unit test success/failure into the queue, we will see the embrace. I salute the testing brigade for all that you have done and will do. It really is a big and important job. I have never seen such unanimity in drupal like we are seeing for delaying this freeze. Consider it done. No need to keep piling on ...
Moshe Weitzman wrote:
I think that our current test coverage by conventional tools is going to be close to 0%. It's also clear that the community has not in fact "embraced testing." Instead, a hardcore group of around 15-20 people (the "testing brigade" ;)) have, and are driving this effort forward on behalf of the rest of the development team.
I am quite certain that you will not see any "embrace" until testing.drupal.org is up and integrated into our workflow. When the TestingBot starts posting unit test success/failure into the queue, we will see the embrace.
Yep. Step 0 of that is making sure all tests pass, otherwise *every* uploaded patch will report test failures. ;) That means getting http://drupal.org/project/issues?projects=3060&components=tests&categories=b... down to 0. Step 1 is abstracting out the issue reply status change functionality - http://drupal.org/node/271216. Steps 2+ will be at http://drupal.org/project/issues/Drupaltestbed Obviously, the more hands on deck, the faster we live in a glorious world where: - patch creators get told within 24 hours whether their patches need re-rolls without having to wait for a reviewer to stumble cross them many weeks later - patch reviewers are assured that any issues marked patch (code needs review) are, in fact, reviewable, and don't waste their invaluable time trying to apply patches that either don't apply anymore or break existing functionality - testers are assured that once they write a test to confirm a bug is fixed or a feature works, that bug will never again recur and that feature will never get broken. - developers are free to refactor with impunity because they can tell instantly if they've broken something fundamental to the system. That said, the Batch API patch makes running all tests tolerable (even a little bit fun!) now from within testing module itself. So although testing.drupal.org is definitely a VERY nice to have, it's not a prerequisite for embracing testing. We can start today. :) -Angie
Dries Buytaert wrote:
I do think we're doing great work on testing. I've been committing testing related patches on a (almost) daily basis. That's pretty sweet.
That said, we aren't able to measure our test coverage yet. In other words, it's really hard to tell how well we actually do. Any updates on that? I've been in contact with the maintainer of the phpcoverage tool we have been attempting to use, and I will try to generate workable coverage reports based on the patch they have just recently supplied to increase the tool's scalability.
However, hook_simpletest() seems to have been removed, so this may require a core patch... but looking into it. As soon as I've generated coverage reports, you will hear about it! :)
Dries Buytaert wrote:
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
I agree that there is still considerable resistance to D6, so let's not push D7 so hard. However, there is a side note to this that I would love to see more heavily pushed: I am still getting module issues related to PHP 4 (even 4.3) and MySql 4. And the users are saying they don't want to push their hosts to upgrade. I really would like to see a lot more emphasis on getting hosting companies ready now, rather than later. In every issue I have where infrastructure releases may be involved, I point out the need to upgrade. But I seem to be the only one who is pointing this out to them. It's going to take some hosting companies a while to get updated, so we need to be pushing this now - even for a first of 2009 roll-out. No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.1/1519 - Release Date: 6/25/2008 4:13 PM
On Thu, 26 Jun 2008 09:36:47 -0400, "Nancy Wichmann" <nan_wich@bellsouth.net> wrote:
Dries Buytaert wrote:
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
I agree that there is still considerable resistance to D6, so let's not push D7 so hard.
However, there is a side note to this that I would love to see more heavily pushed: I am still getting module issues related to PHP 4 (even 4.3) and MySql 4. And the users are saying they don't want to push their hosts to upgrade. I really would like to see a lot more emphasis on getting hosting companies ready now, rather than later.
In every issue I have where infrastructure releases may be involved, I point out the need to upgrade. But I seem to be the only one who is pointing this out to them.
It's going to take some hosting companies a while to get updated, so we need to be pushing this now - even for a first of 2009 roll-out.
Just point people here: http://gophp5.org/ - Anyone still on PHP 4 at this point does so at their own risk, with full knowledge that they're on borrowed time at best. Even the PHP Group has dropped PHP 4 at this point. --Larry Garfield, who spent a large chunk of last year raising awareness. :-)
Larry Garfield wrote:
Just point people here: http://gophp5.org/... Check every one of my project pages.
Earl Miles wrote:
At this point, I'd suggest just adding a requirement to your module for PHP5 if you like. PHP4 has been EOL'd, after all. I have seriously considered this, but I know there are a bunch of my users who would be left out at this point. And of course we still have the less-than-perfectly-functioning hook_requirements in 5.x.
I also look and see the D6 still has a requirement for only 4.3.5 and I'd prefer not to have to force people to upgrade when core doesn't. I know there are other contrib maintainers who don't care, but I do. No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.1/1519 - Release Date: 6/25/2008 4:13 PM
Nancy Wichmann wrote:
Dries Buytaert wrote:
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
I agree that there is still considerable resistance to D6, so let's not push D7 so hard.
However, there is a side note to this that I would love to see more heavily pushed: I am still getting module issues related to PHP 4 (even 4.3) and MySql 4. And the users are saying they don't want to push their hosts to upgrade. I really would like to see a lot more emphasis on getting hosting companies ready now, rather than later.
In every issue I have where infrastructure releases may be involved, I point out the need to upgrade. But I seem to be the only one who is pointing this out to them.
It's going to take some hosting companies a while to get updated, so we need to be pushing this now - even for a first of 2009 roll-out.
At this point, I'd suggest just adding a requirement to your module for PHP5 if you like. PHP4 has been EOL'd, after all. It should not surprise Dries in the slightest that I am in favor of a 2009 code freeze leading to a late 2009 or even scheduled 2010 release for 2007. I don't see a need to rush; and I am in complete agreement with the general opinion that, as Drupal has matured, so too should its release cycle slow down.
To jump on the "yes, please delay" train... On Jun 26, 2008, at 2:08 AM, Dries Buytaert wrote:
Given the current state of things...
A few other facts of the current state: a) Due to multiple crisis in my personal life, and launching my first really major Drupal site, I've had practically no time to work on project*. Therefore, drupal.org is still running D5. A code freeze on D7 before upgrading d.o to D6 seems like a terrible idea. ;) b) There are some significant improvements and fixes that need to happen to Update status, and Earl has his hands full with the "chaos suite" in contrib. c) Aside from project*, I've got a few other important contribs that aren't 6.x-1.0 material yet. d) As a result of a-c, I've been almost entirely out of the loop on D7 development. I was starting to get a little bummed out that I was going to completely miss the chance to seriously work on core for the D7 release at all. Personal factors aside, I also support the more general "slow down, already" sentiment. ;) Drupal adoption is obviously taking off in a big way. I think our "we must be reborn every year or we die" attitude is running up against the reality of "if they rewrite themselves every year, I can't make use of this platform" in the real world. I'm thrilled we don't maintain backwards compatibility, but I do think we need to reconsider the pace of major releases. Thanks, -Derek (dww)
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
+1 to pushing back the code freeze. I'm in the middle of quite a few large Drupal 6 modules, along with a number of ports that my company needs for Drupal 6. Plus, it seems like there are a number of significant features that would not get in to Drupal 7 with a code freeze only a couple of weeks away. Cheers, Kyle Cunningham
If I can say "AOL!" here... :-) The slow uptake of D6 is due mostly to everyone and their brother taking the opportunity to rewrite their contrib modules at the same time as upgrading to D6, or right before doing so. Views, Panels, Project*, CCK, filefield, imagefield, and a half-dozen others have major improvements planned in contrib space that are progressing; they just take time. Those, in turn, block dozens of other modules. Dries and others are right that we really can't close D7 knowing what all we need to do to it until D6 has had time to test its mettle in production, and I don't know of any non-trivial D6 deployments yet. We can only guess at what we need to do to fix the issues in D6 with D7 at this point. webchick lamented the lack of "embracing testing" and that we have only a "testing brigade". I'm actually not surprised at that. That's known as a "QA Team" in many circles, and is a very good thing. A semi-dedicated QA team that beats people over the head is a more efficient use of resources than trying to get everyone to be everything for every patch. My hats off to the "testing brigade" for their ongoing work, and may they continue to thwap the rest of us when appropriate. (Incidentally, is it my imagination or does the Testing Brigade consist mostly of former GHOP students and mentors?) Their work is made even harder by the time needed to basically rewrite our own testing framework, since we're apparently not sticking with any existing testing framework (which seems inline with Drupal's usual policy...) The flipside of that, however, is writing code that is easy to test. Right now, Drupal's code base is really not very unit testable. Various ideas have been floated to for mock functions, runkit, etc., but in the end the real answer here is to refactor Drupal itself so that its APIs are easier to unit test in isolation. That goes hand in hand with one of the key "make it rock" goals for Drupal 7, which is "better internal APIs". We've made some progress on this front, but a lot of patches in that direction are simply waiting on people having time to work on it, many of whom are involved in the testing brigade now. (I'm thinking of the block API refactoring here, and killing $op, as well as various others.) That sort of heavy refactoring takes a lot of time even when your top developers aren't engaged in D6 module ports and building a testing framework. That is critical for "embracing testing", however, as well as bettering Drupal in general. So yes, +1 on delaying the code freeze. There's a lot of work that's half-way through. Let's complete it, and give D6 time to show us where the mines are so we can fix them at the same time. --Larry Garfield On Thu, 26 Jun 2008 09:08:48 +0200, Dries Buytaert <dries.buytaert@gmail.com> wrote:
I've been thinking about this some. While we have made incredible progress with the test infrastructure as well as implemented a dozen of usability improvements, we're still light on feature improvements (such as fields in core).
Combined with the late arrival of CCK and Views, and the many Drupal 6 books that are currently being written, it sounds best to postpone the code freeze a little longer. Given the current state of things, the proposed July 15 deadline seems a bit too aggressive to my liking.
If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement.
Thanks,
On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote:
Hi,
What is the latest news about the D7 code freeze. I haven't seen any announcement on this list. Do we have a date for the code freeze, or at least a better estimate than what was offered at the beginning of the thaw?
thanks,
Augustin.
-- Dries Buytaert :: http://buytaert.net
I am in favor of pushing D7 later, not for testing (which I am not very keen on, due to past experience with automated testing), but for the reasons Larry outlined here: The slow uptake of D6 is due mostly to everyone and their brother taking the
opportunity to rewrite their contrib modules at the same time as upgrading to D6, or right before doing so. Views, Panels, Project*, CCK, filefield, imagefield, and a half-dozen others have major improvements planned in contrib space that are progressing; they just take time. Those, in turn, block dozens of other modules.
If we push for D7 to go out, and sites are just converting to D6 because the crucial modules above are just freshly available, then it will be another round of crunch time to get them to D7, and it would not be on time. So, better spend the time adding more features to D7 (fields, views engine, ...etc.) rather than just a testing framework, which is not visible in a tangible way to end users (site builders and owners in this case). -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
Larry Garfield wrote:
webchick lamented the lack of "embracing testing" and that we have only a "testing brigade". I'm actually not surprised at that. That's known as a "QA Team" in many circles, and is a very good thing. A semi-dedicated QA team that beats people over the head is a more efficient use of resources than trying to get everyone to be everything for every patch. My hats off to the "testing brigade" for their ongoing work, and may they continue to thwap the rest of us when appropriate. (Incidentally, is it my imagination or does the Testing Brigade consist mostly of former GHOP students and mentors?) Their work is made even harder by the time needed to basically rewrite our own testing framework, since we're apparently not sticking with any existing testing framework (which seems inline with Drupal's usual policy...)
A couple things: 1. I wasn't lamenting anything. I was simply stating the reality. The reality is that the community hasn't remotely "embraced testing," and a huge part of that is because the testing brigade has had its hands more than full hammering out larger over-arching issues with the testing framework and existing tests, which I proceeded to document in the rest of my reply. 2. I'm fine with this reality, and at the present point in time it would be silly to expect anything else. If we had tried to get 800+ developers to "embrace testing" back in March, it would've been a complete CF. I'm saying that NOW, we're in a much better position to have a larger body of developers working on testing, thanks to the hard work of the testing brigade over the past several months. 3. We /are/ going to need 800+ people fluent in writing tests by the time the D7 release is upon us. 15-20 people simply cannot provide 100% (or even 10%) test coverage on their own, nor should we want that to happen. The testing brigade should be focusing on doing "test reviews," mentoring developers on how to write good tests and answering their questions, checking for thorny areas which need more test coverage, fix issues in the testing framework that are beyond regular developers' expertise, etc. 4. Yes, there's a strong GHOP tie-in. I think that's because most of the people who helped out with and participated in GHOP are the same people who generally help out with and participate in any community initiative. And the same people who didn't... well... ;) 5. The testing framework re-write I was originally very opposed to. But the fact is that SimpleTest had all manner of problems running with our code, and going in there and monkeying with the code to fix it was a huge time-sink every single time. The code that's there now is at least understandable by more than 3 people, it's fully documented, and it also takes far less time to run the full test suite. In general, I'd say it's a huge win. 6. I agree about testable APIs being another huge component of this. The solution of course is to grow the size of the testing brigade, and the size of the body of people who know how to write tests. If this area was more well-covered, developers who'd normally be putting efforts into API re-writes could resume doing so. As it is currently, however, everyone in the testing brigade has more than enough to do on that single area of focus. -Angie
On Jun 26, 2008, at 11:06 AM, Larry Garfield wrote:
The slow uptake of D6 is due mostly to everyone and their brother taking the opportunity to rewrite their contrib modules at the same time as upgrading to D6, or right before doing so. Views, Panels, Project*, CCK, filefield, imagefield, and a half-dozen others have major improvements planned in contrib space that are progressing; they just take time. Those, in turn, block dozens of other modules.
+1 from a community marketing perspective as well. I'm glad there's general consensus that with the tail wagging the dog, Drupal will benefit from a slowdown so D6 can get established in the marketplace before pushing D7 out. However, I'm -1 on making this a policy towards a new 18-month release cycle. I feel rolling with the flow makes sense. If D8 is coming along well, there will be little to gain by delaying it in the interests of a general slowdown. My two bits. Laura
OK, we'll postpone the code freeze for now. At this point, I won't make any decisions or promises about when the code freeze will be. I'l revisit this question in a couple months time. On 26 Jun 2008, at 22:02, Laura Scott wrote:
The slow uptake of D6 is due mostly to everyone and their brother taking the opportunity to rewrite their contrib modules at the same time as upgrading to D6, or right before doing so. Views, Panels, Project*, CCK, filefield, imagefield, and a half-dozen others have major improvements planned in contrib space that are progressing; they just take time. Those, in turn, block dozens of other modules.
+1 from a community marketing perspective as well. I'm glad there's general consensus that with the tail wagging the dog, Drupal will benefit from a slowdown so D6 can get established in the marketplace before pushing D7 out. However, I'm -1 on making this a policy towards a new 18-month release cycle. I feel rolling with the flow makes sense. If D8 is coming along well, there will be little to gain by delaying it in the interests of a general slowdown.
-- Dries Buytaert :: http://buytaert.net
participants (23)
-
Aaron Winborn -
Angela Byron -
Augustin (Beginner) -
Charlie Gordon -
Chris Johnson -
Darrel O'Pry -
Derek Wright -
Dries Buytaert -
Earl Miles -
Folkert Hielema -
Jerad Bitner -
Karoly Negyesi -
Khalid Baheyeldin -
Kyle Cunningham -
Larry Garfield -
Laura Scott -
Moshe Weitzman -
Nancy Wichmann -
Nathaniel Catchpole -
Robert Douglass -
Shai Gluskin -
Syscrusher -
Wim Leers