August 2007 - Development - lists.drupal.org

#drupal / #drupal-dev split considered harmful
by Angela Byron 03 Aug '07

03 Aug '07

A couple weeks ago, a few developers started going into #drupal-dev instead of #drupal and started a campaign to get people to split off. I guess the reasoning for this was because they disagreed with newbies who didn't read the topic getting 'support?' in their face when they join our "official" channel. I personally think it is a feature, and not a bug, that our main channel is contribution-focused rather than support-focused, but that is largely irrelevant to the topic at hand. The problem is that the people who started this 'fork' have not been present in #drupal, actively taking part in support requests from newbies, thus changing the 'mood' of the channel by their own words in actions. Instead, the main channel's merely been abandoned by several very prominent contributors, a large portion of the development community doesn't even realize there's a separate channel, development discussion in general is now splintered between the channels, and newbies are still getting 'support?' in #drupal. The climate in the 'official' channel right now is more that of a ghost town of join/part messages, except for random musings about the infrastructure and, of course, 'support?'. This gives the exact opposite impression to new Drupal users than the channel did before the split -- a vibrant community of developers sharing issues or patches to review, talking about new modules they're developing, etc. So please, #drupal-dev goers, either finish what you started by actively working in #drupal to make it more newbie-friendly, or abandon the experiment. So far, this feels like a net loss for the community. -Angie

15 30

Core module maintainers
by Boris Mann 03 Aug '07

03 Aug '07

I've brought this up before, but seeing as one of the core maintainers lives in my office, I thought I'd bring it up again. I believe we should up the level of responsibility of our main core community. I believe each module / the MAINTAINERS.txt should have at least two maintainers attached to it. Officially. An example being search module. Right now, it's the "scary code that Steven figured out how to work right". Luckily, Doug Green has been diving in and working out some patches as well. Let's put Steven and Doug listed as maintainers -- they both now have the search.module queue to be responsible for. The same goes for the rest of core modules, or basically anything with a "component" listed in the Drupal project. This does NOT change commit privileges or process: we have a limited set of core committers who must do the final once over when something goes RTBC. But ideally...RTBC should be that. What do you think? Any volunteers for specific parts? -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com

11 18

Question on tracker query
by Narayan Newton 03 Aug '07

03 Aug '07

Not sure if this is the best place to ask this, but I'm sure I'll be informed quickly and forcefully if its not ;). I notice that one of the tracker queries, specifically: $sql = 'SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, GREATEST(n.changed, l.last_comment_timestamp) AS last_updated, l.comment_count FROM {node} n INNER JOIN {node_comment_statistics} l ON n.nid = l.nid INNER JOIN {users} u ON n.uid = u.uid LEFT JOIN {comments} c ON n.nid = c.nid AND (c.status = %d OR c.status IS NULL) WHERE n.status = 1 AND (n.uid = %d OR c.uid = %d) ORDER BY last_updated DESC'; Is using a (in my opinion) rather dubious DISTINCT. Does this ever actually do anything? Given I am not very familiar with the codebase, but I at first glance at least...I just don't see it and its causing a filesort for this query. Thoughts? Corrections? Flames?...Rabbits? --Narayan Newton

2 2

Cleaner and more consistent code.
by ojacquet＠jax.be 03 Aug '07

03 Aug '07

A while ago I suggested on d.o. to remove either db_fetch_row or db_fetch_object. This would result in cleaner code, more consistent function signatures and hooks. At my current work this is included in the coding conventions, we only use mysql_fetch_object(). I'm posting this to the development mailing because I am interested in what you, as developers, think about this. The original suggestion: http://drupal.org/node/158115 Example of an inconsistent hook: http://drupal.org/node/124141

11 17

Auto-setting the node title?
by Richard Morse 03 Aug '07

03 Aug '07

Hi! I'm trying to avoid writing a custom module to do something that CCK, Views, and Workflow/Actions can take care of. I'm almost all the way there -- the only thing remaining is how to set the node title automatically. Is there a way to define a default node title? If not, is there some way to add a CCK field (possibly a computed field?) that runs javascript on form load to set a title? Thanks, Ricky The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.

4 6

Yahoo User Interface library
by Dries Buytaert 03 Aug '07

03 Aug '07

