July 2007 - Development - lists.drupal.org

LM_PayPal Replaced Without Warning!!
by Lee McLoughlin 03 Jul '07

03 Jul '07

I was surprised to be emailed by a couple of people asking if I was going to continue with my LM_PayPal module now an "official" PayPal module (Simple PayPal Framework http://drupal.org/project/simple_paypal ) had been written. I created my module last year because the existing PayPal Framework was no longer supported and the author could no longer be reached. I really needed PayPal based subscriptions and nothing available at the time that supported them. Knowing that "competing" modules are generally frowned upon I did my best to ensure it wasn't duplicating any work and I couldn't find any other PayPal modules (with the exception of the eCommerce suite). When I asked for permission to submit it to CVS I was asked if I had tried to contact the PayPal Framework author. This was checked before I was given permission. (There was by this time someone working on the Framework but he was happy to defer to my work and in fact the module entry now points people to LM_PayPal.) I thought this was the route all replacement modules would take. I was never contacted about this new module. My first knowledge was when my users emailed me. I contacted one of the authors of the Simple PayPal Framework, Khalid Baheyeldin, and he confirmed it is taking over. Today I find that my module has been removed from the contributed modules list (http://drupal.org/project/Modules/name) I'm a pretty surprised by all this. No-one had the courtesy to contact me to let me know my module was being dropped. I was given no warning of any kind. If someone could let me know how much longer LM_PayPal will appear as a project and under CVS I'd appreciate it. Lee

4 3

Re: [development] String freeze
by FGM 03 Jul '07

03 Jul '07

This makes me think of something that has been mentioned at various times: couldn't we have a "default" version (which would happen to be in english for core) and english as just one translation, which would happen to be empty by default for core, returning the default version ? This seems to be along the line of what you suggest by "english translation", and would nicely fit in the overall localization scheme by not supposing contrib modules, for instance, are by default written with english text, but could have english as just one location, and the default distribution would be just that: default. There's no code involved, just a documentation choice, so it is in time for D6. The language code for default would only have to be anything different from the ISO 639 values (anybody for "@@" ? it sorts before any other alpha value). ---- Original Message ---- From: kkaefer(a)gmail.com To: development(a)drupal.org Subject: Re: [development] String freeze Date: Tue, 3 Jul 2007 10:17:59 +0200 >Hi, > >> Last release, we had a "string freeze" once we hit RC1. This meant > >> that any clarifications/clean-ups/etc. to any user-facing text >> (help messages, form labels, etc.) were 'frozen' and couldn't be >> altered after RC1 was released, in order to give translators ample > >> time to translate Drupal. > >I'm all for a string freeze like the last time. Keeping the string >freeze date in mind helped us get a lot of UI text fixes in which >improved overall usability. > > >> b) Is RC1 enough time? If we set it at beta-2 or something would >> that allow us to include a few translations in Drupal core itself >> by RC1? > >I am a translator as well (German translation) and I think it was >enough time to complete at least the most important parts of it. > >I'd like to propose something else, though: While translating, I get > >to read all the help text included in Drupal, and I noticed that most > >of those help texts are not very well written and even include >factual errors (e.g. removed features, no mention of newly added >features etc.). I'd like to cast a kind of "user interface text team" > >that especially takes care of such issues. We could for example set >up a site with Drupal 6, enable locale module and use it to modify >the english strings (english -> english "translation"). After we've >fixed those strings, we can create patches against HEAD. Not sure if > >that's a good/practiable solution. Any suggestions? > >Konstantin Käfer http://kkaefer.com/ > >

2 1

String freeze
by Angela Byron 03 Jul '07

03 Jul '07

Greg Knaddison just asked about this in IRC, and given D6's focus as "the i18n release," it's worth bringing this up, I think... Last release, we had a "string freeze" once we hit RC1. This meant that any clarifications/clean-ups/etc. to any user-facing text (help messages, form labels, etc.) were 'frozen' and couldn't be altered after RC1 was released, in order to give translators ample time to translate Drupal. a) Shall we go ahead and implement this policy again this release? b) Is RC1 enough time? If we set it at beta-2 or something would that allow us to include a few translations in Drupal core itself by RC1? -Angie

8 10

Goals of project module and core issue queues
by Neil Drumm 03 Jul '07

03 Jul '07

Lets take a step back.. what are the goals of project module and the core issues queues? I would say the primary goal is to make good releases of Drupal core. We could take this goal and get to "issue queues should be short" by saying that short issue queues indicate that Drupal has less issues and is good, or that reviewers have less things to think about. Large issue queues happen in all large open source projects. I think we should focus on the bigger goal and make sure our thinking serves that. And how do we measure this? We need to quantitatively show if we are doing a good or bad job before we can be serious about fixing things. We do have http://drupal.org/project/issues/statistics/drupal, but I do not think it is useful. There are plenty of rough metrics that tell us things, but no single number directly tells us when we have done something good. With goals in mind, how do we improve project module? How do we know if the changes are good? -- Neil Drumm http://delocalizedham.com

1 0

Mass node create module
by Bob 02 Jul '07

02 Jul '07

