Re: [development] taking a break
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. :)
Chad Phillips wrote:
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.
Current developments in the patch queue - re the Deletion API, the book module, the proposed update module, and various others - have only strengthened my respect for Dries' integrity and the crucial role he continues to play in the project. It is easy to say, "I like that functionality, let's go with it". It is much harder to insist on quality, and on every patch proving itself on its own merits. To ensure that everything that gets in does so for the right reasons. To not get caught up in the politics of behind the scenes jockeying or the pressures and groupthink that happen when people line up behind a popular developer or feature. To ignore the questions "what are they going to say about me on IRC" or "what will X say about my code now that I criticized his/hers". To insist, quietly but firmly, that three good features, no matter how shiny, don't justify one sloppy or wrong one. To always ask the hard, unpopular, but necessary questions, even in the face of hostility and public criticism. 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. Compare comments here, two and a half years ago: http://drupal.org/node/15916 Have I changed my mind? Have others?
On 7/1/07 11:55 AM, Chad Phillips -- Apartment Lines wrote:
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_?
Actually, while I'm not sure I totally buy Dries' technical arguments against the deleteAPI patch yet, I totally disagree with this. I think so much of the project's success to date has to do with the fact that there is *one* final say guiding core and I think we as a community are very lucky to have Dries in that role. Adding more people with 'final say' just further complicates this issue - you end up with bickering and stale mates amongst that group. 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.
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."
I don't think it's a case of command and control - Dries is very reluctant to set out hard and fast "roadmaps" precisely because it's not just his project. I've been 'round here long enough to see Dries be convinced on more than one occasion - if it's a good feature and done right, it'll go in.
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.
Now, here I agree with you... but 'responsible' != 'final say'. I think part of the problem (as you've expressed eloquently) is that Dries came into the whole (rather large) deleteapi patch late in the game. Now just asking Dries to have his finger on the pulse of every issue in the queue is ridiculous. It's been well over a year and probably pushing two since that's been feasible (I sure know I can't do it). 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 - particularly larger ones like this. One issue is the whole 'code is gold' attitude can be taken to an extreme. Embarking on a major chunk of code - with the hopes that /maybe/ you'll luck onto the 'right' direction and it'll be accepted clearly isn't always fruitful. Sure, with things that can happily live in contrib it can often work out, but major re-workings of code not so much. I don't know the full history on the delete API patch specifically, but the fact that it seems after months of work, Dries isn't even on-side with the approach leads me to believe that a 'meta' conversation about design and approach would have been beneficial. I don't believe finger pointing as to why that didn't happen (or if it did, how we ended up here) - but rather let's look to ways we can better facilitate this moving forward. I've been thinking a lot about this whole issue lately - clearly my thoughts aren't fully formed as a 'plan' yet or anything, but we clearly need to address some of these things as we continue to grow (see: http://buytaert.net/growing-pains ). 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. What I'd love to see is for everyone to stay "at the table", and help brainstorm around best ways through it. I know chx well enough to know he can't *really* stay away - I hope the same holds for everyone else. Happy Canada Day :) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
I know chx well enough to know he can't *really* stay away
I could, for 1.5 days :) however http://drupal4hu.com/node/49 . "This Google results, and the many chipins really boosted my morale when it was needed most. Thanks. Really. See you in the issue queue -- on the train home, I will roll an actions patch." Seems I need the community and the community me. The promised actions patch is in the queue :) Regards, NK
On 7/2/07 9:15 AM, Karoly Negyesi wrote:
I know chx well enough to know he can't *really* stay away
I could, for 1.5 days :)
Uh huh... most people call that a 'weekend'. They do it every week ;) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 7/2/07, James Walker <walkah@walkah.net> wrote:
On 7/2/07 9:15 AM, Karoly Negyesi wrote:
I know chx well enough to know he can't *really* stay away
I could, for 1.5 days :)
Uh huh... most people call that a 'weekend'. They do it every week ;)
There is your clue. You said "people". Meaning those who sleep and can otherwise cut the tether to the big cloud. Not applicable to chx. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
Someone should take a screenshot of this thread and add it to the Chx Cannot Be Distracted tag on Flickr. LOL Khalid Baheyeldin wrote:
On 7/2/07, *James Walker* <walkah@walkah.net <mailto:walkah@walkah.net>> wrote:
On 7/2/07 9:15 AM, Karoly Negyesi wrote: >> I know chx well enough to know he can't *really* stay away > > I could, for 1.5 days :)
Uh huh... most people call that a 'weekend'. They do it every week ;)
There is your clue. You said "people". Meaning those who sleep and can otherwise cut the tether to the big cloud.
Not applicable to chx. -- 2bits.com <http://2bits.com> http://2bits.com Drupal development, customization and consulting.
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
participants (6)
-
Chad Phillips -- Apartment Lines -
James Walker -
Karoly Negyesi -
Khalid Baheyeldin -
Nedjo Rogers -
Sean Robertson