+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

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

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

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

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

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

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:

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

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

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 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

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

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