- Development - lists.drupal.org

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

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