July 2007 - Development - lists.drupal.org

Drupal 6 code freeze
by Dries Buytaert 04 Jul '07

04 Jul '07

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/

16 20

Mass node create module
by Ken Rickard 04 Jul '07

04 Jul '07

Bob- I just released an alpha module (needs testing) that lets you create re-usable book outlines filled with 'template' nodes. it was expressly designed for creating books from CCK nodes of different types. http://drupal.org/project/skeleton And the Node Template module lets you clone existing nodes. http://drupal.org/project/node_template - Ken Rickard agentrickard

1 0

seeking helper and tester for drupal-6.x-dev oracle driver
by Edison Wong 04 Jul '07

04 Jul '07

Dear all, My team is now developing the oracle driver for drupal-6.x-dev, please refer to http://drupal.org/node/39260 for detail information. We face a great problem: without tester, we can't prove the correctness of our product. I wrote a mini-HOWTO about how to let Debian etch, Oracle Database 10g Release 2, Apache2.2, Zend Core for Oracle v.2 and drupal-6.x-dev all works together. Hope this can decrease the difficulty so volunteer may find easier to help the successful of this project. Please refer to the following links for more information :D latest drupal-6.x-dev oracle driver: http://drupal.org/node/39260 drupal-6.x-dev + Oracle Database 10g Release 2 mini-HOWTO: http://edin.no-ip.com/html/?q=drupal_6_x_dev_oracle_database_10g_release_2_… Oracle Database 10g Release 2 + Apache2.2 + Zend Core for Oracle v.2, on Debian etch HOWTO http://edin.no-ip.com/html/?q=oracle_database_10g_release_2_apache2_2_zend_… Regards, Edison Wong

2 1

Core feed publishing
by beerfan 04 Jul '07

04 Jul '07

Feed publishing, and the RSS format in particular, is currently tightly coupled with the node module. Because of this supporting Atom or extending feed functionality with custom modules isn't as clean as it should be. For example, adding a name-space to a node feed requires replacing default feeds with custom feeds instead of simply "theming" the output of feeds as you would do with every other form of content display. Publishing only Atom feeds (and disabling RSS) is impossible. I would like to see feed publishing become more generic and more extensible in the core and I believe there has been discussion around this in the past. Ideally, feed publishing would be a generic module or api which would support the following needs. 1. Multiple arbitrary feed formats (RSS, Atom) with a default 2. Custom name-spaces and elements (possibly via themes or hooks) 3. Publish comment feeds or any other arbitrary content (watchdog events, users, etc.) 4. The ability to provide a feed of any arbitrary set of content (e.g., view, node-queue) 5. Optimize publishing for very high traffic feeds (e.g., caching or saving as static xml file) 6. The ability to disable feeds It is currently possibly to cobble together most of the above functionality with views.module, commentrss.module, and atom.module but the solution is sub-optimal for many reasons. I recently started creating a feed.module against HEAD with the hope that it could turn into a core module which would make feed publishing more flexible and collect all feed formatting and publishing code and eliminate the RSS publishing functionality in node.module. However, since 6.x was just frozen there's probably no hope of introducing this now but I'd still like to re-float the idea and get some feedback. In particular, I'm curious if anyone else is already working on such a project, if there are any side-effects of separating feed publishing from node.module that I haven't considered, or if this problem might be better approached using views as the complete solution (not really viable since views is not a core module). Please ignore the fact that this can't be implemented for 6.x. As an example of an issue I have faced, feedburner.com adds a "number of comments for this entry" if the feed includes the "wfw:commentsRss" element pointing to the comment feed for the entry. I have modified the commentrss.module to add the element to the node feed but there is no way to add the "wfw" name-space to the node feed without replacing it with a custom feed so I had to add the name-space to each instance of the "commentRss" element. Cheers, Chris Cook

3 3

Suggestions for improving the issue tracker
by Derek Wright 03 Jul '07

03 Jul '07

Ok, open season on the devel list regarding feature requests for our issue tracker is hereby closed. ;) There were some great suggestions, and I'm glad I asked. The results are now here: http://groups.drupal.org/node/4970 This is a wiki page, sticky at the top of the issue tracking group: http://groups.drupal.org/issue-tracking-and-software-releases Many of the suggestions already have issues in the queue. Since some were easy for me to fill in, I already added those links. I didn't track them all down, so others have an issue, we just need to find the link. Still others aren't yet in the queue (amazing!), and could use an issue associated with them. The list isn't prioritized or ordered (mostly), it's just in the order I found stuff while processing my inbox. So, you can help by: 1) Adding any further suggestions directly to this list, not via the devel list. 2) Reading through the list, finding issues for things that don't have a link, and filling in the link. Please note: you should search in both the project and the project_issue queue, since many things (especially older issues) are in the wrong queue, or people submitted to the wrong queue and I didn't have the energy to reassign them, etc. 3) If you're sure something doesn't already exist in either queue, submit a new project_issue ticket about it and add a link to the wiki page. 4) General info on how to help with project* development: http://groups.drupal.org/node/3686 Thanks for all the help! ;) Given how much interest there is in this, I'm hopeful that some volunteers will step up. Cheers, -Derek

