- Development - lists.drupal.org

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

Re: [development] taking a break
by Chad Phillips -- Apartment Lines 02 Jul '07

02 Jul '07

i'd like to start by saying i appreciate that you're willing to discuss this and listen to feedback. On Jul 1, 2007, at 6:00 AM, Dries Buytaert wrote: > Furthermore, it is impossible for me to review every single patch > every time it was updated. This means I'm forced to prioritize my > own code reviews, just like you or anyone else prioritizes yours. > I focus my time on patches (i) that people tell me are important or > (ii) that align well with my vision for Drupal. do you think it's possible that it's better for the project if there were more than one person who had 'final say' on matters? i understand that might occasionally mean that something important might not go the way you think it should. i see myself as a bit of a control freak, so i understand why that might cause some discomfort ;) but beyond that discomfort and possibly some temporary misdirection, would that change be better for the project _overall_? from your own blog entry on being a responsible maintainer: "Well, we have to accept and acknowledge the fact that a project the size of Drupal is always going to be a bit broken, and that command and control won't cultivate the Drupal wilderness." > Granted, sometimes important patches are neglected because they > have a high barrier to entry. This is highly unfortunate and I try > to deal with those as time permits. more time can be created by having more responsible parties. > I try to review a lot of these patches. Anyway, we're currently > nearing the code freeze, and people tend to forget about all other > patches except their own. this may be an aside to the present discussion, but i've been quite pleased and surprised by the mutual co-operation that surrounded the deletion API patch. by offering to review other's patches in exchange for their review of my work, progress was made in both directions. futhermore, it generated legitimate personal interest from both parties in another's code that they may have otherwise never bothered to look at. i would highly encourage the patch review trade approach -- everybody wins. :) > These are inherently crazy times. I don't know why, but sometimes > people think of the code freeze as the end of the world, and their > patch being the magic hero that comes in to save the world just in > time. Of course, it is nothing like that, and there is nothing > wrong with patches being postponed. i would agree that there is nothing wrong with a patch being postponed. but the question is: what is a valid reason for postponing a patch? i wouldn't say that a bottleneck in manpower is an invalid reason, but at the same time that should be a problem we can remedy. i've heard other devs comment, and i've seen it as well: there are an ungodly amount of patches in the queue that are RTBC, and are just sitting there, waiting for command control to take the next step. > I agree with parts of the book patch, and I disagree with other > parts of the book patch. Regardless my disagreements, I don't > think the book patch is super-high priority. Frankly, there is no > harm done when the book improvements don't make it into Drupal 6. i thought i heard it mentioned that these book improvements would help the drupal.org documentation effort a lot. if that's the case, then it does sound like there would be harm done. > I care a lot about what the delete API tries to accomplish, and > that's why I think it is so important to do it right, and why I'm > not happy with a half-baked solution. while i may sometimes disagree with the reasoning, i do appreciate the quality control. but let's look a step deeper at what's happened here with this patch. above you seem to indicate that the area i was working in was important for drupal, and yet the work received no attention from you during the development cycle. my repeated requests for your attention to it were met with "it's not high on my priority list". this seems to be a fundamental contradiction. above and beyond my personal frustration, it seems to indicate that you alone do not possess enough time to look at everything that's important, and yet you still maintain the only position of "final decision". that sounds bad for the project to me. i don't mean bad as in fatal, but more bad as in "we can do better". so i'm just suggesting that you take a look at why you're still the only person with final say, and determine if that's the best policy going forward. from my perspective, opening things up a bit more would result in less developer frustration, more quality code being produced, and more leaders being born. i think that's worth an occasional bump in the road that might get past you. :)

6 6

Re: [development] taking a break
by Chad Phillips -- Apartment Lines 02 Jul '07

02 Jul '07

