- Development - lists.drupal.org

RTBC - how does it work?
by Doug Green 05 Jul '07

05 Jul '07

I searched the docs and couldn't find the protocol for this. How does a patch get to be RTBC? Is this a peer review thing or is it limited to a handful of people. The only thread I found was this one, which is clearly a work-in-progress, and one that we've moved past: http://lists.drupal.org/pipermail/development/2005-August/007431.html. I am disappointed that my search enhancements and password security hashing patches feel through. I'm wondering if I just don't understand the rules. Doug Green 904-583-3342 www.douggreenconsulting.com Bringing Ideas to Life with Software Artistry and Invention... Providing open source software political solutions

28 84

Re: [development] Go PHP 5, Go!
by Karen Stevenson 05 Jul '07

05 Jul '07

One more thought on this subject, why not add 'minimum php version' to the .info file, and show modules that require php5 as disabled on the modules list if php5 isn't available. This would be a fairly simple thing that could still be slipped into 6.x that would allow us to start creating contrib modules that require php5 and get users thinking about the advantages of php5 so they start putting pressure on hosts to upgrade. Native timezone support didn't start working until 5.2, for instance, so the version check should test both major and minor version numbers. And add php version info to the module download page, too. Karen

9 9

Re: [development] Core feed publishing
by Ken Rickard 04 Jul '07

04 Jul '07

Boris & Chris- Sorry. Totally misunderstood the original post. I spent the morining reviewing Aggregator SoC stuff. That'll teach me to read 21 development digests in one day. (And those we just from Monday and Tuesday.) And just for you, I'm going off digest mode and we'll see if I can keep up. - Ken Rickard agentrickard

1 0

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