1 0

Modules - start your porting
by Moshe Weitzman 03 Jul '07

03 Jul '07

Hi all. It would be very helpful if module maintainers could soon start porting their modules to Drupal 6. Some big, important modules require multiple people to get this job done right (e.g. Views, CCK, ...). Let's help these maintainers. Porting modules now: - helps our beta testers run their sites to Drupal6 and report bugs. - identify hidden API limitations in core that only surface when modules start using new features (fapi, actions, etc.). the longer we wait, the harder it gets to make even minor API changes in 6. If you have reasons not to port now, then don't. But please don't use this thread to convince others to also wait. Porting early is a generous act which we want to encourage. The API will change very little now, so seize the day! -moshe

4 3

Re: [development] Intelligent use of time (Re: Perm for setting RTBC
by Chad Phillips -- Apartment Lines 03 Jul '07

03 Jul '07

On Jul 3, 2007, at 12:12 PM, andrew morton wrote: > One thing I've seen mentioned a few times that was omitted from > Fernando's list is the feedback early on from core committers. ...snip... > But for everyone else, trying to get that feedback solely > via the issue queue, this list and IRC it's difficult. For me that's > what doesn't work in the current process. i think there's a *very* good chance this is a primary issue. any suggestions on how we can work to improve it??

1 0

Re: [development] Intelligent use of time (Re: Perm for setting RTBC
by Chad Phillips -- Apartment Lines 03 Jul '07

03 Jul '07

On Jul 3, 2007, at 9:53 AM, Jeff Eaton wrote: > The fundamental problem, though, is that a core committer is also > 'the final reviewer,' the last line of defense between Drupal core > and conceptually flawed code. The system works best when core > committers don't *have* to spend a lot of time on that part of > their role. And that's what breaks when the queue gets saturated > with premature RTBC's. Their role as 'final reviewer' sucks up more > and more time, and fewer patches can get the attention necessary to > make the commit happen. perhaps it would be helpful if we could somehow clarify further what the core committers are looking for in that final review -- because if there's a misunderstanding there, that could lead to problems. as i said previously regarding the deletion API: i had two of drupal's finest coders looking at the code. i had half a dozen usability reviews. it complied with the information listed at "Tips for contributing to the core". Yet, somehow, all this wasn't enough. what was the missing link in the dev cycle of that patch?? i think clarifying that could be helpful.

1 0

Re: [development] Perm for setting RTBC - Re: RTBC - how does it work?
by Chad Phillips -- Apartment Lines 03 Jul '07

03 Jul '07

to this excellent list i would like to add: - the ability to manually subscribe/unsubscribe to/from an issue. the 'my issues' queue would be much friendlier if this level of intelligence was added. my 'my issues' screen currently has about 5 pages, maybe 3 of which contain issues where i left a passing comment, and am no longer focusing on. - somebody mentioned it before, but let's make sure it's counted: a way to perform some mass operations on the results of the search page. like mass changing the status of issues, or mass assigning/ unassigning. - this may be reaching a little, but AJAX teasers for issues? i think the above would help to make the search results pages operate more like a 'command center' for patch reviews. On Jul 3, 2007, at 4:01 AM, Neil Drumm wrote: > - Selecting things in small select boxes is a pain. You can't see your > full selection and lose it with one click while not holding down the > right keys. I would recommend checkboxes instead. > - There is no way to select all of 5.x or 4.7.x. > - The defaults include support requests. Does anyone actually leave > that selected? > - There are better page layout mechanisms than the arbitrary table. > Make sure things are in places that make sense. > - A little bit more descriptive text can get new users up to speed > faster, but not get in the way of power users. > > On to the results page: > - This is a good page to come back to, but getting a specific url for > it requires knowing to click the # hidden at the bottom. We should go > directly to the permanent link. > - The dropdowns are inadequate to represent your search and are often > wrong. A full description of the search should be shown, even if it is > not editable. The dropdowns should probably be skipped all together. > - There is no way to get to a pre-filled advanced search screen from > your current results. Making minor adjustments to the search is > impossible, unless you are lucky enough to have it in your browser > history. > - A line saying how many issues were found would help with tracking > progress.

1 0

Close active (needs more info) after two weeks
by Karoly Negyesi 03 Jul '07

03 Jul '07

Hi, We already have a script which closes fixed issues after two weeks so I believe it would not be terribly hard to add a few lines which sets "won't fix" on active (nmi) issues. Thoughts? NK

2 1