Nedjo wrote: >> There are very few members of our community who consistently meet these >> measures. Dries is one of them, and Drupal's success is due in significant >> measure to that fact. i agree. but let me suggest that there's a bit of a self-fulfilling prophecy going on here. i think more members of the community could meet the measures you outlined, if they were given the chance to assume the responsibility, make some mistakes, and learn. what i'm about to say is merely an educated guess, but i'm betting it's fairly accurate given how humans learn and grow: in the beginning, dries probably made more mistakes than he does now in his decisions about what to commit/not commit. he probably committed things that, looking back, he would not have committed given his current level of experience in his position of leadership, or vice versa. he probably learned some invaluable lessons from those mistakes that inform his current decision making process. not providing other people that same process inhibits them from attaining the experience necessary to lead. your greatest lessons come from your mistakes. if, as i have suggested, dries made any mistakes in his time of leadership on the project, we've been able to survive those just fine. we'll survive any mistakes that other leaders will make, too -- especially since they have the benefit of a mentor. in the process we'll build new leaders. (by the way, please don't misconstrue the above to mean that i think the initial commit of the deletion api was a mistake, because i don't! i'm examining a larger dynamic here.) one thing that i find particularly perplexing is the gravity with which these kinds of changes are regarded. we participate in the kind of endeavor where we can make adjustments if we start to see we're heading in the wrong direction. nobody's life is at stake if we make a mis-judgement here or there... ;) i guess for me that engenders some spirit of experimentation -- not wild experimentation, but reasoned changes that result in valuable feedback. >> Compare comments here, two and a half years ago: http:// drupal.org/node/15916 in that long thread, this was one of the most salient passages that i found: "One of the concerns people may then have -- a longer-term concern -- for something like Drupal is: what happens when the torch is passed. Does it remain an autocracy, and are people going to be pleased with whomever assumes the role of autocrat? More importantly; what assurance do the contributors have that this is going to result in the continued health and well-being of the thing they have helped create?" those kinds of considerations provide credible weight to idea of grooming new leaders today, no matter what the current conditions are.

7 6

Go PHP 5, Go!
by Larry Garfield 02 Jul '07

02 Jul '07

This is a follow-up to the PHP 5 thread from a week or two ago. It looks like some momentum is building. Ken Rickard, Robert Douglas, and I have been talking with some of the Jooma folks, and have a working draft of the "core statement and justification". That is, what the goal is and why it is. Joomla's development team is discussing the matter and is leaning yes. Based on the earlier thread here I am hoping that there isn't much objection to Drupal participating in the "Go PHP5" effort. :-) So far Joomla is leaning yes, CakePHP is interested, and I had a positive first response from Typo3. Robert Douglas has volunteered himself to setup a web site for it. I'm not sure how Dries wants to handle the question of Drupal's participation (by vote, by consensus, or by fiat). Dries? Anyway, here's the working statement. Consider this an official recommendation that Drupal commit to participating in this effort. ------------------------------------ PHP 4 has served the web developer community for seven years now, and served it well. However, it also shows its age. Most of PHP 4's shortcomings have been addressed by PHP 5, released three years ago, but the transition from PHP 4 to PHP 5 has been slow for a number of reasons. PHP developers cannot leverage PHP 5's full potential without dropping support for PHP 4, but PHP 4 is still installed on a majority of shared web hosts and users would then be forced to switch to a different application. Web hosts cannot upgrade their servers to PHP 5 without making it impossible for their users to run PHP 4-targeted web apps, and have no incentive to go to the effort of testing and deploying PHP 5 while most web apps are still compatible with PHP 4 and the PHP development team still provides maintenance support for PHP 4. The PHP development team, of course, can't drop maintenance support for PHP 4 while most web hosts still run PHP 4. It is a dangerous cycle, and one that needs to be broken. The open source PHP developer community has decided that it is indeed now time to move forward, together. Therefore, the listed open source PHP projects have all agreed that effective 5 February 2008, any new feature release will have a minimum required PHP version no older than PHP 5.2.0. It is our believe that this will allow web hosts a reason to upgrade and the PHP development team the ability to retire PHP 4 and focus efforts on PHP 5 and the forthcoming PHP 6, all without penalizing any existing project for being "first out of the gate". ------------------------------------ Notes: - I chose the date because I figure that will be 7-8 months after we officially announce this thing, which I believe should be sufficient time for web hosts. It also comes out to 5/2/2008 (using European convention), and I just like inside references like that. :-) - This does not preclude any project from moving before the deadline date, or from supporting older versions for however long they wish to. That's up to each project. - PHP 5.2 is already the most widely installed version of PHP 5, based on the latest published stats. I know at least two web hosts I work with that either have jumped or are in the process of jumping from PHP 4 straight to PHP 5.2. By the target date it will have been out for nearly a year and a half. It also adds a number of new and useful core features (filter_input, json, a stable PDO, etc.). It's a good version to target. Thoughts? Comments? Support? Rotten tomatoes? -- 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