Does anyone know if there's a module that can be used to generate a large number of nodes at once, perhaps 1 per line with much reduced options? It'd come in handy for a lot of CCK stuff I want to do with simple information where you don't need all the menu, input format etc boxes for everything. If not, I'll make one, but just wanted to check I wasn't duplicating effort first. Thanks! Bob xx -- Those who do not move, do not notice their chains. phone: 0774 3917404 skype: daresbalat msn: bobulatorm(a)hotmail.com

5 5

Subsystem maintainers or targeted committers?
by Robert Douglass 02 Jul '07

02 Jul '07

The link[1] Thomas Barregren posted was quite interesting. Indeed, Drupal seems to be experiencing some of the issues the Linux kernel faced some years ago, albeit not nearly as drastically. Reading through that post and the rest of the comments on the mailing list here bring me to some observations. 1. Gabor has done a great job. In particular, he has led the drive for i18n features in core. That's awesome. 2. Gabor came in almost as if he had a mandate to focus on #1, and indeed, he has focused nearly exclusively on #1. 3. Whether this was by accident or design, it worked well and would seem to be scalable and repeatable. 4. Dries could "scale" his vision of Drupal architecture by assigning more such targeted committers. He could say "Jeff Eaton... for D7, your job is to make sure the Data API gets in, and that it rocks." Or "KarenS, for D7, your job is to make sure CCK hits core, and that it rocks." Or "Earl Miles, get your query builder into core and integrated at a deep level, and make sure it rocks." 5. Whether or not the people in #4 get core commit privileges is nearly irrelevant (though I'd opt for them having commit privs, with the understanding that they were to be exercised on a limited domain of applicability only.) The important part would be that one person was understood to be "in charge" of the features. Any other developers wishing to see those features into core would have to work with the target committer, and the target committer would be responsible for tracking and coordinating the effort. We do this in a way now, so codifying it would only be a reinforcement of current patterns. Yet by making it formal we'd be enhancing the efficiency and scale of the operation. Such an approach may be the way in which we get high quality features into core while Dries maintains the overview and flexibility to do what he's been doing so well. -Robert [1] http://lkml.org/lkml/2002/1/28/83

3 3

taking a break, part deux
by Chad Phillips -- Apartment Lines 02 Jul '07

02 Jul '07

recent events regarding the deletion API have given me pause, and i'm feeling like some time off for perspective would be a good thing. i've deleted all ongoing core work from my machine, and unassigned myself from all issues in the queue. my intention is to not do any core work or patch reviews until the Drupal 7 development cycle, at the earliest. while the deletion API rollback was personally very frustrating (and i think suggestive of the need for some tweaking in our dev process somewhere), i'm not taking it personally -- i know everyone involved in the issue was doing what they thought was best for drupal, and we just had different perspectives. i'm sure i'll still be around in IRC and/or available for comments or opinions -- just don't ask me to do any real work... ;) the gauntlet has now been thrown. will the specter of drupal core development draw me back into it's evil clutches this cycle?? only time will tell... ;)

2 1

Re: [development] Subsystem maintainers or targeted committers?
by Karen Stevenson 02 Jul '07

02 Jul '07

<snip> The simpler version would be a new status "concept needs feedback" (or something like that). Indicating "please talk before I write code so that I can write code." For most non-trivial changes that's probably a good idea anyway (design first!), and would be an explicit flag for subsystem experts (formal or informal) as well as committers to jump in and nip a dumb idea in the bud, correct a design flaw before it gets codified, or indicate that they think something is a really good idea. And it keeps it on-site rather than on people's blogs. :-) It could eve have its own custom link (like the "patches needing review" link) so people can see what's being discussed at-a-glance. </snip> This accomplishes most of what I was thinking and it would be very simple to do. So if I see that Dries (or anyone else, but especially Dries) has marked an issue 'concept needs feedback', I would know that I either need to add support to the reasons why it's needed or the direction that it's taking, or assume it's not going anywhere right away and spend my time elsewhere. And 'Concept needs feedback' implies that you want thoughtful responses and not just a '+1'. And it would be very interesting to see what concepts others are discussing on that custom link. I like it :-) Karen

1 0

Which JQuery will be included in Drupal 6?
by adrian rossouw 02 Jul '07

02 Jul '07

jQuery 1.1.3: 800%+ Faster, still 20KB http://digg.com/programming/jQuery_1_1_3_800_Faster_still_20KB After many months of testing, developing, and more testing, we have a very solid release available for download. It comes with roughly 80+ fixed bugs and a handful of enhancements for good measure. (the jquery site itself has been dugg right now)

2 1

Re: [development] Subsystem maintainers or targeted committers?
by Karen Stevenson 02 Jul '07

02 Jul '07

I think this is starting to get somewhere :-) I see the biggest problem is that there is nothing now between 'Feature Request' and 'Patch to be Reviewed'. In fact, it seems that you can't get much attention to a FR unless you provide a patch to be discussed, which puts the cart before the horse and probably encourages everyone to just jump in and start coding without enough support around the idea. Perhaps we need to move Feature Requests to a different system or different part of the system where you can propose a feature and have a forum for discussing in a global way whether the feature is needed and what should be included in a solution. Then, after discussion has solidified and there is agreement that it is a good idea and what direction it should take, and only then, someone creates a patch to be reviewed that is put into the issue queue. And any non-trivial core patch should be somehow be forced through that system before it will be considered. Now, what needs to be done to create a system like that? I'm not sure. Karen

4 3