[development] Code freeze?

[Larry Garfield]

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