March 2006 - Development - lists.drupal.org

Re: [development] OpenID
by Jonathan Daugherty 02 Mar '06

02 Mar '06

> What's the status of this module? I'd like to begin using it on my > personal site. Robin and others, Sorry I've taken so long to get back to you about this. We've been working hard on getting the PHP library (and others) ready for a 1.0 release. Hopefully we'll have 1.0 ready by the end of this week or by early next week. Once 1.0 is out, I'll update the Drupal module I posted to work specifically with 1.0 and I'll also begin work on implementing server support in Drupal. Please contact me off-list if you have any further questions. Thanks! -- Jonathan Daugherty JanRain, Inc.

1 0

critical bugs vs release (candidate)
by Ray Zimmerman 01 Mar '06

01 Mar '06

On 28 Feb 2006, at 22:23, Dries Buytaert wrote: > We're down to 13 critical bugs. > > I guess we'll release a beta 5? I don't think we had 0 critical > bugs left when we released either Drupal 4.5 or Drupal 4.6 but I'm > willing to try. I have this feeling that it might take us many > more weeks to fix them all. On Feb 28, 2006, at 4:52 PM, Karoly Negyesi wrote: > Why not RC , really? Disclaimer: I'm relatively new around here, so please ignore this if the community already has clearly defined conventions for these that I'm not aware of. In order for the terms "critical bug" and "release candidate" to carry consistent meaning, I would suggest that we insist on getting down to 0 critical bugs before release. IMHO, either a bug is not critical or the code is not ready for release (i.e. not a release candidate). If that is not the case, then it sounds to me like we need yet another higher priority level for "show stopper" bugs. Consistent with that, "release candidate" to me means, "this is the version we plan to release if no critical issues arise in the next x days", in which case I think we might be ready for a beta 5, but not for a RC. On a related note, I think it would be useful to have a link on the issue submission pages that points to a help page with some guidelines clarifying the options for the different fields (e.g. how to decide whether to report a bug as normal or critical, etc). Thanks to all of you for making Drupal happen, Ray

1 0

cool comment trick
by Karoly Negyesi 01 Mar '06

01 Mar '06

/* some optional code here /**/ now, if you change the first line to //* some optional code here /**/ then the optional code will run. This is prolly the simplest way (one char!) to switch on-off blocks of code. Regards NK

3 2

Re: [development] unmaintained modules listing
by Kobus Myburgh 01 Mar '06

01 Mar '06

Let me rephrase... Is the project module in CVS head the one used on Drupal.org? Regards, Kobus >>> dries.buytaert(a)gmail.com 3/1/2006 11:56:20 AM >>> With the project module in CVS head, we can show the 'last changed' date for each of the projects. Kobus, care to help improve the project module? That would be invaluable. :) -- Dries Buytaert :: http://www.buytaert.net/

2 1

Re: [development] unmaintained modules listing
by Kobus Myburgh 01 Mar '06

01 Mar '06

> Kobus, care to help improve the project module? That would be > invaluable. :) Dries, thanks for the vote of confidence, but I am not sure I am *that* clued up yet. I can try though. Do I download the project module from the download site, or what do I do? I am sure that the project module on Drupal.org is not stock standard? Regards, Kobus

1 0

Re: [development] unmaintained modules listing
by Kobus Myburgh 01 Mar '06

01 Mar '06

Hi! I don't have access to perform a task like this, and was wondering if someone could implement a simple solution like this one way or another? I'd love to get a list of modules (so that I can select a few basic ones while I get experience) to port them to 4.7. One of them that I have noticed that doesn't work on 4.7 (at least when I last downloaded it) was nodewords, but I think it is maintained, so I don't want to just jump in and maintain modules with active maintainers. I am on a roll now - motivated, because I begin to understand this complexity, and I don't want to lose that motivation, so if someone can do this today sometime, I can perhaps port a module or two tonight... Regards, Kobus >>> greg.knaddison(a)gmail.com 2/28/2006 7:12:13 PM >>> On 2/28/06, Moshe Weitzman <weitzman(a)tejasa.com> wrote: > > no such list that i know of ... i think a sensible way to track this is > to assign all unmaintained projects to a single user called > 'unmaintained'. i just registered that user. then a custom php page > could show these projects in a table. maybe you could write the PHP for > such a page and gather up the list of modules. I can perform the edits > to projects on drupal.org if you don't have edit permission. Well, here is such a list based on the "Show last 5 nodes by user" http://drupal.org/node/22628 $result = db_query("SELECT n.created, n.title, n.nid, n.changed FROM node n INNER JOIN project_projects p ON n.nid = p.nid WHERE n.uid = 51123 ORDER BY n.changed ASC"); $output .= "<div class=\"item-list\"><ul>\n"; $output .= node_title_list($result); $output .= "</ul></div>"; return $output; > > or someone else will volunteer for this task? > Khalid has some good (but more complex) ideas on the process. Greg

2 1

Re: enterprise needs
by Ken Rickard 01 Mar '06

01 Mar '06

>Here's my scaling tree. As you progress up the tree, you will find that time, money, maintenance, headaches will all increase.'' Ben- Thanks, that's a great list. My problem (which I had to explain to Karoly) is that I'm not a sysadmin, so I can't implement (or even really explain) these points. But I will path them along to our guys who are in charge of such things. As I said to Karoly privately, part of our problem is that I _fell_ confident that Drupal will scale, I just don't have the tech cred to back that up. So your list really helps. - Ken

6 5

RCS $Id tag in database source files
by Derek Wright 01 Mar '06

01 Mar '06

The Drupal coding standards (http://drupal.org/node/318) doesn't explicitly list this point. In addition to .php files using: // $Id$ it seems like .mysql and .pgsql files should also include something like this: -- $Id$ Knowing the exact revision of a .mysql file seems just as handy as knowing it for source (.php, .module or .inc) files. Upon further inspection, I see that this has now been done in core/database/database.* in HEAD. Nice work, Markus and Dries, thanks. a) I'd like to encourage all module developers on this list to add this comment to any .mysql and .pgsql files in their own module(s). b) We should update the coding standards page about this. I'd just add a comment to the page, but it seems better to have it in the body of the node, instead. What's the best way for me to help make that happen? I submitted an issue to the Documentation project's "Developer Guide" component... is that the desired behavior? Thanks, -Derek

2 1