41 122

Re: [development] taking a break
by Chad Phillips -- Apartment Lines 02 Jul '07

02 Jul '07

On Jul 1, 2007, at 4:20 PM, walkah wrote: > IMNSHO, the issue we're facing right now is not that Dries is > failing or > we need to add more Dries - but rather we need some stronger support > around him. ...snip... >> more time can be created by having more responsible parties. > > Now, here I agree with you... but 'responsible' != 'final say'. ...snip... > So we need a > way where we can distribute the load a bit - so that Dries has a > sort of > 'executive overview' - and can help guide in the early stages of > patches what you're outlining would be a good step, _if_ there are clear protocols for this setup, and those protocols are well-known to the community. we as developers should know what to expect from the process of trying to get something committed to core, otherwise things can get very discouraging. to take the deletion api as a case study, although i had not received direct input from dries, i was still getting input from steven and chx on my work -- two well-respected members of the community, one of whom is a core committer and 'right hand man' (not to mention quite a few usability reviews from other respected coders). i thought this was enough guidance, but i was mistaken. when steven committed the patch, again i assumed that the change was 'official', and put in another 30 hours of work on documentation, bugfixes, and conversion patches. but again i was mistaken. i may be wrong -- but i don't think my assumptions were way off-base, and yet the whole thing became a big ol' mess. i'm not saying that we need to have some highly restrictive structure in place -- but at least enough of one that a developer has confidence that they're taking the right steps to move in the right direction as they continue to work on their code. i don't think that's too much to ask. :) > Dries has expressed to me more than once a frustration that not enough > people are focused on core. I've heard from some of the people that I > suspect Dries would like to focus on core that there are issues that > make it hard, difficult or unpleasant for them to do so. and this is a very clear sign that we need to make adjustments -- people on both sides are frustrated! one more point about having 'final say', which is mostly theoretical. final say on commits is certainly another level of responsibility than just being able to commit. that level of responsibility has it's own challenges and lessons that are not available at lower levels. while it might introduce other issues, more people having final say would result in more experience for more top-level people. i won't argue if the benefits outweigh the costs -- just seems like something worth considering.

5 4

taking a break
by Karoly Negyesi 02 Jul '07

02 Jul '07

When some patches are more equal than others, I just can't continue. If one of my patches had only tenth the code style errors actions patch had (and I am not talking of the critical bug it has, it's not easy to see albeit module_implements had a five line long comment over the same bug) there would have been no chance that patch got commited. I complained long and hard in the issue queue over the years for helding up this or that important feature over a space or two. Neither the book patch nor the menu fixes are in despite they are tested and supported. I guess my life is so entwined with Drupal that I won't be able to stay away for long. Anyways, I will take a few days break. Regards, NK

6 12

very simple D6 feature patches
by Peter Wolanin 30 Jun '07

30 Jun '07

Here's a quick compilation of very simple feature requests for D6. They have no more than 10 lines of code changed (excluding comments) and are already marked as RTBC. If you have time, do a review and offer your support (or criticisms) before the code freeze hits. Add more or cross them off as needed: http://groups.drupal.org/node/4943 -Peter

1 0

Patch: path.module performance improvement
by Wim Leers 30 Jun '07

30 Jun '07

Hi, yup, yet another desperate call for review. I just need another small review to get this patch (hopefully) marked as RTBC. It has been tested thoroughly already! What does it do? - how: provide the ability to use no optimization at all, a blacklist or a whitelist of Drupal paths, to reduce the number of queries drupal_lookup_path() has to perform - default: a very safe blacklist - UI: none, to avoid confusion for the average user. The UI will be provided by a contrib module. - performance improvement: from 55.07 reqs/sec to 61.46 reqs/sec, which is 11.6% more (using the default). These numbers come from benchmarks that you can see in follow-up #72. The total number of queries per page dropped about 20% (absolute numbers: between 10 and 100 less queries). Of course this all depends on your setup. Conclusion: - this patch gives a "free" performance boost to all path.module users, the difference will be larger for more complex sites - if you're knowledgeable enough to use the UI for this module, you can increase that performance gain even further Link: http://drupal.org/node/106559 Wim Leers

1 0