Hello, Yahoo! just released a new version of their User Interface Library (http://developer.yahoo.com/yui) The funky part? The new version contains some high-level components like a WYSIWYG editor, a Color Picker, a popup calendar, etc. One of the many demos: http://developer.yahoo.com/yui/examples/editor/cal_editor.html It might be well worth a look ... so I figured I'd pass this tidbit along. :) -- Dries Buytaert :: http://buytaert.net/

8 8

Patch assistance
by Larry Garfield 03 Aug '07

03 Aug '07

So I've been working recently on implementing the page-split patches made possible by an addition to the menu system. All but one that I've written so far are in, but there's plenty more that need to be done including the really big core modules: system, user, node, comment. That's where the really big win will be. Unfortunately, two over-deadline projects at work (that always happens when Drupal has a deadline, too) and two out of state trips, the second of which I leave for tomorrow, have not given me the time to get to as many modules as I'd like and Dries is getting justifiably antsy about making large code changes, even if it's 90% just copying and pasting between files. Unfortunately I will not be back until Monday, so won't be able to work on more patches this weekend. This is a very important performance task, but one that really just requires time and grunt work to implement at this point. So please consider this a call for people to help out in splitting up core modules. I'm especially looking at budding developers who want to help with core but aren't sure where to start. You don't need to fully grok all of Drupal to do this, but it is a great way to get your feet wet! See here for a list of modules that still need to be split up: http://groups.drupal.org/node/4179 Patches should be module-by-module, and the issue named "Split up foo module". I'll be back Monday-ish or so to keep working on the split. I'd be a very happy camper if I came back and found not a great deal left to do. :-) Thanks, Drupal! -- Larry Garfield AIM: LOLG42 larry(a)garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

1 0

Re: [development] Core module maintainers
by Steven Peck 03 Aug '07

03 Aug '07

> -----Original Message----- > From: Derek Wright > Subject: Re: [development] Core module maintainers > > > On Aug 2, 2007, at 4:20 PM, Boris Mann wrote: > > > Obviously we need buy in from the big D. > > Big D already bought in to this concept when I asked him about Earl > and myself co-maintaining update.module weeks ago. Consider it > decided. > On Aug 2, 2007, at 4:34 PM, Boris Mann wrote: > > And he needs a buddy. MAINTAINERS.txt is out of date, and needs to > > actually reflect maintainership. > > Agreed. > > > I don't know what process is needed. > > We just need to assemble the updated list of maintainers (g.d.o > wiki?) and then turn that into a single core patch. Or, different > maintainers could file their own patches to add themselves in a > single d.o core issue and skip the unified patch and g.d.o wiki. I > don't really care, either way, but it seems like it's less work for > the core maintainers to sort all of this out without bothering them, > and submit a unified patch for the D6 maintainers.txt file. > > > Other suggestions? Or do we just wait for Europe to wake up? > > Those lazy Europeans, always sleeping aren't they? ;) > Well, I imagine we need Dries to approve the choices too. :) So here is an interesting question. What modules/realms are left that fall under the category THE REST: M: Dries <dries(a)drupal.org> We have aggregator block book (tho a volunteer has stepped up :) color comment forum etc.... So, those lurking on the list. Without involvement the same number of people will continue maintaining a more complex core eco-system that some peoples businesses rely on. Money helps some things, but skilled developer time is invaluable. Steven Peck :: www.blkmtn.org

1 0

Channels solved
by Karoly Negyesi 02 Aug '07

02 Aug '07

Finally, I got there to talk with Angie about this. The solution is as follows: People wanted to have a more quiet place to have development discussions. Let them. But then that place should not be used for anything else but deep development discussions. This is #drupal-dev . Me , Angie and I hope a few others will actively police the channel to keep it the quiet place for development discussions. Let #drupal be whatever it was: devel talk, advocacy, social, one sentence support replies and yes even support? questions. Yes we wanted to avoid this, but there is no way out. If you allow support, any degree of support in #drupal then it eventually leads to having only support in #drupal and that will mean quite some people will avoid it like the plague. While other projects do this, we are much more development focused. The much desired crossover won't happen in this case. I am not happy with not being able to abolish support? question. But if we want newcomers to be faced with development discussions so they can feel being "in the flow" then I fail to see any other solution and the recent discussions and flamewars have not showed any other way. Please, please help us making #drupal an active, friendly place even for newcomers -- give them the chance to become contributors! Regards, NK

2 1

d.o. empty?
by Vasileios Lourdas 02 Aug '07

02 Aug '07

Hi, Just visited the site and it seems like a new installation! No forum messages, no projects, etc. Empty! -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name

2 1