Hello world, as of today, the Drupal 6 code is frozen. This means that we first shift focus towards usability improvements and performance improvements and that we are extremely strict about breaking APIs. We'll only accept patches that break APIs unless required to fix critical issues. The first 2-3 weeks, patches that improve either usability or performance might still be considered assuming they don't break any APIs. However, we're going to be extremely strict about patches that attempt to add new features for usability's sake. After the first couple of weeks, we'll enter the second stage of the code freeze during which only bug fixes are accepted. Finally, when all critical bugs are fixed, we'll release Drupal 6. In addition to that, I'd like to grant six extensions/exceptions. These extensions buy 6 issues another *two* weeks to get committed to Drupal core. Two weeks isn't a lot of time so chances are that these won't make it. However, I'm confident that some patches will. 1. We need the menu module fixes to go in, and these might alter the APIs. 2. We need the update module to go in and it's 95% ready. It would be a shame to hold it back. 3. We want the file API to go in and it's 95% ready. It would be a shame to hold it back. 4. I'm going to grant an extra 2 weeks for the book module patch. I'm not promising that I will go in, but I'd like to see us carefully analyze it some more and maybe strip or massage it a little. It is an important patch for both Drupal's future and the Drupal.org documentation team, so let's focus on making them succeed. 5. I'd like to see us split SQL read and writes as drupal.org would benefit from this a lot. (Important performance improvement that is likely to break APIs.) 6. I'd like to see us merge the node, node_comment_statistics and node_counter tables. (Important performance improvement that is likely to break APIs.) Other than that, we're going to spend a lot of time fixing bugs and banging CPU cycles out of Drupal! It looks like this might be another amazing release for us, especially if we can make Drupal 6 easier to use and snappier than Drupal 5. Please adjust your mindsets to this new focus! I'd like to solicit some feedback surrounding this, and then finally announce the Drupal 6 code freeze on the drupal.org main page first thing tomorrow morning. Thanks for all the hard work, PS: I realize it is tempting to beg for more extensions, but please think twice before you do. I've carefully compiled this list, and by asking for more extensions, you jeopardize the success of the six patches. I want to see us take care of these 6 patches more than anything else. -- Dries Buytaert :: http://www.buytaert.net/
Dries, Good call. This is a nice set of patches to go give precedence to. At the risk of being "that guy," there are three specific patches that could have a pretty significant impact on future contrib development: the FormAPI '#value type' callbacks patch (http:// drupal.org/node/121620), AHAH support for FormAPI (http://drupal.org/ node/154398), and the ability to theme the maintenance pages (http:// drupal.org/node/141727). Would it be correct to assume that these didn't make it in, and don't fall under the performance/UI/bug fixes banner? --Jeff
Before we all add our names to the "that guy" list (I'll refrain from adding my own name)... In general, what is the status of issues that were marked as RTBC before the July 1st code freeze but that haven't been committed or commented on by the core committers? - John On Jul 2, 2007, at 11:04 AM, Jeff Eaton wrote:
Dries,
Good call. This is a nice set of patches to go give precedence to.
At the risk of being "that guy," there are three specific patches that could have a pretty significant impact on future contrib development: the FormAPI '#value type' callbacks patch (http:// drupal.org/node/121620), AHAH support for FormAPI (http:// drupal.org/node/154398), and the ability to theme the maintenance pages (http://drupal.org/node/141727).
Would it be correct to assume that these didn't make it in, and don't fall under the performance/UI/bug fixes banner?
--Jeff
Before we all add our names to the "that guy" list (I'll refrain from adding my own name)...
In general, what is the status of issues that were marked as RTBC before the July 1st code freeze but that haven't been committed or commented on by the core committers?
Specifically, what is the status of 6.x feature requests marked as RTBC before the code freeze? http://drupal.org/project/issues/drupal?states=14&categories=feature
On Jul 2, 2007, at 11:04 AM, Jeff Eaton wrote:
Dries,
Good call. This is a nice set of patches to go give precedence to.
At the risk of being "that guy," there are three specific patches that could have a pretty significant impact on future contrib development: the FormAPI '#value type' callbacks patch (http:// drupal.org/node/121620), AHAH support for FormAPI (http:// drupal.org/node/154398), and the ability to theme the maintenance pages (http://drupal.org/node/141727).
Would it be correct to assume that these didn't make it in, and don't fall under the performance/UI/bug fixes banner?
--Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Wilkins schrieb:
Before we all add our names to the "that guy" list (I'll refrain from adding my own name)...
In general, what is the status of issues that were marked as RTBC before the July 1st code freeze but that haven't been committed or commented on by the core committers?
Specifically, what is the status of 6.x feature requests marked as RTBC before the code freeze?
http://drupal.org/project/issues/drupal?states=14&categories=feature
Unless they were in the list that Dries posted, they will need to wait for when development continues after (or shortly before) the Drupal 6 release. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGiVp7fg6TFvELooQRAthOAJ0dowbWYjnAEQsytmtaYqcD17k88gCfcbzT gPGDmXqnScezZF5Esar/C5s= =cQ6U -----END PGP SIGNATURE-----
Quoting John Wilkins <drupal.user@albin.net>:
Before we all add our names to the "that guy" list (I'll refrain from adding my own name)...
In general, what is the status of issues that were marked as RTBC before the July 1st code freeze but that haven't been committed or commented on by the core committers?
Specifically, what is the status of 6.x feature requests marked as RTBC before the code freeze?
http://drupal.org/project/issues/drupal?states=14&categories=feature
Should not RTBC be considered as good as committed? All that is left is the committing. There are a limited set of committers and the lack of time within that limited set should not prevent an RTBC patch prior to code freeze to not be a part of the code base when the code is frozen. If we work to get RTBC then the code goes uncommitted what good is the status? The code is reviewed waiting on the limited set of people with limited time to commit the code. Earnie
Jeff Eaton a ecrit le 02/07/2007 20:04:
Dries,
Good call. This is a nice set of patches to go give precedence to.
At the risk of being "that guy," there are three specific patches that could have a pretty significant impact on future contrib development: the FormAPI '#value type' callbacks patch (http://drupal.org/node/121620), AHAH support for FormAPI (http://drupal.org/node/154398), and the ability to theme the maintenance pages (http://drupal.org/node/141727). Just my two cents :
"FormAPI '#value type' callbacks patch (http://drupal.org/node/121620)" Amongst other thing, this would allow a considerable refactoring / simplification of CCK's current notion of widgets, and of the related API. This patch has been around for about the whole dev cycle, and RTBC for about two third. One might consider there's no reason to 'reward' the cck team for not much progress of cck in core in this release, though :-) And obviously the AHAH support would ease a lot of UI improvements. It would be quite frustrating to have FAPI3 stop this close (even though - I think ? - it does already potentially allows all the AHAH magic) Yched (well aware of the pathetic aspects of going "please, please, please ?")
Hi Jeff et al, On 02 Jul 2007, at 20:04, Jeff Eaton wrote:
At the risk of being "that guy," there are three specific patches that could have a pretty significant impact on future contrib development: the FormAPI '#value type' callbacks patch (http:// drupal.org/node/121620), AHAH support for FormAPI (http:// drupal.org/node/154398), and the ability to theme the maintenance pages (http://drupal.org/node/141727).
I've let some of these patches slip in as they were ready for quite a while, and of strategic importance too. -- Dries Buytaert :: http://www.buytaert.net/
Thanks for the update, Dries. I see that the two really essential FAPI fixes that I was concerned about are now in -- they were marked as bug fixes, I now see, so they were a bit safer. :D The results will be a much lighter-weight CCK for Drupal 6, something I think we're all excited about. --Jeff On Jul 4, 2007, at 1:53 PM, Dries Buytaert wrote:
Hi Jeff et al,
On 02 Jul 2007, at 20:04, Jeff Eaton wrote:
At the risk of being "that guy," there are three specific patches that could have a pretty significant impact on future contrib development: the FormAPI '#value type' callbacks patch (http:// drupal.org/node/121620), AHAH support for FormAPI (http:// drupal.org/node/154398), and the ability to theme the maintenance pages (http://drupal.org/node/141727).
I've let some of these patches slip in as they were ready for quite a while, and of strategic importance too.
-- Dries Buytaert :: http://www.buytaert.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dries Buytaert schrieb:
6. I'd like to see us merge the node, node_comment_statistics and node_counter tables. (Important performance improvement that is likely to break APIs.)
This is only a performance improvement if you don't run MyISAM. If you run MyISAM this will totally push a busy DB server over the edge as it will cause table locks on the node table for every comment added (or even every node viewed if you use Drupal's view counter). Doing this merge (and thus also "won't fix" this issue: http://drupal.org/node/109037) essentially means "don't run a high load Drupal site on MyISAM". Now, this isn't neccessarily a bad message, but I want to make sure that people know about this message _before_ this is rolled into D6. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGiT8yfg6TFvELooQRAmZUAKCOsQ/2Ki2TuFlxHO807mpTU5owYQCghcQP y8GHmcHN9r4wtYPNWWlsCpU= =Qsjd -----END PGP SIGNATURE-----
On 7/2/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Dries Buytaert schrieb:
6. I'd like to see us merge the node, node_comment_statistics and node_counter tables. (Important performance improvement that is likely to break APIs.)
This is only a performance improvement if you don't run MyISAM. If you run MyISAM this will totally push a busy DB server over the edge as it will cause table locks on the node table for every comment added (or even every node viewed if you use Drupal's view counter).
Doing this merge (and thus also "won't fix" this issue: http://drupal.org/node/109037) essentially means "don't run a high load Drupal site on MyISAM".
Now, this isn't neccessarily a bad message, but I want to make sure that people know about this message _before_ this is rolled into D6.
Cheers, Gerhard
Here is a timely article on implementing counters from a MySQL point of view. Food for thought. http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counte... -- 2bits.com http://2bits.com Drupal development, customization and consulting.
On 7/2/07, Dries Buytaert <dries@buytaert.net> wrote:
PS: I realize it is tempting to beg for more extensions, but please think twice before you do. I've carefully compiled this list, and by asking for more extensions, you jeopardize the success of the six patches. I want to see us take care of these 6 patches more than anything else.
No begging, just a notice that it was basically impossible to work on additional install profiles for core while everything was changing and/or broken (e.g. menu). So, much like at the end of D5, I'd like to think that install profiles fit into this category of additional work to still go in. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
Boris Mann wrote:
No begging, just a notice that it was basically impossible to work on additional install profiles for core while everything was changing and/or broken ( e.g. menu).
So, much like at the end of D5, I'd like to think that install profiles fit into this category of additional work to still go in.
IMO, install profiles should be relatively self contained and contain no API changes, and thus SHOULD fit well into the 'usability improvements' section. Unless you have to change the API for them, which could be problematic.
On 7/2/07, Earl Miles <merlin@logrus.com> wrote:
Boris Mann wrote:
No begging, just a notice that it was basically impossible to work on additional install profiles for core while everything was changing and/or broken ( e.g. menu).
So, much like at the end of D5, I'd like to think that install profiles fit into this category of additional work to still go in.
IMO, install profiles should be relatively self contained and contain no API changes, and thus SHOULD fit well into the 'usability improvements' section. Unless you have to change the API for them, which could be problematic.
No, you're right, they are relatively self contained. In fact, the blocker was waiting to see which APIs actually made it in -- e.g. a bunch of Data API stuff would have been useful, but clearly not the place of install profiles to change that (it's just a point where it's glaringly obvious that it's needed :P ) -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
Larry Garfield wrote:
Can you post links to the specific issues that get "just one more chance", so we know where to focus efforts? I'd like to second Larry's idea that Dries' official announcement of the code freeze include links to the specific issues that are still on the table.
Dries Buytaert wrote:
The first 2-3 weeks, patches that improve either usability or performance might still be considered assuming they don't break any APIs.
I'm hoping that upgrading to the latest jQuery falls underneath the UI or performance exemption umbrella. Here's the issue: http://drupal.org/node/146462 jQuery version 1.1.3 was just released and is reporting up to 800% speed improvements on their DOM traversal. http://jquery.com/blog/2007/07/01/jquery-113-800-faster-still-20kb/ The next target release date for jQuery version 1.1.4 is at the end of July, and so I don't know if that will fall outside of the 2-3 week window. Their announcement says that 1.1.4 "will also mark a number of methods as deprecated, in accordance with the upcoming jQuery 1.2 release." Hopefully Drupal won't be too effected by these deprecated functions. The projected release date for jQuery 1.2 is at the end of August. -Kent.
Dries, A few of those items had multiple patches involved in them. I've lost track of which file patches went in and which are still pending, for instance. Can you post links to the specific issues that get "just one more chance", so we know where to focus efforts? --Larry Garfield On Mon, 2 Jul 2007 19:46:48 +0200, Dries Buytaert <dries@buytaert.net> wrote:
Hello world,
as of today, the Drupal 6 code is frozen. This means that we first shift focus towards usability improvements and performance improvements and that we are extremely strict about breaking APIs. We'll only accept patches that break APIs unless required to fix critical issues.
The first 2-3 weeks, patches that improve either usability or performance might still be considered assuming they don't break any APIs. However, we're going to be extremely strict about patches that attempt to add new features for usability's sake.
After the first couple of weeks, we'll enter the second stage of the code freeze during which only bug fixes are accepted. Finally, when all critical bugs are fixed, we'll release Drupal 6.
In addition to that, I'd like to grant six extensions/exceptions. These extensions buy 6 issues another *two* weeks to get committed to Drupal core. Two weeks isn't a lot of time so chances are that these won't make it. However, I'm confident that some patches will.
1. We need the menu module fixes to go in, and these might alter the APIs.
2. We need the update module to go in and it's 95% ready. It would be a shame to hold it back.
3. We want the file API to go in and it's 95% ready. It would be a shame to hold it back.
4. I'm going to grant an extra 2 weeks for the book module patch. I'm not promising that I will go in, but I'd like to see us carefully analyze it some more and maybe strip or massage it a little. It is an important patch for both Drupal's future and the Drupal.org documentation team, so let's focus on making them succeed.
5. I'd like to see us split SQL read and writes as drupal.org would benefit from this a lot. (Important performance improvement that is likely to break APIs.)
6. I'd like to see us merge the node, node_comment_statistics and node_counter tables. (Important performance improvement that is likely to break APIs.)
Other than that, we're going to spend a lot of time fixing bugs and banging CPU cycles out of Drupal! It looks like this might be another amazing release for us, especially if we can make Drupal 6 easier to use and snappier than Drupal 5. Please adjust your mindsets to this new focus!
I'd like to solicit some feedback surrounding this, and then finally announce the Drupal 6 code freeze on the drupal.org main page first thing tomorrow morning.
Thanks for all the hard work,
PS: I realize it is tempting to beg for more extensions, but please think twice before you do. I've carefully compiled this list, and by asking for more extensions, you jeopardize the success of the six patches. I want to see us take care of these 6 patches more than anything else.
-- Dries Buytaert :: http://www.buytaert.net/
On 7/2/07, Dries Buytaert <dries@buytaert.net> wrote:
3. We want the file API to go in and it's 95% ready. It would be a shame to hold it back.
I'm really glad to hear that. I've posted an updated patch. I'll be around all week to help get it wrapped up.
PS: I realize it is tempting to beg for more extensions, but please think twice before you do. I've carefully compiled this list, and by asking for more extensions, you jeopardize the success of the six patches. I want to see us take care of these 6 patches more than anything else.
I hate to be that guy, but I was hoping you could at least look at: http://drupal.org/node/140932 The short summary is that it cleans up the image tookit API and converts the toolkits into modules rather than .inc files. The main benefit is that it allows us to leverage all the development infrastructure that's built around modules (update status, hook_requirements, etc) rather than .inc files. I'm fine with won't fix or postponed. I just hate having put all the time in to have never been able to get a review from a core committer. Thanks, andrew
On 7/2/07 2:33 PM, andrew morton wrote:
On 7/2/07, Dries Buytaert <dries@buytaert.net> wrote:
3. We want the file API to go in and it's 95% ready. It would be a shame to hold it back.
I'm really glad to hear that. I've posted an updated patch. I'll be around all week to help get it wrapped up.
Yep, glad to see this on the list, I'd be willing to put some hours in this week as well to help close that final 5%.
PS: I realize it is tempting to beg for more extensions, but please think twice before you do. I've carefully compiled this list, and by asking for more extensions, you jeopardize the success of the six patches. I want to see us take care of these 6 patches more than anything else.
I hate to be that guy, but I was hoping you could at least look at: http://drupal.org/node/140932 The short summary is that it cleans up the image tookit API and converts the toolkits into modules rather than .inc files. The main benefit is that it allows us to leverage all the development infrastructure that's built around modules (update status, hook_requirements, etc) rather than .inc files.
I'm fine with won't fix or postponed. I just hate having put all the time in to have never been able to get a review from a core committer.
I was actually running through a last minute review of this when the freeze email came through. As the creator of the original image toolkit mess - I'd like to see this one squeak in too if possible. It cleans up a lot of the confusion around toolkit - essentially by making them something more familiar and re-using that infrastructure. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
FYI: For issues that definitely are *not* making it into D6, there's now a "7.x-dev" version in the core issue queue. http://drupal.org/node/156281 for the placeholder release node. http://drupal.org/node/156247 for the issue where i proposed it. Note to all: please bump issues into 7.x land if that's where they belong. Thanks, -Derek p.s. No, new issue states and versions and improvements to our development tools won't solve all our problems, but that doesn't mean we shouldn't make the most of the tools we have. ;)
On 2-Jul-07, at 1:46 PM, Dries Buytaert wrote:
<snip> In addition to that, I'd like to grant six extensions/exceptions. These extensions buy 6 issues another *two* weeks to get committed to Drupal core. Two weeks isn't a lot of time so chances are that these won't make it. However, I'm confident that some patches will.
I've updated http://drupal.org/patch/spotlight with what I think are the issue URLs for these issues. Could you give a quick look if you get a free couple minutes, and adjust as necessary? -Angie
On 03 Jul 2007, at 01:53, Angela Byron wrote:
In addition to that, I'd like to grant six extensions/exceptions. These extensions buy 6 issues another *two* weeks to get committed to Drupal core. Two weeks isn't a lot of time so chances are that these won't make it. However, I'm confident that some patches will.
I've updated http://drupal.org/patch/spotlight with what I think are the issue URLs for these issues. Could you give a quick look if you get a free couple minutes, and adjust as necessary?
Thanks Angie. That's much appreciated. :) -- Dries Buytaert :: http://www.buytaert.net/
participants (16)
-
andrew morton -
Angela Byron -
Boris Mann -
Derek Wright -
Dries Buytaert -
Dries Buytaert -
Earl Miles -
Earnie Boyd -
Gerhard Killesreiter -
James Walker -
Jeff Eaton -
John Wilkins -
Kent Bye -
Khalid Baheyeldin -
Larry Garfield -
Yves Chedemois