From enboig at gmail.com Wed Apr 1 09:08:30 2009 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Wed, 1 Apr 2009 11:08:30 +0200 Subject: [development] remove or give priority to hook_node_grants In-Reply-To: <45a29f450903311622o51467844t83f0cede061d5cfc@mail.gmail.com> References: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com> <45a29f450903310859w27417c7ah4c1a911cf6c7f0f8@mail.gmail.com> <6117a7500903310946w783d1232r6958d8a7a1c5412a@mail.gmail.com> <200903311409.10324.larry@garfieldtech.com> <25b45da00903311320x16ea67e5h5ff3605901df045a@mail.gmail.com> <45a29f450903311622o51467844t83f0cede061d5cfc@mail.gmail.com> Message-ID: <45a29f450904010208ue3bc9bbl1e86859c38b7331e@mail.gmail.com> I have tested it (never played with drupal_alter before) and what I would need is a patch at node.module: function node_access_grants($op, $account = NULL) { if (!isset($account)) { $account = $GLOBALS['user']; } - return array_merge(array('all' => array(0)), module_invoke_all('node_grants', $account, $op)); + $grants = array_merge(array('all' => array(0)), module_invoke_all('node_grants', $account, $op)); + drupal_alter("node_grants",$grants); return $grants; } but it would also deny my access to the group node so I will have to look for another way to solve my problem. On Wed, Apr 1, 2009 at 1:22 AM, Llu?s wrote: > I will check if the patch is useful to me. If it is, will it manage to drupal6? > > On Tue, Mar 31, 2009 at 10:20 PM, Ken Rickard wrote: >> Larry means "Please work on this existing patch"; >> >> ?http://drupal.org/node/309007 >> >> ?-- Ken >> >> On Tue, Mar 31, 2009 at 3:09 PM, Larry Garfield wrote: >>> Note that if you make a patch for Drupal 7 to add an alter there, it gets >>> committed, and then you make a backport of it, God will only maim a kitten in >>> response rather than killing one. >>> >>> Translation: Patch please, Lluis! ?That would be a great addition to Drupal 7. >>> >>> On Tuesday 31 March 2009 11:46:31 am Moshe Weitzman wrote: >>>> Just add a drupal_alter() right after all the grants have been >>>> provided. yes, this requires a 1 line hack to core. >>>> >>>> On Tue, Mar 31, 2009 at 11:59 AM, Llu?s wrote: >>>> > I think this would be great; but it wouldn't solve my problem neither. >>>> > How can I "remove" a realm from $grants[$realm] >>>> > >>>> > I tried to "overwrite" it, but it uses arrays and merge them, so it is >>>> > impossible. >>> >>> -- >>> Larry Garfield >>> larry at garfieldtech.com >>> >> >> >> >> -- >> Ken Rickard >> agentrickard at gmail.com >> http://ken.therickards.com >> > > > > -- > *La vida ?s com una taronja, que esperes a exprimir-la? > *Si creus que l'educaci? ?s cara, prova la ignor?ncia. > *La vida ?s com una moneda, la pots gastar en el que vulguis per? > nom?s una vegada. > *Abans d'imprimir aquest missatge, pensa en el medi ambient. > -- *La vida ?s com una taronja, que esperes a exprimir-la? *Si creus que l'educaci? ?s cara, prova la ignor?ncia. *La vida ?s com una moneda, la pots gastar en el que vulguis per? nom?s una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From agentrickard at gmail.com Wed Apr 1 16:15:55 2009 From: agentrickard at gmail.com (Ken Rickard) Date: Wed, 1 Apr 2009 12:15:55 -0400 Subject: [development] remove or give priority to hook_node_grants In-Reply-To: <45a29f450904010208ue3bc9bbl1e86859c38b7331e@mail.gmail.com> References: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com> <45a29f450903310859w27417c7ah4c1a911cf6c7f0f8@mail.gmail.com> <6117a7500903310946w783d1232r6958d8a7a1c5412a@mail.gmail.com> <200903311409.10324.larry@garfieldtech.com> <25b45da00903311320x16ea67e5h5ff3605901df045a@mail.gmail.com> <45a29f450903311622o51467844t83f0cede061d5cfc@mail.gmail.com> <45a29f450904010208ue3bc9bbl1e86859c38b7331e@mail.gmail.com> Message-ID: <25b45da00904010915u77d5504el21220b569c10c976@mail.gmail.com> Sorry, that was the wrong issue. We have not filed the node grants issue yet because of changes to the database layer. See http://groups.drupal.org/node/14419 -- Ken On Wed, Apr 1, 2009 at 5:08 AM, Llu?s wrote: > I have tested it (never played with drupal_alter before) and what I > would need is a patch at node.module: > > function node_access_grants($op, $account = NULL) { > > ?if (!isset($account)) { > ? ?$account = $GLOBALS['user']; > ?} > > - ?return array_merge(array('all' => array(0)), > module_invoke_all('node_grants', $account, $op)); > + ?$grants = array_merge(array('all' => array(0)), > module_invoke_all('node_grants', $account, $op)); > + ?drupal_alter("node_grants",$grants); > ?return $grants; > } > > but it would also deny my access to the group node so I will have to > look for another way to solve my problem. > > > On Wed, Apr 1, 2009 at 1:22 AM, Llu?s wrote: >> I will check if the patch is useful to me. If it is, will it manage to drupal6? >> >> On Tue, Mar 31, 2009 at 10:20 PM, Ken Rickard wrote: >>> Larry means "Please work on this existing patch"; >>> >>> ?http://drupal.org/node/309007 >>> >>> ?-- Ken >>> >>> On Tue, Mar 31, 2009 at 3:09 PM, Larry Garfield wrote: >>>> Note that if you make a patch for Drupal 7 to add an alter there, it gets >>>> committed, and then you make a backport of it, God will only maim a kitten in >>>> response rather than killing one. >>>> >>>> Translation: Patch please, Lluis! ?That would be a great addition to Drupal 7. >>>> >>>> On Tuesday 31 March 2009 11:46:31 am Moshe Weitzman wrote: >>>>> Just add a drupal_alter() right after all the grants have been >>>>> provided. yes, this requires a 1 line hack to core. >>>>> >>>>> On Tue, Mar 31, 2009 at 11:59 AM, Llu?s wrote: >>>>> > I think this would be great; but it wouldn't solve my problem neither. >>>>> > How can I "remove" a realm from $grants[$realm] >>>>> > >>>>> > I tried to "overwrite" it, but it uses arrays and merge them, so it is >>>>> > impossible. >>>> >>>> -- >>>> Larry Garfield >>>> larry at garfieldtech.com >>>> >>> >>> >>> >>> -- >>> Ken Rickard >>> agentrickard at gmail.com >>> http://ken.therickards.com >>> >> >> >> >> -- >> *La vida ?s com una taronja, que esperes a exprimir-la? >> *Si creus que l'educaci? ?s cara, prova la ignor?ncia. >> *La vida ?s com una moneda, la pots gastar en el que vulguis per? >> nom?s una vegada. >> *Abans d'imprimir aquest missatge, pensa en el medi ambient. >> > > > > -- > *La vida ?s com una taronja, que esperes a exprimir-la? > *Si creus que l'educaci? ?s cara, prova la ignor?ncia. > *La vida ?s com una moneda, la pots gastar en el que vulguis per? > nom?s una vegada. > *Abans d'imprimir aquest missatge, pensa en el medi ambient. > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com From josh at chapterthree.com Thu Apr 2 23:33:02 2009 From: josh at chapterthree.com (Josh Koenig) Date: Thu, 2 Apr 2009 16:33:02 -0700 Subject: [development] Menu Tree Access Control? Message-ID: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> Hey all, I'm about to launch into yet another custom module build, and I wanted to see if I'm missing the obvious and this thing already exists (or has been somewhat built). The use case is to allow access to nodes (node_access) based on their placement within a drupal menu tree. Seems obvious, but keyword searching through available modules didn't turn up anything that seemed to match. I did locate the "Menu Subtree" module which seems to provide some complimentary functionality in terms of restricting the areas of a menu tree into which new nodes can be placed: http://drupal.org/project/menu_stp For access, it points to fago's menu_per_role module, but this is about access to menu links, not node permissions. In the other node-access modules, I didn't find one that seeks to allow/deny access based on menu position. So that's what I'll begin working on. Implementation seems fairly straightforward based on hook_node_access_records() and hook_node_grants(). Assuming I'm right, the next fun thing would be looking at integrating this with menutrails.module so it can work for broader classes of nodes and not just those placed directly into the menu tree. Please let me know if I'm missing something obvious. :) cheers -josh -- -------------------- Josh Koenig, Partner & CTO http://www.chapterthree.com From weitzman at tejasa.com Fri Apr 3 00:34:07 2009 From: weitzman at tejasa.com (Moshe Weitzman) Date: Thu, 2 Apr 2009 20:34:07 -0400 Subject: [development] Menu Tree Access Control? In-Reply-To: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> Message-ID: <6117a7500904021734r30f5a99fyddedadc75cc5ec78@mail.gmail.com> maybe the d6 version of book_access has some tips. On Thu, Apr 2, 2009 at 7:33 PM, Josh Koenig wrote: > Hey all, > > I'm about to launch into yet another custom module build, and I wanted > to see if I'm missing the obvious and this thing already exists (or > has been somewhat built). > > The use case is to allow access to nodes (node_access) based on their > placement within a drupal menu tree. Seems obvious, but keyword > searching through available modules didn't turn up anything that > seemed to match. I did locate the "Menu Subtree" module which seems to > provide some complimentary functionality in terms of restricting the > areas of a menu tree into which new nodes can be placed: > > http://drupal.org/project/menu_stp > > For access, it points to fago's menu_per_role module, but this is > about access to menu links, not node permissions. In the other > node-access modules, I didn't find one that seeks to allow/deny access > based on menu position. So that's what I'll begin working on. > > Implementation seems fairly straightforward based on > hook_node_access_records() and hook_node_grants(). Assuming I'm right, > the next fun thing would be looking at integrating this with > menutrails.module so it can work for broader classes of nodes and not > just those placed directly into the menu tree. > > Please let me know if I'm missing something obvious. :) > > cheers > -josh > > -- > -------------------- > Josh Koenig, Partner & CTO > http://www.chapterthree.com > From drupal at ryancross.com Fri Apr 3 00:42:43 2009 From: drupal at ryancross.com (Ryan Cross) Date: Fri, 3 Apr 2009 11:42:43 +1100 Subject: [development] Menu Tree Access Control? In-Reply-To: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> Message-ID: <4e983be00904021742w4a37e5cdn7833c5bb88166783@mail.gmail.com> Hey Josh, I've had a similar need, but I was able to make taxonomy_access work for me. Not sure what your specs are, but it might be a reasonable thing to consider before building a custom module. -Ryan On Fri, Apr 3, 2009 at 10:33 AM, Josh Koenig wrote: > Hey all, > > I'm about to launch into yet another custom module build, and I wanted > to see if I'm missing the obvious and this thing already exists (or > has been somewhat built). > > The use case is to allow access to nodes (node_access) based on their > placement within a drupal menu tree. Seems obvious, but keyword > searching through available modules didn't turn up anything that > seemed to match. I did locate the "Menu Subtree" module which seems to > provide some complimentary functionality in terms of restricting the > areas of a menu tree into which new nodes can be placed: > > http://drupal.org/project/menu_stp > > For access, it points to fago's menu_per_role module, but this is > about access to menu links, not node permissions. In the other > node-access modules, I didn't find one that seeks to allow/deny access > based on menu position. So that's what I'll begin working on. > > Implementation seems fairly straightforward based on > hook_node_access_records() and hook_node_grants(). Assuming I'm right, > the next fun thing would be looking at integrating this with > menutrails.module so it can work for broader classes of nodes and not > just those placed directly into the menu tree. > > Please let me know if I'm missing something obvious. :) > > cheers > -josh > > -- > -------------------- > Josh Koenig, Partner & CTO > http://www.chapterthree.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at funnymonkey.com Fri Apr 3 00:56:49 2009 From: bill at funnymonkey.com (Bill Fitzgerald) Date: Thu, 02 Apr 2009 17:56:49 -0700 Subject: [development] Menu Tree Access Control? In-Reply-To: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> Message-ID: <49D55ED1.10302@funnymonkey.com> This thread might be relevant: http://groups.drupal.org/node/16134 Josh Koenig wrote: > Hey all, > > I'm about to launch into yet another custom module build, and I wanted > to see if I'm missing the obvious and this thing already exists (or > has been somewhat built). > > The use case is to allow access to nodes (node_access) based on their > placement within a drupal menu tree. Seems obvious, but keyword > searching through available modules didn't turn up anything that > seemed to match. I did locate the "Menu Subtree" module which seems to > provide some complimentary functionality in terms of restricting the > areas of a menu tree into which new nodes can be placed: > > http://drupal.org/project/menu_stp > > For access, it points to fago's menu_per_role module, but this is > about access to menu links, not node permissions. In the other > node-access modules, I didn't find one that seeks to allow/deny access > based on menu position. So that's what I'll begin working on. > > Implementation seems fairly straightforward based on > hook_node_access_records() and hook_node_grants(). Assuming I'm right, > the next fun thing would be looking at integrating this with > menutrails.module so it can work for broader classes of nodes and not > just those placed directly into the menu tree. > > Please let me know if I'm missing something obvious. :) > > cheers > -josh > > -- Bill Fitzgerald http://funnymonkey.com FunnyMonkey -- Click. Connect. Learn. ph. 503 897 7160 From josh at chapterthree.com Fri Apr 3 00:56:54 2009 From: josh at chapterthree.com (Josh Koenig) Date: Thu, 2 Apr 2009 17:56:54 -0700 Subject: [development] Menu Tree Access Control? In-Reply-To: <4e983be00904021742w4a37e5cdn7833c5bb88166783@mail.gmail.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> <4e983be00904021742w4a37e5cdn7833c5bb88166783@mail.gmail.com> Message-ID: <223073f60904021756i407817e5t3788a97db6b59a62@mail.gmail.com> Thanks for the tips, Moshe and Ryan! First of all, I should have said before I definitely look to release this as a compliment to menutrails module, so the development would definitely see the light of day. There's some chance I could use Taxonomy Access Control (or even TAC lite) for the use-case, but I think there's some value in trying to allow this functionality based on the menu tree. It's very intuitive for non-technical content managers to manage menu placement and to dole out access control based on these realms. If I can figure out how to tie it together w/menutrails in a smart way, it could be quite powerful and useful. Overall, this puts me back into the place of wishing for a more featureful, usable outlining system that combines much of book and menu modules. Maybe a summer project for D7. ;) cheers -josh On Thu, Apr 2, 2009 at 5:42 PM, Ryan Cross wrote: > Hey Josh, > I've had a similar need, but I was able to make taxonomy_access work for me. > Not sure what your specs are, but it might be a reasonable thing to consider > before building a custom module. > -Ryan > > On Fri, Apr 3, 2009 at 10:33 AM, Josh Koenig wrote: >> >> Hey all, >> >> I'm about to launch into yet another custom module build, and I wanted >> to see if I'm missing the obvious and this thing already exists (or >> has been somewhat built). >> >> The use case is to allow access to nodes (node_access) based on their >> placement within a drupal menu tree. Seems obvious, but keyword >> searching through available modules didn't turn up anything that >> seemed to match. I did locate the "Menu Subtree" module which seems to >> provide some complimentary functionality in terms of restricting the >> areas of a menu tree into which new nodes can be placed: >> >> http://drupal.org/project/menu_stp >> >> For access, it points to fago's menu_per_role module, but this is >> about access to menu links, not node permissions. In the other >> node-access modules, I didn't find one that seeks to allow/deny access >> based on menu position. So that's what I'll begin working on. >> >> Implementation seems fairly straightforward based on >> hook_node_access_records() and hook_node_grants(). Assuming I'm right, >> the next fun thing would be looking at integrating this with >> menutrails.module so it can work for broader classes of nodes and not >> just those placed directly into the menu tree. >> >> Please let me know if I'm missing something obvious. :) >> >> cheers >> -josh >> >> -- >> -------------------- >> Josh Koenig, Partner & CTO >> http://www.chapterthree.com > > -- -------------------- Josh Koenig, Partner & CTO http://www.chapterthree.com From mike at mikeyp.net Fri Apr 3 01:32:48 2009 From: mike at mikeyp.net (Michael Prasuhn) Date: Thu, 2 Apr 2009 18:32:48 -0700 Subject: [development] Menu Tree Access Control? In-Reply-To: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> Message-ID: <4CE37D3F-D19A-447B-AB35-9D6920166503@mikeyp.net> I'm not 100% sure I'm following your needs here, but this module may be along the same lines: http://drupal.org/project/menu_access -Mike On Apr 2, 2009, at 4:33 PM, Josh Koenig wrote: > Hey all, > > I'm about to launch into yet another custom module build, and I wanted > to see if I'm missing the obvious and this thing already exists (or > has been somewhat built). > > The use case is to allow access to nodes (node_access) based on their > placement within a drupal menu tree. Seems obvious, but keyword > searching through available modules didn't turn up anything that > seemed to match. I did locate the "Menu Subtree" module which seems to > provide some complimentary functionality in terms of restricting the > areas of a menu tree into which new nodes can be placed: > > http://drupal.org/project/menu_stp > > For access, it points to fago's menu_per_role module, but this is > about access to menu links, not node permissions. In the other > node-access modules, I didn't find one that seeks to allow/deny access > based on menu position. So that's what I'll begin working on. > > Implementation seems fairly straightforward based on > hook_node_access_records() and hook_node_grants(). Assuming I'm right, > the next fun thing would be looking at integrating this with > menutrails.module so it can work for broader classes of nodes and not > just those placed directly into the menu tree. > > Please let me know if I'm missing something obvious. :) > > cheers > -josh > > -- > -------------------- > Josh Koenig, Partner & CTO > http://www.chapterthree.com __________________ Michael Prasuhn 503.488.5433 office 714.356.0168 cell 503.661.7574 home mike at mikeyp.net http://mikeyp.net From andrewberry at sentex.net Fri Apr 3 04:11:51 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Fri, 3 Apr 2009 00:11:51 -0400 Subject: [development] Menu Tree Access Control? In-Reply-To: <223073f60904021756i407817e5t3788a97db6b59a62@mail.gmail.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> <4e983be00904021742w4a37e5cdn7833c5bb88166783@mail.gmail.com> <223073f60904021756i407817e5t3788a97db6b59a62@mail.gmail.com> Message-ID: <6151C3DD-6B77-4FE9-AAFA-943873A9D8AA@sentex.net> On 2-Apr-09, at 8:56 PM, Josh Koenig wrote: > Overall, this puts me back into the place of wishing for a more > featureful, usable outlining system that combines much of book and > menu modules. Maybe a summer project for D7. ;) I'm working on a site nearing completion which uses Books and book_access for a case similar to yours, though without quite as much granularity. We've been quite happy with book_access. If you pursue a more fine-tuned system for permissions within a book outline, let's get a group going and see what we can come up with, as I think it's something my clients would be interested in. > I'm not 100% sure I'm following your needs here, but this module may > be along the same lines: > > http://drupal.org/project/menu_access It looks like the "menu_access" suite of modules has quite a bit of duplication with other modules, especially nodeaccess (note the lack of an underscore). I'm kind of confused by the description, as it seems like you can provide per-menu-item permissions, though those should usually be calculated on a per-path basis automatically. Hopefully any useful features can be merged in to other more popular modules. --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available URL: From larry at garfieldtech.com Fri Apr 3 06:27:27 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Fri, 3 Apr 2009 01:27:27 -0500 Subject: [development] Menu Tree Access Control? In-Reply-To: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> Message-ID: <200904030127.27262.larry@garfieldtech.com> Do you need view access control or edit access control? We (Palantir) actually just developed an edit access control module based on menu position for a client. We plan to release it as soon as the site launches, which hopefully shouldn't be too long. What's your time frame? On Thursday 02 April 2009 6:33:02 pm Josh Koenig wrote: > Hey all, > > I'm about to launch into yet another custom module build, and I wanted > to see if I'm missing the obvious and this thing already exists (or > has been somewhat built). > > The use case is to allow access to nodes (node_access) based on their > placement within a drupal menu tree. Seems obvious, but keyword > searching through available modules didn't turn up anything that > seemed to match. I did locate the "Menu Subtree" module which seems to > provide some complimentary functionality in terms of restricting the > areas of a menu tree into which new nodes can be placed: > > http://drupal.org/project/menu_stp > > For access, it points to fago's menu_per_role module, but this is > about access to menu links, not node permissions. In the other > node-access modules, I didn't find one that seeks to allow/deny access > based on menu position. So that's what I'll begin working on. > > Implementation seems fairly straightforward based on > hook_node_access_records() and hook_node_grants(). Assuming I'm right, > the next fun thing would be looking at integrating this with > menutrails.module so it can work for broader classes of nodes and not > just those placed directly into the menu tree. > > Please let me know if I'm missing something obvious. :) > > cheers > -josh -- Larry Garfield larry at garfieldtech.com From bill at funnymonkey.com Fri Apr 3 14:46:48 2009 From: bill at funnymonkey.com (Bill Fitzgerald) Date: Fri, 03 Apr 2009 07:46:48 -0700 Subject: [development] Menu Tree Access Control? In-Reply-To: <200904030127.27262.larry@garfieldtech.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> <200904030127.27262.larry@garfieldtech.com> Message-ID: <49D62158.8030304@funnymonkey.com> We (FunnyMonkey) released the book manager, which gives individuals the right to create book that only they can add pages to. The nodes within those inividual books can then be governed by any of the usual suspects wrt access control. So, a menu admin could create the outline, with people being granted access to edit/view nodes as needed. What's missing, of course, is access rights that cascade down the hierarchy. But the Book Manager is here: http://drupal.org/project/book_manager Cheers, Bill Larry Garfield wrote: > Do you need view access control or edit access control? We (Palantir) > actually just developed an edit access control module based on menu position > for a client. We plan to release it as soon as the site launches, which > hopefully shouldn't be too long. What's your time frame? > > On Thursday 02 April 2009 6:33:02 pm Josh Koenig wrote: > >> Hey all, >> >> I'm about to launch into yet another custom module build, and I wanted >> to see if I'm missing the obvious and this thing already exists (or >> has been somewhat built). >> >> The use case is to allow access to nodes (node_access) based on their >> placement within a drupal menu tree. Seems obvious, but keyword >> searching through available modules didn't turn up anything that >> seemed to match. I did locate the "Menu Subtree" module which seems to >> provide some complimentary functionality in terms of restricting the >> areas of a menu tree into which new nodes can be placed: >> >> http://drupal.org/project/menu_stp >> >> For access, it points to fago's menu_per_role module, but this is >> about access to menu links, not node permissions. In the other >> node-access modules, I didn't find one that seeks to allow/deny access >> based on menu position. So that's what I'll begin working on. >> >> Implementation seems fairly straightforward based on >> hook_node_access_records() and hook_node_grants(). Assuming I'm right, >> the next fun thing would be looking at integrating this with >> menutrails.module so it can work for broader classes of nodes and not >> just those placed directly into the menu tree. >> >> Please let me know if I'm missing something obvious. :) >> >> cheers >> -josh >> > > -- Bill Fitzgerald http://funnymonkey.com FunnyMonkey -- Click. Connect. Learn. ph. 503 897 7160 From andrewberry at sentex.net Fri Apr 3 16:51:52 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Fri, 3 Apr 2009 12:51:52 -0400 Subject: [development] Menu Tree Access Control? In-Reply-To: <49D62158.8030304@funnymonkey.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> <200904030127.27262.larry@garfieldtech.com> <49D62158.8030304@funnymonkey.com> Message-ID: I've created a g.d.o page to document this. http://groups.drupal.org/node/20913 Larry, it'd be great if you could add your module when you release it, especially any rationale as to why you didn't look at expanding the other modules out there. --Andrew On 3-Apr-09, at 10:46 AM, Bill Fitzgerald wrote: > We (FunnyMonkey) released the book manager, which gives individuals > the right to create book that only they can add pages to. > > The nodes within those inividual books can then be governed by any > of the usual suspects wrt access control. > > So, a menu admin could create the outline, with people being granted > access to edit/view nodes as needed. > > What's missing, of course, is access rights that cascade down the > hierarchy. > > But the Book Manager is here: http://drupal.org/project/book_manager > > Cheers, > > Bill > > Larry Garfield wrote: >> Do you need view access control or edit access control? We >> (Palantir) actually just developed an edit access control module >> based on menu position for a client. We plan to release it as soon >> as the site launches, which hopefully shouldn't be too long. >> What's your time frame? >> On Thursday 02 April 2009 6:33:02 pm Josh Koenig wrote: >> >>> Hey all, >>> >>> I'm about to launch into yet another custom module build, and I >>> wanted >>> to see if I'm missing the obvious and this thing already exists (or >>> has been somewhat built). >>> >>> The use case is to allow access to nodes (node_access) based on >>> their >>> placement within a drupal menu tree. Seems obvious, but keyword >>> searching through available modules didn't turn up anything that >>> seemed to match. I did locate the "Menu Subtree" module which >>> seems to >>> provide some complimentary functionality in terms of restricting the >>> areas of a menu tree into which new nodes can be placed: >>> >>> http://drupal.org/project/menu_stp >>> >>> For access, it points to fago's menu_per_role module, but this is >>> about access to menu links, not node permissions. In the other >>> node-access modules, I didn't find one that seeks to allow/deny >>> access >>> based on menu position. So that's what I'll begin working on. >>> >>> Implementation seems fairly straightforward based on >>> hook_node_access_records() and hook_node_grants(). Assuming I'm >>> right, >>> the next fun thing would be looking at integrating this with >>> menutrails.module so it can work for broader classes of nodes and >>> not >>> just those placed directly into the menu tree. >>> >>> Please let me know if I'm missing something obvious. :) >>> >>> cheers >>> -josh >>> >> >> > > > -- > > Bill Fitzgerald > http://funnymonkey.com > FunnyMonkey -- Click. Connect. Learn. > ph. 503 897 7160 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available URL: From mathews.kyle at gmail.com Fri Apr 3 16:56:34 2009 From: mathews.kyle at gmail.com (Kyle Mathews) Date: Fri, 3 Apr 2009 10:56:34 -0600 Subject: [development] Menu Tree Access Control? In-Reply-To: References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> <200904030127.27262.larry@garfieldtech.com> <49D62158.8030304@funnymonkey.com> Message-ID: You might also want to look at Monsters Menu which does some sophisticated stuff: http://groups.drupal.org/node/10231 Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Fri, Apr 3, 2009 at 10:51 AM, Andrew Berry wrote: > I've created a g.d.o page to document this. > > http://groups.drupal.org/node/20913 > > Larry, it'd be great if you could add your module when you release it, > especially any rationale as to why you didn't look at expanding the other > modules out there. > > --Andrew > > > On 3-Apr-09, at 10:46 AM, Bill Fitzgerald wrote: > > We (FunnyMonkey) released the book manager, which gives individuals the >> right to create book that only they can add pages to. >> >> The nodes within those inividual books can then be governed by any of the >> usual suspects wrt access control. >> >> So, a menu admin could create the outline, with people being granted >> access to edit/view nodes as needed. >> >> What's missing, of course, is access rights that cascade down the >> hierarchy. >> >> But the Book Manager is here: http://drupal.org/project/book_manager >> >> Cheers, >> >> Bill >> >> Larry Garfield wrote: >> >>> Do you need view access control or edit access control? We (Palantir) >>> actually just developed an edit access control module based on menu position >>> for a client. We plan to release it as soon as the site launches, which >>> hopefully shouldn't be too long. What's your time frame? >>> On Thursday 02 April 2009 6:33:02 pm Josh Koenig wrote: >>> >>> Hey all, >>>> >>>> I'm about to launch into yet another custom module build, and I wanted >>>> to see if I'm missing the obvious and this thing already exists (or >>>> has been somewhat built). >>>> >>>> The use case is to allow access to nodes (node_access) based on their >>>> placement within a drupal menu tree. Seems obvious, but keyword >>>> searching through available modules didn't turn up anything that >>>> seemed to match. I did locate the "Menu Subtree" module which seems to >>>> provide some complimentary functionality in terms of restricting the >>>> areas of a menu tree into which new nodes can be placed: >>>> >>>> http://drupal.org/project/menu_stp >>>> >>>> For access, it points to fago's menu_per_role module, but this is >>>> about access to menu links, not node permissions. In the other >>>> node-access modules, I didn't find one that seeks to allow/deny access >>>> based on menu position. So that's what I'll begin working on. >>>> >>>> Implementation seems fairly straightforward based on >>>> hook_node_access_records() and hook_node_grants(). Assuming I'm right, >>>> the next fun thing would be looking at integrating this with >>>> menutrails.module so it can work for broader classes of nodes and not >>>> just those placed directly into the menu tree. >>>> >>>> Please let me know if I'm missing something obvious. :) >>>> >>>> cheers >>>> -josh >>>> >>>> >>> >>> >> >> -- >> >> Bill Fitzgerald >> http://funnymonkey.com >> FunnyMonkey -- Click. Connect. Learn. >> ph. 503 897 7160 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drewish at katherinehouse.com Fri Apr 3 18:36:35 2009 From: drewish at katherinehouse.com (andrew morton) Date: Fri, 3 Apr 2009 11:36:35 -0700 Subject: [development] Menu Tree Access Control? In-Reply-To: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> References: <223073f60904021633h2a5cc80cv5260ed48c9dc5efc@mail.gmail.com> Message-ID: Yet another suggestion for modules you might want to review: http://drupal.org/project/admin_access It's more of an integrated approach to access controls. A quick snip from the project page: "Special care was taken to ensure the usability of permission management was consistent across all sections of the system (nodes, menus, menu items). Also each security module uses a cascading security scheme to allow global security and the option to override or define exceptions to the security model for individual items." andrew On Thu, Apr 2, 2009 at 4:33 PM, Josh Koenig wrote: > Hey all, > > I'm about to launch into yet another custom module build, and I wanted > to see if I'm missing the obvious and this thing already exists (or > has been somewhat built). > > The use case is to allow access to nodes (node_access) based on their > placement within a drupal menu tree. Seems obvious, but keyword > searching through available modules didn't turn up anything that > seemed to match. I did locate the "Menu Subtree" module which seems to > provide some complimentary functionality in terms of restricting the > areas of a menu tree into which new nodes can be placed: > > http://drupal.org/project/menu_stp > > For access, it points to fago's menu_per_role module, but this is > about access to menu links, not node permissions. In the other > node-access modules, I didn't find one that seeks to allow/deny access > based on menu position. So that's what I'll begin working on. > > Implementation seems fairly straightforward based on > hook_node_access_records() and hook_node_grants(). Assuming I'm right, > the next fun thing would be looking at integrating this with > menutrails.module so it can work for broader classes of nodes and not > just those placed directly into the menu tree. > > Please let me know if I'm missing something obvious. :) > > cheers > -josh > > -- > -------------------- > Josh Koenig, Partner & CTO > http://www.chapterthree.com > From lyricnz at gmail.com Sat Apr 4 09:42:54 2009 From: lyricnz at gmail.com (Simon Roberts) Date: Sat, 4 Apr 2009 20:42:54 +1100 Subject: [development] Menu Tree Access Control? Message-ID: <867cfa9c0904040242w462967a2s2f82fd742cb78d8d@mail.gmail.com> > Date: Fri, 3 Apr 2009 00:11:51 -0400 > From: Andrew Berry > Subject: Re: [development] Menu Tree Access Control? > I'm working on a site nearing completion which uses Books and > book_access for a case similar to yours, though without quite as much > granularity. We've been quite happy with book_access. If you pursue a > more fine-tuned system for permissions within a book outline, let's > get a group going and see what we can come up with, as I think it's > something my clients would be interested in. I've also been doing fine-grained book-page access, per-user and per-role, and ended up coding more than I would have liked. (Writing ACLs on the fly, and twiddling with menu-entries during theming - uugh). No idea if this is useful, but I saw this new project pop up a few days ago http://drupal.org/project/book_page_access From earnie at users.sourceforge.net Sat Apr 4 15:59:34 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sat, 04 Apr 2009 15:59:34 +0000 Subject: [development] Menu Tree Access Control? In-Reply-To: <867cfa9c0904040242w462967a2s2f82fd742cb78d8d@mail.gmail.com> References: <867cfa9c0904040242w462967a2s2f82fd742cb78d8d@mail.gmail.com> Message-ID: <20090404155934.17178cn761dmcve0@mail.siebunlimited.com> Quoting Simon Roberts : > I've also been doing fine-grained book-page access, per-user and > per-role, and ended up coding more than I would have liked. (Writing > ACLs on the fly, and twiddling with menu-entries during theming - > uugh). > > No idea if this is useful, but I saw this new project pop up a few days ago > > http://drupal.org/project/book_page_access > And then there is http://drupal.org/project/acl which give you an API. The page lists other modules using it. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From agentrickard at gmail.com Sun Apr 5 22:00:50 2009 From: agentrickard at gmail.com (Ken Rickard) Date: Sun, 5 Apr 2009 18:00:50 -0400 Subject: [development] Menu Tree Access Control? In-Reply-To: <20090404155934.17178cn761dmcve0@mail.siebunlimited.com> References: <867cfa9c0904040242w462967a2s2f82fd742cb78d8d@mail.gmail.com> <20090404155934.17178cn761dmcve0@mail.siebunlimited.com> Message-ID: <25b45da00904051500k4057f05ct350e01b603ad25c4@mail.gmail.com> I am the Palantir developer in question and have two modules just about to release that are relevant here. Release should be by end of month, if all goes well. 1) Menu Node API The menu/node API module keeps track of menu-node relationships for you, so that you can run JOINs from the {node} table to the {menu_links} table through the new {menu_node} table. This is a glue module that will allow for (among other things): -- Menu-based Views -- Node Access modules based on menu hierarchy, 2) Menu (Needs Name) The second module was called menu_access, and someone just took the namespace on d.o. It leverages the Menu Node API and rewrites node/%/edit using hook_menu_alter(). It then lets an administrator define menu 'sections' -- elements of the tree hierarchy that are used as ACLs. Individual users can then be assigned as "section editors". A section editor has cascading rights down the menu hierarchy. This module is _deliberately_ not a Node Access module, since I have not yet figured out the necessary overhead for which menu parents would need to be stored in the {node_access} table as GIDs. And since the client did not require View or Delete access control, Edit control was sufficient. I hope that any delay in releasing these won't force anyone to write duplicate code. Larry and I will convene next week and see if we can get a firm launch date. - Ken Rickard agentrickard On Sat, Apr 4, 2009 at 11:59 AM, Earnie Boyd wrote: > Quoting Simon Roberts : > >> I've also been doing fine-grained book-page access, per-user and >> per-role, and ended up coding more than I would have liked. ?(Writing >> ACLs on the fly, and twiddling with menu-entries during theming - >> uugh). >> >> No idea if this is useful, but I saw this new project pop up a few days >> ago >> >> http://drupal.org/project/book_page_access >> > > And then there is http://drupal.org/project/acl which give you an API. ?The > page lists other modules using it. > > -- > Earnie > -- http://r-feed.com/ ? ? ? ? ? -- http://for-my-kids.com/ > -- http://www.4offer.biz/ ? ? ? -- http://give-me-an-offer.com/ > > > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com From agentrickard at gmail.com Sun Apr 5 22:03:44 2009 From: agentrickard at gmail.com (Ken Rickard) Date: Sun, 5 Apr 2009 18:03:44 -0400 Subject: [development] Menu Tree Access Control? In-Reply-To: <25b45da00904051500k4057f05ct350e01b603ad25c4@mail.gmail.com> References: <867cfa9c0904040242w462967a2s2f82fd742cb78d8d@mail.gmail.com> <20090404155934.17178cn761dmcve0@mail.siebunlimited.com> <25b45da00904051500k4057f05ct350e01b603ad25c4@mail.gmail.com> Message-ID: <25b45da00904051503n73947cb1t1e406adb31e528b4@mail.gmail.com> With reference to http://groups.drupal.org/node/20913. Reviewing the code, the recently released Menu Access module is NOT an access control module in the Drupal sense. It is designed to restrict the editing of menu items. That is it. It does not cascade any ACL functions to nodes or other content. - Ken On Sun, Apr 5, 2009 at 6:00 PM, Ken Rickard wrote: > I am the Palantir developer in question and have two modules just > about to release that are relevant here. > > Release should be by end of month, if all goes well. > > 1) Menu Node API > The menu/node API module keeps track of menu-node relationships for > you, so that you can run JOINs from the {node} table to the > {menu_links} table through the new {menu_node} table. > > This is a glue module that will allow for (among other things): > > -- Menu-based Views > -- Node Access modules based on menu hierarchy, > > 2) Menu (Needs Name) > The second module was called menu_access, and someone just took the > namespace on d.o. It leverages the Menu Node API and rewrites > node/%/edit using hook_menu_alter(). It then lets an administrator > define menu 'sections' -- elements of the tree hierarchy that are used > as ACLs. > > Individual users can then be assigned as "section editors". ?A section > editor has cascading rights down the menu hierarchy. > > This module is _deliberately_ not a Node Access module, since I have > not yet figured out the necessary overhead for which menu parents > would need to be stored in the {node_access} table as GIDs. ?And since > the client did not require View or Delete access control, Edit control > was sufficient. > > I hope that any delay in releasing these won't force anyone to write > duplicate code. ?Larry and I will convene next week and see if we can > get a firm launch date. > > - Ken Rickard > agentrickard > > > > On Sat, Apr 4, 2009 at 11:59 AM, Earnie Boyd > wrote: >> Quoting Simon Roberts : >> >>> I've also been doing fine-grained book-page access, per-user and >>> per-role, and ended up coding more than I would have liked. ?(Writing >>> ACLs on the fly, and twiddling with menu-entries during theming - >>> uugh). >>> >>> No idea if this is useful, but I saw this new project pop up a few days >>> ago >>> >>> http://drupal.org/project/book_page_access >>> >> >> And then there is http://drupal.org/project/acl which give you an API. ?The >> page lists other modules using it. >> >> -- >> Earnie >> -- http://r-feed.com/ ? ? ? ? ? -- http://for-my-kids.com/ >> -- http://www.4offer.biz/ ? ? ? -- http://give-me-an-offer.com/ >> >> >> > > > > -- > Ken Rickard > agentrickard at gmail.com > http://ken.therickards.com > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com From josh at chapterthree.com Wed Apr 8 02:05:45 2009 From: josh at chapterthree.com (Josh Koenig) Date: Tue, 7 Apr 2009 19:05:45 -0700 Subject: [development] Menu Tree Access Control? In-Reply-To: <25b45da00904051500k4057f05ct350e01b603ad25c4@mail.gmail.com> References: <867cfa9c0904040242w462967a2s2f82fd742cb78d8d@mail.gmail.com> <20090404155934.17178cn761dmcve0@mail.siebunlimited.com> <25b45da00904051500k4057f05ct350e01b603ad25c4@mail.gmail.com> Message-ID: <223073f60904071905m279a7d43r78d24773795ff0cd@mail.gmail.com> All: Thanks so much for the links. The group thread that webchick started is precisely the use-case that I'm looking for. Ken/Larry, This sounds like exactly the path I was on (though I was working on one module rather than splitting it into two). My timeframe is somewhat tight: need to have something beta-ready by end of month, which means I need to prototype now. However I have availability to put cycles in to help, and would like to see this problem get solved "right" for the long haul. Is there any chance of getting a CVS checkin of the code you're working -- no official release -- in the short-term? I can help test, submit patches, etc. cheers -josh On Sun, Apr 5, 2009 at 3:00 PM, Ken Rickard wrote: > I am the Palantir developer in question and have two modules just > about to release that are relevant here. > > Release should be by end of month, if all goes well. > > 1) Menu Node API > The menu/node API module keeps track of menu-node relationships for > you, so that you can run JOINs from the {node} table to the > {menu_links} table through the new {menu_node} table. > > This is a glue module that will allow for (among other things): > > -- Menu-based Views > -- Node Access modules based on menu hierarchy, > > 2) Menu (Needs Name) > The second module was called menu_access, and someone just took the > namespace on d.o. It leverages the Menu Node API and rewrites > node/%/edit using hook_menu_alter(). It then lets an administrator > define menu 'sections' -- elements of the tree hierarchy that are used > as ACLs. > > Individual users can then be assigned as "section editors". ?A section > editor has cascading rights down the menu hierarchy. > > This module is _deliberately_ not a Node Access module, since I have > not yet figured out the necessary overhead for which menu parents > would need to be stored in the {node_access} table as GIDs. ?And since > the client did not require View or Delete access control, Edit control > was sufficient. > > I hope that any delay in releasing these won't force anyone to write > duplicate code. ?Larry and I will convene next week and see if we can > get a firm launch date. > > - Ken Rickard > agentrickard > > > > On Sat, Apr 4, 2009 at 11:59 AM, Earnie Boyd > wrote: >> Quoting Simon Roberts : >> >>> I've also been doing fine-grained book-page access, per-user and >>> per-role, and ended up coding more than I would have liked. ?(Writing >>> ACLs on the fly, and twiddling with menu-entries during theming - >>> uugh). >>> >>> No idea if this is useful, but I saw this new project pop up a few days >>> ago >>> >>> http://drupal.org/project/book_page_access >>> >> >> And then there is http://drupal.org/project/acl which give you an API. ?The >> page lists other modules using it. >> >> -- >> Earnie >> -- http://r-feed.com/ ? ? ? ? ? -- http://for-my-kids.com/ >> -- http://www.4offer.biz/ ? ? ? -- http://give-me-an-offer.com/ >> >> >> > > > > -- > Ken Rickard > agentrickard at gmail.com > http://ken.therickards.com > -- -------------------- Josh Koenig, Partner & CTO http://www.chapterthree.com From r.crowther at zen.co.uk Thu Apr 9 08:39:22 2009 From: r.crowther at zen.co.uk (robert crowther) Date: Thu, 09 Apr 2009 09:39:22 +0100 Subject: [development] The router and links tables split - what caused it? Message-ID: <1239266362.6399.25.camel@robert-desktop> Yes, I know they split (Drupal 6, was it?). I seem to remember reading somewhere in code, or near code, documentation that this was not simply for clarity or encapsulation, but performance. If I recall the comment alright, does anyone know what that performance issue was? Were people running, say, college sites, or auction sites, and finding they were bloating the links tables? A more general question - what was the scale of the bloating that caused a database to slow down? Answers to these questions may have a direct impact on the development of my module, http://drupal.org/project/taxonomy_treemenu In response to user discussion I'm considering a complete re-write of the links code. Rob From websweetweb at gmail.com Thu Apr 9 11:41:47 2009 From: websweetweb at gmail.com (Raja Sekharan) Date: Thu, 09 Apr 2009 17:11:47 +0530 Subject: [development] Using multiple databases for drupal? Message-ID: <1239277307.10107.1.camel@Xecutionr> Hi, Is it possible to use multiple databases to power a drupal site without editing the drupal core? Raj From fgm at osinet.fr Thu Apr 9 11:46:41 2009 From: fgm at osinet.fr (FGM) Date: Thu, 9 Apr 2009 13:46:41 +0200 Subject: [development] Using multiple databases for drupal? References: <1239277307.10107.1.camel@Xecutionr> Message-ID: Yes, see http://api.drupal.org/api/function/db_set_active/6 ----- Original Message ----- From: "Raja Sekharan" To: Sent: Thursday, April 09, 2009 1:41 PM Subject: [development] Using multiple databases for drupal? Hi, Is it possible to use multiple databases to power a drupal site without editing the drupal core? Raj From earnie at users.sourceforge.net Thu Apr 9 14:27:19 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Thu, 09 Apr 2009 14:27:19 +0000 Subject: [development] Using multiple databases for drupal? In-Reply-To: References: <1239277307.10107.1.camel@Xecutionr> Message-ID: <20090409142719.172357gtkfp42cws@mail.siebunlimited.com> Quoting FGM : > Yes, see http://api.drupal.org/api/function/db_set_active/6 > > ----- Original Message ----- From: "Raja Sekharan" > To: > Sent: Thursday, April 09, 2009 1:41 PM > Subject: [development] Using multiple databases for drupal? > > > > Hi, > > Is it possible to use multiple databases to power a drupal site without > editing the drupal core? Raj > > But it has to be the same DB vendor (D7 will fix that). -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From fgm at osinet.fr Thu Apr 9 14:32:35 2009 From: fgm at osinet.fr (FGM) Date: Thu, 9 Apr 2009 16:32:35 +0200 Subject: [development] Using multiple databases for drupal? References: <1239277307.10107.1.camel@Xecutionr> <20090409142719.172357gtkfp42cws@mail.siebunlimited.com> Message-ID: Or you can just use the native DB API in your code, bypassing the Drupal DB API for the non-Drupal bits, which is just what I did to integrate Sage on Oracle 8 with Drupal on top on PDO OCI. ----- Original Message ----- From: "Earnie Boyd" To: Sent: Thursday, April 09, 2009 4:27 PM Subject: Re: [development] Using multiple databases for drupal? > > Quoting FGM : > >> Yes, see http://api.drupal.org/api/function/db_set_active/6 >> >> ----- Original Message ----- From: "Raja Sekharan" >> >> To: >> Sent: Thursday, April 09, 2009 1:41 PM >> Subject: [development] Using multiple databases for drupal? >> >> >> >> Hi, >> >> Is it possible to use multiple databases to power a drupal site without >> editing the drupal core? Raj >> >> > > But it has to be the same DB vendor (D7 will fix that). > > -- > Earnie > -- http://r-feed.com/ -- http://for-my-kids.com/ > -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ > > > From allister.beharry at gmail.com Mon Apr 13 21:11:44 2009 From: allister.beharry at gmail.com (Allister Beharry) Date: Mon, 13 Apr 2009 17:11:44 -0400 Subject: [development] err...Views DataSource resuming service Message-ID: <578eb7b60904131411q6c144d52g23a3404a27829b38@mail.gmail.com> This is a general apology to people who filed issues for my module - apparently I am not subscribed to my own module's issues list. This is pretty embarrassing...but anyway yes the the module is alive and I'll be working on the issue queue for the rest of the evening. I think it should be the default behaviour when creating a project on d.o to be auto-subscribed to the issue queue. Allister -- Muppet Show > Monty Python From matt at aleph-null.tv Tue Apr 14 15:23:36 2009 From: matt at aleph-null.tv (Matt) Date: Tue, 14 Apr 2009 10:23:36 -0500 Subject: [development] err...Views DataSource resuming service In-Reply-To: <578eb7b60904131411q6c144d52g23a3404a27829b38@mail.gmail.com> References: <578eb7b60904131411q6c144d52g23a3404a27829b38@mail.gmail.com> Message-ID: <70fbbb000904140823u49daddd8x76db179ebdf9a81b@mail.gmail.com> I'm very happy to hear that work will resume on the module. I think I have a patch or two in the queue from long ago, and would be happy to update them for the latest version of Views. I, too, would like to see maintainers auto-subscribed to their projects. Is there a (non-technical) reason why this is not already the case? Matt On Mon, Apr 13, 2009 at 4:11 PM, Allister Beharry wrote: > This is a general apology to people who filed issues for my module - > apparently I am not subscribed to my own module's issues list. This is > pretty embarrassing...but anyway yes the the module is alive and I'll > be working on the issue queue for the rest of the evening. > > I think it should be the default behaviour when creating a project on > d.o to be auto-subscribed to the issue queue. > > Allister > -- > > Muppet Show > Monty Python > -- http://technosophos.com http://querypath.org From earnie at users.sourceforge.net Tue Apr 14 17:13:22 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 14 Apr 2009 17:13:22 +0000 Subject: [development] err...Views DataSource resuming service In-Reply-To: <70fbbb000904140823u49daddd8x76db179ebdf9a81b@mail.gmail.com> References: <578eb7b60904131411q6c144d52g23a3404a27829b38@mail.gmail.com> <70fbbb000904140823u49daddd8x76db179ebdf9a81b@mail.gmail.com> Message-ID: <20090414171322.18594ewjih7enxmo@mail.siebunlimited.com> Quoting Matt : > I'm very happy to hear that work will resume on the module. I think I > have a patch or two in the queue from long ago, and would be happy to > update them for the latest version of Views. > > I, too, would like to see maintainers auto-subscribed to their > projects. Is there a (non-technical) reason why this is not already > the case? > New projects created by a maintainer will auto-subscribe the maintainer. If a maintainer takes over a project, it is up to the new maintainer to subscribe himself and the old maintainer to unsubscribe. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From nabil at gobrighttree.com Tue Apr 14 19:32:44 2009 From: nabil at gobrighttree.com (Nabil Alsharif) Date: Tue, 14 Apr 2009 14:32:44 -0500 Subject: [development] Block user deletion Message-ID: <20090414193244.GA20023@al-sa3ek> The issue is I need some users to be able to edit other users info but not delete them. There is no permission that I can see that allows editing of users profiles but not deleting them. My second guess was to write a module but I don't see anything in the API that will let me control user access the way I need. Neither could I find a way to block the deletion (I know hackish). Any pointers in the right direction are greatly appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From news at unleashedmind.com Tue Apr 14 20:11:59 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Tue, 14 Apr 2009 22:11:59 +0200 Subject: [development] Block user deletion In-Reply-To: <20090414193244.GA20023@al-sa3ek> Message-ID: <038f01c9bd3d$44f966e0$0200a8c0@structworks.com> Sounds like a nice follow-up to http://drupal.org/node/8 ... "Cancel any account" permission (in addition to the new "Cancel account" permission) Logically those would equal the node permissions we have already: "delete own foo content" + "delete any foo content". sun > -----Original Message----- > From: development-bounces at drupal.org > [mailto:development-bounces at drupal.org] On Behalf Of Nabil Alsharif > Sent: Tuesday, April 14, 2009 9:33 PM > To: development at drupal.org > Subject: [development] Block user deletion > > The issue is I need some users to be able to edit other users > info but not delete them. There is no permission that I can > see that allows editing of users profiles but not deleting > them. My second guess was to write a module but I don't see > anything in the API that will let me control user access the > way I need. Neither could I find a way to block the deletion > (I know hackish). > > Any pointers in the right direction are greatly appreciated. > From agentrickard at gmail.com Tue Apr 14 20:26:31 2009 From: agentrickard at gmail.com (Ken Rickard) Date: Tue, 14 Apr 2009 16:26:31 -0400 Subject: [development] Block user deletion In-Reply-To: <038f01c9bd3d$44f966e0$0200a8c0@structworks.com> References: <20090414193244.GA20023@al-sa3ek> <038f01c9bd3d$44f966e0$0200a8c0@structworks.com> Message-ID: <25b45da00904141326p6403ddf7j3446d9a989631fba@mail.gmail.com> Did you try the User Protect module? On Tue, Apr 14, 2009 at 4:11 PM, Daniel F. Kudwien wrote: > Sounds like a nice follow-up to http://drupal.org/node/8 ... > > "Cancel any account" permission (in addition to the new "Cancel account" > permission) > > Logically those would equal the node permissions we have already: "delete > own foo content" + "delete any foo content". > > sun > >> -----Original Message----- >> From: development-bounces at drupal.org >> [mailto:development-bounces at drupal.org] On Behalf Of Nabil Alsharif >> Sent: Tuesday, April 14, 2009 9:33 PM >> To: development at drupal.org >> Subject: [development] Block user deletion >> >> The issue is I need some users to be able to edit other users >> info but not delete them. There is no permission that I can >> see that allows editing of users profiles but not deleting >> them. My second guess was to write a module but I don't see >> anything in the API that will let me control user access the >> way I need. Neither could I find a way to block the deletion >> (I know hackish). >> >> Any pointers in the right direction are greatly appreciated. >> > > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com From nabil at gobrighttree.com Tue Apr 14 21:03:35 2009 From: nabil at gobrighttree.com (Nabil Alsharif) Date: Tue, 14 Apr 2009 16:03:35 -0500 Subject: [development] Block user deletion In-Reply-To: <25b45da00904141326p6403ddf7j3446d9a989631fba@mail.gmail.com> References: <20090414193244.GA20023@al-sa3ek> <038f01c9bd3d$44f966e0$0200a8c0@structworks.com> <25b45da00904141326p6403ddf7j3446d9a989631fba@mail.gmail.com> Message-ID: <20090414210335.GC22393@al-sa3ek> No I didn't see that module in my search. It looks like it has what I need, or at least a pointer to how to get there. Thanks. On Tue, Apr 14, 2009 at 03:40:58PM -0500, Ken Rickard wrote: > Did you try the User Protect module? > > On Tue, Apr 14, 2009 at 4:11 PM, Daniel F. Kudwien > wrote: > > Sounds like a nice follow-up to http://drupal.org/node/8 ... > > > > "Cancel any account" permission (in addition to the new "Cancel account" > > permission) > > > > Logically those would equal the node permissions we have already: "delete > > own foo content" + "delete any foo content". > > > > sun > > > >> -----Original Message----- > >> From: development-bounces at drupal.org > >> [mailto:development-bounces at drupal.org] On Behalf Of Nabil Alsharif > >> Sent: Tuesday, April 14, 2009 9:33 PM > >> To: development at drupal.org > >> Subject: [development] Block user deletion > >> > >> The issue is I need some users to be able to edit other users > >> info but not delete them. There is no permission that I can > >> see that allows editing of users profiles but not deleting > >> them. My second guess was to write a module but I don't see > >> anything in the API that will let me control user access the > >> way I need. Neither could I find a way to block the deletion > >> (I know hackish). > >> > >> Any pointers in the right direction are greatly appreciated. > >> > > > > > > > > -- > Ken Rickard > agentrickard at gmail.com > http://ken.therickards.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From earnie at users.sourceforge.net Wed Apr 15 12:13:51 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 15 Apr 2009 12:13:51 +0000 Subject: [development] Block user deletion In-Reply-To: <20090414193244.GA20023@al-sa3ek> References: <20090414193244.GA20023@al-sa3ek> Message-ID: <20090415121351.11293lsyp356qpwk@mail.siebunlimited.com> Quoting Nabil Alsharif : > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > The issue is I need some users to be able to edit other users info > but not delete them. There is no permission that I can see that > allows editing of users profiles but not deleting them. My second > guess was to write a module but I don't see anything in the API that > will let me control user access the way I need. Neither could I find > a way to block the deletion (I know hackish). > > Any pointers in the right direction are greatly appreciated. > If you can't find a module for this you could create a module that uses hook_form_alter and remove the delete button from the form and change the access callback and arguments field for the menu to one you create. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From nabil at gobrighttree.com Thu Apr 16 14:13:01 2009 From: nabil at gobrighttree.com (Nabil Alsharif) Date: Thu, 16 Apr 2009 09:13:01 -0500 Subject: [development] Block user deletion In-Reply-To: <20090415121351.11293lsyp356qpwk@mail.siebunlimited.com> References: <20090414193244.GA20023@al-sa3ek> <20090415121351.11293lsyp356qpwk@mail.siebunlimited.com> Message-ID: <20090416141301.GC4629@al-sa3ek> That is what I'm doing until I find a better solution. On Thu, Apr 16, 2009 at 08:56:17AM -0500, Earnie Boyd wrote: > Quoting Nabil Alsharif : > >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> The issue is I need some users to be able to edit other users info but >> not delete them. There is no permission that I can see that allows >> editing of users profiles but not deleting them. My second guess was to >> write a module but I don't see anything in the API that will let me >> control user access the way I need. Neither could I find a way to block >> the deletion (I know hackish). >> >> Any pointers in the right direction are greatly appreciated. >> > > > If you can't find a module for this you could create a module that uses > hook_form_alter and remove the delete button from the form and change the > access callback and arguments field for the menu to one you create. > > -- > Earnie > -- http://r-feed.com/ -- http://for-my-kids.com/ > -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From eric.schaefer at eas-consulting.de Sat Apr 18 12:00:21 2009 From: eric.schaefer at eas-consulting.de (Eric Schaefer) Date: Sat, 18 Apr 2009 14:00:21 +0200 Subject: [development] uninstall: deleting all variables of a module Message-ID: <34f8975d0904180500o5d25a054u9ab65d421ad37e83@mail.gmail.com> Hello List, I want to implement the uninstall hook for scheduler.module (D6). Removing the schema and configuration variables is pretty straight forward. But scheduler lets the user configure some values depending on node type. These variables are called 'scheduler_story' or 'scheduler_touch_event'. To remove these I would need to know all the node types that have ever been used at that site or I could enumerate everything in $conf that begins with 'scheduler_'. What is the recommened way of doing this. Is is even a good idea to access $conf directly? Thanks, Eric From earnie at users.sourceforge.net Sat Apr 18 13:48:55 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sat, 18 Apr 2009 13:48:55 +0000 Subject: [development] uninstall: deleting all variables of a module In-Reply-To: <34f8975d0904180500o5d25a054u9ab65d421ad37e83@mail.gmail.com> References: <34f8975d0904180500o5d25a054u9ab65d421ad37e83@mail.gmail.com> Message-ID: <20090418134855.94945cca8aolrf4s@mail.siebunlimited.com> Quoting Eric Schaefer : > Hello List, > > I want to implement the uninstall hook for scheduler.module (D6). > Removing the schema and configuration variables is pretty straight > forward. But scheduler lets the user configure some values depending > on node type. These variables are called 'scheduler_story' or > 'scheduler_touch_event'. To remove these I would need to know all the > node types that have ever been used at that site or I could enumerate > everything in $conf that begins with 'scheduler_'. What is the > recommened way of doing this. Is is even a good idea to access $conf > directly? > db_query(DELETE FROM {variable} WHERE name LIKE '%s_%%', 'scheduler'); -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From eric.schaefer at eas-consulting.de Sat Apr 18 14:03:15 2009 From: eric.schaefer at eas-consulting.de (Eric Schaefer) Date: Sat, 18 Apr 2009 16:03:15 +0200 Subject: [development] uninstall: deleting all variables of a module In-Reply-To: <20090418134855.94945cca8aolrf4s@mail.siebunlimited.com> References: <34f8975d0904180500o5d25a054u9ab65d421ad37e83@mail.gmail.com> <20090418134855.94945cca8aolrf4s@mail.siebunlimited.com> Message-ID: <34f8975d0904180703l5d1587e7yc353806cda8f3d1e@mail.gmail.com> 2009/4/18 Earnie Boyd : > db_query(DELETE FROM {variable} WHERE name LIKE '%s_%%', 'scheduler'); I guess thats your way of saying "No nice and easy way" (as in "Drupal has save and portable built-in functions for it"). ;-) Thanks, Eric From stefan at borchert.cc Sat Apr 18 14:27:09 2009 From: stefan at borchert.cc (Stefan Borchert) Date: Sat, 18 Apr 2009 16:27:09 +0200 Subject: [development] uninstall: deleting all variables of a module In-Reply-To: <34f8975d0904180703l5d1587e7yc353806cda8f3d1e@mail.gmail.com> References: <34f8975d0904180500o5d25a054u9ab65d421ad37e83@mail.gmail.com> <20090418134855.94945cca8aolrf4s@mail.siebunlimited.com> <34f8975d0904180703l5d1587e7yc353806cda8f3d1e@mail.gmail.com> Message-ID: <49E9E33D.2030207@borchert.cc> Eric Schaefer schrieb: > 2009/4/18 Earnie Boyd : >> db_query(DELETE FROM {variable} WHERE name LIKE '%s_%%', 'scheduler'); > > I guess thats your way of saying "No nice and easy way" (as in "Drupal > has save and portable built-in functions for it"). ;-) http://api.drupal.org/api/function/variable_del/6 $value) { if (strpos($name, $namespace) === 0) { // Variable starts with given namespace. Delete it. variable_del($name); } } } ?> Nice enough? ;-) hth, Stefan From larry at garfieldtech.com Sat Apr 18 15:11:04 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Sat, 18 Apr 2009 10:11:04 -0500 Subject: [development] uninstall: deleting all variables of a module In-Reply-To: <49E9E33D.2030207@borchert.cc> References: <34f8975d0904180500o5d25a054u9ab65d421ad37e83@mail.gmail.com> <34f8975d0904180703l5d1587e7yc353806cda8f3d1e@mail.gmail.com> <49E9E33D.2030207@borchert.cc> Message-ID: <200904181011.04154.larry@garfieldtech.com> On Saturday 18 April 2009 9:27:09 am Stefan Borchert wrote: > Eric Schaefer schrieb: > > 2009/4/18 Earnie Boyd : > >> db_query(DELETE FROM {variable} WHERE name LIKE '%s_%%', 'scheduler'); > > > > I guess thats your way of saying "No nice and easy way" (as in "Drupal > > has save and portable built-in functions for it"). ;-) > > http://api.drupal.org/api/function/variable_del/6 > > > function remove_all_variables($namespace) { > foreach ($conf as $name => $value) > { > if (strpos($name, $namespace) === 0) { > // Variable starts with given namespace. Delete it. > variable_del($name); > } > } > } > ?> > > > Nice enough? ;-) > > hth, > > Stefan I can do you one better. :-) First, some node types may be deleted along the way before your module is disabled. For that, use this hook: http://api.drupal.org/api/function/hook_node_type/6 For the uninstall hook, you can use node_get_types() to get a list of currently extant node types and iterate on that: http://api.drupal.org/api/function/node_get_types/6 And then use variable_del() like Stefan says. -- Larry Garfield larry at garfieldtech.com From domenic at workhabit.com Sun Apr 19 00:21:10 2009 From: domenic at workhabit.com (Domenic Santangelo) Date: Sat, 18 Apr 2009 17:21:10 -0700 Subject: [development] uninstall: deleting all variables of a module In-Reply-To: <200904181011.04154.larry@garfieldtech.com> References: <34f8975d0904180500o5d25a054u9ab65d421ad37e83@mail.gmail.com> <34f8975d0904180703l5d1587e7yc353806cda8f3d1e@mail.gmail.com> <49E9E33D.2030207@borchert.cc> <200904181011.04154.larry@garfieldtech.com> Message-ID: On Sat, Apr 18, 2009 at 8:11 AM, Larry Garfield wrote: > First, some node types may be deleted along the way before your module is > disabled. ?For that, use this hook: > > http://api.drupal.org/api/function/hook_node_type/6 > > For the uninstall hook, you can use node_get_types() to get a list of > currently extant node types and iterate on that: > > http://api.drupal.org/api/function/node_get_types/6 > > And then use variable_del() like Stefan says. With a caveat: this only makes sense if scheduler.module deletes a node type's associated variable when the node type is also deleted. -D From drupal at dwwright.net Sun Apr 19 02:08:45 2009 From: drupal at dwwright.net (Derek Wright) Date: Sat, 18 Apr 2009 19:08:45 -0700 Subject: [development] uninstall: deleting all variables of a module In-Reply-To: <34f8975d0904180703l5d1587e7yc353806cda8f3d1e@mail.gmail.com> References: <34f8975d0904180500o5d25a054u9ab65d421ad37e83@mail.gmail.com> <20090418134855.94945cca8aolrf4s@mail.siebunlimited.com> <34f8975d0904180703l5d1587e7yc353806cda8f3d1e@mail.gmail.com> Message-ID: On Apr 18, 2009, at 7:03 AM, Eric Schaefer wrote: > (as in "Drupal has save and portable built-in functions for it"). ;-) Interested parties should see this issue about fixing all this in D7 and beyond: "DX: Use hook_variable_info to declare variables and defaults" http://drupal.org/node/145164 Enjoy, -Derek (dww) From gabor.nyeste83 at gmail.com Sun Apr 19 13:42:49 2009 From: gabor.nyeste83 at gmail.com (=?ISO-8859-1?Q?G=E1bor_Nyeste?=) Date: Sun, 19 Apr 2009 15:42:49 +0200 Subject: [development] CMS Research Message-ID: <88838390904190642ib354b24jb8344eb2a804c566@mail.gmail.com> Dier Developer! I am a student of Corvinus University of Budapest and I'm writing my thesis in the theme of open source web content management systems. I would like to ask you for help to my research so that I can get acquinted with the world of open source development. Please take a moment to fill out my survey. Survey URL: http://survey.e-businessportal.hu/index.php?sid=63134&lang=en Yours fatihfully, Gabor Nyeste -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard at killesreiter.de Sun Apr 19 13:55:41 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Sun, 19 Apr 2009 15:55:41 +0200 Subject: [development] CMS Research In-Reply-To: <88838390904190642ib354b24jb8344eb2a804c566@mail.gmail.com> References: <88838390904190642ib354b24jb8344eb2a804c566@mail.gmail.com> Message-ID: <49EB2D5D.4020609@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 G?bor Nyeste schrieb: > Dier Developer! > > I am a student of Corvinus University of Budapest and I'm writing my > thesis in the theme of open source web content management systems. I > would like to ask you for help to my research so that I can get > acquinted with the world of open source development. Please take a > moment to fill out my survey. > > Survey URL: > > > http://survey.e-businessportal.hu/index.php?sid=63134&lang=en Unfortunately, the English questions are not always clear. You should improve them. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknrLV0ACgkQfg6TFvELooTSyQCeK8LvZGinCAVSFSkl8VJYrM5f 86wAn3cr1vB0Qunk3qb0+N9avVBbtRV8 =EE5a -----END PGP SIGNATURE----- From karoly at negyesi.net Sun Apr 19 20:38:44 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Sun, 19 Apr 2009 13:38:44 -0700 Subject: [development] Very concerned over Drupal's core development Message-ID: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> Hi, I know there are many patches are written, reviewed and committed still. But, without intending to critique of anyone in particular, I see a very dangerous cycle: As Drupal 5 and 6 are very good, rock solid releases, people are satisfied and very busy there, much less is the need, the drive and the availability for core development. This means less patches are written. Also core got bigger. Very, very few people touch actions/triggers, fields, filter system, openid or for that matter, menu just to name a few. Once a patch is written , it needs a review. However, the testing bot, curiously, made patch reviews even harder -- no longer can a novice just install a patch, click around and report back "works" ( the testing bot, of course added a lot of quality to Drupal, I am not saying, down with the bot). This has very severe consequences: we always had too few reviewers and now the entry barrier is even harder as you need to do meaningful code reviews all the time. Low reviewer activity means patches do not get 'bumped' and they linger. Lingering is exacerbated by the loss of Steven and that the single guy who can call the big decisions now has a kid (soon two) and two companies to run. Of course, this leads to frustration on behalf of the patch writers and even less patches get written or reviewed and people draw back into their own little contrib empire where they call the shots... Regards Karoly Negyesi From dmitrig01 at gmail.com Sun Apr 19 23:46:19 2009 From: dmitrig01 at gmail.com (Dmitri G) Date: Sun, 19 Apr 2009 16:46:19 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> Message-ID: <9d2095ce0904191646u2d013e65ob7fb683f2109ca27@mail.gmail.com> Hi chx, I completely agree. However, how do you suggest we make this better? Dmitri On Sun, Apr 19, 2009 at 1:38 PM, Karoly Negyesi wrote: > Hi, > > I know there are many patches are written, reviewed and committed > still. But, without intending to ?critique of anyone in particular, I > see a very dangerous cycle: > > As Drupal 5 and 6 are very good, rock solid releases, people are > satisfied and very busy there, much less is the need, the drive and > the availability for core development. This means less patches are > written. Also core got bigger. Very, very few people touch > actions/triggers, fields, filter system, openid or for that matter, > menu just to name a few. Once a patch is written , it needs a review. > However, the testing bot, curiously, made patch reviews even harder -- > no longer can a novice just install a patch, click around and report > back "works" ( the testing bot, of course added a lot of quality to > Drupal, I am not saying, down with the bot). This has very severe > consequences: we always had too few reviewers and now the entry > barrier is even harder as you need to do meaningful code reviews all > the time. Low reviewer activity means patches do not get 'bumped' and > they linger. Lingering is exacerbated by the loss of Steven and that > the single guy who can call the big decisions now has a kid (soon two) > and two companies to run. Of course, this leads to frustration on > behalf of the patch writers and even less patches get written or > reviewed and people draw back into their own little contrib empire > where they call the shots... > > Regards > > Karoly Negyesi > From earnie at users.sourceforge.net Mon Apr 20 13:09:24 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 20 Apr 2009 13:09:24 +0000 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> Message-ID: <20090420130924.27105sykwzivp04c@mail.siebunlimited.com> Quoting Karoly Negyesi : > Hi, > > I know there are many patches are written, reviewed and committed > still. But, without intending to critique of anyone in particular, I > see a very dangerous cycle: > > As Drupal 5 and 6 are very good, rock solid releases, people are > satisfied and very busy there, much less is the need, the drive and > the availability for core development. This means less patches are > written. Also core got bigger. Very, very few people touch > actions/triggers, fields, filter system, openid or for that matter, > menu just to name a few. Once a patch is written , it needs a review. > However, the testing bot, curiously, made patch reviews even harder -- > no longer can a novice just install a patch, click around and report > back "works" ( the testing bot, of course added a lot of quality to > Drupal, I am not saying, down with the bot). This has very severe > consequences: we always had too few reviewers and now the entry > barrier is even harder as you need to do meaningful code reviews all > the time. Low reviewer activity means patches do not get 'bumped' and > they linger. Lingering is exacerbated by the loss of Steven and that > the single guy who can call the big decisions now has a kid (soon two) > and two companies to run. Of course, this leads to frustration on > behalf of the patch writers and even less patches get written or > reviewed and people draw back into their own little contrib empire > where they call the shots... > While I review a few drupal core patches once in a while, there are still many prime modules needing a stable port to D6; xmlsitemap for example. I'm putting most of my time into trying to get things like this module working so I can port my sites to D6. Otherwise D7 is just a waste of time since upgrading to it requires upgrading to D6 first. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From news at unleashedmind.com Mon Apr 20 13:15:17 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Mon, 20 Apr 2009 15:15:17 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <9d2095ce0904191646u2d013e65ob7fb683f2109ca27@mail.gmail.com> Message-ID: <0dfa01c9c1ba$0d04dc70$0200a8c0@structworks.com> > wrote: > > As Drupal 5 and 6 are very good, rock solid releases, people are > > satisfied and very busy there, much less is the need, the drive and > > the availability for core development. This means less patches are > > written. Also core got bigger. Very, very few people touch > > actions/triggers, fields, filter system, openid or for that matter, > > menu just to name a few. Once a patch is written , it needs > > a review. > I completely agree. However, how do you suggest we make this better? > > Dmitri I completely agree as well. Core is way ahead of contrib and far ahead of actual implementations. Only a minority of contrib modules has really adopted all new features of D6 thus far. There is an obvious gap between possible implementations and actual implementations of core features in modules. This also explains the fact that only a few contrib developers have the energy to work on improvements to Drupal core that would actually improve our APIs for contrib. The answer to solve this is simple, but somehow disliked by some: Let it mature. i.e. defer the code freeze for D7. I know that I'm not the only one who would prefer that (but capitulated in disagreement). sun From gerhard at killesreiter.de Mon Apr 20 13:39:32 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Mon, 20 Apr 2009 15:39:32 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <0dfa01c9c1ba$0d04dc70$0200a8c0@structworks.com> References: <0dfa01c9c1ba$0d04dc70$0200a8c0@structworks.com> Message-ID: <49EC7B14.7060706@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel F. Kudwien schrieb: > I completely agree as well. Core is way ahead of contrib and far > ahead of actual implementations. Only a minority of contrib modules > has really adopted all new features of D6 thus far. There is an > obvious gap between possible implementations and actual > implementations of core features in modules. > > This also explains the fact that only a few contrib developers have the > energy to work on improvements to Drupal core that would actually improve > our APIs for contrib. > > The answer to solve this is simple, but somehow disliked by some: > > Let it mature. > > > i.e. defer the code freeze for D7. I know that I'm not the only one who > would prefer that (but capitulated in disagreement). I don't think you are making much sense here. You claim that module developers haven't found time to add the new D6 features in their code and at the same time want to have a D7 which is more mature (and presumably thus contains even more features). In the end your proposal would only serve to disconnect core and contrib even more. Cheers, Ger?release early, release often?hard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknsexQACgkQfg6TFvELooTtRQCfZ6yHwd4VH0fvWXnso5r7XOVS pN0An1T7yjRF7+bybYCXFxkDSS/WWQx4 =Mguz -----END PGP SIGNATURE----- From news at unleashedmind.com Mon Apr 20 13:58:50 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Mon, 20 Apr 2009 15:58:50 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49EC7B14.7060706@killesreiter.de> Message-ID: <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> > I don't think you are making much sense here. You claim that > module developers haven't found time to add the new D6 > features in their code and at the same time want to have a D7 > which is more mature (and presumably thus contains even more > features). > > In the end your proposal would only serve to disconnect core > and contrib even more. > > Cheers, > Ger?release early, release often?hard In case this really was ambigious: Let it [D6] mature. => i.e. defer the code freeze for D7. Obviously, I mean the exact opposite of what you understood. Contrib needs time to catch up with core. sun From bto108 at psu.edu Mon Apr 20 14:06:50 2009 From: bto108 at psu.edu (Bryan Ollendyke) Date: Mon, 20 Apr 2009 10:06:50 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> Message-ID: <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> lol yeah, I believe the intent of the original author was to hold off on D7 until D6 matured more from a crontrib standpoint. I'll +1 that idea. D5 was and still is a very mature platform that you can develop and build off of, seemingly without "need" to upgrade if you have a site up and running stablly; this isn't always the case with 6 with some of the more major projects just getting to full releases in the last 6 months. I think once D6 stablizes and you start to feel that clamoring for D7 is the time to move to it. I know there's a push to keep the community / versioning alive and active since it's a very deliver or die out in the open source world and we want to stay on top of over big projects in our space but having a full functional D6 that people are adopting the APIs / features of and THEN working towards 7 is probably a better idea. I've started to notice a bunch of dev / alpha D7 module ports too; maybe having versions of D7 released and keeping it in the alpha phase longer (once it reaches that point) will encourage developers to play around with it and start porting things over in the interum. No timeline, no "this is the date we move", a more organic window to maturation much like the nature of open source in the first place... Or get it out tomorrow; I'll end up using it either way ;) On Mon, Apr 20, 2009 at 9:58 AM, Daniel F. Kudwien wrote: > > I don't think you are making much sense here. You claim that > > module developers haven't found time to add the new D6 > > features in their code and at the same time want to have a D7 > > which is more mature (and presumably thus contains even more > > features). > > > > In the end your proposal would only serve to disconnect core > > and contrib even more. > > > > Cheers, > > Ger?release early, release often?hard > > In case this really was ambigious: > > Let it [D6] mature. > > => i.e. defer the code freeze for D7. > > > Obviously, I mean the exact opposite of what you understood. Contrib needs > time to catch up with core. > > sun > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard at killesreiter.de Mon Apr 20 14:17:48 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Mon, 20 Apr 2009 16:17:48 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> References: <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> Message-ID: <49EC840C.5090607@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel F. Kudwien schrieb: >> I don't think you are making much sense here. You claim that >> module developers haven't found time to add the new D6 >> features in their code and at the same time want to have a D7 >> which is more mature (and presumably thus contains even more >> features). >> >> In the end your proposal would only serve to disconnect core >> and contrib even more. >> >> Cheers, >> Ger?release early, release often?hard > > In case this really was ambigious: > > Let it [D6] mature. > > => i.e. defer the code freeze for D7. > > > Obviously, I mean the exact opposite of what you understood. Contrib needs time to catch up with core. Ah, that makes much more sense, although I still disagree. If a module author hasn't found the time to include D6 features over one year after D6 was released, he'll not find time regardless of when D7 is released. If, however, D7 was released in June, he'd look at his code again at least in July and maybe kick out some D5 leftovers. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknshAwACgkQfg6TFvELooQUXwCgwKKCLDzJJAW/GapYvVMDMRrr XnAAoJBa2oCwisnKX0sNSJFjVSCBRHMw =G4Z8 -----END PGP SIGNATURE----- From karoly at negyesi.net Mon Apr 20 14:18:27 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 20 Apr 2009 07:18:27 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> Message-ID: <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> On Mon, Apr 20, 2009 at 7:06 AM, Bryan Ollendyke wrote: > lol yeah, I believe the intent of the original author was to hold off on D7 > until D6 matured more from a crontrib standpoint.? I'll +1 that idea. I had concerns and I shared that with the community. I had no solutions. I stil do not have. I am not sure postponing Drupal 7 even further is the solution. Because then, as Gerhard says, what will you do when Drupal 7 gets out, send core development on vacation for two years? From andrewberry at sentex.net Mon Apr 20 14:33:04 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Mon, 20 Apr 2009 10:33:04 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> Message-ID: On 19-Apr-09, at 4:38 PM, Karoly Negyesi wrote: > we always had too few reviewers and now the entry > barrier is even harder as you need to do meaningful code reviews all > the time A significant issue I've encountered in participating with core patches is the time required to synthesize hundreds of comments into a cohesive overview of where the issue is at and what the next steps are. Of course, most of the comments will be valid points of discussion, but the barrier to entry can be quite high due to the initial time involved to get familiar with the issue. One idea to help simply patch reviews would be to add single checklist of review tasks for an issue. CNR is too vague of a status to be meaningful in many cases. When a patch is set to CNR for the first time, review items (such as those at http://drupal.org/patch/review) could be added to the issue automatically. One item would be "passing the test bot". Each checkbox could have associated comment ID / user name fields, so it would be easy to say "this code has been benchmarked at comment #1234". Those more involved with the issue would need to be able to add additional tasks as well. Code isn't set to RTBC until all of the tasks have been marked as done. I think this would help get more individuals reviewing patches. For example, perhaps one of the tasks for UI related patches would be "Needs screenshot of changes". A potential reviewer could search for all CNR issues where that task needs to be done, and do them all at once. Developers have specific specialities, and as-is it's not incredibly easy for new reviewers to find the issues where they can contribute the most. --Andrew From news at unleashedmind.com Mon Apr 20 14:40:42 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Mon, 20 Apr 2009 16:40:42 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> Message-ID: <0e3001c9c1c5$fb797950$0200a8c0@structworks.com> > From: Karoly Negyesi > > I had concerns and I shared that with the community. I had no > solutions. I stil do not have. I am not sure postponing > Drupal 7 even further is the solution. Because then, as > Gerhard says, what will you do when Drupal 7 gets out, send > core development on vacation for two years? Well, I asked myself the very same questions like you: > This means less patches are written. [why?] > Very, very few people touch actions/triggers, fields, filter system, > openid or for that matter, menu just to name a few. [why?] The most obvious that crosses my mind is: Most developers did not really work with the current feature-set and APIs, they did not experience (and suffer from) current limitations, and have no clear idea or vision of how Drupal *should* really work. Once this prerequisite is there, we will see much more interest and traction in core development. Releasing yet another new API, developers have to catch up with, means that it will take them even longer to get into core development business. sun From nan_wich at bellsouth.net Mon Apr 20 15:09:03 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 20 Apr 2009 11:09:03 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> Message-ID: Karoly Negyesi wrote: > what will you do when Drupal 7 gets out, send core development on vacation for two years? Hmm, I wonder what would happen if we all realized that every member of DO is a "core developer?" There may be a few people who are more or less directly responsible for consolidating proposed changes, but it is the community at large that is responsible for making those proposals - and patches. Even though we sometimes refer to those privileged (burdened) few as "Drupal-gods," they are not perfect; they cannot predict every way someone will use the code, nor can they test everything all together the way we put them together. Those people have real lives too (I think), and have to do the same thing we do: fit in time for Drupal amidst all our other demands. I don't always agree with everything they do or say - I dare say chx is one of them who knows that already. But Drupal is a great system, and it will stay that way only if we all think of ourselves as core developers. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.0/2068 - Release Date: 4/19/2009 8:04 PM From nedjo at islandnet.com Mon Apr 20 15:35:08 2009 From: nedjo at islandnet.com (Nedjo Rogers) Date: Mon, 20 Apr 2009 09:35:08 -0600 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> Message-ID: <49EC962C.70107@islandnet.com> Karoly Negyesi wrote: > On Mon, Apr 20, 2009 at 7:06 AM, Bryan Ollendyke wrote: > > I had concerns and I shared that with the community. I had no > solutions. I stil do not have. I am not sure postponing Drupal 7 even > further is the solution. I agree that bottlenecks in the reviewing and applying of patches is a huge problem majorly holding up Drupal development. I suspect we need some significant structural changes to address it. Partly I think we need to look at changes in the drivers of Drupal development. There was a time when it was mainly hobbyists, who weren't particularly tied to external timelines. No longer. The biggest amount of focused development time now comes from medium to large companies needing specific functionality within set timelines. The typical development cycle for a large project (e.g., a major site or multisite installation) is a matter of months. Development can't wait the many months or even years before a new version is ready and can't deal with the uncertainty of fluxuating timelines. So the significant work they sponsor is almost never for core, which is years ahead of what can be used. It's instead for the current usable release version. Meanwhile, with fewer resources, core goes its different direction, choosing its own solutions to many of the same problems. And so the contrib-core gap increases. Even when a corporate-sponsored project is specifically designed to contribute to core, the results can be mixed at best. Take the internationalization work CivicActions did, sponsored by Sony Music, see http://drupal.org/node/383954. We worked just as hard or harder on numerous core fixes and enhancements as we did on work in contrib. But at the end of the six or seven months, when pretty much every significant patch had been accepted and applied in dozens of contrib modules (Views, CCK, Flag, Voting API, Internationalization, Date, etc.), practically none of our core patches had got in. I conclude: 1. More than tweaks and further exhortations to just do more reviewing, we probably need to consider some major changes. 2. Any changes should increase the ease and incentive of contributing major improvements to core as part of the regular development work. Here are some concrete ideas: 1. Expand our team of core committers. Since 4.7 we have had a single maintainer per major version in addition to the permanent core committers (now reduced to one). We could consider changing this. Possible changes: a. Each core committer either becomes a permanent core committer or is maintained for two or three versions instead of one. E.g., while Angie is the primary maintainer of 7.x, some or all of Gerhard, Neil and Gabor retain the ability to accept and apply patches for HEAD. b. Two or three core committers are appointed per major release instead of just one. c. The maintainers listed at http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co are given permanent commit access to be used only in the areas they are responsible for. 2. Shorten our release cycle. Instead of trying to fit many major API changes and improvements into each major release, we instead limit ourselves to a focused few changes and a much shorter timeline. This quickens the pace of change, reducing the contrib-core gap. 3. Rather than always limiting new functionality to the new version, we accept specific, break-nothing backports in core of new functionality and APIs. E.g., we have two branches of each major version, one a feature-frozen branch (what we have now) and the other one (yes, somewhat less stable) that accepts selected new APIs and features that have been added already to HEAD. This allows contrib modules to use the new APIs in the current version. I know that all of these potential changes - and others that I hope others will come up with - would have potential pitfalls and disasters. But I think these are the sorts of discussions we should be having. We've recognized a long-standing issue. We need some creative thinking, drawing on our strengths, to consider afresh how to keep core development accessible, rewarding, and effective. Nedjo From rob at robshouse.net Mon Apr 20 16:03:40 2009 From: rob at robshouse.net (Robert Douglass) Date: Mon, 20 Apr 2009 18:03:40 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49EC962C.70107@islandnet.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> Message-ID: <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> Nedjo has given us the first response to chx's origninal problem statement that addresses the real intent of the concern, and proposes solutions. Of the three solutions Nedjo proposed, I favor c) giving targeted commit rights to people who have historically been the maintainers for certain subsystems. We would need to develop guidelines around where their turf ends and they are no longer free to commit without escalating to either the branch maintainer or a permanent core maintainer (Dries), but this is a feasible solution that could speed the development of certain subsystems (actions, triggers, openID, i18n). The other solution which chx and I have discussed, and which is a long time goal of mine, would be to reduce the size of core. We carry around a lot of modules that don't absolutely need to be part of core: - aggregator - blog - blogapi - forum - help - poll - profile - search - statistics - taxonomy - tracker I believe that all of these modules could have brilliant lives outside of core. A slimmer core means more focused development for the core team. It would also make us focus our attention on the APIs that support these very important modules. For example, the search API is in great need of being decoupled from the node module. If our goal were to remove search from core we'd need to really make sure the API were in place for letting core be searched. My argument squarely reflects opinion that "core" Drupal should be an application framework that doesn't offer any specialized functionality. Forums, polls, profiles, blogs and even taxonomy are specialized web application functions that don't need the 10,000 layers of red tape that core has. I firmly believe that taxonomy, for example, is hampered by its presence in core. There has been amazing work done on turning taxonomy into something far beyond what we have today, but the very presence of taxonomy IN CORE means that nobody uses it. Same with search. When I first wrote the ApacheSolr module it utilized as much of the search "API" as possible. Now we're moving to make it completely independent of core search because there is no way core can keep up with our development pace. So, in my opinion, if you want to take Drupal to the moon, you do two things: 1) give more people the keys to the car, and 2) shed a bunch of the pieces that we currently call "core". Robert Douglass The RobsHouse.net Newsletter: http://robshouse.net/newsletter/robshousenet-newsletter Follow me on Twitter: http://twitter.com/robertDouglass On Apr 20, 2009, at 5:35 PM, Nedjo Rogers wrote: > Karoly Negyesi wrote: >> On Mon, Apr 20, 2009 at 7:06 AM, Bryan Ollendyke >> wrote: >> >> I had concerns and I shared that with the community. I had no >> solutions. I stil do not have. I am not sure postponing Drupal 7 even >> further is the solution. > I agree that bottlenecks in the reviewing and applying of patches is a > huge problem majorly holding up Drupal development. I suspect we need > some significant structural changes to address it. > > Partly I think we need to look at changes in the drivers of Drupal > development. > > There was a time when it was mainly hobbyists, who weren't > particularly > tied to external timelines. No longer. The biggest amount of focused > development time now comes from medium to large companies needing > specific functionality within set timelines. The typical development > cycle for a large project (e.g., a major site or multisite > installation) > is a matter of months. Development can't wait the many months or even > years before a new version is ready and can't deal with the > uncertainty > of fluxuating timelines. So the significant work they sponsor is > almost > never for core, which is years ahead of what can be used. It's instead > for the current usable release version. > > Meanwhile, with fewer resources, core goes its different direction, > choosing its own solutions to many of the same problems. And so the > contrib-core gap increases. > > Even when a corporate-sponsored project is specifically designed to > contribute to core, the results can be mixed at best. Take the > internationalization work CivicActions did, sponsored by Sony Music, > see > http://drupal.org/node/383954. We worked just as hard or harder on > numerous core fixes and enhancements as we did on work in contrib. But > at the end of the six or seven months, when pretty much every > significant patch had been accepted and applied in dozens of contrib > modules (Views, CCK, Flag, Voting API, Internationalization, Date, > etc.), practically none of our core patches had got in. > > I conclude: > > 1. More than tweaks and further exhortations to just do more > reviewing, > we probably need to consider some major changes. > 2. Any changes should increase the ease and incentive of contributing > major improvements to core as part of the regular development work. > > Here are some concrete ideas: > > 1. Expand our team of core committers. > > Since 4.7 we have had a single maintainer per major version in > addition > to the permanent core committers (now reduced to one). We could > consider > changing this. Possible changes: > > a. Each core committer either becomes a permanent core committer or is > maintained for two or three versions instead of one. E.g., while Angie > is the primary maintainer of 7.x, some or all of Gerhard, Neil and > Gabor > retain the ability to accept and apply patches for HEAD. > > b. Two or three core committers are appointed per major release > instead > of just one. > > c. The maintainers listed at > http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co > are given permanent commit access to be used only in the areas they > are > responsible for. > > 2. Shorten our release cycle. Instead of trying to fit many major API > changes and improvements into each major release, we instead limit > ourselves to a focused few changes and a much shorter timeline. This > quickens the pace of change, reducing the contrib-core gap. > > 3. Rather than always limiting new functionality to the new version, > we > accept specific, break-nothing backports in core of new functionality > and APIs. E.g., we have two branches of each major version, one a > feature-frozen branch (what we have now) and the other one (yes, > somewhat less stable) that accepts selected new APIs and features that > have been added already to HEAD. This allows contrib modules to use > the > new APIs in the current version. > > I know that all of these potential changes - and others that I hope > others will come up with - would have potential pitfalls and > disasters. > But I think these are the sorts of discussions we should be having. > We've recognized a long-standing issue. We need some creative > thinking, > drawing on our strengths, to consider afresh how to keep core > development accessible, rewarding, and effective. > > Nedjo From eric.schaefer at eas-consulting.de Mon Apr 20 16:09:24 2009 From: eric.schaefer at eas-consulting.de (Eric Schaefer) Date: Mon, 20 Apr 2009 18:09:24 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> Message-ID: <34f8975d0904200909i5009fcacp1d723ad7fa499567@mail.gmail.com> Some word from the contrib side of drupal: Why am I not participating in reviews of core patches? Naked fear. How could I possibly understand whats going on in core? Although I am using and developing for drupal since version 3.somthing (??) I still have problems with the inner workings of drupal. One reason for this is the fact that core is a moving target. All kinds of APIs change between major releases. Joe Contrib Developer (thats me) does not understand why. I am sure those changes are important, but I don't understand them. I just fought a furious fight with the fapi last weekend. Something that was working fine 5.x is behaving strangely in 6.x. If I am not understanding the USE of those APIs how can I judge patches to the code behind them? Solution: Dunno. Maybe extensive documentation? Not just docs for the APIs, but docs about the functionality and docs about design decisions. Such docs would also aid ports of modules to new core releases since devs would loose fear. I am currently maintaining scheduler and I am still struggling with the difference between D5 and D6. I dare not even think about a port to D7. One more thought about the docs: Maybe everything is I would need to loose fear is documented. But where? I always get lost in the drupal documentation... My 0.02?, Eric From gabor at hojtsy.hu Mon Apr 20 16:13:21 2009 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Mon, 20 Apr 2009 18:13:21 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> Message-ID: <86ca3ccb0904200913n343a5c00w2d9e98df6ba83085@mail.gmail.com> On Mon, Apr 20, 2009 at 6:03 PM, Robert Douglass wrote: > So, in my opinion, if you want to take Drupal to the moon, you do two > things: 1) give more people the keys to the car, and 2) shed a bunch of the > pieces that we currently call "core". Would that solve our other problem: that many contrib modules got updates later, so it turns out after a stable release that certain APIs are not complete or suitable for important contrib stuff? If we move more of the modules which use these APIs outside of core, we go to pure API design without validation of those APIs with real life modules, no? While I agree some modules would be best to go, maybe moving all is not the solution. Poll was joked to be one of the best API validation modules (for drag and drop, AHAH, etc). While that was a joke to some degree, it also has roots in reality. G?bor From rob at robshouse.net Mon Apr 20 16:40:58 2009 From: rob at robshouse.net (Robert Douglass) Date: Mon, 20 Apr 2009 18:40:58 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <86ca3ccb0904200913n343a5c00w2d9e98df6ba83085@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> <86ca3ccb0904200913n343a5c00w2d9e98df6ba83085@mail.gmail.com> Message-ID: <92BB6DDF-1551-43FF-9CA7-E7F4860D7BBB@robshouse.net> On Apr 20, 2009, at 6:13 PM, G?bor Hojtsy wrote: > On Mon, Apr 20, 2009 at 6:03 PM, Robert Douglass > wrote: >> So, in my opinion, if you want to take Drupal to the moon, you do two >> things: 1) give more people the keys to the car, and 2) shed a >> bunch of the >> pieces that we currently call "core". > > Would that solve our other problem: that many contrib modules got > updates later, so it turns out after a stable release that certain > APIs are not complete or suitable for important contrib stuff? If we > move more of the modules which use these APIs outside of core, we go > to pure API design without validation of those APIs with real life > modules, no? While I agree some modules would be best to go, maybe > moving all is not the solution. Poll was joked to be one of the best > API validation modules (for drag and drop, AHAH, etc). While that was > a joke to some degree, it also has roots in reality. > > G?bor I agree that your concerns are valid, but I think that solving those concerns would be easier than solving the larger core concerns raised by chx if we continue to follow the exact strategy that we have now. API validation is vitally important, and should be driven by contrib. Contrib should be instructing core "hey, I need this in the API so that I can do what I want". Contrib module maintainers currently submit patches to core to tend to the important APIs that affect their modules. Witness Earl Mile's recent patch that has major ramifications on future Views development. http://drupal.org/node/322344 Contrib modules are real modules. They do a fine job of finding the limitations and strengths of core's APIs. The feedback loop from contrib to core is there, and it is strong. In one direction. Most of that feedback currently sits idle in the core issue queue, however, and contrib module authors often choose to just work around core instead of enhancing it. Poll, despite being "core's regression test", is the best example. The only time anyone pays any attention to poll module development is when other people scream "get poll out of core!" loudly enough :P These days, if we need regression tests, we should put them in the Simpletest framework. Another solution would be to split core into two parts. "Framework", and "CMS". The framework would be the things like user, node, block, system, actions, fields, etc., and the CMS would be things like poll, blog, forum and who knows what. The smart thing would be to make "Framework" in this case as small as possible, and push as much as we can into "Framework". Then "Framework" could adopt a nice, long release cycle and focus on big API changes, whereas "CMS" could focus on shorter release cycles upon any given "Framework" release. "CMS" would get a new set of "core" committers. From tz at it-arts.org Mon Apr 20 16:41:05 2009 From: tz at it-arts.org (Thomas Zahreddin) Date: Mon, 20 Apr 2009 18:41:05 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <34f8975d0904200909i5009fcacp1d723ad7fa499567@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <34f8975d0904200909i5009fcacp1d723ad7fa499567@mail.gmail.com> Message-ID: <1240245665.15492.14.camel@thomas-laptop> Am Montag, den 20.04.2009, 18:09 +0200 schrieb Eric Schaefer: > Some word from the contrib side of drupal: > > Why am I not participating in reviews of core patches? Naked fear. How > could I possibly understand whats going on in core? Although I am > using and developing for drupal since version 3.somthing (??) I still > have problems with the inner workings of drupal. One reason for this > is the fact that core is a moving target. All kinds of APIs change > between major releases. > Joe Contrib Developer (thats me) does not > understand why. the answers to the question 'Why ..' are often design decisions and these are maybe documented, e.g. in issues, mailinglist, IRC, groups.drupal.org - but often in a form nobody can tell from that documentation what the decision is. > I am sure those changes are important, but I don't > understand them. I just fought a furious fight with the fapi last > weekend. Something that was working fine 5.x is behaving strangely in > 6.x. If I am not understanding the USE of those APIs how can I judge > patches to the code behind them? Solution: Dunno. Maybe extensive > documentation? Not just docs for the APIs, but docs about the > functionality and docs about design decisions. Such docs would also > aid ports of modules to new core releases since devs would loose fear. .. The question behind is: how are design decisions made _and_ coordinated? my suggestion form e.g. Nov. 2008 original: http://lists.drupal.org/pipermail/development/2008-November/031354.html " .. If the group of persons working on a module keeps a logbook about their decisions, then everybody is able to follow the decisions regarding a module. A short description of this method of dynamic selfgovernance can be found on http://en.wikipedia.org/wiki/Sociocracy or as free pdf http://www.governancealive.com/Links/The_Creative_Forces_of_Self_Organization.pdf A longer description is in Buck, John and Sharon Villines (2007). We the People: Consenting to a Deeper Democracy, A Guide to Sociocraty " So what do you think now of a _log_ for requirements and design decisions for core, APIs and modules? > > One more thought about the docs: Maybe everything is I would need to > loose fear is documented. But where? I always get lost in the drupal > documentation... > > My 0.02?, > Eric From drewish at katherinehouse.com Mon Apr 20 16:52:37 2009 From: drewish at katherinehouse.com (andrew morton) Date: Mon, 20 Apr 2009 10:52:37 -0600 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> Message-ID: On Mon, Apr 20, 2009 at 10:03 AM, Robert Douglass wrote: > The other solution which chx and I have discussed, and which is a long time > goal of mine, would be to reduce the size of core. We carry around a lot of > modules that don't absolutely need to be part of core: While there might be specific modules that would be better off in contrib, on the whole, I think we need to have code in core that actually uses our APIs. Converting core modules to use a new API is one of the first and most informative tests the API will get. And importantly it happens while the original developers are still engaged and working with the code rather than months later when no one remembers exactly why a decision was made. I've heard poll.module referred to as the canary of the FormsAPI because it helps spot subtle flaws in the API that might have gone unnoticed for months after core ships. Back in the D5 beta days I tried to keep the audio module updated for HEAD to help test it but HEAD was insanely unstable. These days, due to the unittests, HEAD is the most stable I've seen since I stared with 4.6 but most of my modules are have enough dependencies on other contrib modules that it would be impossible to keep them updated. The one success I've had in this regard was back porting the fixes that quicksketch did moving the ImageAPI module into core (http://drupal.org/node/373613) back to the contrib module. There's been one core bug fixed and another identified. I'm hoping something similar comes from the push to get ImageCache into core (http://drupal.org/node/371374). So while I'm all for reviewing the list of modules in core and dropping some I think we'd be well served to have several higher level modules that exist solely to help smoke test our core APIs. andrew From everyone at asifproductions.com Mon Apr 20 16:59:45 2009 From: everyone at asifproductions.com (As If Productions) Date: Mon, 20 Apr 2009 09:59:45 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: Message-ID: <20090420170102.IEAF15318.fed1rmmtao105.cox.net@fed1rmimpo02.cox.net> Nedjo Rogers and Robert Douglass said some great stuff. Read them again! Core improvements are going in some great directions, but there is an obvious and growing disconnect between these new directions and their assimilation into methodology by contrib developers (and site developers). This gap could be narrowed by *writing more documentation* but we all know how popular that is. Nedjo's points about client development schedules are very pertinent now, much more than ever because Drupal has become mainstream-popular. I've spent so much time patching/fixing/hacking modules for my D6 clients I haven't more than glanced at D7 yet. But I can tell you this - it took A YEAR for D6 to stabilize to the point where I would consider it truly useful, and D5 is still a safer choice for any non-tiny job with a real deadline. IMHO, the plan to release a major rev every year was the worst decision ever. Personally I'd like to spend another year documenting the D6 changes and patching the D6 contribs. LVX TF --- As If Productions http://www.asifproductions.com Interactive Worlds and Immersive Obsessions From pwolanin at gmail.com Mon Apr 20 17:06:58 2009 From: pwolanin at gmail.com (Peter Wolanin) Date: Mon, 20 Apr 2009 13:06:58 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <86ca3ccb0904200913n343a5c00w2d9e98df6ba83085@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> <86ca3ccb0904200913n343a5c00w2d9e98df6ba83085@mail.gmail.com> Message-ID: <2247a8a70904201006o652311fex8cc6253bf393d0b7@mail.gmail.com> I would strongly agree with chx and others that in some way we need additional committers. I think that it does make sense for Dries to be providing overall guidance, but I think it would be helpful if in some/many cases Dries would lay out criteria for a proposed change to be accepted and then delegate review and commit implementation details to others. A few of the modules Robert mention (maybe blog, tracker, and help) should either go or get a serious revamping. I general, however, many of the module in core serve as reference implementations of certain APIs and allow you to build a reasonable little site with just core - there can and should be other or more feature-rich implementations in contrib. -Peter On Mon, Apr 20, 2009 at 12:13 PM, G?bor Hojtsy wrote: > On Mon, Apr 20, 2009 at 6:03 PM, Robert Douglass wrote: >> So, in my opinion, if you want to take Drupal to the moon, you do two >> things: 1) give more people the keys to the car, and 2) shed a bunch of the >> pieces that we currently call "core". > > Would that solve our other problem: that many contrib modules got > updates later, so it turns out after a stable release that certain > APIs are not complete or suitable for important contrib stuff? If we > move more of the modules which use these APIs outside of core, we go > to pure API design without validation of those APIs with real life > modules, no? While I agree some modules would be best to go, maybe > moving all is not the solution. Poll was joked to be one of the best > API validation modules (for drag and drop, AHAH, etc). While that was > a joke to some degree, it also has roots in reality. > > G?bor > From michael at favias.org Mon Apr 20 17:10:12 2009 From: michael at favias.org (Michael Favia) Date: Mon, 20 Apr 2009 12:10:12 -0500 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <34f8975d0904200909i5009fcacp1d723ad7fa499567@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <34f8975d0904200909i5009fcacp1d723ad7fa499567@mail.gmail.com> Message-ID: <49ECAC74.8060007@favias.org> Eric Schaefer wrote: > Why am I not participating in reviews of core patches? Naked fear. How > could I possibly understand whats going on in core? Fire up your debugger (i use eclipse + pdt + zend debugger) and step through the major operations of the bootstrap process to discover the big picture. Then walk through the loading of a node that is decorated with cck fields and taxonomy terms. Finish up your tour with the editing of a form (node, admin) to get a good look at fapi and the form processing involved in form.inc and you have a VERY strong foundation from which to build. Most people involved in core don't understand 100% of it. Many specialize in a particular area. This is why we have reviews and the testbot. > One reason for this is the fact that core is a moving target. This is a conscious and purposeful decision on the part of the project it will not change. > If I am not understanding the USE of those APIs how can I judge > patches to the code behind them? api.drupal.org lists each function and in the declaration is detailed everywhere that function is also used in core. This is a good start but your IDE can help you alot more if you use one especially if you put a breakpoint in your function and start debugging to see how various functions arrive at the location and what the variables are set to at that time. Please take the time and try it just once. Install D7, apply a couple patches, review their changes and you'll be surprised how quickly you fall in place. We want your help. I normally find that future contributors are simply scared away by the challenge certainly not actually unable to rise to it. Pick a patch that seems interesting to you. If you ever need help find me in IRC and I'll always be happy to lend a hand. -mf From drewish at katherinehouse.com Mon Apr 20 17:15:20 2009 From: drewish at katherinehouse.com (andrew morton) Date: Mon, 20 Apr 2009 11:15:20 -0600 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <92BB6DDF-1551-43FF-9CA7-E7F4860D7BBB@robshouse.net> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> <86ca3ccb0904200913n343a5c00w2d9e98df6ba83085@mail.gmail.com> <92BB6DDF-1551-43FF-9CA7-E7F4860D7BBB@robshouse.net> Message-ID: On Mon, Apr 20, 2009 at 10:40 AM, Robert Douglass wrote: > API validation is vitally important, and should be driven by contrib. > Contrib should be instructing core "hey, I need this in the API so that I > can do what I want". Contrib module maintainers currently submit patches to > core to tend to the important APIs that affect their modules. Witness Earl > Mile's recent patch that has major ramifications on future Views > development. http://drupal.org/node/322344 > > Contrib modules are real modules. They do a fine job of finding the > limitations and strengths of core's APIs. The feedback loop from contrib to > core is there, and it is strong. In one direction. Most of that feedback > currently sits idle in the core issue queue, however, and contrib module > authors often choose to just work around core instead of enhancing it. I think contrib authors submitting back core patches is really the exception. I know it too me two full versions of working around a crappy file APIs before I finally decided to wade in an experience the utter frustration that is core development. And even then it was two versions before things really started to improve. Someone at DCDC described core development as not a meritocracy but a who's-got-more-free-time-ocracy and as Nedjo identified most corporate sponsored development doesn't come with that free time leading to the idle feedback you identified. > Another solution would be to split core into two parts. "Framework", and > "CMS". The framework would be the things like user, node, block, system, > actions, fields, etc., and the CMS would be things like poll, blog, forum > and who knows what. The smart thing would be to make "Framework" in this > case as small as possible, and push as much as we can into "Framework". Then > "Framework" could adopt a nice, long release cycle and focus on big API > changes, whereas "CMS" could focus on shorter release cycles upon any given > "Framework" release. I like this idea but it sort of goes into the whole "golden" module list that seems to come up ever now and again. andrew From fintan at io1.biz Mon Apr 20 17:19:11 2009 From: fintan at io1.biz (fintan galvin) Date: Mon, 20 Apr 2009 18:19:11 +0100 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <20090420170102.IEAF15318.fed1rmmtao105.cox.net@fed1rmimpo02.cox.net> References: <20090420170102.IEAF15318.fed1rmmtao105.cox.net@fed1rmimpo02.cox.net> Message-ID: <4839f5e60904201019hf0ff6f6p7c98ee72c3527819@mail.gmail.com> I am not a coder so don't comment on this list much however I am the person who makes the decisions about when we move to different versions and as such "might" have something to offer this discussion of value (although probably not). The issue with people not moving to D6 and slow uptake on module upgrades imo was nothing to do with how good D5 was (is), true its a great release that does loads that we need, but still is nowhere near the level that we need it to be. The simple reason was there is nothing in D6 that is significant enough commercially to justify moving to it. We use D6 to some degree but if a significant module is missing we just use D5 as the difference between the two is not that great and the value of the contrib modules is greater than the differences. We like most others had coded our way around most of the issues D6 solved in D5. I suspect that a lot of drupal houses like us have stacks of running code for doing the more arduous drupal tasks like content staging and D6 did not offer us enough to justify moving wholeheartedly to it. This is not the case with D7, this version brings real commercial value with it specifically in replication / database abstraction / performance / RDF etc. Not only does this allow us to improve the way we currently do things but also allows us to make some new money by building bigger / better sites. I believe that this will be the real driver behind modules being upgraded. In short if you want to take Drupal to the moon, it costs a lot of money and you have to get commercial support, that comes in many forms a lot of it unseen. The necessity for Drupal house's to make profit is not as well supported in D6 as it is in D7 (helps that dries and co. now rely for their living on commercial application of Drupal ;-) and this will be the core driver (pun intended). IMHO D6 will never get the level of support it needs and most people will just jump straight to D7 as this is where the money changes are I.E. don't slow D7 in favour of D6 or because modules have not been updated quickly enough for D6, accept that D6 simply was not commercially compelling enough to get people to move. D7 is extremely compelling and will in my opinion get a much more rapid uptake, so we should look to speed it up so that we can all build bigger and better sites and make more money to support Drupal better. The modules will follow the money. And I 100% support the concept of removing stuff from core as per Robert's list and having a core framework, I still struggle every time I have to call Drupal a CMS when its so much more. Fin 2009/4/20 As If Productions > Nedjo Rogers and Robert Douglass said some great stuff. Read them again! > > Core improvements are going in some great directions, but there is an > obvious and growing disconnect between these new directions and their > assimilation into methodology by contrib developers (and site developers). > This gap could be narrowed by *writing more documentation* but we all know > how popular that is. > > Nedjo's points about client development schedules are very pertinent now, > much more than ever because Drupal has become mainstream-popular. I've > spent so much time patching/fixing/hacking modules for my D6 clients I > haven't more than glanced at D7 yet. But I can tell you this - it took A > YEAR for D6 to stabilize to the point where I would consider it truly > useful, and D5 is still a safer choice for any non-tiny job with a real > deadline. IMHO, the plan to release a major rev every year was the worst > decision ever. Personally I'd like to spend another year documenting the D6 > changes and patching the D6 contribs. > > LVX > TF > > --- > As If Productions > http://www.asifproductions.com > Interactive Worlds and Immersive Obsessions > > -- Fintan Galvin Managing Director IO1 Limited Skpye: johnfgalvin http://twitter.com/suncao Mobile: 44 773 8506781 Phone: 44 20 8816 7690 Website: http://www.io1.biz -------------- next part -------------- An HTML attachment was scrubbed... URL: From drupal-devel at webchick.net Mon Apr 20 17:25:54 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Mon, 20 Apr 2009 13:25:54 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49EC962C.70107@islandnet.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> Message-ID: On 20-Apr-09, at 11:35 AM, Nedjo Rogers wrote: > > c. The maintainers listed at > http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co > are given permanent commit access to be used only in the areas they > are > responsible for. Let's examine the consequences of this, since it's always a popular option when it comes up. I'm going to choose the menu system as a random example, but you can easily substitute 'menu system' as $subsystem and 'chx and pwolanin' as $subsystem_maintainers in the following narrative. The menu system is a bit tweaky and its innards not easily understood by the "common developer" in the Drupal community. As a result, patches that improve the menu system tend to languish in the queue in "code needs review" for weeks or months. When a review does happen, it's normally on more minor things like coding style or similar; not about the fundamental architecture of the menu system. This is extremely frustrating to chx and pwolanin, the menu system maintainers, since they want to keep going with their crazy development ideas and are blocked. So, to resolve the issue of menu system patches languishing in the queue, chx and pwolanin are granted commit access to the menu system. Suddenly, all of our problems with languishing patches magically disappear! After a quick discussion in #drupal-dev, patch after patch that improves the menu system is committed. The menu system has never evolved so quickly in such a short period of time! And better still, the committers for the field API, the database system, actions/ triggers, etc. are all empowered to do so as well, so Drupal evolves at lightning speed! WIN! Of course, without any kind of peer oversight, while these patches that get committed make perfect sense to chx and pwolanin, they completely mystify the "common developer." When Drupal 7 is released, it becomes painfully obvious that we've developed extremely well- engineered subsystems without ever exposing a "real" human developer to having to work with them. And since these patches only needed to make sense to two subsystem maintainers with intimate knowledge of the underlying subsystem already, documentation is extremely sparse. It's now way harder than ever before to jump in and get involved in core development. Worse, because all of these subsystems were rapidly evolving within their own sphere, 20, 30, perhaps 50 patches committed per day, it's become impossible for anyone to oversee all of them; at best you have people inspecting one-off patches here and there. That means things like coding standards compliance, performance benchmarking, algorithm optimization, and the collective DX (not to mention UX) experience of Drupal 7 plummets. Drupal 7 is usable by chx, pwolanin, DamZ, catch, and about 20 other people, and everyone else switches to Django. ;) We have this kind of decentralized development model, where one or two people are solely responsible for code with basically zero peer review. It's called contrib. And it's notoriously filled with sub- standard, shoddily documented code that needs to be closely inspected by individual site maintainers before being deployed on any serious production sites. The entire strength of Drupal core *is* that it is peer reviewed (sometimes mercilessly so :)), it has oversight from others who are *not* deeply immersed in APIs who can give sanity checks, and has people who are bringing a very *diverse* range of experience levels, specializations, and use cases. You remove that, you remove what I would argue is the very heart and soul of Drupal. "But webchick!" I hear you say. "Obviously, we wouldn't let these subsystem maintainers work /completely/ bereft of peer review. We'd surely have someone else check over their work." And I say, "Great! Then *why aren't these mythical someones doing this right now*?" and *then* you get at what I believe is the /actual/ root of the problem. ;) *We need to grow the base of people who have understanding in these subsystems.* People who consider themselves subsystem maintainers should be actively working to build teams around their subsystem of choice. They should be documenting how their underlying APIs work so that someone without familiarity could jump in and get oriented quickly. They should be recruiting from contrib authors who are doing interesting/ innovative work in their areas. They should be maintaining a "patch spotlight" page under http://drupal.org/community-initiatives/drupal-core so that people who want to jump in and don't know where to start have a direction. They should be guiding and mentoring "younger" contributors on how to do patch reviews, and actively advocating for others to do so as well. If subsystem maintainers do this, the collective IQ of the Drupal development community goes up, we grow the larger pool of contributors, and no patch gets left as code needs review. Then you can come back to me when the RTBC queue is 6 pages long (as opposed to cleared down to zero about once every couple of months as it has been) and say "webchick, we need subsystem maintainers to have commit rights, because these patches have all been thoroughly peer reviewed and are languishing at RTBC." and I will probably back you up 110%. -Angie From karoly at negyesi.net Mon Apr 20 17:29:35 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 20 Apr 2009 10:29:35 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <2247a8a70904201006o652311fex8cc6253bf393d0b7@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> <86ca3ccb0904200913n343a5c00w2d9e98df6ba83085@mail.gmail.com> <2247a8a70904201006o652311fex8cc6253bf393d0b7@mail.gmail.com> Message-ID: <7e270cea0904201029p2a654fe7x9e66f76781009ead@mail.gmail.com> On Mon, Apr 20, 2009 at 10:06 AM, Peter Wolanin wrote: > I would strongly agree with chx and others that in some way we need > additional committers. You can't agree with me because I have not said so. Check the thread again :) I have not suggested anything and will not (for some time at least). I deliberately avoid taking sides and rather play devil's advocate. Do not presume I agree or disagree with any idea presented in here. The rest of this mail will be reflections on many of the things were raised in here. It really must be noted that the Drupal 6 cycle was unusual because major contribs decided they do not want to maintain old crap and did a complete refactoring and started that only once D6 was out the door. This, hopefully, won't repeat so in the future contribs will be ready somewhat sooner. This does not help the contrib-core gap, of course. One of the reasons I left contrib is that my perfectionist half could not stand the crappy code my programmer half produced. I can't write pretty code without peer review. If you think you can, my best advice is to think again. Really, peer review is almost mandatory. Simply allowing people to commit patches will not help our code quality. Really, check most contrib vs core. I started with a post which showed how a shortage of patch writers, reviewers and committers create a self strenghening cycle. Making a half-assed fix at committers is not enough to fix the whole cycle. Slimming down core is an idea but as was noted we do we need them to validate. Also, if you slim down core and thus speed up development, how again will that help the contrib-core gap? Now, Drupal shops. Sure, you can't sell to a client directly core development but what about this, say, you would ask for 100/hr on a project which takes 400 hrs (less hree man-months, not that much). If you ask 110/hr instead then that client sponsored 40 hrs of core work, too. On the other hand if you can get away with 110/hr then why not just bill that and go to the beach? From dries.buytaert at gmail.com Mon Apr 20 17:33:49 2009 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon, 20 Apr 2009 19:33:49 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> Message-ID: <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> As core matures, we might see more patches getting stale. I think the reason is (at least) two-fold: 1) More patches compete for attention, but fewer of these patches are truly important. In this case, patches getting stale is not necessarily a bad thing because history has proven that important patches will eventually bubble to the top for the right reasons. However, I understand that it might be frustrating because it takes longer, and some patches don't make it at all. As a core contributor, I think you have to trust that you patch will eventually bubble up -- it just takes a bit longer for people with the same pain point to weigh in and participate in the review process. It is also important that you convince other people as why your patch should bubble up -- this is something a lot of people can get better at. 2) Drupal is getting increasingly complex. You already hinted that the test framework increases the barrier to participation for aspiring developers. However, it is not just that -- things like the new database abstraction layer, the registry, the form API, the new menu system, the theme preprocess functions, load multiple and jQuery make Drupal a better platform, but also increase the barrier to participation. As a result, fewer people are capable of reviewing patches in great depth. In ways, complexity is a disease. We have to strive towards making Drupal easier to develop for while maintaining its functionality and flexibility. Fighting unnecessary complexity and abstractions is increasingly important. Webchick and I have been pretty good at managing the RTBC queue. It used to be several pages long, but the last couple of months we never had more than 20 Drupal 7 patches marked RTBC (as far as I remember). We only have 8 Drupal 7 patches marked as RTBC at the time of this writing. But even today, with many patches in the 'code needs review' state (not in RTBC state), core continues to be a fast moving target. I don't think we should speed things up, or we risk de-railing contrib, and many of the contributed module authors in the process. I think we progressing at a good pace, and I think many important patches have gone in. Already, Drupal 7 promises to be a great release. On Sun, Apr 19, 2009 at 10:38 PM, Karoly Negyesi wrote: > Hi, > > I know there are many patches are written, reviewed and committed > still. But, without intending to ?critique of anyone in particular, I > see a very dangerous cycle: > > As Drupal 5 and 6 are very good, rock solid releases, people are > satisfied and very busy there, much less is the need, the drive and > the availability for core development. This means less patches are > written. Also core got bigger. Very, very few people touch > actions/triggers, fields, filter system, openid or for that matter, > menu just to name a few. Once a patch is written , it needs a review. > However, the testing bot, curiously, made patch reviews even harder -- > no longer can a novice just install a patch, click around and report > back "works" ( the testing bot, of course added a lot of quality to > Drupal, I am not saying, down with the bot). This has very severe > consequences: we always had too few reviewers and now the entry > barrier is even harder as you need to do meaningful code reviews all > the time. Low reviewer activity means patches do not get 'bumped' and > they linger. Lingering is exacerbated by the loss of Steven and that > the single guy who can call the big decisions now has a kid (soon two) > and two companies to run. Of course, this leads to frustration on > behalf of the patch writers and even less patches get written or > reviewed and people draw back into their own little contrib empire > where they call the shots... > > Regards > > Karoly Negyesi > -- Dries Buytaert :: http://buytaert.net/ From matt at mattfarina.com Mon Apr 20 18:02:33 2009 From: matt at mattfarina.com (Matt Farina) Date: Mon, 20 Apr 2009 14:02:33 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> Message-ID: <9A804352-61DF-4298-9315-C3D79E875C44@mattfarina.com> A few idea (I'm flinging IT at the wall to see what sticks): 1) Building on what Angie wrote about teams. We could put some time into tools to help people build teams. g.d.o helps with the tools. We could see what's missing and bring the tools there to help form the teams. Maybe come up with common solutions to making successful teams and sharing them. Maybe a guide to team building. It may seem basic but a guide can help people who don't know how. 2) The complex systems (like filters, menus, etc.) can be scary to people. Even really smart and capable developers. We could create training and teaching to explain how these work and why these work the way they do. The caching systems interaction with filters has caused more than a few questions, arguments, and violent beatings on drupal code. Tools to lower the barrier to entry to understand the more complex systems can invite people to learn them and learn how to code better raising the bar overall. 3) dww started to work on a distribution system for drupal some time ago. A package with an install profile, drupal core, modules, themes, etc. Imagine drupal.org creating distributions. There could be one for blogging, a video site, a knowledge management system, etc. We could be less worried about what core puts out for people to use and let it be a tool that things are built upon. The concern I've had is more along the lines of what chx noted. Go back and read it. It's not the committing of patches. It's the people with expertise in different areas working on and reviewing patches. For all the hundreds of people working on core there are areas we need more people qualified to work on the tough stuff, more people reviewing patches, and more people crafting them to be core worthy. More committers doesn't help with this part of the process (though that may eventually become a bottleneck). Additionally, there is the time aspect. Core development isn't a high priority for many people. How can we change that? If it's a priority people will find to be involved. Matt On Apr 20, 2009, at 1:25 PM, Angela Byron wrote: > > On 20-Apr-09, at 11:35 AM, Nedjo Rogers wrote: > >> >> c. The maintainers listed at >> http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co >> are given permanent commit access to be used only in the areas they >> are >> responsible for. > > Let's examine the consequences of this, since it's always a popular > option when it comes up. I'm going to choose the menu system as a > random example, but you can easily substitute 'menu system' as > $subsystem and 'chx and pwolanin' as $subsystem_maintainers in the > following narrative. > > The menu system is a bit tweaky and its innards not easily > understood by the "common developer" in the Drupal community. As a > result, patches that improve the menu system tend to languish in the > queue in "code needs review" for weeks or months. When a review does > happen, it's normally on more minor things like coding style or > similar; not about the fundamental architecture of the menu system. > This is extremely frustrating to chx and pwolanin, the menu system > maintainers, since they want to keep going with their crazy > development ideas and are blocked. > > So, to resolve the issue of menu system patches languishing in the > queue, chx and pwolanin are granted commit access to the menu > system. Suddenly, all of our problems with languishing patches > magically disappear! After a quick discussion in #drupal-dev, patch > after patch that improves the menu system is committed. The menu > system has never evolved so quickly in such a short period of time! > And better still, the committers for the field API, the database > system, actions/triggers, etc. are all empowered to do so as well, > so Drupal evolves at lightning speed! WIN! > > Of course, without any kind of peer oversight, while these patches > that get committed make perfect sense to chx and pwolanin, they > completely mystify the "common developer." When Drupal 7 is > released, it becomes painfully obvious that we've developed > extremely well-engineered subsystems without ever exposing a "real" > human developer to having to work with them. And since these patches > only needed to make sense to two subsystem maintainers with intimate > knowledge of the underlying subsystem already, documentation is > extremely sparse. It's now way harder than ever before to jump in > and get involved in core development. > > Worse, because all of these subsystems were rapidly evolving within > their own sphere, 20, 30, perhaps 50 patches committed per day, it's > become impossible for anyone to oversee all of them; at best you > have people inspecting one-off patches here and there. That means > things like coding standards compliance, performance benchmarking, > algorithm optimization, and the collective DX (not to mention UX) > experience of Drupal 7 plummets. Drupal 7 is usable by chx, > pwolanin, DamZ, catch, and about 20 other people, and everyone else > switches to Django. ;) > > We have this kind of decentralized development model, where one or > two people are solely responsible for code with basically zero peer > review. It's called contrib. And it's notoriously filled with sub- > standard, shoddily documented code that needs to be closely > inspected by individual site maintainers before being deployed on > any serious production sites. > > The entire strength of Drupal core *is* that it is peer reviewed > (sometimes mercilessly so :)), it has oversight from others who are > *not* deeply immersed in APIs who can give sanity checks, and has > people who are bringing a very *diverse* range of experience levels, > specializations, and use cases. You remove that, you remove what I > would argue is the very heart and soul of Drupal. > > "But webchick!" I hear you say. "Obviously, we wouldn't let these > subsystem maintainers work /completely/ bereft of peer review. We'd > surely have someone else check over their work." And I say, "Great! > Then *why aren't these mythical someones doing this right now*?" and > *then* you get at what I believe is the /actual/ root of the > problem. ;) > > *We need to grow the base of people who have understanding in these > subsystems.* > > People who consider themselves subsystem maintainers should be > actively working to build teams around their subsystem of choice. > They should be documenting how their underlying APIs work so that > someone without familiarity could jump in and get oriented quickly. > They should be recruiting from contrib authors who are doing > interesting/innovative work in their areas. They should be > maintaining a "patch spotlight" page under http://drupal.org/community-initiatives/drupal-core > so that people who want to jump in and don't know where to start > have a direction. They should be guiding and mentoring "younger" > contributors on how to do patch reviews, and actively advocating for > others to do so as well. > > If subsystem maintainers do this, the collective IQ of the Drupal > development community goes up, we grow the larger pool of > contributors, and no patch gets left as code needs review. Then you > can come back to me when the RTBC queue is 6 pages long (as opposed > to cleared down to zero about once every couple of months as it has > been) and say "webchick, we need subsystem maintainers to have > commit rights, because these patches have all been thoroughly peer > reviewed and are languishing at RTBC." and I will probably back you > up 110%. > > -Angie > From merlin at logrus.com Mon Apr 20 18:04:15 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 20 Apr 2009 11:04:15 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> Message-ID: <49ECB91F.8050305@logrus.com> Angela Byron wrote: > We have this kind of decentralized development model, where one or two > people are solely responsible for code with basically zero peer review. > It's called contrib. And it's notoriously filled with sub-standard, > shoddily documented code that needs to be closely inspected by > individual site maintainers before being deployed on any serious > production sites. I stop following your argument here. The only way this argument holds up is that if *all* of contrib is substandard crap. It is not. There is a level of contrib that is above that, and there is a reason those particular pieces of contrib are above that. Chew on that. From merlin at logrus.com Mon Apr 20 18:07:08 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 20 Apr 2009 11:07:08 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> Message-ID: <49ECB9CC.9030807@logrus.com> Dries Buytaert wrote: > As core matures, we might see more patches getting stale. I think the > reason is (at least) two-fold: > > 1) More patches compete for attention, but fewer of these patches are > truly important. In this case, patches getting stale is not > necessarily a bad thing because history has proven that important > patches will eventually bubble to the top for the right reasons. If the 'right reasons' are because the developers got frustrated with the process and quit pushing their patch, whereas other developers are extremely stubborn and managed to push their patch through anyway, then sure. But just because some developer is bullheaded enough to wade through the crap doesn't mean that's the right reasons. From merlin at logrus.com Mon Apr 20 18:14:58 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 20 Apr 2009 11:14:58 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> Message-ID: <49ECBBA2.60300@logrus.com> Dries Buytaert wrote: > weigh in and participate in the review process. It is also important > that you convince other people as why your patch should bubble up -- > this is something a lot of people can get better at. This statement right here is what's wrong with Drupal core development. At this time, you must be better at debate, arguing and general Drupal politics than you are at actual code design and implementation. At one point 'talk is silver, code is gold' was the motto. But this has changed. Now talk is gold and code is defined by those who talk the best. From drupal-devel at webchick.net Mon Apr 20 18:15:38 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Mon, 20 Apr 2009 14:15:38 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECB91F.8050305@logrus.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> Message-ID: <383E1ED4-3C4A-4EF6-A766-0D4D8D6E7886@webchick.net> On 20-Apr-09, at 2:04 PM, Earl Miles wrote: > Angela Byron wrote: >> We have this kind of decentralized development model, where one or >> two people are solely responsible for code with basically zero peer >> review. It's called contrib. And it's notoriously filled with sub- >> standard, shoddily documented code that needs to be closely >> inspected by individual site maintainers before being deployed on >> any serious production sites. > > I stop following your argument here. The only way this argument > holds up is that if *all* of contrib is substandard crap. It is not. > There is a level of contrib that is above that, and there is a > reason those particular pieces of contrib are above that. Chew on > that. And this level contrib is the kind that has enough users so that peer reviews occur naturally, or at the very least peer QA after the fact. As we've noted, peer review and peer QA is *not* happening with these core subsystems, which makes it a lot closer to the "darker, scarier" contrib. So I'm not sure what there is to chew on. :) -Angie From merlin at logrus.com Mon Apr 20 18:20:03 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 20 Apr 2009 11:20:03 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <383E1ED4-3C4A-4EF6-A766-0D4D8D6E7886@webchick.net> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <383E1ED4-3C4A-4EF6-A766-0D4D8D6E7886@webchick.net> Message-ID: <49ECBCD3.4030304@logrus.com> Angela Byron wrote: > > On 20-Apr-09, at 2:04 PM, Earl Miles wrote: > >> Angela Byron wrote: >>> We have this kind of decentralized development model, where one or >>> two people are solely responsible for code with basically zero peer >>> review. It's called contrib. And it's notoriously filled with >>> sub-standard, shoddily documented code that needs to be closely >>> inspected by individual site maintainers before being deployed on any >>> serious production sites. >> >> I stop following your argument here. The only way this argument holds >> up is that if *all* of contrib is substandard crap. It is not. There >> is a level of contrib that is above that, and there is a reason those >> particular pieces of contrib are above that. Chew on that. > > And this level contrib is the kind that has enough users so that peer > reviews occur naturally, or at the very least peer QA after the fact. As > we've noted, peer review and peer QA is *not* happening with these core > subsystems, which makes it a lot closer to the "darker, scarier" > contrib. So I'm not sure what there is to chew on. :) Perhaps you attribute more peer review and QA to some of these modules than is truly there. I don't think there is very much. There is peer review pretty much after the fact; that's the review that said "it's ok to use this module." But the responsibility of the committer is what made that happen in the first place. I personally believe that anyone who is given the right to commit directly to Drupal core is going to think several times longer before committing something than he or she would to contrib. Obviously this varies based on personality, but the suggestion that adding more committers to core will turn core into contrib does not work for me. From catch56 at googlemail.com Mon Apr 20 18:24:39 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 20 Apr 2009 19:24:39 +0100 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECB9CC.9030807@logrus.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> Message-ID: I agree with Earl here. Several of my patches, including quite big popular patches that people have bought me beers for, have only got in because I'm a stubborn git - either re-rolling them 50 times due to patch conflicts or writing reams of arguments to get them committed. Not to mention nagging people time after time on irc to get reviews and/or advice. Plenty of other people give up (either on the individual patch or core as a whole), and then those patches either sit in the queue for years or sometimes get revived by another developer, and then they can still sit in the queue for another year or two. This doesn't mean that /all/ lingering patches are lingering for the wrong reasons, but there's a lot of overhead getting patches in other than just writing the code. Having said that, none of this overhead exists for reviewing patches - and it's slow review turnover which leads to a lot of the lingering, and being someone who reviews a lot of patches is one of the easiest ways to get your own patches reviewed faster. On Mon, Apr 20, 2009 at 7:07 PM, Earl Miles wrote: > Dries Buytaert wrote: >> >> As core matures, we might see more patches getting stale. ?I think the >> reason is (at least) two-fold: >> >> ?1) More patches compete for attention, but fewer of these patches are >> truly important. ?In this case, patches getting stale is not >> necessarily a bad thing because history has proven that important >> patches will eventually bubble to the top for the right reasons. > > If the 'right reasons' are because the developers got frustrated with the > process and quit pushing their patch, whereas other developers are extremely > stubborn and managed to push their patch through anyway, then sure. But just > because some developer is bullheaded enough to wade through the crap doesn't > mean that's the right reasons. > From eric.schaefer at eas-consulting.de Mon Apr 20 18:27:50 2009 From: eric.schaefer at eas-consulting.de (Eric Schaefer) Date: Mon, 20 Apr 2009 20:27:50 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECAC74.8060007@favias.org> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <34f8975d0904200909i5009fcacp1d723ad7fa499567@mail.gmail.com> <49ECAC74.8060007@favias.org> Message-ID: <34f8975d0904201127r27ac0dawd0eebef06b1d3bde@mail.gmail.com> 2009/4/20 Michael Favia : > Fire up your debugger (i use eclipse + pdt + zend debugger) and step through I will. > api.drupal.org lists each function and in the declaration is detailed > everywhere that function is also used in core. This is a good start but your > IDE can help you alot more if you use one especially if you put ?a > breakpoint in your function and start debugging to see how various functions > arrive at the location and what the variables are set to at that time. > > Please take the time and try it just once. Install D7, apply a couple > patches, review their changes and you'll be surprised how quickly you fall > in place. I am sure you are right. But still. I can understand a lot of stuff by debugging and reading code. But it is really hard to understand the bigger picture from the code view. It can see WHAT the code does but I might not be able to understand WHY or it might be very time consuming. Eric From matt at mattfarina.com Mon Apr 20 18:33:57 2009 From: matt at mattfarina.com (Matt Farina) Date: Mon, 20 Apr 2009 14:33:57 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> Message-ID: Some responsibilities, actions, and expectations seem to be unclear to me: Is getting the patches committed the problem or is the problem getting them reviewed and to the point where they can be committed the problem? Is it getting the from needs review to RTBC? What is the role of a core committer in the review process compared to your average joe developer. Obviously there are differences between your average joe developer and a core committer. I guess I'm trying to find the bottleneck. It doesn't look to be in committing the patches when they become RTBC. It seems to be in the area of reviewing patches and understanding subsystems and good design (especially in the complex parts). Am I missing something? If this is the case, from a process perspective, adding more core committers doesn't solve the problem we are facing. Or, am I missing something? On Apr 20, 2009, at 2:24 PM, Nathaniel Catchpole wrote: > I agree with Earl here. Several of my patches, including quite big > popular patches that people have bought me beers for, have only got in > because I'm a stubborn git - either re-rolling them 50 times due to > patch conflicts or writing reams of arguments to get them committed. > Not to mention nagging people time after time on irc to get reviews > and/or advice. > > Plenty of other people give up (either on the individual patch or core > as a whole), and then those patches either sit in the queue for years > or sometimes get revived by another developer, and then they can still > sit in the queue for another year or two. > > This doesn't mean that /all/ lingering patches are lingering for the > wrong reasons, but there's a lot of overhead getting patches in other > than just writing the code. > > Having said that, none of this overhead exists for reviewing patches - > and it's slow review turnover which leads to a lot of the lingering, > and being someone who reviews a lot of patches is one of the easiest > ways to get your own patches reviewed faster. > > > > > On Mon, Apr 20, 2009 at 7:07 PM, Earl Miles wrote: >> Dries Buytaert wrote: >>> >>> As core matures, we might see more patches getting stale. I think >>> the >>> reason is (at least) two-fold: >>> >>> 1) More patches compete for attention, but fewer of these patches >>> are >>> truly important. In this case, patches getting stale is not >>> necessarily a bad thing because history has proven that important >>> patches will eventually bubble to the top for the right reasons. >> >> If the 'right reasons' are because the developers got frustrated >> with the >> process and quit pushing their patch, whereas other developers are >> extremely >> stubborn and managed to push their patch through anyway, then sure. >> But just >> because some developer is bullheaded enough to wade through the >> crap doesn't >> mean that's the right reasons. >> From dries.buytaert at gmail.com Mon Apr 20 18:35:08 2009 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon, 20 Apr 2009 20:35:08 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <9A804352-61DF-4298-9315-C3D79E875C44@mattfarina.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <9A804352-61DF-4298-9315-C3D79E875C44@mattfarina.com> Message-ID: <61bca48a0904201135t4458c0edq7605a1a0c4527517@mail.gmail.com> On Mon, Apr 20, 2009 at 8:02 PM, Matt Farina wrote: > The concern I've had is more along the lines of what chx noted. Go back and > read it. It's not the committing of patches. It's the people with expertise > in different areas working on and reviewing patches. For all the hundreds of > people working on core there are areas we need more people qualified to work > on the tough stuff, more people reviewing patches, and more people crafting > them to be core worthy. More committers doesn't help with this part of the > process (though that may eventually become a bottleneck). This is spot on. It's important that we look at Drupal core development at the macro-level -- "Drupal core is a very healthy project that is making steady progress, but it risks going too fast and becoming too complex for (contrib) developers". Often, contributors, including myself, are thinking at the micro-level -- "my patch is really important, but it doesn't bubble to the top, and it doesn't get committed so let's get grumpy because things are too slow". Giving more people commit access doesn't solve the macro-problem. It seemingly solves the micro-level problem, but at the expense of making the macro-level problem worse. That is key to understand -- and explained by webchick. Matt is spot on because he succeeds at looking at the macro-level. It is what I call a 'community responsibility' to help solve this problem. From doing a better job educating people to fighting complexity. The fact that we have poll module is not a source of complexity because it can be safely ignored 98% of the time. The fact that we have difficult to understand subsystems and increasingly more Drupal-isms is a problem. -- Dries Buytaert :: http://buytaert.net/ From gerhard at killesreiter.de Mon Apr 20 18:35:03 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Mon, 20 Apr 2009 20:35:03 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECB91F.8050305@logrus.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> Message-ID: <49ECC057.7040101@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Earl Miles schrieb: > Angela Byron wrote: >> We have this kind of decentralized development model, where one or two >> people are solely responsible for code with basically zero peer >> review. It's called contrib. And it's notoriously filled with >> sub-standard, shoddily documented code that needs to be closely >> inspected by individual site maintainers before being deployed on any >> serious production sites. > > I stop following your argument here. The only way this argument holds up > is that if *all* of contrib is substandard crap. It is not. There is a > level of contrib that is above that, and there is a reason those > particular pieces of contrib are above that. Chew on that. Because they follow core's development model? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknswFcACgkQfg6TFvELooSYZwCgiXjOIsgkkaXzHMh9et0yGIY3 L2MAn3VLhZwL0Th9kHDtQAIUmuZ9QNPV =3YWz -----END PGP SIGNATURE----- From karoly at negyesi.net Mon Apr 20 18:36:24 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 20 Apr 2009 11:36:24 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> Message-ID: <7e270cea0904201136q1549ce31oeaeffdc11e75dd70@mail.gmail.com> > Plenty of other people give up (either on the individual patch or core > as a whole), Note: this is very very and a very sad important fact. From catch56 at googlemail.com Mon Apr 20 18:37:47 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 20 Apr 2009 19:37:47 +0100 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> <86ca3ccb0904200913n343a5c00w2d9e98df6ba83085@mail.gmail.com> <92BB6DDF-1551-43FF-9CA7-E7F4860D7BBB@robshouse.net> Message-ID: > >> Another solution would be to split core into two parts. "Framework", and >> "CMS". The framework would be the things like user, node, block, system, >> actions, fields, etc., and the CMS would be things like poll, blog, forum >> and who knows what. The smart thing would be to make "Framework" in this >> case as small as possible, and push as much as we can into "Framework". Then >> "Framework" could adopt a nice, long release cycle and focus on big API >> changes, whereas "CMS" could focus on shorter release cycles upon any given >> "Framework" release. > > I like this idea but it sort of goes into the whole "golden" module > list that seems to come up ever now and again. > > andrew > I think the problem is less the number of modules we have in core (mainly CMS-ish ones), and much more that the ones we have in core are only there for arbitrary / historical reasons. A patch to add forum, blog, help, poll, tracker, taxonomy to core now would be almost immediately won't fixed or stay at CNW for a very long time requiring years of work to get right - either because there are better contrib alternatives, or because the code is crappy, or both. However taking them out requires an upgrade path and a responsible contrib maintainer, not to mention consensus, and getting all three of those at the same time is hard too. On the other hand, getting eternally useful modules like token, CCK, Views etc. into core is a very long and drawn out process too - for good reason - if only in part because we know that once they're in core it's very hard to take them out, and any wrong design implications have a much longer lifespan and are harder to fix (hence the main query in tracker module which was bringing Drupal.org down regularly on Drupal 5 still hasn't been fixed in core for three releases). Packaging and better install profiles might help, getting those major APIs into core will hopefully help us push the old-style modules out of core eventually as well - i.e. replace tracker.module with a couple of default views. I don't think this is the root of the various recurring frustrations with core development though at all - either those of us very active in the core issue queue or those who avoid it like the plague. In my opinion it's a combination of factors, most very hard to fix - hence threads like this and discussions in #drupal on a regular basis. Nat From tomi at vacilando.org Mon Apr 20 18:37:30 2009 From: tomi at vacilando.org (=?UTF-8?B?VG9tw6HFoSBGw7xsw7ZwcCAodmFjaWxhbmRvLm9yZyk=?=) Date: Mon, 20 Apr 2009 20:37:30 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> Message-ID: <593475f90904201137r6e808aacy721ff714ff4e1afd@mail.gmail.com> I am in Drupal up to my eyebrows every day but still I am not finding enough time for my few contrib modules, the less for the core patches. I am not giving up though - the opposite, understanding more and more every day, gearing up. Even without being a current core or active contributor I too clearly see a problem with the differing speeds of development of core and contrib, and I very much agree with most of the refreshing proposals of Nedjo Rogers and Robert Douglass above. In general, I think that so powerfully creative and committed (!) people should be given more rights and space for driving development in their areas of expertise. It is sad to hear people who have made major contributions to Drupal feel shackled. Let me give two comments to Angie's otherwise good and useful reasoning: Worse, because all of these subsystems were rapidly evolving within their > own sphere, 20, 30, perhaps 50 patches committed per day, it's become > impossible for anyone to oversee all of them; at best you have people > inspecting one-off patches here and there. That means things like coding > standards compliance, performance benchmarking, algorithm optimization, and > the collective DX (not to mention UX) experience of Drupal 7 plummets. > Drupal 7 is usable by chx, pwolanin, DamZ, catch, and about 20 other people, > and everyone else switches to Django. ;) I could read what you say as: "no commit rights because the group might not be able to oversee the changes", hence "better slow and frustrating development than fast and exciting one". That might finally stifle Drupal. I firmly believe more coders would be attracted to providing and testing patches if development took up speed in this way. Far too often we see modules sprouting with the apologetic explanation that 'it would take too long in core, see the patch xy that's laying there for months'. Probably in this way the teams of interested coders-turning-experts you talk about would naturally emerge from the exciting development activity in such areas! Further, if the maintainers of subsystems had commit rights they would probably be more motivated to manage and work with such teams, etc. Or turn it around - how can we expect the most able developers be motivated to do fantastic things in their areas of experience if they cannot commit them? "But webchick!" I hear you say. "Obviously, we wouldn't let these subsystem > maintainers work /completely/ bereft of peer review. We'd surely have > someone else check over their work." And I say, "Great! Then *why aren't > these mythical someones doing this right now*?" and *then* you get at what I > believe is the /actual/ root of the problem. ;) I think the development would speed up, and so those who want to follow would have to keep the pace. Its a tax you pay for the exciting new functionality and stability. It works in major and vital contrib modules, so why not in such specialized areas of core? Problem of overseeing fast changes is there at any speed of development. That can be mitigated by increasing pressure for providing documentation and decision paths along with the code. (Perhaps a condition like: you can commit in your area but only with full documentation of not only the code but also your clearly stated and referenced reasoning and immediate roadmap.) As I said, I am determined to contribute much more than I have ever done, to contrib, and to core. But I believe adding more rights to the biggest Drupal coders as proposed above would greatly help me and everybody, and Drupal as a project. Anyways; back to coding! See you around -- Tom?? -- Tom?? F?l?pp (vacilando) http://vacilando.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlin at logrus.com Mon Apr 20 18:44:27 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 20 Apr 2009 11:44:27 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECC057.7040101@killesreiter.de> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <49ECC057.7040101@killesreiter.de> Message-ID: <49ECC28B.407@logrus.com> Gerhard Killesreiter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Earl Miles schrieb: >> Angela Byron wrote: >>> We have this kind of decentralized development model, where one or two >>> people are solely responsible for code with basically zero peer >>> review. It's called contrib. And it's notoriously filled with >>> sub-standard, shoddily documented code that needs to be closely >>> inspected by individual site maintainers before being deployed on any >>> serious production sites. >> I stop following your argument here. The only way this argument holds up >> is that if *all* of contrib is substandard crap. It is not. There is a >> level of contrib that is above that, and there is a reason those >> particular pieces of contrib are above that. Chew on that. > > Because they follow core's development model? They don't, actually, or at least, mine don't. I don't post patches and have half a dozen people review them before I commit code. If someone posts a patch, chances are there's only 1 or 2 reviews on it, and I have to do the real review prior to deciding whether or not to commit it. Sometimes some patch will be both simple enough and important enough for more than a couple people to review it, but that is the exception, not the rule. Right now, it's because I try to hold myself to a high standard. And I admit that I can be sloppy and commit too fast due to the workload, but ultimately even with that I do a better job than a lot of contrib, simply because I try to see the bigger picture prior to committing. The reason I think more committers in targeted areas will work is because I think it will create more activity in those areas. The people who have the right to commit will have a more vested interest, and therefore you will get more of their time, effort and energy, plus any that they can draw to them. webchick commented earlier that one of the issues was providing an incentive to do reviews. And that's certainly a key issue, right there. There isn't much incentive to do reviews. There's the good of the project, but there is no pride of ownership in a review. The pride of ownership drives a lot of the initial development, and it drives the committers, but the reviewers? I cannot remember a time in the 4 years I've been with this project that we haven't had a longstanding complaint about lack of good patch reviews. That is one of the first complaints I heard then, and it is one of the complaints I hear now. It has not changed, and asking people to do more reviews has already proven to be ineffective in combatting the issue. Give your reviewers some ownership and you'll find a lot more people interested in reviewing. From drupal-devel at webchick.net Mon Apr 20 18:48:45 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Mon, 20 Apr 2009 14:48:45 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECBCD3.4030304@logrus.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <383E1ED4-3C4A-4EF6-A766-0D4D8D6E7886@webchick.net> <49ECBCD3.4030304@logrus.com> Message-ID: <23CCAD87-A0D3-45D1-BA6E-9BA9F62FA176@webchick.net> On 20-Apr-09, at 2:20 PM, Earl Miles wrote: > Angela Byron wrote: >> On 20-Apr-09, at 2:04 PM, Earl Miles wrote: >>> Angela Byron wrote: >>>> We have this kind of decentralized development model, where one >>>> or two people are solely responsible for code with basically zero >>>> peer review. It's called contrib. And it's notoriously filled >>>> with sub-standard, shoddily documented code that needs to be >>>> closely inspected by individual site maintainers before being >>>> deployed on any serious production sites. >>> >>> I stop following your argument here. The only way this argument >>> holds up is that if *all* of contrib is substandard crap. It is >>> not. There is a level of contrib that is above that, and there is >>> a reason those particular pieces of contrib are above that. Chew >>> on that. >> And this level contrib is the kind that has enough users so that >> peer reviews occur naturally, or at the very least peer QA after >> the fact. As we've noted, peer review and peer QA is *not* >> happening with these core subsystems, which makes it a lot closer >> to the "darker, scarier" contrib. So I'm not sure what there is to >> chew on. :) > > Perhaps you attribute more peer review and QA to some of these > modules than is truly there. I don't think there is very much. There > is peer review pretty much after the fact; that's the review that > said "it's ok to use this module." > > But the responsibility of the committer is what made that happen in > the first place. I personally believe that anyone who is given the > right to commit directly to Drupal core is going to think several > times longer before committing something than he or she would to > contrib. Obviously this varies based on personality, but the > suggestion that adding more committers to core will turn core into > contrib does not work for me. I guess I view it as the following simple pseudo-query, assuming an active maintainer: $relative_project_quality = db_result(db_query('SELECT (number of active participants in issues, filtering out '+1 subscribe') FROM {the_issue_queue} WHERE project = %d', $project->nid)). On a project such as Views, with a very high number, $relative_project_quality will be very high. On a project such as any of mine ;) with a very low number, code quality will be much lower. This is not because I'm a horrible coder or that I'm not conscientious about my work or that I don't care about quality. It's because there's no body of diverse people chiming in to say "actually that will break my use case and here's why," or "I actually find that a bit hard to grasp; what if we did it this way instead?" There's no one looking over my shoulder for obvious brain-os that I miss in the height of my caffeine-powered coding rush. And furthermore, even if I *wanted* to bounce ideas off of more experienced developers or peers (which I do!), I quite simply can't; they don't have expertise in this space. So I do what most contributed module authors do, which is muddle through and try my best. Now, if you do the above query with project = 3060, you will get an extremely healthy project. And by having only a small number of committers, through whom *all* changes are run, this number holds true. However, If we move to a subsystem maintainer committing model, we need to change that query for the Drupal project so that it's WHERE project_component = %d. And if you do /that/, you do not get a rosy Views-esque picture of things like the menu system. You get a very worst-case scenario picture of webchick-maintained contributed modules. So my argument is quite simply that without building this number much higher for each of the underlying subsystems, I don't see what choice core has *but* to turn into the dark, scary kind of contrib by adding more committers to the mix. -Angie From earnie at users.sourceforge.net Mon Apr 20 18:55:27 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 20 Apr 2009 18:55:27 +0000 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> Message-ID: <20090420185527.17020l12is593128@mail.siebunlimited.com> Quoting Bryan Ollendyke : > lol yeah, I believe the intent of the original author was to hold off on D7 > until D6 matured more from a crontrib standpoint. I'll +1 that idea. D5 > was and still is a very mature platform that you can develop and build off > of, seemingly without "need" to upgrade if you have a site up and running > stablly; this isn't always the case with 6 with some of the more major > projects just getting to full releases in the last 6 months. > Especially when you have issues with core modules causing issues with cron actually executing. See http://drupal.org/node/436028 for what I'm referring to. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From gerhard at killesreiter.de Mon Apr 20 18:59:48 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Mon, 20 Apr 2009 20:59:48 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECB9CC.9030807@logrus.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> Message-ID: <49ECC624.5050205@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Earl Miles schrieb: > Dries Buytaert wrote: >> As core matures, we might see more patches getting stale. I think the >> reason is (at least) two-fold: >> >> 1) More patches compete for attention, but fewer of these patches are >> truly important. In this case, patches getting stale is not >> necessarily a bad thing because history has proven that important >> patches will eventually bubble to the top for the right reasons. > > If the 'right reasons' are because the developers got frustrated with > the process and quit pushing their patch, whereas other developers are > extremely stubborn and managed to push their patch through anyway, then > sure. But just because some developer is bullheaded enough to wade > through the crap doesn't mean that's the right reasons. > Right or wrong: this is not new. You always had to be persistent (or stubborn) in order to push through larger changes. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknsxiQACgkQfg6TFvELooQqyACgsWljMV3QDG+bHe8pDa0RCs/s M7sAn1fA7LrXKLnypzJdKupGvxYxByOy =h5fv -----END PGP SIGNATURE----- From merlin at logrus.com Mon Apr 20 19:02:59 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 20 Apr 2009 12:02:59 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <23CCAD87-A0D3-45D1-BA6E-9BA9F62FA176@webchick.net> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <383E1ED4-3C4A-4EF6-A766-0D4D8D6E7886@webchick.net> <49ECBCD3.4030304@logrus.com> <23CCAD87-A0D3-45D1-BA6E-9BA9F62FA176@webchick.net> Message-ID: <49ECC6E3.7090901@logrus.com> Angela Byron wrote: > > On 20-Apr-09, at 2:20 PM, Earl Miles wrote: > >> Angela Byron wrote: >>> On 20-Apr-09, at 2:04 PM, Earl Miles wrote: >>>> Angela Byron wrote: >>>>> We have this kind of decentralized development model, where one or >>>>> two people are solely responsible for code with basically zero peer >>>>> review. It's called contrib. And it's notoriously filled with >>>>> sub-standard, shoddily documented code that needs to be closely >>>>> inspected by individual site maintainers before being deployed on >>>>> any serious production sites. >>>> >>>> I stop following your argument here. The only way this argument >>>> holds up is that if *all* of contrib is substandard crap. It is not. >>>> There is a level of contrib that is above that, and there is a >>>> reason those particular pieces of contrib are above that. Chew on that. >>> And this level contrib is the kind that has enough users so that peer >>> reviews occur naturally, or at the very least peer QA after the fact. >>> As we've noted, peer review and peer QA is *not* happening with these >>> core subsystems, which makes it a lot closer to the "darker, scarier" >>> contrib. So I'm not sure what there is to chew on. :) >> >> Perhaps you attribute more peer review and QA to some of these modules >> than is truly there. I don't think there is very much. There is peer >> review pretty much after the fact; that's the review that said "it's >> ok to use this module." >> >> But the responsibility of the committer is what made that happen in >> the first place. I personally believe that anyone who is given the >> right to commit directly to Drupal core is going to think several >> times longer before committing something than he or she would to >> contrib. Obviously this varies based on personality, but the >> suggestion that adding more committers to core will turn core into >> contrib does not work for me. > > I guess I view it as the following simple pseudo-query, assuming an > active maintainer: > > $relative_project_quality = db_result(db_query('SELECT (number of active > participants in issues, filtering out '+1 subscribe') FROM > {the_issue_queue} WHERE project = %d', $project->nid)). What if a project is small and so mature that there simply aren't issues? Does that make it poor quality? This metric does. Also, flexinode. That also would hit your metric, but the code quality of flexinode was not high. It had a huge number of issue participants because it was a cool idea, not good code. In fact, what your metric gets you are "Things people really want but may not work right," not "quality contrib modules." From merlin at logrus.com Mon Apr 20 19:05:05 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 20 Apr 2009 12:05:05 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECC624.5050205@killesreiter.de> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> <49ECC624.5050205@killesreiter.de> Message-ID: <49ECC761.1070709@logrus.com> Gerhard Killesreiter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Earl Miles schrieb: >> Dries Buytaert wrote: >>> As core matures, we might see more patches getting stale. I think the >>> reason is (at least) two-fold: >>> >>> 1) More patches compete for attention, but fewer of these patches are >>> truly important. In this case, patches getting stale is not >>> necessarily a bad thing because history has proven that important >>> patches will eventually bubble to the top for the right reasons. >> If the 'right reasons' are because the developers got frustrated with >> the process and quit pushing their patch, whereas other developers are >> extremely stubborn and managed to push their patch through anyway, then >> sure. But just because some developer is bullheaded enough to wade >> through the crap doesn't mean that's the right reasons. >> > > Right or wrong: this is not new. You always had to be persistent (or > stubborn) in order to push through larger changes. I don't disagree with this. I disagree with the interpretation: Calling 'being stubborn' the right reasons is not an indication that the right patches float to the top automatically. It is a little bit like argument trickle-down economics: Giving money to the rich enriches the poor. From karoly at negyesi.net Mon Apr 20 19:08:42 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 20 Apr 2009 12:08:42 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECC28B.407@logrus.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <49ECC057.7040101@killesreiter.de> <49ECC28B.407@logrus.com> Message-ID: <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> > The people who have the right to commit will have a more vested interest > There isn't much incentive to do reviews. > There's the good of the project, but there is no pride of ownership in a review. > The pride of ownership drives a lot of the initial development, and it drives the > committers, but the reviewers? I am giving up my neutral position (already...) and I must say: I agree. I *am* sloppy but if I am given the keys to Drupal core? I will second-guess every decision of mine for sure. From development at standoutdesign.nl Mon Apr 20 19:20:49 2009 From: development at standoutdesign.nl (Stefan Nagtegaal) Date: Mon, 20 Apr 2009 21:20:49 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904201136q1549ce31oeaeffdc11e75dd70@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> <7e270cea0904201136q1549ce31oeaeffdc11e75dd70@mail.gmail.com> Message-ID: <7597D04C-CB9A-43C4-83A6-D17B852118B7@standoutdesign.nl> Op 20 apr 2009, om 20:36 heeft Karoly Negyesi het volgende geschreven: >> Plenty of other people give up (either on the individual patch or >> core >> as a whole), > > Note: this is very very and a very sad important fact. Yup, I was one of them.. I was tired of fighting my patch up the issue queue for months. Also the lack of interest of a core committer, for answering some simple questions (what is wrong with this patch? Why isn't this committed yet?) closed the door for me. Now, after 1,5 year without drupal I am trying to get up to speed again. Mainly because the file system has been improved, and because of the fact that I wan;t to participate in the image API overhaul. Seriously, almost 60-70% of the core modules, i have never used or only used to scratch my own itch. The motto "talk is silver, code is gold" has died a long time ago imo, when drupal got more commercial. Now, whenever I look at the drupal.org homepage, drupal.org is being (ab)used for asking people money for some conference, or whatever else.. Drupal isn't the drupal anymore which I *loved* so much in the past. It is grown up, and made to be a money making machine. In my opinion, that is truly a very very sad fact. (Even when it isn't a fact, it's sad people are getting the feeling that this is the case) Kind regards, Stefan From news at unleashedmind.com Mon Apr 20 19:21:59 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Mon, 20 Apr 2009 21:21:59 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201135t4458c0edq7605a1a0c4527517@mail.gmail.com> Message-ID: <0ed301c9c1ed$47194c60$0200a8c0@structworks.com> >From my point of view, this discussion has some real value, but targets other areas that could use improvement. Braindump: It's not about the speed of patches being committed. It's about core patches lacking review, and core evolving in ways and areas that leave contrib behind. It's about contrib development not being able to catch up with core. Core development is driven by some core developers. Only a few of them being contrib maintainers. But the real applications live in contrib. Contrib developers need to catch up with new core APIs and features before they can think about and work on improving core. But next to catching up with that, they also have to maintain, solve issues, and develop new stuff for their projects/applications. By doing so, they identify areas in core that need improvement. At the time they realize what needs improvement, new core APIs are released, so they start from scratch. Contrib should influence and drive core development. Currently, I experience the opposite. I have to decide whether I want to improve my XYZ module or whether I want to work on core without taking into account what XYZ module would really need in X months when new core is released. If I do both, neither core nor my module is mature. Gotta go. sun From neclimdul at gmail.com Mon Apr 20 19:38:24 2009 From: neclimdul at gmail.com (James Gilliland) Date: Mon, 20 Apr 2009 14:38:24 -0500 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECC624.5050205@killesreiter.de> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> <49ECC624.5050205@killesreiter.de> Message-ID: <877d4f280904201238l4ef257fbycd3e78f4c9ae9013@mail.gmail.com> On Mon, Apr 20, 2009 at 1:59 PM, Gerhard Killesreiter < gerhard at killesreiter.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Earl Miles schrieb: > > Dries Buytaert wrote: > >> As core matures, we might see more patches getting stale. I think the > >> reason is (at least) two-fold: > >> > >> 1) More patches compete for attention, but fewer of these patches are > >> truly important. In this case, patches getting stale is not > >> necessarily a bad thing because history has proven that important > >> patches will eventually bubble to the top for the right reasons. > > > > If the 'right reasons' are because the developers got frustrated with > > the process and quit pushing their patch, whereas other developers are > > extremely stubborn and managed to push their patch through anyway, then > > sure. But just because some developer is bullheaded enough to wade > > through the crap doesn't mean that's the right reasons. > > > > Right or wrong: this is not new. You always had to be persistent (or > stubborn) in order to push through larger changes. I noted this wasn't new in a brief chat on irc. More its amplified. It sounds like some people feel things have changed procedurally in someway that has made things worse but its more we haven't grown in the way we do things in a way that's kept up with the size of our community. When the community was smaller it was easier for you to just hope on IRC and talk out a concern with someone about an issue before derailing things. Now there are so many people discussing and so many people with a stake in core these derailing discussions become more and more common place and harder to get around. The way we seem to have delt with this for some crucial systems in the D7 is with numerous code sprints. I don't think this is going to pan out as an answer either since not everyone can pick up and travel or get time off to sit down and contribute to things they are interested in. Another option that's happened is making little Drupal forks in external repositories where they can work on these larger problems. Without any policy or direction this is its own scary can of worms. So, I definitely feel we need to take a look at how we develop core a bit. There seems to be a need to group core into systems and initiatives that people can direct their focus on. I don't think what we really want is to remove the core commiter role but we want to widen things directly below that. Based on the external repositories, maybe the more distributed lieutenant model used in the linux kernel would work for us? That might have a heavy infrastructure cost but it might address the problem. Another option might be just something clever in the d.o redesign that more closely tie issues with groups so issues are easier to find, follow and discuss. There might even be some sort of group/core component ownership that can help funnel better reviews into patches and by proxy better patches to the core committers. Either way, I think that we need something allows the community to scale a little better as we continue to grow. -- James Gilliland -------------- next part -------------- An HTML attachment was scrubbed... URL: From drupal at samboyer.org Mon Apr 20 19:38:22 2009 From: drupal at samboyer.org (Sam Boyer) Date: Mon, 20 Apr 2009 14:38:22 -0500 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> Message-ID: <200904201438.22769.drupal@samboyer.org> On Monday 20 April 2009 14:08:42 Karoly Negyesi wrote: > > The people who have the right to commit will have a more vested interest > > > > There isn't much incentive to do reviews. > > There's the good of the project, but there is no pride of ownership in a > > review. The pride of ownership drives a lot of the initial development, > > and it drives the committers, but the reviewers? > > I am giving up my neutral position (already...) and I must say: I agree. > > I *am* sloppy but if I am given the keys to Drupal core? I will > second-guess every decision of mine for sure. Hear hear for that. Nothing like the knowledge that if you commit a screw-up, it'll be noted by core devs within hours (if not minutes), which any self- respecting dev would find at least a smidge humiliating. When reading this little part of the thread, I got this mental image of Angie and Dries each driving enormous vans along a precarious cliffside road, trying to listen to a cacophony of conflicting navigational advice (ranging in quality from "local expert guide" to "pin the tail on the donkey") mixed in with a healthy dose of griping and "ARE WE THERE YET?!?" Not intended to paint us as whiny or unhelpful. My only point: personally, I got a lot better at navigating after I started driving. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From drupal-devel at webchick.net Mon Apr 20 19:39:27 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Mon, 20 Apr 2009 15:39:27 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECC28B.407@logrus.com> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <49ECC057.7040101@killesreiter.de> <49ECC28B.407@logrus.com> Message-ID: <44F09F04-38AD-453D-B089-29474C921EA7@webchick.net> On 20-Apr-09, at 2:44 PM, Earl Miles wrote: > The reason I think more committers in targeted areas will work is > because I think it will create more activity in those areas. The > people who have the right to commit will have a more vested > interest, and therefore you will get more of their time, effort and > energy, plus any that they can draw to them. webchick commented > earlier that one of the issues was providing an incentive to do > reviews. And that's certainly a key issue, right there. There isn't > much incentive to do reviews. There's the good of the project, but > there is no pride of ownership in a review. The pride of ownership > drives a lot of the initial development, and it drives the > committers, but the reviewers? > > I cannot remember a time in the 4 years I've been with this project > that we haven't had a longstanding complaint about lack of good > patch reviews. That is one of the first complaints I heard then, and > it is one of the complaints I hear now. It has not changed, and > asking people to do more reviews has already proven to be > ineffective in combatting the issue. > > Give your reviewers some ownership and you'll find a lot more people > interested in reviewing. Now this "how to get more reviewers" is a line of discussion I'm *very* interested in having since, regardless if we have subsystem committers or not, we need to resolve it. Here are some ideas around that: 1. A community-led mentorship/journeyman program for people who want to get involved in core development and don't know where to start. Basically, taking what we do at code sprints at Drupalcons twice a year that always lead to a big increase in new core contributors, and making an e-version of it, or something that could be done in person at camps and local meetups. 2. Developing some sort of system that can formalize a bit more "patch review swaps." The biggest incentive people currently have for reviewing a patch is that they want one in core and need to get other reviewers to look at it in order to do so. Making it easier to identify people who are willing to engage in this would help everyone out. 3. Providing tools on g.d.o, d.o, or elsewhere to make it easier for core subsystem maintainers to nurture their pocket of Drupal core. Not really sure what those would be yet. Perhaps one aspect could be liaising with the documentation team to help get their subsystem documentation cleaned up and some clear step 1, step 2, step 3 stuff. 4. Monthly contests for "review queue smashing," like other projects have "bug fix days" or similar. Winners get their name in lights on the d.o front page, or we could pony up for some cash incentives or similar. 5. Calling specific attention out to people who did thorough reviews in commit messages, either by including them in the list of contributors or something like "#xxxx by dev1, dev1, and reviewed by rev1: wah wah wah." 6. Add more people to MAINTAINERS.txt, and have it reflect the current committer "trust" model. If that document can be trusted, this makes it easier for reviewers to know who to talk to if they're interested in helping out with X system. We could also add subsystem maintainer names to the pages on http://drupal.org/community-initiatives/drupal-core perhaps. Curious about others people might have as well. -Angie From tz at it-arts.org Mon Apr 20 19:49:53 2009 From: tz at it-arts.org (Thomas Zahreddin) Date: Mon, 20 Apr 2009 21:49:53 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <44F09F04-38AD-453D-B089-29474C921EA7@webchick.net> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <49ECC057.7040101@killesreiter.de> <49ECC28B.407@logrus.com> <44F09F04-38AD-453D-B089-29474C921EA7@webchick.net> Message-ID: <1240256993.6371.8.camel@thomas-desktop> Am Montag, den 20.04.2009, 15:39 -0400 schrieb Angela Byron: ... > Monthly contests for "review queue smashing," like other projects > have "bug fix days" or similar. Winners get their name in lights on > the d.o front page, or we could pony up for some cash incentives or > similar. I don't want many loosers and a few winners - I want cooperation! Is this so hard to understand? Best Thomas Zahreddin From wdlists at optonline.net Mon Apr 20 20:04:37 2009 From: wdlists at optonline.net (Walt Daniels) Date: Mon, 20 Apr 2009 16:04:37 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECBBA2.60300@logrus.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECBBA2.60300@logrus.com> Message-ID: <9230E4613DE9465BAB0959BF8330B654@Squirt> If code is gold, then documentation is platinum. -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org] On Behalf Of Earl Miles Sent: Monday, April 20, 2009 2:15 PM To: development at drupal.org Subject: Re: [development] Very concerned over Drupal's core development Dries Buytaert wrote: > weigh in and participate in the review process. It is also important > that you convince other people as why your patch should bubble up -- > this is something a lot of people can get better at. This statement right here is what's wrong with Drupal core development. At this time, you must be better at debate, arguing and general Drupal politics than you are at actual code design and implementation. At one point 'talk is silver, code is gold' was the motto. But this has changed. Now talk is gold and code is defined by those who talk the best. From csuthyb at gmail.com Mon Apr 20 20:12:49 2009 From: csuthyb at gmail.com (Csuthy Balint) Date: Mon, 20 Apr 2009 22:12:49 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904201136q1549ce31oeaeffdc11e75dd70@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> <7e270cea0904201136q1549ce31oeaeffdc11e75dd70@mail.gmail.com> Message-ID: <49ECD741.1040008@gmail.com> Karoly Negyesi wrote: >> Plenty of other people give up (either on the individual patch or core >> as a whole), >> > > Note: this is very very and a very sad important fact. > > next fact: there won't be more good core reviewers joke1: your old feature patch is still not in core. Don't worry "There are at least two modules for that!" joke2: create another account on d.o and RTBC your own patch, then at least the core committer will give you a quick review on the changes. joke3: if you need a core patch review, then you should create a blog post about it first. K?roly: sorry, I will not review patches created for the menu module, as I still do not know it enough, and no time to learn it. I have a huge list what should I work on, as many Drupal developers have, but core development is not on the list any more.. I don't know anyone other than Peter who would make the time and would give you a good review. I trust you, so your changes should be in the module. My real advice, if it is possible then create a contrib module which is better than the one in core. I will switch without hesitation.. My reviews will be submitted as bug reports. If something does not work you will know it sooner or later.. Advanced menu would be a good name.. From catch56 at googlemail.com Mon Apr 20 20:30:03 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 20 Apr 2009 21:30:03 +0100 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <200904201438.22769.drupal@samboyer.org> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> Message-ID: On Mon, Apr 20, 2009 at 8:38 PM, Sam Boyer > Hear hear for that. Nothing like the knowledge that if you commit a screw-up, > it'll be noted by core devs within hours (if not minutes), which any self- > respecting dev would find at least a smidge humiliating. > This is interesting, because I find it really comforting that we manage to pick up screw-ups both before and after commit, especially mine, maybe I'm not self-respecting enough. I don't really like the experience of coming across an issue which just got committed and have to mark it code needs work (sometimes with rollback patch ready if it's really, really bad) - but when people do it to me I don't get offended or overly humiliated - I'm just glad it never made it into a final release. Actually I think a big part of the problem is this perception that core is hard and contrib is easy, personally I find the contrib workflow really hard. A lot of people's first attempt to contribute to Drupal is often when they apply for a CVS account to contribute back a module. A lot of companies view that as their primary way to contribute back resources as well. What we end up with is 4,000 projects of very varying quality, and the projects which /everyone/ uses - Views, CCK etc. are crying out for people to help in their issue queues - not just writing and reviewing patches at a high level, but answering support requests, closing out duplicates, stuff like that. One issue with this is the way our user profiles work in terms of highlighting contributions. I'd been contributing to core for more than a year before I got a CVS account, and that was when one of my core patches removed a slice of user.module on the condition it was maintained in contrib. So for a long time I never had any projects listed on my profile page, nor any entries in 'track code'. I've still only got commit access on a handful of projects, and don't actively maintain any of them - a situation I'm quite happy with. However if I posted a couple of crappy modules and committed loads of tiny patches to them, then to the casual observer that'd make the user profile look a lot beefier. The only way that code contributions to core get measured is when Greg Knaddison parses commit logs and puts everything into a spreadsheet once or twice a year - our commit model also completely breaks sites like ohloh. Personally I'd really like better statistics on how many people are reviewing/submitting patches, getting them committed etc. since it'd at least help to spot clear trends when having discussions like these. And I think it'd be a bit of incentive to review and post patches more if there was some way of having that data recorded more firmly than just in commit messages themselves. There was talk of having 'issue queue maintainers' without actual commit access for contrib projects as well - for people who answer lots of support requests and write documentation etc. Similar issue and it goes two ways. Identifying the people who you need to speak to about a particular area is hard unless you know who they are. Identifying what any particular individual is doing is hard unless you trawl through their tracker. There ought to be better ways to deal with this than filing patches to add people to maintainers.txt and having to write big long lists of names in commit messages (then what if you forgot someone or spell their name wrong). Nat From dries.buytaert at gmail.com Mon Apr 20 21:03:08 2009 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon, 20 Apr 2009 23:03:08 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> Message-ID: <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> I think catch hits a lot of good points about how our reward and trust system could be improved. I'm all for better profile pages, giving credit where credit is due, and providing better visibility into who is working on what. It might be useful to provide a "Reviewer rating" or "Reviewer score" -- something which could be an incentive for more people to review patches. Maybe this can be accomplished through some project module extensions? I'm not sure what the best approach would be, but it is worthy of a discussion. On Mon, Apr 20, 2009 at 10:30 PM, Nathaniel Catchpole wrote: > On Mon, Apr 20, 2009 at 8:38 PM, Sam Boyer > >> Hear hear for that. Nothing like the knowledge that if you commit a screw-up, >> it'll be noted by core devs within hours (if not minutes), which any self- >> respecting dev would find at least a smidge humiliating. >> > > This is interesting, because I find it really comforting that we > manage to pick up screw-ups both before and after commit, especially > mine, maybe I'm not self-respecting enough. I don't really like the > experience of coming across an issue which just got committed and have > to mark it code needs work (sometimes with rollback patch ready if > it's really, really bad) - but when people do it to me I don't get > offended or overly humiliated - I'm just glad it never made it into a > final release. > > Actually I think a big part of the problem is this perception that > core is hard and contrib is easy, personally I find the contrib > workflow really hard. > > A lot of people's first attempt to contribute to Drupal is often when > they apply for a CVS account to contribute back a module. A lot of > companies view that as their primary way to contribute back resources > as well. What we end up with is 4,000 projects of very varying > quality, and the projects which /everyone/ uses - Views, CCK etc. are > crying out for people to help in their issue queues - not just writing > and reviewing patches at a high level, but answering support requests, > closing out duplicates, stuff like that. > > One issue with this is the way our user profiles work in terms of > highlighting contributions. I'd been contributing to core for more > than a year before I got a CVS account, and that was when one of my > core patches removed a slice of user.module on the condition it was > maintained in contrib. So for a long time I never had any projects > listed on my profile page, nor any entries in 'track code'. I've still > only got commit access on a handful of projects, and don't actively > maintain any of them - a situation I'm quite happy with. However if I > posted a couple of crappy modules and committed loads of tiny patches > to them, then to the casual observer that'd make the user profile look > a lot beefier. > > The only way that code contributions to core get measured is when Greg > Knaddison parses commit logs and puts everything into a spreadsheet > once or twice a year - our commit model also completely breaks sites > like ohloh. Personally I'd really like better statistics on how many > people are reviewing/submitting patches, getting them committed etc. > since it'd at least help to spot clear trends when having discussions > like these. And I think it'd be a bit of incentive to review and post > patches more if there was some way of having that data recorded more > firmly than just in commit messages themselves. > > There was talk of having 'issue queue maintainers' without actual > commit access for contrib projects as well - for people who answer > lots of support requests and write documentation etc. Similar issue > and it goes two ways. Identifying the people who you need to speak to > about a particular area is hard unless you know who they are. > Identifying what any particular individual is doing is hard unless you > trawl through their tracker. There ought to be better ways to deal > with this than filing patches to add people to maintainers.txt and > having to write big long lists of names in commit messages (then what > if you forgot someone or spell their name wrong). > > Nat > -- Dries Buytaert :: http://buytaert.net/ From dries.buytaert at gmail.com Mon Apr 20 21:04:34 2009 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon, 20 Apr 2009 23:04:34 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <200904201438.22769.drupal@samboyer.org> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> Message-ID: <61bca48a0904201404o89792b8s7df4dd41cbe8769e@mail.gmail.com> On Mon, Apr 20, 2009 at 9:38 PM, Sam Boyer wrote: > When reading this little part of the thread, I got this mental image of Angie > and Dries each driving enormous vans along a precarious cliffside road, trying > to listen to a cacophony of conflicting navigational advice (ranging in > quality from "local expert guide" to "pin the tail on the donkey") mixed in > with a healthy dose of griping and "ARE WE THERE YET?!?" Roflmao! -- Dries Buytaert :: http://buytaert.net/ From jpetso at gmx.at Mon Apr 20 21:04:32 2009 From: jpetso at gmx.at (Jakob Petsovits) Date: Mon, 20 Apr 2009 23:04:32 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <200904201438.22769.drupal@samboyer.org> Message-ID: <200904202304.33275.jpetso@gmx.at> On Monday 20 April 2009, Nathaniel Catchpole wrote: > The only way that code contributions to core get measured is when Greg > Knaddison parses commit logs and puts everything into a spreadsheet > once or twice a year - our commit model also completely breaks sites > like ohloh. It's not the commit model that breaks Ohloh but the fact that we're using a distributed version control workflow with a centralized one (CVS) as tool. That's a mismatch, because most projects using centralized VCSs don't work that way. In fact, iirc then Linus Torvalds dropped CVS in favor of Bitkeeper (later Git) because the former did not work with his development model. Now they're working as a bunch of subsystem teams with each subsystem maintainer keeping track of his version of the Linux kernel, while the final word is still spoken by Linus who has a lot of say in terms of direction and the "large picture" (or should I say "macro-problems"). Sound familiar? Of course, even current DVCSs treat reviewed-by and approved-by as part of the textual message instead of core concept. As long as it's standardized though, Ohloh should be able to deal with it :) From alex at developmentseed.org Mon Apr 20 21:15:25 2009 From: alex at developmentseed.org (Alex Barth) Date: Mon, 20 Apr 2009 17:15:25 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <44F09F04-38AD-453D-B089-29474C921EA7@webchick.net> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <49ECC057.7040101@killesreiter.de> <49ECC28B.407@logrus.com> <44F09F04-38AD-453D-B089-29474C921EA7@webchick.net> Message-ID: <82DC36A8-BF56-4ACA-A431-56551048B0C7@developmentseed.org> On Apr 20, 2009, at 3:39 PM, Angela Byron wrote: > > On 20-Apr-09, at 2:44 PM, Earl Miles wrote: > >> The reason I think more committers in targeted areas will work is >> because I think it will create more activity in those areas. The >> people who have the right to commit will have a more vested >> interest, and therefore you will get more of their time, effort and >> energy, plus any that they can draw to them. webchick commented >> earlier that one of the issues was providing an incentive to do >> reviews. And that's certainly a key issue, right there. There isn't >> much incentive to do reviews. There's the good of the project, but >> there is no pride of ownership in a review. The pride of ownership >> drives a lot of the initial development, and it drives the >> committers, but the reviewers? >> >> I cannot remember a time in the 4 years I've been with this project >> that we haven't had a longstanding complaint about lack of good >> patch reviews. That is one of the first complaints I heard then, >> and it is one of the complaints I hear now. It has not changed, and >> asking people to do more reviews has already proven to be >> ineffective in combatting the issue. >> >> Give your reviewers some ownership and you'll find a lot more >> people interested in reviewing. > > Now this "how to get more reviewers" is a line of discussion I'm > *very* interested in having since, regardless if we have subsystem > committers or not, we need to resolve it. A huge disincentive for getting involved in core is that it doesn't yield immediately deployable results. This keeps shops and individuals from putting more labor towards core work. Robert Douglass suggested on this thread to remove modules that don't absolutely need to be in core (aggregator, blog, blogapi, forum). I absolutely concur. This would not just make core easier to overlook and remove a huge tax from the drupal core infrastructure, but it would most importantly allow us to release and deploy these modules quicker. Like mentioned already by others on this thread, these modules could create a new tier of Drupal modules on d.o. that would be packaged with installer profiles and maintained for core compatibility for every release of the current Drupal release branch and Drupal HEAD. In my mind, such a third tier of modules would fill the gap between core and contrib: it would create a peer reviewed space between Drupal core and Drupal contrib while not suffering from long release cycles. In turn we would get more reviewers for the new tier of modules but I also for Drupal core as there is going to be more activity on modules that will be available in the current release branch *and* in HEAD. A third tier of Drupal modules does not solve all issues of course, but I think it makes our problem *a lot* smaller. > > > Here are some ideas around that: > > 1. A community-led mentorship/journeyman program for people who want > to get involved in core development and don't know where to start. > Basically, taking what we do at code sprints at Drupalcons twice a > year that always lead to a big increase in new core contributors, > and making an e-version of it, or something that could be done in > person at camps and local meetups. > > 2. Developing some sort of system that can formalize a bit more > "patch review swaps." The biggest incentive people currently have > for reviewing a patch is that they want one in core and need to get > other reviewers to look at it in order to do so. Making it easier to > identify people who are willing to engage in this would help > everyone out. > > 3. Providing tools on g.d.o, d.o, or elsewhere to make it easier for > core subsystem maintainers to nurture their pocket of Drupal core. > Not really sure what those would be yet. Perhaps one aspect could be > liaising with the documentation team to help get their subsystem > documentation cleaned up and some clear step 1, step 2, step 3 stuff. > > 4. Monthly contests for "review queue smashing," like other projects > have "bug fix days" or similar. Winners get their name in lights on > the d.o front page, or we could pony up for some cash incentives or > similar. > > 5. Calling specific attention out to people who did thorough reviews > in commit messages, either by including them in the list of > contributors or something like "#xxxx by dev1, dev1, and reviewed by > rev1: wah wah wah." > > 6. Add more people to MAINTAINERS.txt, and have it reflect the > current committer "trust" model. If that document can be trusted, > this makes it easier for reviewers to know who to talk to if they're > interested in helping out with X system. We could also add subsystem > maintainer names to the pages on http://drupal.org/community-initiatives/drupal-core > perhaps. > > Curious about others people might have as well. > > -Angie > Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633 From dries.buytaert at gmail.com Mon Apr 20 21:19:03 2009 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon, 20 Apr 2009 23:19:03 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> Message-ID: <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> Something else which is worth to discuss. In private conversations, various people have expressed concerns that our release cycles are too long, and that, as a result, they are not interested in working on core. If they have a problem, and they fix it in core, they have to wait 1-2 years before they can actual use their own improvement in a production environment. In a lot of cases, people don't bother with it because they can't wait that long. We see evidence of that around code freeze time, when people actually do start to bother and patches tend to move through the review cycle quite a bit faster -- creating it own set of frustrations. In other words, moving to shorter release cycles could help. Not only does it increase the incentive for people to work on core, it could also provide additional focus. Because we have been working on Drupal 6 so long, people might have lost some of their incentive and motivation. There is a certain engery-cycle/rhythm that we might have broken with the longer Drupal 6 development cycle. In fact, a lot of big projects, like the Linux kernel, Gnome, KDE, Ubuntu, Fedora and Wordpress all switched to 6 month release cycles. Mark Shuttleworth posted some good insights about that in a recent blog post: http://www.markshuttleworth.com/archives/288. I'm not suggesting that we should switch to 6 month release cycles, I'm merely bringing it up to get feedback on the idea. On Mon, Apr 20, 2009 at 11:03 PM, Dries Buytaert wrote: > I think catch hits a lot of good points about how our reward and trust > system could be improved. ?I'm all for better profile pages, giving > credit where credit is due, and providing better visibility into who > is working on what. ?It might be useful to provide a "Reviewer rating" > or "Reviewer score" -- something which could be an incentive for more > people to review patches. ?Maybe this can be accomplished through some > project module extensions? ?I'm not sure what the best approach would > be, but it is worthy of a discussion. -- Dries Buytaert :: http://buytaert.net/ From m.kruisselbrink at student.tue.nl Mon Apr 20 21:27:31 2009 From: m.kruisselbrink at student.tue.nl (Marijn Kruisselbrink) Date: Mon, 20 Apr 2009 23:27:31 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> Message-ID: <200904202327.31699.m.kruisselbrink@student.tue.nl> On Monday 20 April 2009 23:19:03 Dries Buytaert wrote: > In fact, a lot of big projects, like the Linux kernel, Gnome, KDE, > Ubuntu, Fedora and Wordpress all switched to 6 month release cycles. > Mark Shuttleworth posted some good insights about that in a recent > blog post: http://www.markshuttleworth.com/archives/288. I'm not > suggesting that we should switch to 6 month release cycles, I'm merely > bringing it up to get feedback on the idea. I don't think any of those projects have 6 month release cycles that break backwards compatibility, which I think major drupal releases do... Marijn From cxjohnson at gmail.com Mon Apr 20 21:36:50 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 20 Apr 2009 16:36:50 -0500 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECB9CC.9030807@logrus.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECB9CC.9030807@logrus.com> Message-ID: <9ea8d6030904201436n65b83ce8ud7396bdf6644cfc8@mail.gmail.com> On Mon, Apr 20, 2009 at 1:07 PM, Earl Miles wrote: > Dries Buytaert wrote: >> >> As core matures, we might see more patches getting stale. ?I think the >> reason is (at least) two-fold: >> >> ?1) More patches compete for attention, but fewer of these patches are >> truly important. ?In this case, patches getting stale is not >> necessarily a bad thing because history has proven that important >> patches will eventually bubble to the top for the right reasons. > > If the 'right reasons' are because the developers got frustrated with the > process and quit pushing their patch, whereas other developers are extremely > stubborn and managed to push their patch through anyway, then sure. But just > because some developer is bullheaded enough to wade through the crap doesn't > mean that's the right reasons. > That, and time. Core committers, as the DCDC comment noted, are those with more time to devote to the effort. It's tough to find the time to contribute to core because the entry point is high, but additionally because it's painful to spend lots of time on a core patch, only to see it languish. The same amount of effort can create and maintain several contrib modules. From tz at it-arts.org Mon Apr 20 21:38:19 2009 From: tz at it-arts.org (Thomas Zahreddin) Date: Mon, 20 Apr 2009 23:38:19 +0200 Subject: [development] Very concerned over Drupal's core development - Meta -reflection In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> Message-ID: <1240263499.6371.50.camel@thomas-desktop> Hi, this or similar topics come up again and again. The fact of repetition of complains and topics like this comming up from time to time (see eg. october / november 2008: http://lists.drupal.org/pipermail/development/2008-October/031263.html). So putting in the mailinglist more arguments for whatever will probably not help, since these discussions and all related arguments come up every few months. What can we learn form that fact? 1.) The topic was not solved in November 2008 - at least not for the people discussing in this thread now. 2.) The process to solve the issue '[development] How to post bug reports and patches' failed! (hope the following is clear enough for chx ;-) ) What can we do? 1.) Getting a better insight of what are the complains / bugs of the actual problem / issue. 2.) Define with all related persons (users, developers ...) a aim / goal. 3.) Define measures for the aim / goal to measure progress and completion (or for ongoing task monitoring criteria and corridors where the measured values should stay in) 4.) Identify the influencing factors for the measurement criteria. 5.) Integreate all criteria and influencing factor to a model of the problem. 6.) Identify all people who rule over the influencing factors and who are affected of the problem, identify the needs of all the involved persons. 7.) Decide with all involved persons what influencing fatctors should be changed. 8.) Create a project plan for the change. 9.) Perform the planed changes with the involved persons. 10.) Check your results on the defined measurements and criterias. 11.) Decide with all involved persons to iterate or to stop. So please let me know, if you understand these eleven steps, bevor we go to discuss how we walk the talk. Best Thomas Zahreddin (I pointed this out to Dries even in Barcelona, but we did not find the time to speak about in detail - so unsolved problems keep coming back ;-) ) From catch56 at googlemail.com Mon Apr 20 21:44:46 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 20 Apr 2009 22:44:46 +0100 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> Message-ID: On Mon, Apr 20, 2009 at 10:19 PM, Dries Buytaert wrote: > Something else which is worth to discuss. > > In private conversations, various people have expressed concerns that > our release cycles are too long, and that, as a result, they are not > interested in working on core. ?If they have a problem, and they fix > it in core, they have to wait 1-2 years before they can actual use > their own improvement in a production environment. ?In a lot of cases, > people don't bother with it because they can't wait that long. > > > In other words, moving to shorter release cycles could help. ?Not only > does it increase the incentive for people to work on core, it could > also provide additional focus. With testing, dbtng and Field API I think it would have been impossible to get them all in during the six month release cycle, and hard to do any of them properly in that time either (unless they were committed the first week) - actually writing tests and converting modules has taken a long time, and that's been a good thing as all three APIs are maturing during the process. However, having made all those big changes in one release, it'd be really interesting to consider a shorter cycle for Drupal 8. Some things which are looking less likely for Drupal 7 (views in core, a non-crappy comment and forum module) would be great to have in a shorter timespan than another two year release cycle. Nat > > In fact, a lot of big projects, like the Linux kernel, Gnome, KDE, > Ubuntu, Fedora and Wordpress all switched to 6 month release cycles. > Mark Shuttleworth posted some good insights about that in a recent > blog post: http://www.markshuttleworth.com/archives/288. ?I'm not > suggesting that we should switch to 6 month release cycles, I'm merely > bringing it up to get feedback on the idea. > > > On Mon, Apr 20, 2009 at 11:03 PM, Dries Buytaert > wrote: >> I think catch hits a lot of good points about how our reward and trust >> system could be improved. ?I'm all for better profile pages, giving >> credit where credit is due, and providing better visibility into who >> is working on what. ?It might be useful to provide a "Reviewer rating" >> or "Reviewer score" -- something which could be an incentive for more >> people to review patches. ?Maybe this can be accomplished through some >> project module extensions? ?I'm not sure what the best approach would >> be, but it is worthy of a discussion. > > -- > Dries Buytaert :: http://buytaert.net/ > From hovercrafter at earthlink.net Mon Apr 20 22:24:19 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Mon, 20 Apr 2009 18:24:19 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <200904202327.31699.m.kruisselbrink@student.tue.nl> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> Message-ID: <49ECF613.3080109@earthlink.net> Marijn Kruisselbrink wrote: > On Monday 20 April 2009 23:19:03 Dries Buytaert wrote: > > In fact, a lot of big projects, like the Linux kernel, Gnome, KDE, > > Ubuntu, Fedora and Wordpress all switched to 6 month release cycles. > > Mark Shuttleworth posted some good insights about that in a recent > > blog post: http://www.markshuttleworth.com/archives/288. I'm not > > suggesting that we should switch to 6 month release cycles, I'm merely > > bringing it up to get feedback on the idea. > I don't think any of those projects have 6 month release cycles that break > backwards compatibility, which I think major drupal releases do... > > Marijn > > Looking at that list, one thing sticks out - there is only one blogging/CMS platform listed. Even though I know that list isn't a comprehensive collection of project release cycles, can anyone find any other blogging or CMS system pushing releases out every six months? I'm not saying its a bad thing, but I believe serious consideration needs to be given to backwards compatibility and support length of releases. Perhaps one good route for Drupal would be to mimic the Ubuntu system of offering a "long term support"release after X releases. That would benefit sites with a large custom code base, or even the smaller guy, who is less tech-savvy and dreads the upgrade for fear of breaking their site. From karoly at negyesi.net Mon Apr 20 23:01:08 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 20 Apr 2009 16:01:08 -0700 Subject: [development] Some of core to contrib? Message-ID: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> Hi, So it seems there is quite some talk about moving some of the core to contrib. This talk comes up from time but we did not have testing and now we do. And that makes a big, big difference, I tell you. So let's suppose that aggregator gets moved into contrib. Every core tarball still contains aggregator, the latest tag from the DRUPAL-7--1 branch. But the aggregator people can churn out bugfixes as fast as they can and the tests will make sure they won't break stuff. Meanwhile, new features can get into DRUPAL-7--2. Every user can use --2 invidually, core will come with --1 still. Also, they maintain a DRUPAL-8--1 branch and for every unstable/beta/RC they make sure they have ported aggregator and tag similarly as core does (we can punt some of the unstables -- I could understand that not every module gets DBTNG'd immediately it did not happen anyways). Let's list the benefits again: *) if a company is interested in a module it can grow a community around much easier than with core. They can both release bugfixes and features. *) core does not lose the feedback from its modules Possible problems: *) lose of maintenance *) additional burden on these maintainers w/ HEAD compatibility. Also, aspiring projects can opt for core inclusion (if they accept that a branch can not break APIs and willing to tag along with core) which can be much easier this way. Let's face it, there are much higher quality contribs than the mess called comment module so why not? There is the small problem of how can people using cvs update core now, do they need to run a cvs up for every directory? Hardly. We can create a 'mirror' which pulls together the commits. This is an easily doable (and yes I am willing to script it). Regards Karoly Negyesi From catch56 at googlemail.com Mon Apr 20 23:23:29 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 21 Apr 2009 00:23:29 +0100 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> Message-ID: So we discussed this a lot in irc this evening and I personally like it a lot. It's got a lot of advantages over simply dumping poll in contrib, or giving chx commit access to menu.inc. 1. We're not giving additional commit access to subsystems, just to user-facing optional core modules which don't require the same levels of expertise in patch reviews as the database layer or FAPI. 2. All issues for these modules would still show up in the core issue queue (hopefully, somehow). 3. We wouldn't break any APIs in the official core release 4. Development still happens in HEAD, with features and bug fixes backported to 7.x-2.x and bug fixes only backported to 7.x.1-x. That way, for these modules at least, there's a consistent release model, parallel to core (apart from the 2.x branch), which they all follow - so you know you're not going to get new features or API breakage in 7.x-1.8 or anything like that, and you're guaranteed an upgrade path (unlike trying to mimic this with a fork in contrib and forward porting). 5. The majority of improvements to these modules (which don't rely on API changes elsewhere in core) would be available in a release within a month or two of getting committed to HEAD, not a year or two - which would provide many more incentives to contribute to them. 6. The 7.x-2.x branch being used on real sites (opt-in only, not shipped with core), means that 8.x-1.x will be ultra-stable and subject to lots of real-world usage - no-one clicks around core any more now we have the test bot, now they pretty much would. This means /more/ review of changes in HEAD before a release, not less. Our core CMS-like modules really suffer for lack of this - comment, forum, aggregator are all in a sorry state. 7. Nothing changes for the core-required modules or anything in /includes It'd be more work than now, but work which people would actually be able to see the benefits of a lot quicker, meaning it'd be much easier to build up the teams which webchick was talking about to distribute that work - and wouldn't require a change to the core development cycle itself. Nat On Tue, Apr 21, 2009 at 12:01 AM, Karoly Negyesi wrote: > Hi, > > So it seems there is quite some talk about moving some of the core to > contrib. This talk comes up from time but we did not have testing and > now we do. And that makes a big, big difference, I tell you. > > So let's suppose that aggregator gets moved into contrib. Every core > tarball still contains aggregator, the latest tag from the DRUPAL-7--1 > branch. But the aggregator people can churn out bugfixes as fast as > they can and the tests will make sure they won't break stuff. > Meanwhile, new features can get into DRUPAL-7--2. Every user can use > --2 invidually, core will come with --1 still. Also, they maintain a > DRUPAL-8--1 branch and for every unstable/beta/RC they make sure they > have ported aggregator and tag similarly as core does (we can punt > some of the unstables -- I could understand that not every module gets > DBTNG'd immediately it did not happen anyways). Let's list the > benefits again: > > *) if a company is interested in a module it can grow a community > around much easier than with core. They can both release bugfixes and > features. > *) core does not lose the feedback from its modules > > Possible problems: > > *) lose of maintenance > *) additional burden on these maintainers w/ HEAD compatibility. > > Also, aspiring projects can opt for core inclusion (if they accept > that a branch can not break APIs and willing to tag along with core) > which can be much easier this way. Let's face it, there are much > higher quality contribs than the mess called comment module so why > not? > > There is the small problem of how can people using cvs update core > now, do they need to run a cvs up for every directory? Hardly. We can > create a 'mirror' which pulls together the commits. This is an easily > doable (and yes I am willing to script it). > > Regards > > Karoly Negyesi > From pwolanin at gmail.com Mon Apr 20 23:33:04 2009 From: pwolanin at gmail.com (Peter Wolanin) Date: Mon, 20 Apr 2009 19:33:04 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <23CCAD87-A0D3-45D1-BA6E-9BA9F62FA176@webchick.net> References: <49EC7B14.7060706@killesreiter.de> <0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com> <89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com> <7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com> <49EC962C.70107@islandnet.com> <49ECB91F.8050305@logrus.com> <383E1ED4-3C4A-4EF6-A766-0D4D8D6E7886@webchick.net> <49ECBCD3.4030304@logrus.com> <23CCAD87-A0D3-45D1-BA6E-9BA9F62FA176@webchick.net> Message-ID: <2247a8a70904201633t35e78200v3385afd63161279c@mail.gmail.com> On Mon, Apr 20, 2009 at 2:48 PM, Angela Byron wrote: > So my argument is quite simply that without building this number much higher > for each of the underlying subsystems, I don't see what choice core has > *but* to turn into the dark, scary kind of contrib by adding more committers > to the mix. > > -Angie I have to take issue with this in as much as any added committers would almost certainly not (as you do not) commit their own patches. If we were to move towards the notion of subsystem committers I would imagine that they would have to be in close communication with you and Dires about the overall direction and API design, get one or more serious reviews in addition to their own review, and probably would have much less time for writing patches as opposed to reviewing and committing them. In other words, they would behave w.r.t. a subset of the code in much as we observe you (and Gabor, and Neil) behaving. -Peter From drupal at ryancross.com Mon Apr 20 23:43:24 2009 From: drupal at ryancross.com (Ryan Cross) Date: Tue, 21 Apr 2009 09:43:24 +1000 Subject: [development] Some of core to contrib? In-Reply-To: References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> Message-ID: <4e983be00904201643y6a872222l4da4460e8fe98375@mail.gmail.com> This sounds like it would also have the knock-on effect of making it easier for more/different modules to get included in core over time, which I think many people are also keen on. Is that part of the consideration? seems like with this process we could conceivably have a "experimental" couple of modules included in each version to test their suitability for core. (like the tokens module or similar) I am not sure I followed the necessary cvs tag work flow completely, but I'm sure you're discussed the details and the overview sounds good. Would this mean that we would get a packaging script for install profiles? Side note - several people are commenting that comment.module is quite poor. Is there an alternative that people are using that I'm not aware of? It works for me usually. From catch56 at googlemail.com Tue Apr 21 00:04:44 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 21 Apr 2009 01:04:44 +0100 Subject: [development] Some of core to contrib? In-Reply-To: <4e983be00904201643y6a872222l4da4460e8fe98375@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <4e983be00904201643y6a872222l4da4460e8fe98375@mail.gmail.com> Message-ID: On Tue, Apr 21, 2009 at 12:43 AM, Ryan Cross wrote: > This sounds like it would also have the knock-on effect of making it > easier for more/different modules to get included in core over time, > which I think many people are also keen on. I think it'd make it easier to move modules in and out of core yes. With token specifically that'd be unlikely to be a module in Drupal core - it'd probably be part of system.module since everything else would need to use it. Views also would have to move into core proper since we'd want to use it for administrative pages etc. - so it's not a model that'd work for everything, and generally not for 'cool API-providing modules we want to see in core'. The only reason I'd suggest it for things like comment and forum is they don't provide far-reaching APIs. > I am not sure I followed the necessary cvs tag work flow completely, > but I'm sure you're discussed the details and the overview sounds > good. Would this mean that we would get a packaging script for install > profiles? > We didn't discuss this in any depth, just the overview. > Side note - several people are commenting that comment.module is quite > poor. Is there an alternative that people are using that I'm not aware > of? It works for me usually. > comment.module works for most things, but the code, APIs, architecture and a few very annoying long-running bugs haven't changed much since Drupal 4.something. For the basic job of attaching comments to nodes it's completely fine, but it's not what it should be. For example you can't attach fields to comments in Drupal 7 yet, and no-one has started work on a patch. More on that general area here: http://groups.drupal.org/node/18705 - and no I'm not aware of any viable contrib alternatives except nodecomment. Nat From gerhard at killesreiter.de Tue Apr 21 00:05:52 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue, 21 Apr 2009 02:05:52 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> Message-ID: <49ED0DE0.2070203@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dries Buytaert schrieb: > blog post: http://www.markshuttleworth.com/archives/288. I'm not > suggesting that we should switch to 6 month release cycles, I'm merely > bringing it up to get feedback on the idea. I'd be very happy if we could at least break the trend towards longer and longer release cycles. 4.5.0 October 18, 2004 4.6.0 April 15, 2005 4.7.0 May 1, 2006 5.0 January 15, 2007 6.0 February 13, 2008 7.0 Codefreeze: Sept 2009 6, 12, 8, 13, 18+, ...? Cheers, Gerhard P.S.: Whoever thinks about complaining about the perceived lack of commercial viability of such a development model: Just can it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkntDd8ACgkQfg6TFvELooSpnQCgp29vFEfNBK4vx2nu4J1+T1Ge Jk8An18wUCezp/I+lcQG/xfbbJI7rZ6t =ZAq5 -----END PGP SIGNATURE----- From karoly at negyesi.net Tue Apr 21 00:21:35 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 20 Apr 2009 17:21:35 -0700 Subject: [development] Some of core to contrib? In-Reply-To: References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <4e983be00904201643y6a872222l4da4460e8fe98375@mail.gmail.com> Message-ID: <7e270cea0904201721i5e3c0723u77c249fa720f5116@mail.gmail.com> >> I am not sure I followed the necessary cvs tag work flow completely, >> but I'm sure you're discussed the details and the overview sounds >> good. Would this mean that we would get a packaging script for install >> profiles? > We didn't discuss this in any depth, just the overview. Absolutely not. Writing the packaging script for every install profile out there is a colossal task, it needs profile changes (I need Panels3...) too. We are talking of one install profile here, the Drupal core install profile. I have not looked at the code but surely Drupal is already special cased from contrib, it's another repo, different tag structure so it'd not be that big a change and once again, it's a change I am willing to contribute to. Once again, the way I imagine this, there would be a repository merged together from core and these core-contrib hybrid modules and you can check out from there. The fundamental difference between merely giving people commit access to specific parts of core is the ability for them to develop a DRUPAL-7--2 alongside the DRUPAL-8--1 version if they so want (and I believe they will want to). This makes it possible to have (some of the) aggregator features from D8 on a D7 install without having the whole site on D8. If the question is, but then why would anyone want to upgrade to D8, there will still be huge under the hood changes (DBTNG, registry) which you will want to have. NK From drupal at samboyer.org Tue Apr 21 00:44:04 2009 From: drupal at samboyer.org (Sam Boyer) Date: Mon, 20 Apr 2009 19:44:04 -0500 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <200904201438.22769.drupal@samboyer.org> Message-ID: <200904201944.10054.drupal@samboyer.org> On Monday 20 April 2009 15:30:03 Nathaniel Catchpole wrote: > One issue with this is the way our user profiles work in terms of > highlighting contributions. I'd been contributing to core for more > than a year before I got a CVS account, and that was when one of my > core patches removed a slice of user.module on the condition it was > maintained in contrib. So for a long time I never had any projects > listed on my profile page, nor any entries in 'track code'. I've still > only got commit access on a handful of projects, and don't actively > maintain any of them - a situation I'm quite happy with. However if I > posted a couple of crappy modules and committed loads of tiny patches > to them, then to the casual observer that'd make the user profile look > a lot beefier. > > The only way that code contributions to core get measured is when Greg > Knaddison parses commit logs and puts everything into a spreadsheet > once or twice a year - our commit model also completely breaks sites > like ohloh. Personally I'd really like better statistics on how many > people are reviewing/submitting patches, getting them committed etc. > since it'd at least help to spot clear trends when having discussions > like these. And I think it'd be a bit of incentive to review and post > patches more if there was some way of having that data recorded more > firmly than just in commit messages themselves. Heh. So I had a project that I started on last fall which would do exactly this kind of thing - collect richer statistics on drupal participation - and I'm gonna have to finish if I want to get my degree. Which reminds me that I've been meaning to ask if someone couldn't point me towards any colossal discussion(s) we've had about this kind of thing of thing in the past, so that I can digest what's already been thrown around. cheers Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From metzlerd at metzlerd.com Tue Apr 21 00:47:38 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Mon, 20 Apr 2009 17:47:38 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> Message-ID: <8B0EE0CA-CD2F-40B7-B278-98256A54E2FF@metzlerd.com> IMHO, we'd have to have a different stance on backward compatibility if we were planning on shortening release cycles much. The linux Kernel does not require significant refactoring of code built on top of it every 6 months. I'm still not sure if I have a migration path identified for my universities drupal sites with D6, even though I've already ported all of my modules to D6. It is possible that much of the interesting work about extending drupal really is properly in contrib and not in Core. The fact that most of what I hear being touted as new features for drupal 6/7 are the movement of contrib support into core is not necessarily a bad thing. It''s pretty proven code after all. I think finding a pathway to move old stuff out of core is not necessarily a bad idea either. Strikes me as the pathway for evolution of drupal. I think think the right answer about drupal stagnating was really about having Views, Panels, and WYSIWG api all going through major refactoring on D6, all lagging significantly the D6 release. I know it's why I'm not using my own D6 ported modules in any production sites yet. Dave On Apr 20, 2009, at 2:19 PM, Dries Buytaert wrote: > Something else which is worth to discuss. > > In private conversations, various people have expressed concerns that > our release cycles are too long, and that, as a result, they are not > interested in working on core. If they have a problem, and they fix > it in core, they have to wait 1-2 years before they can actual use > their own improvement in a production environment. In a lot of cases, > people don't bother with it because they can't wait that long. > > We see evidence of that around code freeze time, when people actually > do start to bother and patches tend to move through the review cycle > quite a bit faster -- creating it own set of frustrations. > > In other words, moving to shorter release cycles could help. Not only > does it increase the incentive for people to work on core, it could > also provide additional focus. Because we have been working on Drupal > 6 so long, people might have lost some of their incentive and > motivation. There is a certain engery-cycle/rhythm that we might have > broken with the longer Drupal 6 development cycle. > > In fact, a lot of big projects, like the Linux kernel, Gnome, KDE, > Ubuntu, Fedora and Wordpress all switched to 6 month release cycles. > Mark Shuttleworth posted some good insights about that in a recent > blog post: http://www.markshuttleworth.com/archives/288. I'm not > suggesting that we should switch to 6 month release cycles, I'm merely > bringing it up to get feedback on the idea. > > > On Mon, Apr 20, 2009 at 11:03 PM, Dries Buytaert > wrote: >> I think catch hits a lot of good points about how our reward and >> trust >> system could be improved. I'm all for better profile pages, giving >> credit where credit is due, and providing better visibility into who >> is working on what. It might be useful to provide a "Reviewer >> rating" >> or "Reviewer score" -- something which could be an incentive for more >> people to review patches. Maybe this can be accomplished through >> some >> project module extensions? I'm not sure what the best approach would >> be, but it is worthy of a discussion. > > -- > Dries Buytaert :: http://buytaert.net/ From drumm at delocalizedham.com Tue Apr 21 03:06:32 2009 From: drumm at delocalizedham.com (Neil Drumm) Date: Mon, 20 Apr 2009 20:06:32 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> Message-ID: I'm not going to pretend I read this whole thread, these are some general thoughts on this discussion. I don't have a lot of answers. We should understand why this situation exists before attempting to solve it. I have not contributed a lot to Drupal 7. I didn't contribute a lot to Drupal 6, but that was because I was spending more time on Drupal 5. I can't blame this on the process, I've worked with it and know how it works. The main factor is how I use my time, but the process does make a difference. We should focus on removing barriers and pain points, not adding complexity. Many minor changes are better than major changes. The current bottleneck does seem to be reviewing, not committing. Planning out big changes is hard, but that might be okay. UI makes a big difference. Issue tags changed how people structure their attention. Flag integration will remove subscribe noise. We haven't tested testing in a code freeze situation. More problems should be found and improved. I would like to see more quantitative data. Giant mailing list discussions have their place, but we need some way to test/prove/quantify/measure. Not everything can be quantified, but we should do something better than a big bag of opinions. Structural changes are okay. We have gotten where we are with the same structure since 4.7, and that was simply adding another committer per-version. Something has been working, but the size and scope of the problem has changed. I don't know what/if structural changes would be ideal. Adding more core committers without changing the structure would likely be good short-term, but we will run into the same situation later, that might be okay. Adding subsystem maintainers might be helpful, as long as we remember that writing and committing are different processes. Any additional committers need to be skilled willing volunteers with time. I am fine with the Dries chooses process. If you are seriously interested in filling a new position, you should already be doing what you want to do, then we remove a step from your process. We should not make complex CVS branch/tag/repository systems. We should keep things simple and, if there are structural changes, consider moving to a distributed version control system. API changes per year, reguardless of release cycle, should go down, which is a good thing. This is a more important measure than release cycle length. More features and APIs, not necessarily modules, should go into core, we are too reliant on contrib. Substantive things to do to help are: - Review patches and look for annoyances in the process. - Contribute to the Drupal.org redesign, http://groups.drupal.org/drupalorg-redesign-implementers. - Contribute to project module, http://drupal.org/project/project. - If you are serious about changes, go ahead and do the work. If it works, we can codify it. -Neil -- Neil Drumm http://delocalizedham.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpetso at gmx.at Tue Apr 21 05:50:54 2009 From: jpetso at gmx.at (Jakob Petsovits) Date: Tue, 21 Apr 2009 07:50:54 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <200904202327.31699.m.kruisselbrink@student.tue.nl> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> Message-ID: <200904210750.55120.jpetso@gmx.at> On Monday 20 April 2009, Marijn Kruisselbrink wrote: > On Monday 20 April 2009 23:19:03 Dries Buytaert wrote: > > In fact, a lot of big projects, like the Linux kernel, Gnome, KDE, > > Ubuntu, Fedora and Wordpress all switched to 6 month release cycles. > > Mark Shuttleworth posted some good insights about that in a recent > > blog post: http://www.markshuttleworth.com/archives/288. I'm not > > suggesting that we should switch to 6 month release cycles, I'm merely > > bringing it up to get feedback on the idea. > > I don't think any of those projects have 6 month release cycles that break > backwards compatibility, which I think major drupal releases do... I think that's just another argument in favor of Robert's suggested move of core modules to contrib. The Form/Fields/File/whatever APIs deserve longer release cycles so that contrib has at least some chance to stick with feature work for a single core version only. However, for the modules built on top of the APIs (Forum, Aggregator, etc.) nobody really cares about API compatibility, those are the ones that would actually benefit from significantly shorter release cycles. While I'm not yet convinced that stripping down Drupal to a bare framework is the right approach, I do think that the two aspects of core should get different treatment. -- Jakob From larry at garfieldtech.com Tue Apr 21 06:05:19 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Tue, 21 Apr 2009 01:05:19 -0500 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> Message-ID: <200904210105.19215.larry@garfieldtech.com> On Monday 20 April 2009 4:03:08 pm Dries Buytaert wrote: > I think catch hits a lot of good points about how our reward and trust > system could be improved. I'm all for better profile pages, giving > credit where credit is due, and providing better visibility into who > is working on what. It might be useful to provide a "Reviewer rating" > or "Reviewer score" -- something which could be an incentive for more > people to review patches. Maybe this can be accomplished through some > project module extensions? I'm not sure what the best approach would > be, but it is worthy of a discussion. Dear god this is a monster thread... :-) I'm going to jump in here for lack of anywhere better to do so. As others have noted, the problem isn't the speed of commits, it's the speed of reviews and the ability of sufficient people to grok them to review them usefully. I would add a related problem: The speed of decision making. Some have suggested giving subsystem maintainers commit access. I am not sure that's a good idea, given Drupal's current architecture. It's still too intertwined, with poor separation between systems. Hooks are well and good but they don't separate subsystems from each other. (I freely admit that one of my ulterior motives with the handlers project is to encourage further separation between components, making it easier to grok them separately, test them separately, and develop them separately, even in contrib. I hope to get back to that soon, as I've been heavily distracted by personal matters of late.) For subsystem committers to work, we would need to have a way for there to be layered levels of commit. That is, as others have mentioned before, the Linux model. Linus almost never reviews or even sees individual patches. He gets periodic rollups from subsystem maintainers, reviews them in general but not at a line-by-line level, and adds in a great deal of trust that said subsystem maintainer is doing his job and that what he's getting has already been vetted by someone who understands, say, the power management system far better than he does. It's the power management subsystem maintainer's job to go line by line, not Linus'. We could adopt that sort of model without giving subsystem maintainers core commit access, if and only if 1) We switched to a distributed VCS, because CVS really can't handle that. Really, I see greater autonomy for submaintainers and a DVCS for core as fundamentally linked; doing one without the other is pointless. 2) We need to trust that subsystem maintainers have and are implementing long-term planning that makes sense, and then let them sweat the line-by-line details. As webchick noted earlier, and as I discussed with her in IRC, we need more "maintainer teams" like we have for the DB system. The DB system is sort of an oddball case, though, since it breaks into subcomponents so easily (each driver is its own subcomponent). Of course, if we want to get more people to be domain experts, whether formally recognized or not, there needs to be an incentive. "Pleeeeeese???" is our current incentive model, and I don't think it works all that well. :-) Informal karma only goes so far. What is the incentive for people to become and remain domain experts? Now that I have finally managed to get query builders into core so that I never have to deal with the frickin' INSERT query syntax again, what's the incentive for me to remain active and on top of the DB system? (Not that I'm planning to wander off and ignore it, mind you; I'm just using that as an example.) I first became the DB maintainer right before Szeged. In Szeged, I asked Dries and Angie what they wanted me to do, exactly. "OK, so what did I just sign up for?" Their answer was "just keep doing what you're doing". That didn't really make much sense to me, as what I'd been doing was developing a several hundred KB patch over the course of a year and a half and not sleeping for two weeks in order to get it committed and I really didn't want to keep doing things that way. :-) I've not gotten a particularly different answer since. Sometimes I see "I'd like to get Crell's thoughts on this issue" type comments, and sometimes I get emails with an issue that a core committer wants me to have a look at, but usually I know about them already because I have the DB issue queue bookmarked. I don't mean that to sound like a whiny complaint. The point is that if I, as a current submaintainer / domain expert, don't really know what the benefit is for being one besides feeding my own ego, then what incentive is there for anyone else to become a domain expert on FAPI, or to give forum.module the extensive love it desperately needs? Which brings me to something else that Dries said earlier about the micro vs. macro level. Looking at the macro level and planning things out to ensure consistency and so forth is very important. It also has a name, which is even dirtier to mention around here than "backward compatibility" but I shall do so anyway: A roadmap. Roadmaps help ensure that small tasks fit together into a cohesive whole, and that everyone knows what that whole is. They also give people a clear task list of things that need to be done and WHY. That makes life easier for developers and for reviewers, because they can see why we're making this change to a given piece of code; it's a small change that is part of a larger effort, and the larger effort makes sense. OK, call them community initiatives or whatever; that's still what they are. We're seeing more of them appear haphazardly in the issue queue with multi-part issues that reference each other. That's a very good thing. Drupal is, really, past the size at which "scratch an itch somewhere" can be the primary organizational mechanism, especially if we actually want clean and consistent APIs. OK, so we don't necessarily need one huge roadmap for all of core. Given our development model I doubt that would work anyway. But, if we tone down the anti-planning rhetoric and instead allow for smaller, subsystem roadmaps or particular campaign roadmaps (like Fields-ifying core), that gives people more context in which to review, as well as more documentation on why something is being done, which again makes it easier to review. Then, allow submaintainers to direct roadmaps. If someone wants to become the big fish in the little pond for blog.module and do amazing things with it, and it's someone that has already shown that they are reliable in general, OK. Let's see what your plan (roadmap) is. Discuss and approve it in general. Let them work on it and also be the go-to person for anyone wanting to work on it to make sure that that particular piece of core is consistent and clean and robust. That's their responsibility... and also their authority. When something comes down to a subjective opinion question, the submaintainer's opinion needs to carry more than usual weight. (Objective measures like performance, sure, benchmarks win. I'm referring to judgment calls.) Then the subsystem maintainers, together with the maintainers (Dries and Angie for D7), coordinate to ensure consistency and cleanliness and elegance across core, so that the API decisions for node.module and the API decisions for comment.module and the decisions for FAPI all mirror each other where appropriate, which in turn leads to more consistent and therefore more learnable APIs, which lowers the barrier to entry for future reviewers, etc. Positive feedback loops are a good thing. -- Larry Garfield larry at garfieldtech.com From sepeck at gmail.com Tue Apr 21 06:20:15 2009 From: sepeck at gmail.com (Steven Peck) Date: Mon, 20 Apr 2009 23:20:15 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <200904210750.55120.jpetso@gmx.at> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> Message-ID: To my knowledge, every module removed from Drupal core has died. I use several of the modules on Roberts list (blog, aggregator, blogapi) and if they were removed, then I would be out of luck as one of the few remaining 'hobbyist' users. And Stefan, I too miss the old front page where it wasn't all site implementations and Drupalcons but things people found interesting, but that's just what happened. -sepeck On Mon, Apr 20, 2009 at 10:50 PM, Jakob Petsovits wrote: > On Monday 20 April 2009, Marijn Kruisselbrink wrote: >> On Monday 20 April 2009 23:19:03 Dries Buytaert wrote: >> > In fact, a lot of big projects, like the Linux kernel, Gnome, KDE, >> > Ubuntu, Fedora and Wordpress all switched to 6 month release cycles. >> > Mark Shuttleworth posted some good insights about that in a recent >> > blog post: http://www.markshuttleworth.com/archives/288. ?I'm not >> > suggesting that we should switch to 6 month release cycles, I'm merely >> > bringing it up to get feedback on the idea. >> >> I don't think any of those projects have 6 month release cycles that break >> backwards compatibility, which I think major drupal releases do... > > I think that's just another argument in favor of Robert's suggested move of > core modules to contrib. The Form/Fields/File/whatever APIs deserve longer > release cycles so that contrib has at least some chance to stick with feature > work for a single core version only. > > However, for the modules built on top of the APIs (Forum, Aggregator, etc.) > nobody really cares about API compatibility, those are the ones that would > actually benefit from significantly shorter release cycles. > > While I'm not yet convinced that stripping down Drupal to a bare framework is > the right approach, I do think that the two aspects of core should get > different treatment. > > -- Jakob > > From sepeck at gmail.com Tue Apr 21 06:25:35 2009 From: sepeck at gmail.com (Steven Peck) Date: Mon, 20 Apr 2009 23:25:35 -0700 Subject: [development] CMS Research In-Reply-To: <49EB2D5D.4020609@killesreiter.de> References: <88838390904190642ib354b24jb8344eb2a804c566@mail.gmail.com> <49EB2D5D.4020609@killesreiter.de> Message-ID: You say "theme of open source web content management systems" but the survey seems to only consider people who contribute code and leaves out the rest of the community infrastructure/volunteers. As I do not contribute code, I quit the survey. sepeck On Sun, Apr 19, 2009 at 6:55 AM, Gerhard Killesreiter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > G?bor Nyeste schrieb: >> Dier Developer! >> >> I am a student of Corvinus University of Budapest and I'm writing my >> thesis in the theme of open source web content management systems. I >> would like to ask you for help to my research so that I can get >> acquinted with the world of open source development. Please take a >> moment to fill out my survey. >> >> Survey URL: >> >> >> ? ? ? ?http://survey.e-businessportal.hu/index.php?sid=63134&lang=en > > Unfortunately, the English questions are not always clear. You should > improve them. > > Cheers, > ? ? ? ?Gerhard > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAknrLV0ACgkQfg6TFvELooTSyQCeK8LvZGinCAVSFSkl8VJYrM5f > 86wAn3cr1vB0Qunk3qb0+N9avVBbtRV8 > =EE5a > -----END PGP SIGNATURE----- > From merlin at logrus.com Tue Apr 21 06:45:20 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 20 Apr 2009 23:45:20 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> Message-ID: <49ED6B80.8010009@logrus.com> Steven Peck wrote: > To my knowledge, every module removed from Drupal core has died. I > use several of the modules on Roberts list (blog, aggregator, blogapi) > and if they were removed, then I would be out of luck as one of the > few remaining 'hobbyist' users. > > And Stefan, I too miss the old front page where it wasn't all site > implementations and Drupalcons but things people found interesting, > but that's just what happened. I don't believe this would be true if we were still packaging them together, but treating them differently. Think of the Drupal Framework as the Linux Kernel, and then the Drupal distribution as Linux. The framework includes only the APIs -- node, user, base object stuff. The foundation. Drupal then provides applications built upon that foundation. It starts with just one: Something resembling Drupal as we know it today. We split core, and we devote effort to the most important projects. This might allow us to better focus efforts, anyway. One of the issues I see is that core itself is too big. Neither of the two committers really understand everything they've been committing, lately. (If you doubt me...field API =) From gerhard at killesreiter.de Tue Apr 21 07:13:09 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue, 21 Apr 2009 09:13:09 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> Message-ID: <49ED7205.90709@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven Peck schrieb: > To my knowledge, every module removed from Drupal core has died. I > use several of the modules on Roberts list (blog, aggregator, > blogapi) and if they were removed, then I would be out of luck as > one of the few remaining 'hobbyist' users. There are more hobbyist users than you think. They just are not on this list. I don't think that removing current core modules to the contrib repo is a good idea. It would screw up the upgrade path for thousands of existing sites. Things like the blog module simply do not need much development, they are feature complete. Adding bells and whistles would only make them harder to use. > And Stefan, I too miss the old front page where it wasn't all site > implementations and Drupalcons but things people found interesting, > but that's just what happened. Yeah, I've read enough site implementations for the rest of my life I think. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkntcgUACgkQfg6TFvELooRw5QCdFu/6omXbEZnJbEi5vVblgPpR m9sAoMaV49l1DrFNfDZqaGkWPsccTXfI =YVlr -----END PGP SIGNATURE----- From development at standoutdesign.nl Tue Apr 21 07:31:31 2009 From: development at standoutdesign.nl (Stefan Nagtegaal) Date: Tue, 21 Apr 2009 09:31:31 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> Message-ID: <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> Op 21 apr 2009, om 08:20 heeft Steven Peck het volgende geschreven: > > > And Stefan, I too miss the old front page where it wasn't all site > implementations and Drupalcons but things people found interesting, > but that's just what happened. > > -sepeck Happy to hear that Sepeck, sometimes I wonder if it is just me who is experiencing this. Drupal is not for users anymore, drupal is for making money and profit. One example is the "Support the Drupal redesign! Donate Now"- button, which is currently cycling over the frontpage. Why can't we - as a community - build the new drupal.org design? It gives us a good reality check why drupal is (too) hard for true designers. That said, you could wonder that if some module is moved from core to contrib and dies silently, if it wasn't in core too long already. If nobody feels the urge to keep a certain module up to date, then you could argue about its usefullnes. I would rather see modules like views(1|2|3).module in core, which are very well designed and maintained and deserves to be in core, because of it's quality and filling the gap which there currently is in core. Building views/page-layouts is something drupal needs. Although, I do not think that the current implementation is right, the functionality surely is. Getting rid of modules like the help.module is not that smart imo. Dries started a monster project to make drupal more accessible and easier to use by attracting Mark Boulton and Leisa, which I think is a good thing. Although, I do not doubt that they could make things easier to use, but I'm pretty convinced they could not make things as easy that the help texts are becoming redundant. Kind regards, Stefan From sepeck at gmail.com Tue Apr 21 07:56:55 2009 From: sepeck at gmail.com (Steven Peck) Date: Tue, 21 Apr 2009 00:56:55 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> Message-ID: On Tue, Apr 21, 2009 at 12:31 AM, Stefan Nagtegaal wrote: > > Op 21 apr 2009, om 08:20 heeft Steven Peck het volgende geschreven: > >> >> >> And Stefan, I too miss the old front page where it wasn't all site >> implementations and Drupalcons but things people found interesting, >> but that's just what happened. >> >> -sepeck > > Happy to hear that Sepeck, sometimes I wonder if it is just me who is > experiencing this. > Drupal is not for users anymore, drupal is for making money and profit. One > example is the "Support the Drupal redesign! Donate Now"-button, which is > currently cycling over the frontpage. Why can't we - as a community - build > the new drupal.org design? It gives us a good reality check why drupal is > (too) hard for true designers. Now now, the redesign is complex and time consuming. People are busy, so outside perspective is useful. > That said, you could wonder that if some module is moved from core to > contrib and dies silently, if it wasn't in core too long already. > If nobody feels the urge to keep a certain module up to date, then you could > argue about its usefullnes. I still use them. I know a number of people I support do as well. If it's been working fine then it hasn't needed much attention, but we are still have a large non-professional, minimal coding group of people that use Drupal so I would rather see a gradual enhancement/generalization of core to absorb these remaining specialized modules. > I would rather see modules like views(1|2|3).module in core, which are very > well designed and maintained and deserves to be in core, because of it's > quality and filling the gap which there currently is in core. Building > views/page-layouts is something drupal needs. Although, I do not think that > the current implementation is right, the functionality surely is. Different discussion. But on par with how CCK migrated into core as it and the community matured around it. > Getting rid of modules like the help.module is not that smart imo. Dries > started a monster project to make drupal more accessible and easier to use > by attracting Mark Boulton and Leisa, which I think is a good thing. > Although, I do not doubt that they could make things easier to use, but I'm > pretty convinced they could not make things as easy that the help texts are > becoming redundant. I liked the old built in help system, but we've gone 3 different ways since then. > > Kind regards, > > > Stefan > Steven From news at unleashedmind.com Tue Apr 21 08:42:54 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Tue, 21 Apr 2009 10:42:54 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <200904210105.19215.larry@garfieldtech.com> Message-ID: <100f01c9c25d$29ffb220$0200a8c0@structworks.com> > Some have suggested giving subsystem maintainers commit > access. I am not sure that's a good idea, given Drupal's > current architecture. ... > Looking at the macro level and planning things > out to ensure consistency and so forth is very important. It > also has a name, which is even dirtier to mention around here > than "backward compatibility" but I shall do so > anyway: A roadmap. FWIW, it mostly agree with Larry's points. But anyway. You all lost me here. I'm already considering whether the issue I face is really my own, personal issue only. I consider myself a contrib developer, reviewing and providing "upstream" patches for core occasionally. I have to stop doing that, because I still have to rewrite contrib modules for new API features in D6 and to improve them in general. These are the applications I (and the users of my modules) build Drupal sites with. My time is limited (I have a life as well), so I have to stop caring about D7/HEAD. Regarding better WYSIWYG support in Drupal, someone else has to take over the left side of the roadmap: http://groups.drupal.org/node/6492/summary Hopefully, the stuff that ends up in core will be compatible and useful for Wysiwyg API in D7 in the end. The same applies to some other modules. Especially regarding UX and Drupal's administrative interface, I've lost track and hope anyway already. I can only hope that one will be able to disable any oh-so-nifty-UX-widgets that may be added in D7. Thanks to Karoly for bringing up this discussion. sun From g at 8vue.com Tue Apr 21 09:57:35 2009 From: g at 8vue.com (George) Date: Tue, 21 Apr 2009 11:57:35 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ED6B80.8010009@logrus.com> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> Message-ID: <49ED988F.3010207@8vue.com> Earl Miles wrote: > Think of the Drupal Framework as the Linux Kernel, and then the Drupal > distribution as Linux. The framework includes only the APIs -- node, > user, base object stuff. The foundation. Drupal then provides > applications built upon that foundation. It starts with just one: > Something resembling Drupal as we know it today. We split core, and we > devote effort to the most important projects. This might allow us to > better focus efforts, anyway. One of the issues I see is that core > itself is too big. Neither of the two committers really understand > everything they've been committing, lately. (If you doubt me...field > API =) I think Drupal growing in size is natural. Drupal doesn't have to fit onto a floppy disk. Code bloat, and overall code size are two different things. I'm really surprised and scared at how quickly Drupal is progressing. At this rate, contrib will never be able to keep up all the features in core, with only handfuls of people really understanding it, and so it will be a complete waste of time coding the features in the first place. Each radical change between major core versions means more time investment for contrib developers to upgrade their modules. So, instead of trying to clump lots of really great cool features into the next major release and blowing everyone away, how about picking a few major features, and make them the best they can be, and then adding other new features at a later date? This would give contrib developers time to develop for them, and the docs team time to document. From jpetso at gmx.at Tue Apr 21 11:24:19 2009 From: jpetso at gmx.at (Jakob Petsovits) Date: Tue, 21 Apr 2009 13:24:19 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> References: <49EC7B14.7060706@killesreiter.de> <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> Message-ID: <200904211324.20333.jpetso@gmx.at> On Tuesday 21 April 2009, Stefan Nagtegaal wrote: > Happy to hear that Sepeck, sometimes I wonder if it is just me who is > experiencing this. > Drupal is not for users anymore, drupal is for making money and > profit. One example is the "Support the Drupal redesign! Donate Now"- > button, which is currently cycling over the frontpage. Why can't we - > as a community - build the new drupal.org design? It gives us a good > reality check why drupal is (too) hard for true designers. Actually we do build it, I think the steady flow of redesign sprints with a large number of community members is a testament to that. Also, the community provided plenty of input for the actual design process, it's just that *someone* has to oversee the process and has the final word, because design by committee doesn't really work. On the other hand, Drupal has actually grown very commercial, not least because the community is made up of the people who use it. (And if those people include lots of companies with monetary resources, their influence and contributions will not go unnoticed.) I don't think that's a bad idea per se, the challenge is just how to cope with this situation. Deciding how to deal with this is mainly an issue of vision and focus, which to a great extent is a responsibility of the project leader. * Do we want to focus on innovation and pushing the web forward, or is it more important to us to preserve existing functionality in an easily supportable way? * Do we want to focus on "free as in speech" political issues or are we satisfied with plain "open source" collaboration principles? * Do we give see ourselves as companies collaborating with each other, or are we still a team of individuals where certain people happen to work for certain employers? * Are sponsors (including Acquia) given special treatment, power and/or responsibility, or is code (and arguments) still gold when it comes to decisions that affect commercial reusability? * Do we emphasize the "product" aspect of Drupal or rather the "community" one? * Do we focus on excellence of code and inviting skilled contributors, or do we take an inclusive approach by tailoring to the newbie masses? Each project has to answer those questions for itself. So far, I think Dries has done a pretty good job of not letting money take over the development process of Drupal core, and has given clear answers to most of these questions. Maybe the promotional side has gotten a bit out of hand, because the number of "community" related stuff is not increasing as much as the number of commercial sites that are built and submitted as case studies. On the whole though, I think the Drupal community has always been this way, and the current state of "commercialism" is just the logical extension of how we are as a community. The thing that I worry more about than companies occupying d.o is that Drupal lacks the drive to search for solutions how the user can be guaranteed control over her data, as opposed to handing it to service providers. But that was never a stated goal or common vision, and I can live with it. Drupal has not been subverted, it just has evolved in its natural way. I hope that's not too off-topic to still fit into this thread... cheers, Jakob From marcomsousa at gmail.com Tue Apr 21 11:38:24 2009 From: marcomsousa at gmail.com (Marco Sousa) Date: Tue, 21 Apr 2009 13:38:24 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ED988F.3010207@8vue.com> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> <49ED988F.3010207@8vue.com> Message-ID: Or we can have one Drupal Legacy Module that we can suport the modules of previous drupal release. Pros: * Lots of previous module will work. * The "contrib developer" have more time to decide to upgrade the module. (instead 1 years will have 2 years or more) * More users will update their Drupal version. * I think with that, instead contrib modules became more not up to date, will became more up to date. because with this we can use the modules with the new version of drupal, so the process of migrating modules will became more faster.. Why? because some developers wait until all others modules (that they use) became migrated, before start.. Cons: * Modules that use this module will run more slow * Some Modules will not run and others have some break's. -- ------------------------------------- Marco Sousa -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcomsousa at gmail.com Tue Apr 21 11:46:19 2009 From: marcomsousa at gmail.com (Marco Sousa) Date: Tue, 21 Apr 2009 13:46:19 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> <49ED988F.3010207@8vue.com> Message-ID: I forget, we can start suporting Drupal 7 Contrib Modules to work with Drupal 8. Because of the realy change in BD and POO... On Tue, Apr 21, 2009 at 1:38 PM, Marco Sousa wrote: > Or we can have one Drupal Legacy Module that we can suport the modules of > previous drupal release. > > Pros: > * Lots of previous module will work. > * The "contrib developer" have more time to decide to upgrade the module. > (instead 1 years will have 2 years or more) > * More users will update their Drupal version. > * I think with that, instead contrib modules became more not up to date, > will became more up to date. because with this we can use the modules with > the new version of drupal, so the process of migrating modules will became > more faster.. > Why? because some developers wait until all others modules (that they use) > became migrated, before start.. > > Cons: > * Modules that use this module will run more slow > * Some Modules will not run and others have some break's. > > > -- > ------------------------------------- > Marco Sousa > -- ------------------------------------- Marco Sousa -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcomsousa at gmail.com Tue Apr 21 11:54:00 2009 From: marcomsousa at gmail.com (Marco Sousa) Date: Tue, 21 Apr 2009 13:54:00 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> <49ED988F.3010207@8vue.com> Message-ID: See the joomla way: Legacy Mode: *http://tinyurl.com/cxr45d* -- ------------------------------------- Marco Sousa -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard at killesreiter.de Tue Apr 21 12:02:13 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue, 21 Apr 2009 14:02:13 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> <49ED988F.3010207@8vue.com> Message-ID: <49EDB5C5.5050904@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marco Sousa schrieb: > See the joomla way: > > Legacy Mode: > *http://tinyurl.com/cxr45d* > Feel free to provide such a module in contrib and package it as part of an install profile. Or just use Joomla. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknttcUACgkQfg6TFvELooRMCgCaAxzzc+Pc/JH1/f/I0pGkr3Zo 1fgAoIRZKF5kqJ2YrSOJHGWrFQtVLuJN =Vw90 -----END PGP SIGNATURE----- From catch56 at googlemail.com Tue Apr 21 12:07:18 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 21 Apr 2009 13:07:18 +0100 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> <49ED988F.3010207@8vue.com> Message-ID: > Or we can have one Drupal Legacy Module that we can suport the modules of > previous drupal release. No we can't. The API changes in Drupal 7 include things like changing the way modules are defined in .info files to make them compatible with the registry, and changing the syntax of every single database query. It's impossible to make a module which would allow you to run a Drupal 6 module on Drupal 7 with no changes, and that's a very, very good thing. It's already been said once in this thread, but the reason it took so long for contrib to catch up to Drupal 6 was a massive refactoring of CCK, Views, wysiwyg API and other modules all the same time - and the fact that contrib has a very complex web of dependencies (baz module extends foo module which extends bar module, so can't do an update until both bar and foo are upgraded). A Views 2 which was backwards compatible with Views 1 wouldn't be half as much fun - and if you just want to use the same D5 modules you were using already without any of the advantages, why upgrade at all? We don't make API changes for fun, we make them because we have to - either to correct previous mistakes or open up new possibilities. If an API doesn't need to change then it usually doesn't - for example hook_menu() is pretty much exactly the same between 6 and 7. All the effort talking about backwards compatibility should instead be focused on http://drupal.org/project/deadwood and http://drupal.org/project/coder - and also on the Field API and Views related patches to core which will be necessary for field, views, and views-dependent modules to upgrade to D7. Coder already has an initial port to Drupal 7 and does a great deal of the work required to update a module. The better it gets, the less work module maintainers (or upgrade patch contributors) need to do to get a basic port of their module going. Combined with unstable releases, it's quite possible to start upgrading modules to Drupal 7 now - in fact there's 7 pages of modules which have some kind of port in the works, months before code freeze - something we've never, ever had before. http://drupal.org/project/modules?filters=drupal_core:103&solrsort=sort_title%20asc Nat From jpetso at gmx.at Tue Apr 21 12:07:30 2009 From: jpetso at gmx.at (Jakob Petsovits) Date: Tue, 21 Apr 2009 14:07:30 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <49ED988F.3010207@8vue.com> Message-ID: <200904211407.31146.jpetso@gmx.at> On Tuesday 21 April 2009, Marco Sousa wrote: > Or we can have one Drupal Legacy Module that we can suport the modules of > previous drupal release. This is proposed by someone for every Drupal version, it has been tried several times, and it has never worked for reasons that have been discussed at length in previous threads on this list. Please search the archives to read up those arguments. If we really go with module-supported "automatical" compatibility, the forward-facing way (deadwood) is much more promising than the legacy one. From eric.schaefer at eas-consulting.de Tue Apr 21 12:25:11 2009 From: eric.schaefer at eas-consulting.de (Eric Schaefer) Date: Tue, 21 Apr 2009 14:25:11 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <200904211407.31146.jpetso@gmx.at> References: <49EC7B14.7060706@killesreiter.de> <49ED988F.3010207@8vue.com> <200904211407.31146.jpetso@gmx.at> Message-ID: <34f8975d0904210525x60c98e9dn9c5f5cd7d2625e6e@mail.gmail.com> 2009/4/21 Jakob Petsovits : >> Or we can have one Drupal Legacy Module that we can suport the modules of >> previous drupal release. > > This is proposed by someone for every Drupal version, it has been tried > several times, and it has never worked for reasons that have been discussed at > length in previous threads on this list. Please search the archives to read up > those arguments. Last night, just before I went to sleep, I was thinking if it would be good to have CHANGES.txt accompanied by DIDNOTCHANGE.txt to aid porting of contrib modules. In some cases people might even be able to have xyz.module and xyz.d6.inc as well as xyz.d7.inc. xyz.module would contain everthing mentioned in DIDNOTCHANGE.txt. But maybe this is silly... Eric From eric.schaefer at eas-consulting.de Tue Apr 21 12:27:15 2009 From: eric.schaefer at eas-consulting.de (Eric Schaefer) Date: Tue, 21 Apr 2009 14:27:15 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <34f8975d0904210525x60c98e9dn9c5f5cd7d2625e6e@mail.gmail.com> References: <49EC7B14.7060706@killesreiter.de> <49ED988F.3010207@8vue.com> <200904211407.31146.jpetso@gmx.at> <34f8975d0904210525x60c98e9dn9c5f5cd7d2625e6e@mail.gmail.com> Message-ID: <34f8975d0904210527o7fabac8bwf033065adee3b9ea@mail.gmail.com> 2009/4/21 Eric Schaefer : > But maybe this is silly... At least the parallel development of multiple releases would be easier. Don't know if it whould work thou.... Eric From matt at mattfarina.com Tue Apr 21 13:04:21 2009 From: matt at mattfarina.com (Matt Farina) Date: Tue, 21 Apr 2009 09:04:21 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> Message-ID: Two thoughts occurred to me on the community. First, we are no longer what the community was 3 or 5 years ago. The front page of drupal has changed with a changing focus and need. Instead of a few thousand users there are hundreds of thousands of users. The front page of d.o has a different place in the ecosystem than it used to. But, we still need a place for some of those things that used to get posted. Is g.d.o the place for that? Second, we seem to have a bit of an identity crisis. Is drupal a framework or a CMS? If it's both should they be cleanly separated? How does this and should this work? Moving the CMS like features into contrib, as some have suggested, seems to be centered around this. If we have a drupal framework and a drupal cms do we have maintainers for each piece? How does this interaction work? Ah, growing pains. Now we just have to figure out how to bribe the kids to clean their rooms (i.e. review patches and clean the queue). On Apr 21, 2009, at 3:31 AM, Stefan Nagtegaal wrote: > > Op 21 apr 2009, om 08:20 heeft Steven Peck het volgende geschreven: > >> >> >> And Stefan, I too miss the old front page where it wasn't all site >> implementations and Drupalcons but things people found interesting, >> but that's just what happened. >> >> -sepeck > > Happy to hear that Sepeck, sometimes I wonder if it is just me who > is experiencing this. > Drupal is not for users anymore, drupal is for making money and > profit. One example is the "Support the Drupal redesign! Donate Now"- > button, which is currently cycling over the frontpage. Why can't we > - as a community - build the new drupal.org design? It gives us a > good reality check why drupal is (too) hard for true designers. > > That said, you could wonder that if some module is moved from core > to contrib and dies silently, if it wasn't in core too long already. > If nobody feels the urge to keep a certain module up to date, then > you could argue about its usefullnes. > > I would rather see modules like views(1|2|3).module in core, which > are very well designed and maintained and deserves to be in core, > because of it's quality and filling the gap which there currently is > in core. Building views/page-layouts is something drupal needs. > Although, I do not think that the current implementation is right, > the functionality surely is. > > Getting rid of modules like the help.module is not that smart imo. > Dries started a monster project to make drupal more accessible and > easier to use by attracting Mark Boulton and Leisa, which I think is > a good thing. Although, I do not doubt that they could make things > easier to use, but I'm pretty convinced they could not make things > as easy that the help texts are becoming redundant. > > > Kind regards, > > > Stefan From earnie at users.sourceforge.net Tue Apr 21 13:05:32 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 21 Apr 2009 13:05:32 +0000 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <200904211407.31146.jpetso@gmx.at> References: <49EC7B14.7060706@killesreiter.de> <49ED988F.3010207@8vue.com> <200904211407.31146.jpetso@gmx.at> Message-ID: <20090421130532.764445on0vs5s9kw@mail.siebunlimited.com> Quoting Jakob Petsovits : > On Tuesday 21 April 2009, Marco Sousa wrote: >> Or we can have one Drupal Legacy Module that we can suport the modules of >> previous drupal release. > > This is proposed by someone for every Drupal version, it has been tried > several times, and it has never worked for reasons that have been > discussed at > length in previous threads on this list. Please search the archives > to read up > those arguments. > > If we really go with module-supported "automatical" compatibility, the > forward-facing way (deadwood) is much more promising than the legacy one. > > I started to suggest the legacy issue yesterday but stopped because I realize that supporting legacy becomes an unending task that just postpones forever the upgrade to the newer API. I agree the deadwood module is a great benefit. One desire I would have with it is to report in foo.deadwood things of caution instead of inserting comments into foo.module. Yea, yea, I know a feature request in the deadwood issue queue. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From earnie at users.sourceforge.net Tue Apr 21 13:22:14 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 21 Apr 2009 13:22:14 +0000 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> <49ED988F.3010207@8vue.com> Message-ID: <20090421132214.86322nk21dngq8ao@mail.siebunlimited.com> Quoting Marco Sousa : > > Cons: > * Modules that use this module will run more slow > * Some Modules will not run and others have some break's. * There will be less interest in upgrading a module prolonging the inevitable. * Most modules will suddenly break when moving from D7 to Dx. * Legacy remains legacy forever and the maintenance of such a module becomes unbearable as more core versions are released. As has been mentioned already deadwood and coder modules are the way to go when upgrading. Identifying to the module maintainer or interested party where the code needs to be upgraded is jump in the correct direction. Deadwood even changes what it can. Improving that module is where we need to focusing the legacy issue. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From marcomsousa at gmail.com Tue Apr 21 13:26:30 2009 From: marcomsousa at gmail.com (Marco Sousa) Date: Tue, 21 Apr 2009 15:26:30 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49EDB5C5.5050904@killesreiter.de> References: <49EC7B14.7060706@killesreiter.de> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> <49ED988F.3010207@8vue.com> <49EDB5C5.5050904@killesreiter.de> Message-ID: On Tue, Apr 21, 2009 at 2:02 PM, Gerhard Killesreiter < gerhard at killesreiter.de> wrote: >Feel free to provide such a module in contrib and package it as part of >an install profile. Or just use Joomla. Gehard, this comment is useful? Please stop that. I just want to give more alternatives (used by one CMS), to we have all variables to choose the better one.. I'm not inflame nothing... -- ------------------------------------- Marco Sousa -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard at killesreiter.de Tue Apr 21 13:30:54 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue, 21 Apr 2009 15:30:54 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <49ED6B80.8010009@logrus.com> <49ED988F.3010207@8vue.com> <49EDB5C5.5050904@killesreiter.de> Message-ID: <49EDCA8E.50308@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marco Sousa schrieb: > On Tue, Apr 21, 2009 at 2:02 PM, Gerhard Killesreiter < > gerhard at killesreiter.de> wrote: >> Feel free to provide such a module in contrib and package it as part of >> an install profile. Or just use Joomla. > > Gehard, this comment is useful? Please stop that. > > I just want to give more alternatives (used by one CMS), to we have all > variables to choose the better one.. > > I'm not inflame nothing... You are repeating a discussion we are having every couple of months or years. Last time was February, IIRC. This is not helpful and has to be stopped. The others gave you more detailed answers why your proposal is not only annoying but also not working. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkntyo4ACgkQfg6TFvELooSxngCePiG5knjL9t9XhnND4us9yVEq 2eAAn2GWA/i98wWaY4LpB8QH9CwLAnL8 =jkQ1 -----END PGP SIGNATURE----- From larry at garfieldtech.com Tue Apr 21 13:51:07 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Tue, 21 Apr 2009 08:51:07 -0500 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> Message-ID: <200904210851.07871.larry@garfieldtech.com> On Tuesday 21 April 2009 8:04:21 am Matt Farina wrote: > Second, we seem to have a bit of an identity crisis. Is drupal a > framework or a CMS? If it's both should they be cleanly separated? How > does this and should this work? Moving the CMS like features into > contrib, as some have suggested, seems to be centered around this. If > we have a drupal framework and a drupal cms do we have maintainers for > each piece? How does this interaction work? Last week, I gave a workshop at the Museums and the Web conference in Indianapolis on remote data handling in Drupal. One of the main things I drove home during the session was that Drupal has a split personality of CMS and framework... and that is a very very good thing. That is what makes Drupal powerful and well-suited to, in that case, remote data handling within a CMS. That multiple personality disorder is great, because you get to pick which Drupal personality you speak to at any given time. "Both" is the answer that has gotten Drupal so far. Let's not drop half of our power. Balance is the answer. -- Larry Garfield larry at garfieldtech.com From earnie at users.sourceforge.net Tue Apr 21 14:20:04 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 21 Apr 2009 14:20:04 +0000 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <8B0EE0CA-CD2F-40B7-B278-98256A54E2FF@metzlerd.com> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <8B0EE0CA-CD2F-40B7-B278-98256A54E2FF@metzlerd.com> Message-ID: <20090421142004.18621a7x8w1pldtw@mail.siebunlimited.com> Quoting David Metzler : > > I think think the right answer about drupal stagnating was really > about having Views, Panels, and WYSIWG api all going through major > refactoring on D6, all lagging significantly the D6 release. I know > it's why I'm not using my own D6 ported modules in any production > sites yet. > And to avoid this the module developer needs to agree to port the existing functionality of a module from one version to the next while the new features of the module are being developed. The deadwood and coder modules can help with that and should be one of the first modules upgraded out of the door. New functionality in a module is great but once a Drupal version is out and people are knocking on the modules door for "when is Dx going to be supported" carrying over the old functionality to the new Dx should have a priority over a more powerful, better looking model. D6 still lags because modules are improving their API and developers aren't willing to put out a module that is carries the sins of the older D5 version. A worthy goal but so is getting a module that is working just like the previous. This is really a sore sticking point making using Drupal sour in some eyes. I agree that Drupal has a nice feature rich framework for building many different applications (modules). I agree that the CMS work is what has drawn many to Drupal. However, a focus on CMS often drowns the other usefulness of the framework and you have a situation similar to HORDE/IMP. Does anyone think framework when they hear HORDE? Maybe as a second thought but usually you think an email client. Unfortunately when people here Drupal they think CMS and not framework. Most users of the CMS don't care that the framework of Drupal or the framework of their favorite module is now more feature rich at first. They care that their sites will work exactly the same as it does before upgrading. Then they might look at the newer features. There are more users of Drupal than there are hackers providing code, peer reviews and module functionality. Yes, these are important but not to the non-technical user of the product. People are tired of waiting on module maintainers and probably will go elsewhere or worse create their own version of the module. This is why it is important for contrib modules to be readily available within a month of a new Dx release. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From csuthyb at gmail.com Tue Apr 21 14:23:15 2009 From: csuthyb at gmail.com (Csuthy Balint) Date: Tue, 21 Apr 2009 16:23:15 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> Message-ID: <49EDD6D3.1040802@gmail.com> let me try to explain it with an example if I understand your request correctly. module version core-hybrid: aggregator-7.x-1.x = drupal 7.x contrib: aggregator-7.x-2.x and above core-hybrid: aggregator-8.x-1.x = drupal 8.x contrib: aggregator-8.x-2.x and above Yes, sounds good, one small step in the right direction, I support this idea.. I think it is a similar model how Acquia choose module versions, just much more strict.. one thing which I do not understand is what happens with the modules, which have files in the "includes" directory, like the menu module with menu.inc. I guess it won't be possible to change (improve) the menu.inc file in menu-7.x-2.x, but of course there would be a larger pressure on core committers if something really have to be changed in those include files for the new module versions.. From alex at developmentseed.org Tue Apr 21 14:25:37 2009 From: alex at developmentseed.org (Alex Barth) Date: Tue, 21 Apr 2009 10:25:37 -0400 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> Message-ID: <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> I am actually planning to create a 6 backport of OpenID and Aggregator for 7 (depending on the outcome of http://groups.drupal.org/node/21221 and http://drupal.org/node/293318). I'd use project/openid and project/ aggregator for these backports. I need to have these modules on 6 to deploy them on production sites - the only way to make sure stuff works. Working on HEAD without deploying changes in months is scary. Current Drupal infrastructure is not conducive to these kind of backports, being able to keep these alternate versions for 6 in the same repository would be great. But I would pay for this advantage with the project page (crucial for communication around alternate versions like this) and with the packaging infrastructure of contrib. So let me recap your suggestion, Aggregator DRUPAL-7--1 would be packaged with Drupal 7.x, there would be an Aggregator DRUPAL-7--2 that would contain new features more or less mirroring HEAD. How would Aggregator DRUPAL-7--2 be packaged? It would need a similar infrastructure like a Drupal contrib project, right? Alex On Apr 20, 2009, at 7:01 PM, Karoly Negyesi wrote: > Hi, > > So it seems there is quite some talk about moving some of the core to > contrib. This talk comes up from time but we did not have testing and > now we do. And that makes a big, big difference, I tell you. > > So let's suppose that aggregator gets moved into contrib. Every core > tarball still contains aggregator, the latest tag from the DRUPAL-7--1 > branch. But the aggregator people can churn out bugfixes as fast as > they can and the tests will make sure they won't break stuff. > Meanwhile, new features can get into DRUPAL-7--2. Every user can use > --2 invidually, core will come with --1 still. Also, they maintain a > DRUPAL-8--1 branch and for every unstable/beta/RC they make sure they > have ported aggregator and tag similarly as core does (we can punt > some of the unstables -- I could understand that not every module gets > DBTNG'd immediately it did not happen anyways). Let's list the > benefits again: > > *) if a company is interested in a module it can grow a community > around much easier than with core. They can both release bugfixes and > features. > *) core does not lose the feedback from its modules > > Possible problems: > > *) lose of maintenance > *) additional burden on these maintainers w/ HEAD compatibility. > > Also, aspiring projects can opt for core inclusion (if they accept > that a branch can not break APIs and willing to tag along with core) > which can be much easier this way. Let's face it, there are much > higher quality contribs than the mess called comment module so why > not? > > There is the small problem of how can people using cvs update core > now, do they need to run a cvs up for every directory? Hardly. We can > create a 'mirror' which pulls together the commits. This is an easily > doable (and yes I am willing to script it). > > Regards > > Karoly Negyesi Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633 From earnie at users.sourceforge.net Tue Apr 21 14:30:26 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 21 Apr 2009 14:30:26 +0000 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ED0DE0.2070203@killesreiter.de> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <49ED0DE0.2070203@killesreiter.de> Message-ID: <20090421143026.1178162ti1vu9ndw@mail.siebunlimited.com> Quoting Gerhard Killesreiter : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dries Buytaert schrieb: > >> blog post: http://www.markshuttleworth.com/archives/288. I'm not >> suggesting that we should switch to 6 month release cycles, I'm merely >> bringing it up to get feedback on the idea. > > I'd be very happy if we could at least break the trend towards longer > and longer release cycles. > I can imagine that this could happen with fewer features added in one cycle. Things like dbTNG that requires a whole rewrite of queries will take a longer cycle and should be the only feature change for that release. Other changes like fields in core could be released earlier. This though requires a different paradigm in version control. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From news at unleashedmind.com Tue Apr 21 14:39:14 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Tue, 21 Apr 2009 16:39:14 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> Message-ID: <10e401c9c28e$f198fe50$0200a8c0@structworks.com> > So let me recap your suggestion, Aggregator DRUPAL-7--1 would > be packaged with Drupal 7.x, there would be an Aggregator > DRUPAL-7--2 that would contain new features more or less > mirroring HEAD. > > How would Aggregator DRUPAL-7--2 be packaged? It would need a > similar infrastructure like a Drupal contrib project, right? > > Alex Any attempt to move Foo module 7.x-1.x from core into contrib to allow for a co-existing 7.x-2.x requires to have module dependencies based on minor versions first. The alternative is to drop most of the module system and replace it with plugins (CTools). ;) sun From earnie at users.sourceforge.net Tue Apr 21 14:46:39 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 21 Apr 2009 14:46:39 +0000 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> Message-ID: <20090421144639.22605hxy506y62kg@mail.siebunlimited.com> Quoting Karoly Negyesi : > Hi, > > So it seems there is quite some talk about moving some of the core to > contrib. This talk comes up from time but we did not have testing and > now we do. And that makes a big, big difference, I tell you. > Maybe a different twist to contrib but rather these optional core provided modules residing in CVS as drupal/modules they reside in CVS as drupal-optional/modules? The drupal-optional modules would take on the same level of core review but cvs commit could be handled slightly different. Then the discussion is what contrib module becomes a drupal-optional module or what drupal-optional module do we want to drop support for and move to contrib. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From karoly at negyesi.net Tue Apr 21 14:47:35 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 21 Apr 2009 07:47:35 -0700 Subject: [development] Some of core to contrib? In-Reply-To: <10e401c9c28e$f198fe50$0200a8c0@structworks.com> References: <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <10e401c9c28e$f198fe50$0200a8c0@structworks.com> Message-ID: <7e270cea0904210747s22652d32l6c71019a3e669f7c@mail.gmail.com> > Any attempt to move Foo module 7.x-1.x from core into contrib to allow for a > co-existing 7.x-2.x requires to have module dependencies based on minor > versions first. /me puts his hand up I want to do that, anyways. From karoly at negyesi.net Tue Apr 21 14:58:27 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 21 Apr 2009 07:58:27 -0700 Subject: [development] Some of core to contrib? In-Reply-To: <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> Message-ID: <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> > I am actually planning to create a 6 backport of OpenID and Aggregator for 7 > (depending on the outcome of http://groups.drupal.org/node/21221 and > http://drupal.org/node/293318). I'd use project/openid and > project/aggregator for these backports. Right. That's what I wanted to use, too. > I need to have these modules on 6 to deploy them on production sites - the > only way to make sure stuff works. Working on HEAD without deploying changes > in months is scary. See, that's why I campaign for this change. > So let me recap your suggestion, Aggregator DRUPAL-7--1 would be packaged > with Drupal 7.x, there would be an Aggregator DRUPAL-7--2 that would contain > new features more or less mirroring HEAD. That entirely depends on the maintainer. Core would come with DRUPAL-7--1 and then what the maintainer does with the project is her/his own doing -- the only two restrictions are that DRUPAL-7--1 should only get bugfixes and DRUPAL-8--1 needs to tag along with HEAD. What you do with DRUPAL-7--2 and/or DRUPAL-7--3 is absolutely your call. > How would Aggregator DRUPAL-7--2 be packaged? It would need a similar > infrastructure like a Drupal contrib project, right? It would be just a package exactly like any other. Already, if I am not mistaken, if you put a module of the same name in sites/all/modules then it will win over the core modules. If that's not so anymore, it'll be too easy to change. Regards NK From alex at developmentseed.org Tue Apr 21 15:07:13 2009 From: alex at developmentseed.org (Alex Barth) Date: Tue, 21 Apr 2009 11:07:13 -0400 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> Message-ID: On Apr 21, 2009, at 10:58 AM, Karoly Negyesi wrote: > >> How would Aggregator DRUPAL-7--2 be packaged? It would need a similar >> infrastructure like a Drupal contrib project, right? > > It would be just a package exactly like any other. Already, if I am > not mistaken, if you put a module of the same name in > sites/all/modules then it will win over the core modules. If that's > not so anymore, it'll be too easy to change. Packaging in the sense of packaging scripts on drupal.org. I. e. where would I send people to download a tarball of the aggregator DRUPAL-7--2 version? > > > Regards > > NK Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633 From karoly at negyesi.net Tue Apr 21 15:12:35 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 21 Apr 2009 08:12:35 -0700 Subject: [development] Some of core to contrib? In-Reply-To: References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> Message-ID: <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> > Packaging in the sense of packaging scripts on drupal.org. I. e. where would > I send people to download a tarball of the aggregator DRUPAL-7--2 version? project/aggregator. From c.r1 at gmx.de Tue Apr 21 15:21:16 2009 From: c.r1 at gmx.de (Cornelius) Date: Tue, 21 Apr 2009 17:21:16 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> Message-ID: <49EDE46C.3040508@gmx.de> Karoly Negyesi schrieb: >> Packaging in the sense of packaging scripts on drupal.org. I. e. where would >> I send people to download a tarball of the aggregator DRUPAL-7--2 version? > > project/aggregator. > who would search there? Most people will never use a DRUPAL-X--2 version, as they simply don't know about it - except if you provide them via update-status, where it annoys the people who want their 'stable' core as shipped. This would imho lead to frustration of the foo.module's maintainer as all the new features he developed have to be a) forward-ported for HEAD of drupal b) maintained for current drupal, with a low user-base. I think it's better for these modules, that, if they *are* stable in a x.y-2.x release and this release contains the same features as the x.y-1.x release (shipped with core) did is deployed to all sites with this module through drupal's update mechanism. Cornelius From karoly at negyesi.net Tue Apr 21 15:23:34 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 21 Apr 2009 08:23:34 -0700 Subject: [development] Some of core to contrib? In-Reply-To: <49EDE46C.3040508@gmx.de> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> Message-ID: <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> > who would search there? The same who searches for cck/views/etc. Not to mention we can add links, handbook pages etc etc to explain the situation. From catch56 at googlemail.com Tue Apr 21 15:38:19 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 21 Apr 2009 16:38:19 +0100 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> Message-ID: Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it. And the idea here is not that we encourage everyone running Drupal core to upgrade to the -2.x versions of these modules - it's that they're available for those who need the extra features they provide. So if they end up with a few hundred or couple of thousand users instead of 80,000 (not that all core sites are running aggregator or poll anyway), that's completely fine. Better than the < 1000 people who install Drupal 7 before it gets to beta and rely on the testbot to pretend to use these modules otherwise. Nat On Tue, Apr 21, 2009 at 4:23 PM, Karoly Negyesi wrote: >> who would search there? > > The same who searches for cck/views/etc. Not to mention we can add > links, handbook pages etc etc to explain the situation. > From csuthyb at gmail.com Tue Apr 21 15:54:01 2009 From: csuthyb at gmail.com (Csuthy Balint) Date: Tue, 21 Apr 2009 17:54:01 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <49EDE46C.3040508@gmx.de> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> Message-ID: <49EDEC19.8030800@gmail.com> Cornelius wrote: > Karoly Negyesi schrieb: >>> Packaging in the sense of packaging scripts on drupal.org. I. e. >>> where would >>> I send people to download a tarball of the aggregator DRUPAL-7--2 >>> version? >> >> project/aggregator. >> > who would search there? Most people will never use a DRUPAL-X--2 > version, as they simply don't know about it - except if you provide > them via update-status, where it annoys the people who want their > 'stable' core as shipped. This would imho lead to frustration of the > foo.module's maintainer as all the new features he developed have to be > a) forward-ported for HEAD of drupal > b) maintained for current drupal, with a low user-base. > I think it's better for these modules, that, if they *are* stable in a > x.y-2.x release and this release contains the same features as the > x.y-1.x release (shipped with core) did is deployed to all sites with > this module through drupal's update mechanism. > Cornelius > the update status may list (core-hybrid module) project/aggregator-7.x-2.x as "Also available" as it does with any contrib module, and it does not force you to update. I do not see the problem here. From wdlists at optonline.net Tue Apr 21 15:55:54 2009 From: wdlists at optonline.net (Walt Daniels) Date: Tue, 21 Apr 2009 11:55:54 -0400 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> Message-ID: <5D4D938DAF4444038D6FBFC5745CEF15@Squirt> >It would be just a package exactly like any other. Already, if I am not mistaken, if you put a module of the same name in sites/all/modules then it will win over the core modules. If that's not so anymore, it'll be too easy to change. Regards NK ---------------- I believe this is true as I just did it on a Acquia site that had some of their package in a subdirectory of /modules (non-core contrib). However I wound up with conflicts somewhere as some parts of the theme no longer worked. I fixed it by downloading all the Acquia approved modules to /sites/all/modules and deleting the Acquia versions. I have no idea if theirs were vanilla off contrib or if they had tweeked them. I did not do a careful experiment to find out exactly what caused the problem (problem was the theme config page did not save its results to the database so it had no effect). I think what Acquia is doing is a precursor of some of the discussion here. So this is a warning that there be dragons there. From earnie at users.sourceforge.net Tue Apr 21 16:21:54 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 21 Apr 2009 16:21:54 +0000 Subject: [development] Framework or CMS [WAS: Very concerned over Drupal's core development] In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> Message-ID: <20090421162154.103964zzaarwb6o0@mail.siebunlimited.com> Quoting Matt Farina : > Is drupal a framework or a CMS? If it's both should they be cleanly > separated? Drupal is both a framework and a CMS. The framework itself is geared toward managing dynamic content. The parts of Drupal that make it a traditional CMS must remain with the core of Drupal because that gives Drupal better definition. > How does this and should this work? Moving the CMS like features > into contrib, as some have suggested, seems to be centered around > this. If we have a drupal framework and a drupal cms do we have > maintainers for each piece? How does this interaction work? > Since the framework is geared toward a CMS how can we separate all of those pieces. There may be some modules dwelling in core that may be moved but certainly not those that pertain to a minimal CMS. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From news at unleashedmind.com Tue Apr 21 16:30:38 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Tue, 21 Apr 2009 18:30:38 +0200 Subject: [development] Some of core to contrib? In-Reply-To: Message-ID: <111801c9c29e$815d0c70$0200a8c0@structworks.com> > Looks like we could try to do this without changing HEAD > development at all - if Alex starts with OpenID and > Aggregator 2.x branches in contrib, then anyone who wants to > could do the same for the other optional core modules. Then > if it works we could look at better infrastructure around it. No insults, but we don't really want to start wild forks of core modules with arbitrary maintainers and features in contrib. If we just do that, the quality of those forks won't differ from any other contrib module, and I would not see nor understand why those forks can't use a different module namespace (like any other module that thinks it can do better). Additionally, system module's updates would need to be properly split up into .install files of the respective modules or they'll run unintentionally (i.e. twice for straight back-ports of stuff in HEAD). sun From karoly at negyesi.net Tue Apr 21 16:38:15 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 21 Apr 2009 09:38:15 -0700 Subject: [development] Some of core to contrib? In-Reply-To: References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> Message-ID: <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> On Tue, Apr 21, 2009 at 8:38 AM, Nathaniel Catchpole wrote: > Looks like we could try to do this without changing HEAD development > at all - if Alex starts with OpenID and Aggregator 2.x branches in > contrib, then anyone who wants to could do the same for the other > optional core modules. Then if it works we could look at better > infrastructure around it. This is not so simple. The gain for Alex would be that he can work on DRUPAL-7--1 while core is open with much more freedom. here, let me state this: would the quality of the code of aggregator be less high than the core standards? maybe. but, it already is way below. These only-by-history core module are already not core quality so let them develop more freely. We are looking for responsible maintainers so I am sure they wont degrade into a stinking pile of debris. From fgm at osinet.fr Tue Apr 21 17:18:08 2009 From: fgm at osinet.fr (=?iso-8859-1?Q?Fr=E9d=E9ric_G._MARAND?=) Date: Tue, 21 Apr 2009 19:18:08 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> References: <49EC7B14.7060706@killesreiter.de><0e1c01c9c1c0$221dcdf0$0200a8c0@structworks.com><89c4d4df0904200706t5fdbd5bfv8aa0f23fef5e5d06@mail.gmail.com><7e270cea0904200718j2f14d23ep970056990c6e0c9d@mail.gmail.com><49EC962C.70107@islandnet.com> <38EE7AA2-F191-4B24-B393-06E5FA277156@robshouse.net> Message-ID: <64BAE8F864154054B7E755D6CF90DDC4@PCdeMarand> Notwithstanding the fact that modules shed from core tend to die, I think some of the modules you mention could indeed be made contrib, because their are "application"-type (like aggregator, forum, or poll), whereas one (taxonomy) is what really defines Drupal to many people outside the coder group, and others (search, statistics, ....profile(!) ) are part of anyone's basic expectations in a CMS. ----- Original Message ----- From: "Robert Douglass" To: Sent: Monday, April 20, 2009 6:03 PM Subject: Re: [development] Very concerned over Drupal's core development [...] The other solution which chx and I have discussed, and which is a long time goal of mine, would be to reduce the size of core. We carry around a lot of modules that don't absolutely need to be part of core: - aggregator - blog - blogapi - forum - help - poll - profile - search - statistics - taxonomy - tracker I believe that all of these modules could have brilliant lives outside of core. A slimmer core means more focused development for the core team. It would also make us focus our attention on the APIs that support these very important modules. For example, the search API is in great need of being decoupled from the node module. If our goal were to remove search from core we'd need to really make sure the API were in place for letting core be searched. [...] From alex at developmentseed.org Tue Apr 21 17:56:44 2009 From: alex at developmentseed.org (Alex Barth) Date: Tue, 21 Apr 2009 13:56:44 -0400 Subject: [development] Some of core to contrib? In-Reply-To: <111801c9c29e$815d0c70$0200a8c0@structworks.com> References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> Message-ID: <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> On Apr 21, 2009, at 12:30 PM, Daniel F. Kudwien wrote: >> Looks like we could try to do this without changing HEAD >> development at all - if Alex starts with OpenID and >> Aggregator 2.x branches in contrib, then anyone who wants to >> could do the same for the other optional core modules. Then >> if it works we could look at better infrastructure around it. > > No insults, but we don't really want to start wild forks of core > modules > with arbitrary maintainers and features in contrib. If we just do > that, the > quality of those forks won't differ from any other contrib module, > and I > would not see nor understand why those forks can't use a different > module > namespace (like any other module that thinks it can do better). I'd call it a backport. The same namespace makes it much easier to maintain the backport. The incentive for keeping the backport up to Drupal core standard is that its very reason-to-be is validating changes being made to HEAD and using these changes in the current release version. Any 'fork' in contrib with the same name as a Drupal core module only worries me in so far as it's using up valuable namespace for exactly doing that. > > > Additionally, system module's updates would need to be properly > split up > into .install files of the respective modules or they'll run > unintentionally > (i.e. twice for straight back-ports of stuff in HEAD). > > sun > Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633 From gerhard at killesreiter.de Tue Apr 21 18:05:21 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue, 21 Apr 2009 20:05:21 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> Message-ID: <49EE0AE1.7090600@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Barth schrieb: > > On Apr 21, 2009, at 12:30 PM, Daniel F. Kudwien wrote: > >>> Looks like we could try to do this without changing HEAD >>> development at all - if Alex starts with OpenID and >>> Aggregator 2.x branches in contrib, then anyone who wants to >>> could do the same for the other optional core modules. Then >>> if it works we could look at better infrastructure around it. >> >> No insults, but we don't really want to start wild forks of core modules >> with arbitrary maintainers and features in contrib. If we just do >> that, the >> quality of those forks won't differ from any other contrib module, and I >> would not see nor understand why those forks can't use a different module >> namespace (like any other module that thinks it can do better). > > I'd call it a backport. The same namespace makes it much easier to > maintain the backport. The incentive for keeping the backport up to > Drupal core standard is that its very reason-to-be is validating changes > being made to HEAD and using these changes in the current release version. > > Any 'fork' in contrib with the same name as a Drupal core module only > worries me in so far as it's using up valuable namespace for exactly > doing that. I think that this would be rather confusing for joe average user and request that you leave the core namespaces alone. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuCuEACgkQfg6TFvELooRn9QCfcJG8+eBDKholM76kcmRGutIj XaUAn0MMOy9sDLrgkYstGi7wppAokSa5 =NE10 -----END PGP SIGNATURE----- From cxjohnson at gmail.com Tue Apr 21 18:07:17 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 21 Apr 2009 13:07:17 -0500 Subject: [development] Some of core to contrib? In-Reply-To: <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> Message-ID: <9ea8d6030904211107g58fbf1e2k9791c203a4af524c@mail.gmail.com> Conceptually, I view Drupal as shown in this illustration: http://i43.tinypic.com/2zqfll1.jpg Core is really 3 things -- the lowest level subsystems and abstractions providing APIs, the required glue and UI modules wrapped around them, and the current CMS-oriented modules included with core. It would be nice, in my view, to minimize the amount of "required" code to build a site with Drupal. The more there are specific use case modules which are tightly coupled in core, the more it gets in the way of developing flexible sites and supporting flexible APIs. ..chris From gerhard at killesreiter.de Tue Apr 21 18:10:45 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue, 21 Apr 2009 20:10:45 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> Message-ID: <49EE0C25.9030700@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karoly Negyesi schrieb: > On Tue, Apr 21, 2009 at 8:38 AM, Nathaniel Catchpole > wrote: >> Looks like we could try to do this without changing HEAD development >> at all - if Alex starts with OpenID and Aggregator 2.x branches in >> contrib, then anyone who wants to could do the same for the other >> optional core modules. Then if it works we could look at better >> infrastructure around it. > > This is not so simple. The gain for Alex would be that he can work on > DRUPAL-7--1 while core is open with much more freedom. > > here, let me state this: would the quality of the code of aggregator > be less high than the core standards? maybe. but, it already is way > below. How do you reach this judgement? > These only-by-history core module are already not core quality so > let them develop more freely. We are looking for responsible > maintainers so I am sure they wont degrade into a stinking pile of > debris. I use aggregator on drupal.org and the only feature I miss is to exclude specific posts from a feed. Anything added beyond that would constitute cruft in my pov. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuDCQACgkQfg6TFvELooSkmQCfZLKnb2g+prgW/dGLY6hbsL/b mgQAn2BHMlOpJqQ87o+kFunEDk6w4zOt =o4Ss -----END PGP SIGNATURE----- From sepeck at gmail.com Tue Apr 21 19:51:32 2009 From: sepeck at gmail.com (Steven Peck) Date: Tue, 21 Apr 2009 12:51:32 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: References: <49EC7B14.7060706@killesreiter.de> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <200904202327.31699.m.kruisselbrink@student.tue.nl> <200904210750.55120.jpetso@gmx.at> <6C969409-7727-4DEF-964D-D394F81B8C11@standoutdesign.nl> Message-ID: On Tue, Apr 21, 2009 at 6:04 AM, Matt Farina wrote: > Two thoughts occurred to me on the community. > > First, we are no longer what the community was 3 or 5 years ago. The front > page of drupal has changed with a changing focus and need. Instead of a few > thousand users there are hundreds of thousands of users. The front page of > d.o has a different place in the ecosystem than it used to. But, we still > need a place for some of those things that used to get posted. Is g.d.o the > place for that? It is and I find it disturbing that it changed the way it did but it happened. I haven't decided what, if anything, I want to do about it. > Second, we seem to have a bit of an identity crisis. Is drupal a framework > or a CMS? If it's both should they be cleanly separated? How does this and > should this work? Moving the CMS like features into contrib, as some have > suggested, seems to be centered around this. If we have a drupal framework > and a drupal cms do we have maintainers for each piece? How does this > interaction work? I disagree with the identity crisis. Drupal has always been in balance. This balance is extremely beneficial and because it is 'close enough' for many it gets used, but it is also 'not quite right' for others and leads them into contributing or learning development. Some persist, some give up, some get angry and some do notable things. Drupal has been like this every release I have seen. If it hadn't been usable as a CMS (4.3), I would never have used it past learning how to install it. As long as the edge cases (toss everything out of core now vs just make it build my site telepathically) don't get their way we've probably kept a nice middle ground. As I am one of the few people on the dev list in the 'want some CMS features' camp, I feel it is important for me to speak up when the 'toss everything out' camp puts up their list. It's just the way discussions work is all. > Ah, growing pains. Now we just have to figure out how to bribe the kids to > clean their rooms (i.e. review patches and clean the queue). See historical emails for those discussions :) Steven > On Apr 21, 2009, at 3:31 AM, Stefan Nagtegaal wrote: > >> >> Op 21 apr 2009, om 08:20 heeft Steven Peck het volgende geschreven: >> >>> >>> >>> And Stefan, I too miss the old front page where it wasn't all site >>> implementations and Drupalcons but things people found interesting, >>> but that's just what happened. >>> >>> -sepeck >> >> Happy to hear that Sepeck, sometimes I wonder if it is just me who is >> experiencing this. >> Drupal is not for users anymore, drupal is for making money and profit. >> One example is the "Support the Drupal redesign! Donate Now"-button, which >> is currently cycling over the frontpage. Why can't we - as a community - >> build the new drupal.org design? It gives us a good reality check why drupal >> is (too) hard for true designers. >> >> That said, you could wonder that if some module is moved from core to >> contrib and dies silently, if it wasn't in core too long already. >> If nobody feels the urge to keep a certain module up to date, then you >> could argue about its usefullnes. >> >> I would rather see modules like views(1|2|3).module in core, which are >> very well designed and maintained and deserves to be in core, because of >> it's quality and filling the gap which there currently is in core. Building >> views/page-layouts is something drupal needs. Although, I do not think that >> the current implementation is right, the functionality surely is. >> >> Getting rid of modules like the help.module is not that smart imo. Dries >> started a monster project to make drupal more accessible and easier to use >> by attracting Mark Boulton and Leisa, which I think is a good thing. >> Although, I do not doubt that they could make things easier to use, but I'm >> pretty convinced they could not make things as easy that the help texts are >> becoming redundant. >> >> >> Kind regards, >> >> >> Stefan > > From jpetso at gmx.at Tue Apr 21 20:37:24 2009 From: jpetso at gmx.at (Jakob Petsovits) Date: Tue, 21 Apr 2009 22:37:24 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> Message-ID: <200904212237.24390.jpetso@gmx.at> On Tuesday 21 April 2009, Alex Barth wrote: > > No insults, but we don't really want to start wild forks of core > > modules with arbitrary maintainers and features in contrib. If we just do > > that, the quality of those forks won't differ from any other contrib > > module, and I would not see nor understand why those forks can't use a > > different module namespace (like any other module that thinks it can do > > better). > > I'd call it a backport. The same namespace makes it much easier to > maintain the backport. The incentive for keeping the backport up to > Drupal core standard is that its very reason-to-be is validating > changes being made to HEAD and using these changes in the current > release version. So the "new" plan is not to actually *move* stuff to contrib and let feature development happen there, but to only provide features in contrib that already made it into core. Sounds like a workable plan. Short pro/contra recap: + Same core-worthy standard for new code, no reliance of the "backport maintainer" to do the job as well as Dries does + No problems with getting code merged back into core for Drupal N+1 + No problems with upgrade paths, unless... well, whatever - solvable + Solves the "little incentive to work on core" issue, because the backport will be available in contrib soon + Integrates seamlessly with the current infrastructure + No worries about the module dying in contrib + Less effort backporting new features than forwardporting and constantly syncing with core - Important patches might get blocked by languishing in the core issue queue, can only be solved through a non-trivial number of maintainers/reviewers - ...actually, I can't currently think of any more real disadvantages. I think this is a great model to follow. The only requirement for success seems to be that the speed of feature development aligns with core for the "backport maintainer". When the developer needs lots of new features in a limited timeframe that are not interesting for core (or subject of heated discussions, say, "feed items as nodes") then unhappiness will still arise. But that's just peanuts, compared to the benefits. Also, I find it interesting that the same model is actually already practiced by Simpletest in contrib. -- Jakob's usual 3 cents From agentrickard at gmail.com Tue Apr 21 20:41:13 2009 From: agentrickard at gmail.com (Ken Rickard) Date: Tue, 21 Apr 2009 16:41:13 -0400 Subject: [development] Some of core to contrib? In-Reply-To: <49EE0C25.9030700@killesreiter.de> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> <49EE0C25.9030700@killesreiter.de> Message-ID: <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> Well, just to be clear, my biggest issue with core aggregator has long been that it is not an API, so you cannot call most aggregator functions outside of the context of the core module. This is a problem when trying to extend its functionality, and why FeedAPI (and the push for FeedAPI in core) was created. Killes, since I know you have used MySite, take a look at the kludge I had to write to allow users to add feeds there -- aggregator in core should support that feature (e.g. non-admins adding feeds to a collection), but did not (and probably still does not). So I think that supports the statement that aggregator code is "below" the node module, for instance. Should we add new features to aggregator? Maybe not. But it needs an architecture overhaul. One that is better done in contrib, as it turns out. - Ken On Tue, Apr 21, 2009 at 2:10 PM, Gerhard Killesreiter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Karoly Negyesi schrieb: >> On Tue, Apr 21, 2009 at 8:38 AM, Nathaniel Catchpole >> wrote: >>> Looks like we could try to do this without changing HEAD development >>> at all - if Alex starts with OpenID and Aggregator 2.x branches in >>> contrib, then anyone who wants to could do the same for the other >>> optional core modules. Then if it works we could look at better >>> infrastructure around it. >> >> This is not so simple. The gain for Alex would be that he can work on >> DRUPAL-7--1 while core is open with much more freedom. >> >> here, let me state this: would the quality of the code of aggregator >> be less high than the core standards? maybe. but, it already is way >> below. > > How do you reach this judgement? > >> These only-by-history core module are already not core quality so >> let them develop more freely. We are looking for responsible >> maintainers so I am sure they wont degrade into a stinking pile of >> debris. > > I use aggregator on drupal.org and the only feature I miss is to > exclude specific posts from a feed. > > Anything added beyond that would constitute cruft in my pov. > > Cheers, > ? ? ? ?Gerhard > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAknuDCQACgkQfg6TFvELooSkmQCfZLKnb2g+prgW/dGLY6hbsL/b > mgQAn2BHMlOpJqQ87o+kFunEDk6w4zOt > =o4Ss > -----END PGP SIGNATURE----- > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com From gerhard at killesreiter.de Tue Apr 21 20:57:20 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Tue, 21 Apr 2009 22:57:20 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> <49EE0C25.9030700@killesreiter.de> <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> Message-ID: <49EE3330.3000506@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ken Rickard schrieb: > Well, just to be clear, my biggest issue with core aggregator has > long been that it is not an API, so you cannot call most aggregator > functions outside of the context of the core module. This is a > problem when trying to extend its functionality, and why FeedAPI > (and the push for FeedAPI in core) was created. I can't understand why somebody remotely cares about such ephemeral things as feeds. :p > Killes, since I know you have used MySite, take a look at the kludge > I had to write to allow users to add feeds there -- aggregator in Frankly: Mysite was full of cludges at the time I used it (over a year ago). > core should support that feature (e.g. non-admins adding feeds to a > collection), but did not (and probably still does not). > > So I think that supports the statement that aggregator code is "below" > the node module, for instance. > > Should we add new features to aggregator? Maybe not. But it needs an > architecture overhaul. Ok, it you can make it more API-like while not bloating it too much, I can live with that. > One that is better done in contrib, as it turns out. Still not sure I buy that. How should a core committer review the resulting patch? It will be a "take all or leave it" thing. And I think that the result might be "leave it". Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuMzAACgkQfg6TFvELooQyeACff1yIVZZW8wJM4HdjU3k/M+f2 5W8AoI3kC0Q/RbVcOG3Nz993lQb5wfpB =kFnL -----END PGP SIGNATURE----- From larry at garfieldtech.com Tue Apr 21 22:01:21 2009 From: larry at garfieldtech.com (larry at garfieldtech.com) Date: Tue, 21 Apr 2009 17:01:21 -0500 Subject: [development] Some of core to contrib? In-Reply-To: <49EE3330.3000506@killesreiter.de> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> <49EE0C25.9030700@killesreiter.de> <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> <49EE3330.3000506@killesreiter.de> Message-ID: <49EE4231.4060100@garfieldtech.com> Gerhard Killesreiter wrote: >> Should we add new features to aggregator? Maybe not. But it needs an >> architecture overhaul. > > Ok, it you can make it more API-like while not bloating it too much, I > can live with that. > >> One that is better done in contrib, as it turns out. > > Still not sure I buy that. How should a core committer review the > resulting patch? It will be a "take all or leave it" thing. And I > think that the result might be "leave it". Which brings us back to my earlier comment about roadmaps and submaintainers who can be trusted to implement them without the core maintainers having to take the time to sweat over every single flipping line in every single flipping patch, and because people know that they can't make decisions about implementation because every single line can be second guessed and vetoed by just two very busy people, so the patch stalls waiting for feedback from them that doesn't come because they're reviewing 15 other patches. Part of the problem with a shortage of reviewers is that there's a very small number of reviewers who, well, matter. :-) And there's an increasing amount of code they have to deal with. --Larry Garfield From gerhard at killesreiter.de Tue Apr 21 22:26:34 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed, 22 Apr 2009 00:26:34 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <9ea8d6030904211107g58fbf1e2k9791c203a4af524c@mail.gmail.com> References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> <9ea8d6030904211107g58fbf1e2k9791c203a4af524c@mail.gmail.com> Message-ID: <49EE481A.2060101@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Johnson schrieb: > Conceptually, I view Drupal as shown in this illustration: > http://i43.tinypic.com/2zqfll1.jpg > > Core is really 3 things -- the lowest level subsystems and > abstractions providing APIs, the required glue and UI modules wrapped > around them, and the current CMS-oriented modules included with core. > > It would be nice, in my view, to minimize the amount of "required" > code to build a site with Drupal. This is already work in progress. Even block.module will be optional in D7. > The more there are specific use case modules which are tightly coupled in core, the more it gets in > the way of developing flexible sites and supporting flexible APIs. None of the modules that have been recommended for removal from core are really tightly coupled and hardly get in the way at all if you don't need them. CHeers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuSBoACgkQfg6TFvELooQQIwCfR2YEwCznDD5vHiBNetMTpmXY rZgAoIVGGuWyWHfGyE77x+A/mVqEGE2W =/SQ5 -----END PGP SIGNATURE----- From darthclue at gmail.com Tue Apr 21 22:28:14 2009 From: darthclue at gmail.com (Darth Clue) Date: Tue, 21 Apr 2009 17:28:14 -0500 Subject: [development] Some of core to contrib? In-Reply-To: <49EE4231.4060100@garfieldtech.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> <49EE0C25.9030700@killesreiter.de> <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> <49EE3330.3000506@killesreiter.de> <49EE4231.4060100@garfieldtech.com> Message-ID: <49EE487E.6020702@gmail.com> I'll take full blame for having started this whole thing even though chx was the first to post it. I brought up being able to have more influence over core modules between major releases because of previously encountered instances of "Features don't get implemented outside of a major release, eg D7 will have new features but D6 will always be about bug fixes." In particular, I mentioned the aggregator module and the inability to change the sort order of the feeds. I am in full support of anything that will make Drupal more attractive to the general masses. Being able to add features between major releases is something that I think would do this. It would help to attract people to core since they would then have the knowledge that a patch might actually have a chance of being accepted in the next two months instead of the next two years. Maintaining stability is a huge thing, more than supporting my little request. This also means that anyone who takes on maintainership of a core module would need to be willing to commit to keeping the code in line with core standards. I think those persons, including myself, who are making this request and recommendation are willing to do that. And if we're not, then we shouldn't be making such a request. From drewish at katherinehouse.com Tue Apr 21 22:29:09 2009 From: drewish at katherinehouse.com (andrew morton) Date: Tue, 21 Apr 2009 18:29:09 -0400 Subject: [development] Some of core to contrib? In-Reply-To: <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> <49EE0C25.9030700@killesreiter.de> <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> Message-ID: On Tue, Apr 21, 2009 at 4:41 PM, Ken Rickard wrote: > Well, just to be clear, my biggest issue with core aggregator has long > been that it is not an API, so you cannot call most aggregator > functions outside of the context of the core module. ?This is a > problem when trying to extend its functionality, and why FeedAPI (and > the push for FeedAPI in core) was created. And the FeedAPI code has been working it's way into the agregator module: http://drupal.org/node/303930 andrew From metzlerd at metzlerd.com Wed Apr 22 01:58:10 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Tue, 21 Apr 2009 18:58:10 -0700 Subject: [development] Some of core to contrib? In-Reply-To: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> Message-ID: <821E8917-46CD-43A5-A52C-6CA902F7E62C@metzlerd.com> I'm confused about one point here. I must confess that although I don't have a lot of experience with Test driven development, I've done some of it and am familiar with the concepts. Are we sure that drupal.org provides automated testing infrastructure for contrib? I don't quite understand how that works given the possibilites of module conflicts and dependencies. If you say it works and can point to an example of a test driven contrib supported by d.o, I'll happily withdraw this concern, but I've always assumed that contrib test driven development couldn't happen, but that contrib providers would need their own infrastructure. Although my own module list of contrib to remove doesn't include comments or aggregator, I'm certainly ok with seeing contrib's removed from core, but I think there's value in having a small set of useful simple modules track with core and therefor get tests run for it (assuming I'm right about testing support). Dave On Apr 20, 2009, at 4:01 PM, Karoly Negyesi wrote: > Hi, > > So it seems there is quite some talk about moving some of the core to > contrib. This talk comes up from time but we did not have testing and > now we do. And that makes a big, big difference, I tell you. > > So let's suppose that aggregator gets moved into contrib. Every core > tarball still contains aggregator, the latest tag from the DRUPAL-7--1 > branch. But the aggregator people can churn out bugfixes as fast as > they can and the tests will make sure they won't break stuff. > Meanwhile, new features can get into DRUPAL-7--2. Every user can use > --2 invidually, core will come with --1 still. Also, they maintain a > DRUPAL-8--1 branch and for every unstable/beta/RC they make sure they > have ported aggregator and tag similarly as core does (we can punt > some of the unstables -- I could understand that not every module gets > DBTNG'd immediately it did not happen anyways). Let's list the > benefits again: > > *) if a company is interested in a module it can grow a community > around much easier than with core. They can both release bugfixes and > features. > *) core does not lose the feedback from its modules > > Possible problems: > > *) lose of maintenance > *) additional burden on these maintainers w/ HEAD compatibility. > > Also, aspiring projects can opt for core inclusion (if they accept > that a branch can not break APIs and willing to tag along with core) > which can be much easier this way. Let's face it, there are much > higher quality contribs than the mess called comment module so why > not? > > There is the small problem of how can people using cvs update core > now, do they need to run a cvs up for every directory? Hardly. We can > create a 'mirror' which pulls together the commits. This is an easily > doable (and yes I am willing to script it). > > Regards > > Karoly Negyesi From metzlerd at metzlerd.com Wed Apr 22 02:05:20 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Tue, 21 Apr 2009 19:05:20 -0700 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <20090421142004.18621a7x8w1pldtw@mail.siebunlimited.com> References: <49EC7B14.7060706@killesreiter.de> <49ECC28B.407@logrus.com> <7e270cea0904201208t66bb3459q44b61f50ad1e6fcf@mail.gmail.com> <200904201438.22769.drupal@samboyer.org> <61bca48a0904201403u608ef4f0seb5edc38bc223d3e@mail.gmail.com> <61bca48a0904201419n53882b64v8a2519fd0c5c704c@mail.gmail.com> <8B0EE0CA-CD2F-40B7-B278-98256A54E2FF@metzlerd.com> <20090421142004.18621a7x8w1pldtw@mail.siebunlimited.com> Message-ID: <61A18AD8-7A2C-4F65-BC8D-C29112DA206C@metzlerd.com> I agree with this post, but also understand that there are times when this is not possible. I read enough of the panels thread to understand that there were some changes in the menu system that made porting Panels 2 in a feature complete way to D6 significantly difficult, and I want to acknowledge that this is a reality that maintainers must live with when frameworks change (which I continue to believe is a good thing). Dave On Apr 21, 2009, at 7:20 AM, Earnie Boyd wrote: > Quoting David Metzler : > >> >> I think think the right answer about drupal stagnating was really >> about having Views, Panels, and WYSIWG api all going through major >> refactoring on D6, all lagging significantly the D6 release. I >> know it's why I'm not using my own D6 ported modules in any >> production sites yet. >> > > And to avoid this the module developer needs to agree to port the > existing functionality of a module from one version to the next > while the new features of the module are being developed. The > deadwood and coder modules can help with that and should be one of > the first modules upgraded out of the door. New functionality in a > module is great but once a Drupal version is out and people are > knocking on the modules door for "when is Dx going to be supported" > carrying over the old functionality to the new Dx should have a > priority over a more powerful, better looking model. D6 still lags > because modules are improving their API and developers aren't > willing to put out a module that is carries the sins of the older > D5 version. A worthy goal but so is getting a module that is > working just like the previous. This is really a sore sticking > point making using Drupal sour in some eyes. > > I agree that Drupal has a nice feature rich framework for building > many different applications (modules). I agree that the CMS work > is what has drawn many to Drupal. However, a focus on CMS often > drowns the other usefulness of the framework and you have a > situation similar to HORDE/IMP. Does anyone think framework when > they hear HORDE? Maybe as a second thought but usually you think > an email client. Unfortunately when people here Drupal they think > CMS and not framework. Most users of the CMS don't care that the > framework of Drupal or the framework of their favorite module is > now more feature rich at first. They care that their sites will > work exactly the same as it does before upgrading. Then they might > look at the newer features. > > There are more users of Drupal than there are hackers providing > code, peer reviews and module functionality. Yes, these are > important but not to the non-technical user of the product. People > are tired of waiting on module maintainers and probably will go > elsewhere or worse create their own version of the module. This is > why it is important for contrib modules to be readily available > within a month of a new Dx release. > > -- > Earnie > -- http://r-feed.com/ -- http://for-my-kids.com/ > -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ > > From drupal at dave-cohen.com Wed Apr 22 03:58:38 2009 From: drupal at dave-cohen.com (David Cohen) Date: Tue, 21 Apr 2009 20:58:38 -0700 Subject: [development] watchdog() does not always work - or am I missing something? Message-ID: <1240372718.9607.1311694433@webmail.messagingengine.com> I'm debugging a situation where one of my drupal menu items is being called via javascript, AJAX style. To debug a problem, I've added watchdog() calls to the callback - as a sanity check that the callback is being reached, and so I can inspect some values. The problem is that the log entries never show the messages I'm trying to write. Its as if the menu callback is never called. However the apache log shows that the path is being requested. Let's say the path is /drupal/my/callback. Now, when I explicitly point a browser to the URL, lets say http://example.com/drupal/my/callback, then the watchdog messages are written to the log! It's as if watchdog only succeeds when the browser explicitly makes the request. I've tried disabling drupal's cache. I've tried refreshing the cache. No matter what I do, either my callback is not being called (despite apache logs to the contrary) or the watchdog calls fail without error (which would be crazy). But only fail when the call is made via javascript. When made explicitly from the browser everything works as expected. BTW, the apache logs indicate the proper number of bytes is returned by the request, and I've changed the size of the page returned to confirm this - evidence that caching is not the cause of this. Has anyone seen this or have any ideas? Many thanks. -Dave From karoly at negyesi.net Wed Apr 22 04:03:04 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 21 Apr 2009 21:03:04 -0700 Subject: [development] watchdog() does not always work - or am I missing something? In-Reply-To: <1240372718.9607.1311694433@webmail.messagingengine.com> References: <1240372718.9607.1311694433@webmail.messagingengine.com> Message-ID: <7e270cea0904212103o2ec968e0kc2e1f6403a7552df@mail.gmail.com> I will presume you run Drupal 6. Visit admin/build/modules to rebuild you rmenu. From marco.carbone at gmail.com Wed Apr 22 04:06:27 2009 From: marco.carbone at gmail.com (Marco Carbone) Date: Tue, 21 Apr 2009 21:06:27 -0700 Subject: [development] watchdog() does not always work - or am I missing something? In-Reply-To: <7e270cea0904212103o2ec968e0kc2e1f6403a7552df@mail.gmail.com> References: <1240372718.9607.1311694433@webmail.messagingengine.com> <7e270cea0904212103o2ec968e0kc2e1f6403a7552df@mail.gmail.com> Message-ID: <93bcb5e50904212106t9ca100dkcd7a2e6ddb2622cf@mail.gmail.com> Try using syslog to debug -- add one to your call and to the watchdog call itself. -marco On Tue, Apr 21, 2009 at 9:03 PM, Karoly Negyesi wrote: > I will presume you run Drupal 6. Visit admin/build/modules to rebuild you rmenu. > From nevets at tds.net Wed Apr 22 04:25:00 2009 From: nevets at tds.net (Steve Ringwood) Date: Tue, 21 Apr 2009 23:25:00 -0500 Subject: [development] watchdog() does not always work - or am I missing something? In-Reply-To: <1240372718.9607.1311694433@webmail.messagingengine.com> References: <1240372718.9607.1311694433@webmail.messagingengine.com> Message-ID: <49EE9C1C.7020504@mailbag.com> Another useful tool is firebug and the net tab, you should see the request go out and see how the server responds. My first thought is the path the js uses is relative (no leading slash for example) and not resolving as expected. From fgm at osinet.fr Wed Apr 22 06:16:02 2009 From: fgm at osinet.fr (=?iso-8859-1?Q?Fr=E9d=E9ric_G._MARAND?=) Date: Wed, 22 Apr 2009 08:16:02 +0200 Subject: [development] watchdog() does not always work - or am I missingsomething? In-Reply-To: <1240372718.9607.1311694433@webmail.messagingengine.com> References: <1240372718.9607.1311694433@webmail.messagingengine.com> Message-ID: <719C687D0E384B64A4A9514F866F8128@PCdeMarand> I've seen a similar case, where watchdog wouldn't work because the referer field was too long and the insert request in dblog failed almost silently instead of truncating that field (innodb engine, not checked with myisam engine): the request wasn't logged and the failure of that request wasn't stored either, IIRC for the same reason. Had to see it in a debugger to understand what was going on. You might want to try a debugger too. ----- Original Message ----- From: "David Cohen" To: Sent: Wednesday, April 22, 2009 5:58 AM Subject: [development] watchdog() does not always work - or am I missingsomething? I'm debugging a situation where one of my drupal menu items is being called via javascript, AJAX style. To debug a problem, I've added watchdog() calls to the callback - as a sanity check that the callback is being reached, and so I can inspect some values. The problem is that the log entries never show the messages I'm trying to write. Its as if the menu callback is never called. However the apache log shows that the path is being requested. Let's say the path is /drupal/my/callback. Now, when I explicitly point a browser to the URL, lets say http://example.com/drupal/my/callback, then the watchdog messages are written to the log! It's as if watchdog only succeeds when the browser explicitly makes the request. I've tried disabling drupal's cache. I've tried refreshing the cache. No matter what I do, either my callback is not being called (despite apache logs to the contrary) or the watchdog calls fail without error (which would be crazy). But only fail when the call is made via javascript. When made explicitly from the browser everything works as expected. BTW, the apache logs indicate the proper number of bytes is returned by the request, and I've changed the size of the page returned to confirm this - evidence that caching is not the cause of this. Has anyone seen this or have any ideas? Many thanks. -Dave -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.287 / Virus Database: 270.12.1/2071 - Release Date: 04/21/09 08:30:00 From Peter at attiks.com Wed Apr 22 07:03:23 2009 From: Peter at attiks.com (Peter Droogmans) Date: Wed, 22 Apr 2009 09:03:23 +0200 Subject: [development] watchdog() does not always work - or am I missing something? In-Reply-To: <49EE9C1C.7020504@mailbag.com> References: <1240372718.9607.1311694433@webmail.messagingengine.com> <49EE9C1C.7020504@mailbag.com> Message-ID: You can also change the size of the field in mysql, for the moment it's set as varchar(128) -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org] On Behalf Of Steve Ringwood Sent: woensdag 22 april 2009 06:25 To: development at drupal.org Subject: Re: [development] watchdog() does not always work - or am I missing something? Another useful tool is firebug and the net tab, you should see the request go out and see how the server responds. My first thought is the path the js uses is relative (no leading slash for example) and not resolving as expected. From gerhard at killesreiter.de Wed Apr 22 06:46:20 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed, 22 Apr 2009 08:46:20 +0200 Subject: [development] Some of core to contrib? In-Reply-To: <49EE0AE1.7090600@killesreiter.de> References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> <49EE0AE1.7090600@killesreiter.de> Message-ID: <49EEBD3C.8020001@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerhard Killesreiter schrieb: > Alex Barth schrieb: >> On Apr 21, 2009, at 12:30 PM, Daniel F. Kudwien wrote: > >>>> Looks like we could try to do this without changing HEAD >>>> development at all - if Alex starts with OpenID and >>>> Aggregator 2.x branches in contrib, then anyone who wants to >>>> could do the same for the other optional core modules. Then >>>> if it works we could look at better infrastructure around it. >>> No insults, but we don't really want to start wild forks of core modules >>> with arbitrary maintainers and features in contrib. If we just do >>> that, the >>> quality of those forks won't differ from any other contrib module, and I >>> would not see nor understand why those forks can't use a different module >>> namespace (like any other module that thinks it can do better). >> I'd call it a backport. The same namespace makes it much easier to >> maintain the backport. The incentive for keeping the backport up to >> Drupal core standard is that its very reason-to-be is validating changes >> being made to HEAD and using these changes in the current release version. > >> Any 'fork' in contrib with the same name as a Drupal core module only >> worries me in so far as it's using up valuable namespace for exactly >> doing that. > > I think that this would be rather confusing for joe average user and > request that you leave the core namespaces alone. Let me illustrate the "why". I am in the process of writing a slightly changed version of the dblog module. Most of the changes will be in the .install file. While I do think my changes are a good idea, others might disagree. It is one of the patches where Dries was more stubborn than me after all (http://drupal.org/node/78503, for the interested reader). Now, should I really call this dblog and use the 6--2 branch? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuvTwACgkQfg6TFvELooRFqwCZAfNgHTy/c76CK12e1/WVQAC4 AVoAoJoM5w6gYUTAwfmmqlyapHgytC6x =4SxK -----END PGP SIGNATURE----- From catch56 at googlemail.com Wed Apr 22 09:17:17 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Wed, 22 Apr 2009 10:17:17 +0100 Subject: [development] Some of core to contrib? In-Reply-To: <49EEBD3C.8020001@killesreiter.de> References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> <49EE0AE1.7090600@killesreiter.de> <49EEBD3C.8020001@killesreiter.de> Message-ID: > > Gerhard Killesreiter schrieb: > > Let me illustrate the "why". > > I am in the process of writing a slightly changed version of the dblog > module. Most of the changes will be in the .install file. > > While I do think my changes are a good idea, others might disagree. It > is one of the patches where Dries was more stubborn than me after all > (http://drupal.org/node/78503, for the interested reader). > > Now, should I really call this dblog and use the 6--2 branch Alex is only talking about backporting patches which are actually in Drupal 7 already (as far as I know), so assuming that patch gets refreshed and committed, why not? A module with an issue queue is better than people clamouring for 'can I have a D6 version of this patch plz' on fixed issues in the core queue which are never going to get a straight backport in core itself. However I think using the actual namespace for the module does bring up some issues (hook_update_N() and just general potential confusion) - so we could consider aggregator_backport and dblog_backport or something instead (or at least really, really clear and standard descriptions on project pages). Another example where this is has happened already is tracker2 (which runs on Drupal.org) - although the issue it fixes is still a critical bug in HEAD and hasn't been updated in a while - hence why I think a 2.x branch of core modules is a good idea - it saves having to manually apply patches, fork, or reinvent the wheel - all of which has happened with aggregator, tracker, comment and others to various levels of success and confusion. Nat From earnie at users.sourceforge.net Wed Apr 22 11:54:51 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 22 Apr 2009 11:54:51 +0000 Subject: [development] Some of core to contrib? In-Reply-To: References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> <49EE0AE1.7090600@killesreiter.de> <49EEBD3C.8020001@killesreiter.de> Message-ID: <20090422115451.15982yny58a86vms@mail.siebunlimited.com> Quoting Nathaniel Catchpole : > > However I think using the actual namespace for the module does bring > up some issues (hook_update_N() and just general potential confusion) > - so we could consider aggregator_backport and dblog_backport or > something instead (or at least really, really clear and standard > descriptions on project pages). > I would rather see a different directory named backports than filling up contrib creating yet another confusion point to entry level people. Really this isn't fit for the contrib modules. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From earnie at users.sourceforge.net Wed Apr 22 12:01:08 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 22 Apr 2009 12:01:08 +0000 Subject: [development] Some of core to contrib? In-Reply-To: <49EEBD3C.8020001@killesreiter.de> References: <111801c9c29e$815d0c70$0200a8c0@structworks.com> <7239F498-54A5-4D10-9F1D-B0B125CE7650@developmentseed.org> <49EE0AE1.7090600@killesreiter.de> <49EEBD3C.8020001@killesreiter.de> Message-ID: <20090422120108.53496nwssdv36d4w@mail.siebunlimited.com> Quoting Gerhard Killesreiter : > > Now, should I really call this dblog and use the 6--2 branch? > I know your question is rhetorical so I'll give a rhetorical answer of hell no. It's not even a backport. It is dblog-gerhard-style. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From alex at developmentseed.org Wed Apr 22 14:14:47 2009 From: alex at developmentseed.org (Alex Barth) Date: Wed, 22 Apr 2009 10:14:47 -0400 Subject: [development] Some of core to contrib? In-Reply-To: <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> References: <7e270cea0904201601i2085794bof92614d5c4a40a5d@mail.gmail.com> <1F0CA907-8ABC-4781-8E12-C2C4EA8730BB@developmentseed.org> <7e270cea0904210758m1e3989d9hddf205d271895900@mail.gmail.com> <7e270cea0904210812s2a31461av3899e33ae586b816@mail.gmail.com> <49EDE46C.3040508@gmx.de> <7e270cea0904210823k22033839q83b6c295a3a2a7a5@mail.gmail.com> <7e270cea0904210938x690f8006t7840629e271aed45@mail.gmail.com> <49EE0C25.9030700@killesreiter.de> <25b45da00904211341pa85eaecq4f00e02df6f9fa8a@mail.gmail.com> Message-ID: <96B65D92-A2F3-48EA-90AC-799FD4F56C33@developmentseed.org> On Apr 21, 2009, at 4:41 PM, Ken Rickard wrote: > > Should we add new features to aggregator? Maybe not. But it needs an > architecture overhaul. One that is better done in contrib, as it turns > out. Agree, we needed to start aggregator API improvements in contrib, it gave us the freedom to dabble and learn quick. The result is FeedAPI, you've been part of that as the mentor of the initial FeedAPI project in GSoC 07. Looking at FeedAPI you will be able to tell that we were still learning what it takes to build an API for feed aggregation. We're now about to apply the best approaches to core aggregator: http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted=&participant=&status []= 1 &status []= 16 &status []= 8 &status []= 13 &status []=14&status[]=15&status[]=2&version[]=7.x&component[]=aggregator.module I invite everybody to review :-) PS: the long link up there? that's a bookmark in my browser :P > > > - Ken > > On Tue, Apr 21, 2009 at 2:10 PM, Gerhard Killesreiter > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Karoly Negyesi schrieb: >>> On Tue, Apr 21, 2009 at 8:38 AM, Nathaniel Catchpole >>> wrote: >>>> Looks like we could try to do this without changing HEAD >>>> development >>>> at all - if Alex starts with OpenID and Aggregator 2.x branches in >>>> contrib, then anyone who wants to could do the same for the other >>>> optional core modules. Then if it works we could look at better >>>> infrastructure around it. >>> >>> This is not so simple. The gain for Alex would be that he can work >>> on >>> DRUPAL-7--1 while core is open with much more freedom. >>> >>> here, let me state this: would the quality of the code of aggregator >>> be less high than the core standards? maybe. but, it already is way >>> below. >> >> How do you reach this judgement? >> >>> These only-by-history core module are already not core quality so >>> let them develop more freely. We are looking for responsible >>> maintainers so I am sure they wont degrade into a stinking pile of >>> debris. >> >> I use aggregator on drupal.org and the only feature I miss is to >> exclude specific posts from a feed. >> >> Anything added beyond that would constitute cruft in my pov. >> >> Cheers, >> Gerhard >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iEYEARECAAYFAknuDCQACgkQfg6TFvELooSkmQCfZLKnb2g+prgW/dGLY6hbsL/b >> mgQAn2BHMlOpJqQ87o+kFunEDk6w4zOt >> =o4Ss >> -----END PGP SIGNATURE----- >> > > > > -- > Ken Rickard > agentrickard at gmail.com > http://ken.therickards.com Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633 From cxjohnson at gmail.com Wed Apr 22 16:07:48 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 22 Apr 2009 11:07:48 -0500 Subject: [development] watchdog() does not always work - or am I missing something? In-Reply-To: References: <1240372718.9607.1311694433@webmail.messagingengine.com> <49EE9C1C.7020504@mailbag.com> Message-ID: <9ea8d6030904220907s434ae037id3e259f6331c79fd@mail.gmail.com> As Fr?d?ric described, this sounds like a bug in watchdog. On Wed, Apr 22, 2009 at 2:03 AM, Peter Droogmans wrote: > You can also change the size of the field in mysql, for the moment it's set as varchar(128) From steven at digitalpulp.com Wed Apr 22 16:12:26 2009 From: steven at digitalpulp.com (Steven Surowiec) Date: Wed, 22 Apr 2009 12:12:26 -0400 Subject: [development] Watchdog dieing on large queries Message-ID: <49EF41EA.4060709@digitalpulp.com> I've found a workaround for myself for this one but just wanted to put it out there. When a query fails watchdog is used to insert it into the DB, which is fine 99.9% of the time, until that .1% bites you. The problem is that if the query (say inserting a new record into the "cache") causes a query that is larger than the MySQL query buffer limit. This results in a MySQL error that the query is too large to insert, which watchdog then picks up and tries to insert, which fails, which watchdog picks up ... and you get the point. Result? Infinite loop and then either a timeout or PHP runs out of memory and dies. I'd think the proper way to handle this would be to have a check that the specific error code for a MySQL error resulting from a query buffer violation doesn't try to insert the query, again just putting this out there. From weitzman at tejasa.com Wed Apr 22 16:29:15 2009 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed, 22 Apr 2009 12:29:15 -0400 Subject: [development] Watchdog dieing on large queries In-Reply-To: <49EF41EA.4060709@digitalpulp.com> References: <49EF41EA.4060709@digitalpulp.com> Message-ID: <6117a7500904220929p46753b29vd5339151fa65ca65@mail.gmail.com> sounds reasonable. please file an issue and ideally provide a patch. On Wed, Apr 22, 2009 at 12:12 PM, Steven Surowiec wrote: > I've found a workaround for myself for this one but just wanted to put it > out there. When a query fails watchdog is used to insert it into the DB, > which is fine 99.9% of the time, until that .1% bites you. The problem is > that if the query (say inserting a new record into the "cache") causes a > query that is larger than the MySQL query buffer limit. This results in a > MySQL error that the query is too large to insert, which watchdog then picks > up and tries to insert, which fails, which watchdog picks up ... and you get > the point. Result? Infinite loop and then either a timeout or PHP runs out > of memory and dies. I'd think the proper way to handle this would be to have > a check that the specific error code for a MySQL error resulting from a > query buffer violation doesn't try to insert the query, again just putting > this out there. > From drupal at dave-cohen.com Wed Apr 22 16:51:40 2009 From: drupal at dave-cohen.com (Dave Cohen) Date: Wed, 22 Apr 2009 09:51:40 -0700 Subject: [development] watchdog() does not always work - or am I missingsomething? In-Reply-To: <719C687D0E384B64A4A9514F866F8128@PCdeMarand> References: <1240372718.9607.1311694433@webmail.messagingengine.com> <719C687D0E384B64A4A9514F866F8128@PCdeMarand> Message-ID: <200904220951.41263.drupal@dave-cohen.com> Good call Fr?d?ric. I just found messages in my /var/log/messages.log... query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES(1, 'php', '<em>Data too long for column &amp;#039;referer&amp;#039; at row 1 I recently added sql_mode=STRICT_ALL_TABLES to my.cnf, in order to catch issues like this in my own modules. And that's the setting that tells mysql to fail rather than truncate the long values. -Dave On Tuesday 21 April 2009 23:16:02 Fr?d?ric G. MARAND wrote: > I've seen a similar case, where watchdog wouldn't work because the referer > field was too long and the insert request in dblog failed almost silently > instead of truncating that field (innodb engine, not checked with myisam > engine): the request wasn't logged and the failure of that request wasn't > stored either, IIRC for the same reason. Had to see it in a debugger to > understand what was going on. You might want to try a debugger too. > From kb at 2bits.com Wed Apr 22 17:00:13 2009 From: kb at 2bits.com (Khalid Baheyeldin) Date: Wed, 22 Apr 2009 13:00:13 -0400 Subject: [development] Watchdog dieing on large queries In-Reply-To: <49EF41EA.4060709@digitalpulp.com> References: <49EF41EA.4060709@digitalpulp.com> Message-ID: <4a9fdc630904221000q7f7144den19e57d65d461b57e@mail.gmail.com> On Wed, Apr 22, 2009 at 12:12 PM, Steven Surowiec wrote: > I've found a workaround for myself for this one but just wanted to put it > out there. When a query fails watchdog is used to insert it into the DB, > which is fine 99.9% of the time, until that .1% bites you. The problem is > that if the query (say inserting a new record into the "cache") causes a > query that is larger than the MySQL query buffer limit. This results in a > MySQL error that the query is too large to insert, which watchdog then picks > up and tries to insert, which fails, which watchdog picks up ... and you get > the point. This is why we have syslog as an option in core since D6. Having to log to the database does not scale for may sites, either because they are large and hit the db too often, or because of large queries that overflow MySQL buffer or something else. I used it on most D6 sites. > Result? Infinite loop and then either a timeout or PHP runs out of memory > and dies. I'd think the proper way to handle this would be to have a check > that the specific error code for a MySQL error resulting from a query buffer > violation doesn't try to insert the query, again just putting this out > there. > Seems like a reasonable change to the dblog module. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci -------------- next part -------------- An HTML attachment was scrubbed... URL: From karoly at negyesi.net Wed Apr 22 17:26:09 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed, 22 Apr 2009 10:26:09 -0700 Subject: [development] watchdog() does not always work - or am I missingsomething? In-Reply-To: <200904220951.41263.drupal@dave-cohen.com> References: <1240372718.9607.1311694433@webmail.messagingengine.com> <719C687D0E384B64A4A9514F866F8128@PCdeMarand> <200904220951.41263.drupal@dave-cohen.com> Message-ID: <7e270cea0904221026h55a972ebgaf89caac777c03b0@mail.gmail.com> What is the issue link you filed for this bug then on drupal.org? :) On Wed, Apr 22, 2009 at 9:51 AM, Dave Cohen wrote: > Good call Fr?d?ric. ?I just found messages in my /var/log/messages.log... > > query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES(1, 'php', '<em>Data too long for column &amp;#039;referer&amp;#039; at row 1 > > I recently added sql_mode=STRICT_ALL_TABLES to my.cnf, in order to catch issues like this in my own modules. ?And that's the setting that tells mysql to fail rather than truncate the long values. > > -Dave > > > On Tuesday 21 April 2009 23:16:02 Fr?d?ric G. MARAND wrote: >> I've seen a similar case, where watchdog wouldn't work because the referer >> field was too long and the insert request in dblog failed almost silently >> instead of truncating that field (innodb engine, not checked with myisam >> engine): the request wasn't logged and the failure of that request wasn't >> stored either, IIRC for the same reason. Had to see it in a debugger to >> understand what was going on. You might want to try a debugger too. >> >

From news at unleashedmind.com Wed Apr 22 17:32:21 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Wed, 22 Apr 2009 19:32:21 +0200 Subject: [development] watchdog() does not always work - or am Imissingsomething? In-Reply-To: <7e270cea0904221026h55a972ebgaf89caac777c03b0@mail.gmail.com> Message-ID: <14b901c9c370$4addc090$0200a8c0@structworks.com> > >

> This is why I love WYSIWYG. From karoly at negyesi.net Wed Apr 22 17:42:44 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed, 22 Apr 2009 10:42:44 -0700 Subject: [development] watchdog() does not always work - or am Imissingsomething? In-Reply-To: <14b901c9c370$4addc090$0200a8c0@structworks.com> References: <7e270cea0904221026h55a972ebgaf89caac777c03b0@mail.gmail.com> <14b901c9c370$4addc090$0200a8c0@structworks.com> Message-ID: <7e270cea0904221042k2086cf1ai65532e0ae84bc5eb@mail.gmail.com> While the hate for WYSIWYG is well place, this is http://www.google.com/support/forum/p/gmail/thread?tid=1e986c013a16a9bb&hl=en On Wed, Apr 22, 2009 at 10:32 AM, Daniel F. Kudwien wrote: >> >>

>> > > This is why I love WYSIWYG. > > From inaki.lopez at gmail.com Wed Apr 22 18:13:51 2009 From: inaki.lopez at gmail.com (=?ISO-8859-1?Q?I=F1aki_Lopez?=) Date: Wed, 22 Apr 2009 20:13:51 +0200 Subject: [development] Watchdog dieing on large queries In-Reply-To: <4a9fdc630904221000q7f7144den19e57d65d461b57e@mail.gmail.com> References: <49EF41EA.4060709@digitalpulp.com> <4a9fdc630904221000q7f7144den19e57d65d461b57e@mail.gmail.com> Message-ID: <4f097c7f0904221113r7d2ad7b4y459e776a21de3774@mail.gmail.com> There's another kind of error I'm dealing with today, It's not a too long inserting error, but php extension errors would do.. fsockopen for example starts another dblog loop when the connection fails because of drupal's inhability to parse the error (the unserialize on dblog.admin.inc, line:251 -> return t($dblog->message, unserialize($dblog->variables)); I just noticed it, but did not debug enough about. On Wed, Apr 22, 2009 at 7:00 PM, Khalid Baheyeldin wrote: > On Wed, Apr 22, 2009 at 12:12 PM, Steven Surowiec wrote: > >> I've found a workaround for myself for this one but just wanted to put it >> out there. When a query fails watchdog is used to insert it into the DB, >> which is fine 99.9% of the time, until that .1% bites you. The problem is >> that if the query (say inserting a new record into the "cache") causes a >> query that is larger than the MySQL query buffer limit. This results in a >> MySQL error that the query is too large to insert, which watchdog then picks >> up and tries to insert, which fails, which watchdog picks up ... and you get >> the point. > > > This is why we have syslog as an option in core since D6. Having to log to > the database does not scale for may sites, either because they are large and > hit the db too often, or because of large queries that overflow MySQL buffer > or something else. > > I used it on most D6 sites. > > >> Result? Infinite loop and then either a timeout or PHP runs out of memory >> and dies. I'd think the proper way to handle this would be to have a check >> that the specific error code for a MySQL error resulting from a query buffer >> violation doesn't try to insert the query, again just putting this out >> there. >> > > Seems like a reasonable change to the dblog module. > -- > Khalid M. Baheyeldin > 2bits.com, Inc. > http://2bits.com > Drupal optimization, development, customization and consulting. > Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra > Simplicity is the ultimate sophistication. -- Leonardo da Vinci > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miriam at mail.snunit.k12.il Thu Apr 23 12:19:46 2009 From: miriam at mail.snunit.k12.il (Miriam Natanzon) Date: Thu, 23 Apr 2009 15:19:46 +0300 Subject: [development] Watchdog dieing on large queries In-Reply-To: <49EF41EA.4060709@digitalpulp.com> Message-ID: I also have this problem. Any Solution?? It caused me a timeout and then "MySQL server has gone away" response message... -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]On Behalf Of Steven Surowiec Sent: Wednesday, April 22, 2009 7:12 PM To: development at drupal.org Subject: [development] Watchdog dieing on large queries I've found a workaround for myself for this one but just wanted to put it out there. When a query fails watchdog is used to insert it into the DB, which is fine 99.9% of the time, until that .1% bites you. The problem is that if the query (say inserting a new record into the "cache") causes a query that is larger than the MySQL query buffer limit. This results in a MySQL error that the query is too large to insert, which watchdog then picks up and tries to insert, which fails, which watchdog picks up ... and you get the point. Result? Infinite loop and then either a timeout or PHP runs out of memory and dies. I'd think the proper way to handle this would be to have a check that the specific error code for a MySQL error resulting from a query buffer violation doesn't try to insert the query, again just putting this out there. From steven at digitalpulp.com Thu Apr 23 12:36:51 2009 From: steven at digitalpulp.com (Steven Surowiec) Date: Thu, 23 Apr 2009 08:36:51 -0400 Subject: [development] Watchdog dieing on large queries In-Reply-To: References: Message-ID: <49F060E3.4010301@digitalpulp.com> The problem for me was that the query in question was larger than max_allowed_packet would allow, so I just had to increase this a bit. MySQL has some documentation on this setting at the below URL. http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_max_allowed_packet Miriam Natanzon wrote: > I also have this problem. > > Any Solution?? > It caused me a timeout and then "MySQL server has gone away" response > message... > > -----Original Message----- > From: development-bounces at drupal.org > [mailto:development-bounces at drupal.org]On Behalf Of Steven Surowiec > Sent: Wednesday, April 22, 2009 7:12 PM > To: development at drupal.org > Subject: [development] Watchdog dieing on large queries > > I've found a workaround for myself for this one but just wanted to put > it out there. When a query fails watchdog is used to insert it into the > DB, which is fine 99.9% of the time, until that .1% bites you. The > problem is that if the query (say inserting a new record into the > "cache") causes a query that is larger than the MySQL query buffer > limit. This results in a MySQL error that the query is too large to > insert, which watchdog then picks up and tries to insert, which fails, > which watchdog picks up ... and you get the point. Result? Infinite loop > and then either a timeout or PHP runs out of memory and dies. I'd think > the proper way to handle this would be to have a check that the specific > error code for a MySQL error resulting from a query buffer violation > doesn't try to insert the query, again just putting this out there. > > From drupal at dave-cohen.com Thu Apr 23 19:53:51 2009 From: drupal at dave-cohen.com (Dave Cohen) Date: Thu, 23 Apr 2009 12:53:51 -0700 Subject: [development] watchdog() does not always work - or am I missingsomething? In-Reply-To: <7e270cea0904221026h55a972ebgaf89caac777c03b0@mail.gmail.com> References: <1240372718.9607.1311694433@webmail.messagingengine.com> <200904220951.41263.drupal@dave-cohen.com> <7e270cea0904221026h55a972ebgaf89caac777c03b0@mail.gmail.com> Message-ID: <200904231253.51576.drupal@dave-cohen.com> On Wednesday 22 April 2009 10:26:09 Karoly Negyesi wrote: > What is the issue link you filed for this bug then on drupal.org? :) http://drupal.org/node/443182 Thanks for asking! :) From drupal at dave-cohen.com Thu Apr 23 20:09:05 2009 From: drupal at dave-cohen.com (Dave Cohen) Date: Thu, 23 Apr 2009 13:09:05 -0700 Subject: [development] varchar(255) Message-ID: <200904231309.05808.drupal@dave-cohen.com> In another recent thread (about watchdog), Fr?d?ric suggested increasing the size of the watchdog.referer column. And he's right to suggest it because strings that are too long are not written to the database. This brings to 3 the number of columns I increase to varchar(255) on my Drupal sites. The three are watchdog.referer, users.mail, and sessions.sid. If my understanding of mysql is correct, there is no difference between a varchar(128) column filled with 128-byte strings and a varchar(255) column filled with 128-byte strings. However, there is a huge difference between a varchar(128) column filled with 129-byte strings and a varchar(255) filled with 129-byte strings. (The latter will work). So please, when developing for Drupal and wondering what size to make that varchar... stop wondering and use varchar(255). Or if you need it even longer varchar(65535). Note that lengths up to 255 can be represented in one byte, and 65535 in two bytes. Oh and please do correct me if I'm wrong about any of this, -Dave From mfburdett at gmail.com Thu Apr 23 20:27:01 2009 From: mfburdett at gmail.com (mark burdett) Date: Thu, 23 Apr 2009 13:27:01 -0700 Subject: [development] varchar(255) In-Reply-To: <200904231309.05808.drupal@dave-cohen.com> References: <200904231309.05808.drupal@dave-cohen.com> Message-ID: On Thu, Apr 23, 2009 at 1:09 PM, Dave Cohen wrote: > In another recent thread (about watchdog), Fr?d?ric suggested increasing the size of the watchdog.referer column. ?And he's right to suggest it because strings that are too long are not written to the database. referer is now a text field in drupal 7, but not yet backported to drupal 6, see http://drupal.org/node/107824 --mark From nan_wich at bellsouth.net Sat Apr 25 18:48:43 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Sat, 25 Apr 2009 14:48:43 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed Message-ID: If I do anything to a menu item, including changing its position (weight) with menu administration, then hook_menu_alter is unable to change its title. This seems to be contrary to the way the hook should work; essentially the hook is all but worthless in this case. Does anyone know why this is this way? Yes, I can update the menu_links table and change it there just fine, but then I?m doing a query to change what a query should be about to do anyway. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2079 - Release Date: 4/24/2009 7:04 PM From karoly at negyesi.net Sat Apr 25 18:50:59 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat, 25 Apr 2009 11:50:59 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: Message-ID: <7e270cea0904251150seb60d69p5f12bbfde1059eaa@mail.gmail.com> When generating navigation links from router items, core honors customized menu links. You customized your link so we do not overwrite it. I feel this is correct behaviour. From jbrown at bluedroplet.com Sat Apr 25 19:54:27 2009 From: jbrown at bluedroplet.com (Jonathan Brown) Date: Sat, 25 Apr 2009 20:54:27 +0100 Subject: [development] varchar(255) In-Reply-To: <200904231309.05808.drupal@dave-cohen.com> References: <200904231309.05808.drupal@dave-cohen.com> Message-ID: <1240689267.3902.0.camel@akalabeth.home> It would make sense to truncate strings to the field size before inserting to ensure that they succeed. Mysql silently changes varchar(65535) to mediumtext I think this is because the max row size is 65535 http://dev.mysql.com/doc/refman/5.0/en/char.html On Thu, 2009-04-23 at 13:09 -0700, Dave Cohen wrote: > In another recent thread (about watchdog), Fr?d?ric suggested increasing the size of the watchdog.referer column. And he's right to suggest it because strings that are too long are not written to the database. > > This brings to 3 the number of columns I increase to varchar(255) on my Drupal sites. The three are watchdog.referer, users.mail, and sessions.sid. > > If my understanding of mysql is correct, there is no difference between a varchar(128) column filled with 128-byte strings and a varchar(255) column filled with 128-byte strings. However, there is a huge difference between a varchar(128) column filled with 129-byte strings and a varchar(255) filled with 129-byte strings. (The latter will work). > > So please, when developing for Drupal and wondering what size to make that varchar... stop wondering and use varchar(255). > > Or if you need it even longer varchar(65535). Note that lengths up to 255 can be represented in one byte, and 65535 in two bytes. > > Oh and please do correct me if I'm wrong about any of this, > > -Dave From nan_wich at bellsouth.net Sat Apr 25 19:58:58 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Sat, 25 Apr 2009 15:58:58 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <7e270cea0904251150seb60d69p5f12bbfde1059eaa@mail.gmail.com> Message-ID: I understand your reasoning. However, there is "customized" and there is "customized." Dragging a menu item to a new position in the menu is not really "customized" in most people's opinion. This behavior forces me to do an UPDATE query on the menu_links table because hook_menu_alter doesn't work; is that really what you want? Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2079 - Release Date: 4/24/2009 7:04 PM From karoly at negyesi.net Sat Apr 25 20:35:52 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat, 25 Apr 2009 13:35:52 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: <7e270cea0904251150seb60d69p5f12bbfde1059eaa@mail.gmail.com> Message-ID: <7e270cea0904251335p73b015fej36de40cb0558081e@mail.gmail.com> No, I want you to use menu_link_save.If there are various customizations then please file a patch. On Sat, Apr 25, 2009 at 12:58 PM, Nancy Wichmann wrote: > I understand your reasoning. However, there is "customized" and there is > "customized." Dragging a menu item to a new position in the menu is not > really "customized" in most people's opinion. > > This behavior forces me to do an UPDATE query on the menu_links table > because hook_menu_alter doesn't work; is that really what you want? > > Nancy E. Wichmann, PMP > Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. > > > > No virus found in this outgoing message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.12.4/2079 - Release Date: 4/24/2009 7:04 PM > >

From nan_wich at bellsouth.net Sat Apr 25 21:37:11 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Sat, 25 Apr 2009 17:37:11 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <7e270cea0904251335p73b015fej36de40cb0558081e@mail.gmail.com> Message-ID: This is wacky! In 5.x to change the title of a content type, all it took was a variable_get and a simple bit of code in hook_menu and hook_node_info. But in 6.x I have to jump through all kinds of hoops changing the menu? I still haven't succeeded in getting it to update the description in the rendered menu. Is there an example somewhere? I see several, but I don't have the "mlid"; if I have to do a query to get that, I might as well go ahead and keep updating the tables directly. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2079 - Release Date: 4/24/2009 7:04 PM From karoly at negyesi.net Sun Apr 26 04:42:30 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat, 25 Apr 2009 21:42:30 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: <7e270cea0904251335p73b015fej36de40cb0558081e@mail.gmail.com> Message-ID: <7e270cea0904252142j5bc162bcm9e93ecb821bb8b50@mail.gmail.com> No. Only if you customized your menu link then you need to. I am sorry, but this is how it is. If you consider this a bug, then please file an issue. The bugfix would be changing f (!$existing_item || !$existing_item['customized']) in menu.inc to something a lot more sophisticated. I am happy to review such a patch while I am not exactly eager to write it. On Sat, Apr 25, 2009 at 2:37 PM, Nancy Wichmann wrote: > This is wacky! In 5.x to change the title of a content type, all it took was > a variable_get and a simple bit of code in hook_menu and hook_node_info. But > in 6.x I have to jump through all kinds of hoops changing the menu? I still > haven't succeeded in getting it to update the description in the rendered > menu. Is there an example somewhere? I see several, but I don't have the > "mlid"; if I have to do a query to get that, I might as well go ahead and > keep updating the tables directly. > > Nancy E. Wichmann, PMP > Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. > > > > No virus found in this outgoing message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.12.4/2079 - Release Date: 4/24/2009 7:04 PM > >

From earnie at users.sourceforge.net Sun Apr 26 13:17:35 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sun, 26 Apr 2009 13:17:35 +0000 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: Message-ID: <20090426131735.95771u7vexj717gk@mail.siebunlimited.com> Quoting Nancy Wichmann : > This is wacky! In 5.x to change the title of a content type, all it took was > a variable_get and a simple bit of code in hook_menu and hook_node_info. But > in 6.x I have to jump through all kinds of hoops changing the menu? I still > haven't succeeded in getting it to update the description in the rendered > menu. Is there an example somewhere? I see several, but I don't have the > "mlid"; if I have to do a query to get that, I might as well go ahead and > keep updating the tables directly. > The menu is cached and is only rebuilt in certain circumstances. This doesn't provide for changing a static menu that is predefined unless you rebuild the cache for all menu items. This is a costly effect. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From nedjo at islandnet.com Sun Apr 26 19:56:56 2009 From: nedjo at islandnet.com (Nedjo Rogers) Date: Sun, 26 Apr 2009 13:56:56 -0600 Subject: [development] Drupal development maintenance teams Message-ID: <49F4BC88.3020307@islandnet.com> Karoly's recent post to this list about stagnation in the core issue queue sparked a lot of good ideas and some great short term action, including this weekend's patch review sprint (yeah participants!). I want to follow up on one of the ideas--that we should consider new structures in our patch management and in particular look at building teams responsible for different areas of development. Of all the great ideas that came up, this is the one that I find the most exciting. In lots of ways it builds on what we're already doing elsewhere. Take code sprints--these are short term development teams, working together on a particular area of development. Or else consider the security team. Formal membership, clear mandate and responsibilities, and a great track record of members stepping up and capably doing the work. What would the equivalent be for core development? Here's the idea in a nutshell. Instead of the current situation, where it's pretty much every patch for itself, we have instead a team of maintainers for each area of core (mapped to the core "component" identified in project issues). For each area, we have one or two leads--an expanded version of the "maintainers" we already have designated for different areas of Drupal core. These leads continue to be appointed by Dries. But instead of being individually responsible for an area, these leads select and lead a team of maintainers. These teams are managed a lot like the current maintainers list. Here's an idea of how it might work. Dries appoints an lead in a given area, e.g., internationalization. That lead invites individuals with proven expertise and a track record to become formal members of the internationalization maintenance team, responsible for all issues in the "multilingual support" and locale module components. Members of this team are listed on a drupal.org page along with members of the other members of the team. The basic responsibility of team members is to review, update, and refine patches in their given areas until they are closed. They can also take a step back as needed and evaluate overall progress and needs in an area, prioritizing patches to review and improve or creating new ones. Patch contributors can contact team members directly to discuss their patches and get help. A key advantage is that this approach wouldn't rely on big process or infrastructural changes. In many ways it's just a small step in the same direction we've been going. But, by enabling developers and contributors to take on formal responsibilities in patch management, it could have the potential to harness and coordinate our currently disparate efforts. Drupal development maintenance teams--an idea whose time has come? If so, what are our first steps to make it happen? Nedjo From nan_wich at bellsouth.net Sun Apr 26 20:00:33 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Sun, 26 Apr 2009 16:00:33 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <20090426131735.95771u7vexj717gk@mail.siebunlimited.com> Message-ID: I am aware of the overhead. I am using menu_rebuild() but it is not working because just re-weighting a menu item marks it as "customized." Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2080 - Release Date: 4/25/2009 8:29 AM From larry at garfieldtech.com Sun Apr 26 20:42:21 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Sun, 26 Apr 2009 15:42:21 -0500 Subject: [development] Drupal development maintenance teams In-Reply-To: <49F4BC88.3020307@islandnet.com> References: <49F4BC88.3020307@islandnet.com> Message-ID: <200904261542.21914.larry@garfieldtech.com> On Sunday 26 April 2009 2:56:56 pm Nedjo Rogers wrote: > Karoly's recent post to this list about stagnation in the core issue > queue sparked a lot of good ideas and some great short term action, > including this weekend's patch review sprint (yeah participants!). > > I want to follow up on one of the ideas--that we should consider new > structures in our patch management and in particular look at building > teams responsible for different areas of development. Of all the great > ideas that came up, this is the one that I find the most exciting. > > In lots of ways it builds on what we're already doing elsewhere. Take > code sprints--these are short term development teams, working together > on a particular area of development. Or else consider the security team. > Formal membership, clear mandate and responsibilities, and a great track > record of members stepping up and capably doing the work. > > What would the equivalent be for core development? > > Here's the idea in a nutshell. Instead of the current situation, where > it's pretty much every patch for itself, we have instead a team of > maintainers for each area of core (mapped to the core "component" > identified in project issues). > > For each area, we have one or two leads--an expanded version of the > "maintainers" we already have designated for different areas of Drupal > core. These leads continue to be appointed by Dries. But instead of > being individually responsible for an area, these leads select and lead > a team of maintainers. These teams are managed a lot like the current > maintainers list. > > Here's an idea of how it might work. Dries appoints an lead in a given > area, e.g., internationalization. That lead invites individuals with > proven expertise and a track record to become formal members of the > internationalization maintenance team, responsible for all issues in the > "multilingual support" and locale module components. Members of this > team are listed on a drupal.org page along with members of the other > members of the team. The basic responsibility of team members is to > review, update, and refine patches in their given areas until they are > closed. They can also take a step back as needed and evaluate overall > progress and needs in an area, prioritizing patches to review and > improve or creating new ones. Patch contributors can contact team > members directly to discuss their patches and get help. > > A key advantage is that this approach wouldn't rely on big process or > infrastructural changes. In many ways it's just a small step in the same > direction we've been going. But, by enabling developers and contributors > to take on formal responsibilities in patch management, it could have > the potential to harness and coordinate our currently disparate efforts. > > Drupal development maintenance teams--an idea whose time has come? If > so, what are our first steps to make it happen? > > Nedjo Nedjo, that's very closely related to my earlier comments. The database subsystem already has this sort of setup, in practice. (The team consists of myself, chx, DamZ, David Strauss, and Josh.) However, it still doesn't address the point I raised before: Aside from bragging rights, what incentive is there for someone to want such a job? Let me give a concrete example: http://drupal.org/node/432440 In that issue, we are discussing possible ways to improve schema API, specifically with regards to table modification statements. There are two perfectly viable options available, each with pros and cons (listed). It is a waste of my time or anyone else's to try to write code for it until we know which one we want to do, so "talk is silver code is gold" does not apply. How do we decide which approach to take? 1) I, as DB maintainer, make an executive decision on which one to do and we do that (presumably based on what feedback we've gotten so far, which is not much). 2) The DB team (listed above) pow-wows somewhere and comes to a, executive decision, and we do that. 3) We sit and twiddle our thumbs and hope that people notice the issue enough to discuss it for 200 comments so that we have enough data points to be able to determine a majority consensus and then implement that, and pray that when Dries or webchick get to the issue they agree with whatever that decision was rather than kill the issue with the fatal "let's discuss this more" comment. 4) I kidnap webchick in IRC and talk for 2 hours, and explain every possible detail to her 3 times so that she groks it, then she makes a recommendation and I go code it and we hope that Dries agrees when he gets there. Right now most issues follow #3. For most of the DB layer I've tried to follow #4 in order to avoid the death by a thousand comments that is #3, but that can be quite time consuming and only works when both the branch maintainer (webchick) and I have 2 hours to spare in IRC. (That's been less and less frequent of late.) I really don't think #3 is going to continue to scale, in fact I think it has already ceased to scale. However, I do not feel comfortable with #1 or #2 because I have no reason to believe that I have any actual authority, either individually or as part of the DB team, to make such decisions and not have to just redo everything later. If that's not the case then I wish someone would tell me. So before we talk about adding more people to MAINTAINERS.txt, we need to have a very clear, explicit understanding of what it means to be in MAINTAINERS.txt. I am listed in there twice, and I have no clear idea what it actually means. This is a problem. :-) -- Larry Garfield larry at garfieldtech.com From naheemzaffar at gmail.com Sun Apr 26 21:31:39 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 26 Apr 2009 22:31:39 +0100 Subject: [development] Drupal development maintenance teams In-Reply-To: <200904261542.21914.larry@garfieldtech.com> References: <49F4BC88.3020307@islandnet.com> <200904261542.21914.larry@garfieldtech.com> Message-ID: <3adc77210904261431u53aff630wf0c59b57171f453e@mail.gmail.com> > 3) We sit and twiddle our thumbs and hope that people notice the issue > enough > to discuss it for 200 comments so that we have enough data points to be > able > to determine a majority consensus and then implement that, and pray that > when > Dries or webchick get to the issue they agree with whatever that decision > was > rather than kill the issue with the fatal "let's discuss this more" > comment. > ... Could this problem be solved by some sort of semi regular developer companion/list/news/other subscribable thing/section on the website? A place that lists any issues, big developments related to core developments? This should be able to be done by people who are not coders too, so there may be a pool of followers out there who can help? It could help focus attention on issues that are not code related (or maybe even code related issues). -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg at GrowingVentureSolutions.com Mon Apr 27 01:03:16 2009 From: Greg at GrowingVentureSolutions.com (Greg Knaddison) Date: Sun, 26 Apr 2009 19:03:16 -0600 Subject: [development] Drupal development maintenance teams In-Reply-To: <49F4BC88.3020307@islandnet.com> References: <49F4BC88.3020307@islandnet.com> Message-ID: <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> On Sun, Apr 26, 2009 at 1:56 PM, Nedjo Rogers wrote: > For each area, we have one or two leads--an expanded version of the > "maintainers" we already have designated for different areas of Drupal > core. These leads continue to be appointed by Dries. But instead of > being individually responsible for an area, these leads select and lead > a team of maintainers. These teams are managed a lot like the current > maintainers list. > > Here's an idea of how it might work. Dries appoints an lead in a given > area, e.g., internationalization. That lead invites individuals with > proven expertise and a track record to become formal members of the > internationalization maintenance team, responsible for all issues in the > "multilingual support" and locale module components. Members of this > team are listed on a drupal.org page along with members of the other > members of the team. The basic responsibility of team members is to > review, update, and refine patches in their given areas until they are > closed. They can also take a step back as needed and evaluate overall > progress and needs in an area, prioritizing patches to review and > improve or creating new ones. Patch contributors can contact team > members directly to discuss their patches and get help. FWIW, I really like the current (somewhat chaotic) system without maintainers and teams. Teams in other projects strike me as something that creates a barrier to entry rather than increasing involvement. I like how anyone can show up and, with a few days of commenting/patching intelligently join a "team." The docs team is morphing and has moved to a more distributed model that allows anyone to maintain most of the pages in the handbook. I've heard several people say "well, I'm not on Drupal's core team so I can't be involved in developing patches." Of course I correct them that we have no such team and they are empowered to contribute just like everyone, but the "team/outsider" feeling persists based on false perceptions of the project. I wonder if there's something that can be done to provide greater recognition/control for individuals in certain areas without erecting this kind of false barrier. Another alternative would be to try out the team idea in one area - like i18n - and then re-evaluate for core in general based on the success of that pilot. Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com From rob at robshouse.net Mon Apr 27 01:22:18 2009 From: rob at robshouse.net (Robert Douglass) Date: Mon, 27 Apr 2009 03:22:18 +0200 Subject: [development] Drupal development maintenance teams In-Reply-To: <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> References: <49F4BC88.3020307@islandnet.com> <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> Message-ID: <2EF72CE8-E70F-40C2-BEFA-54B504C9E4D1@robshouse.net> Greg, I totally understand your sentiment about "teams". However, if there are "leaders" in these areas, and the teams can be ad-hoc, how does that feel? The important thing, to me, is empowering more of the exceptional people in the community become stronger leaders (by vesting power and responsibility in them). Robert Douglass The RobsHouse.net Newsletter: http://robshouse.net/newsletter/robshousenet-newsletter Follow me on Twitter: http://twitter.com/robertDouglass On Apr 27, 2009, at 3:03 AM, Greg Knaddison wrote: > On Sun, Apr 26, 2009 at 1:56 PM, Nedjo Rogers > wrote: >> For each area, we have one or two leads--an expanded version of the >> "maintainers" we already have designated for different areas of >> Drupal >> core. These leads continue to be appointed by Dries. But instead of >> being individually responsible for an area, these leads select and >> lead >> a team of maintainers. These teams are managed a lot like the current >> maintainers list. >> >> Here's an idea of how it might work. Dries appoints an lead in a >> given >> area, e.g., internationalization. That lead invites individuals with >> proven expertise and a track record to become formal members of the >> internationalization maintenance team, responsible for all issues >> in the >> "multilingual support" and locale module components. Members of this >> team are listed on a drupal.org page along with members of the other >> members of the team. The basic responsibility of team members is to >> review, update, and refine patches in their given areas until they >> are >> closed. They can also take a step back as needed and evaluate overall >> progress and needs in an area, prioritizing patches to review and >> improve or creating new ones. Patch contributors can contact team >> members directly to discuss their patches and get help. > > FWIW, I really like the current (somewhat chaotic) system without > maintainers and teams. Teams in other projects strike me as something > that creates a barrier to entry rather than increasing involvement. I > like how anyone can show up and, with a few days of > commenting/patching intelligently join a "team." > > The docs team is morphing and has moved to a more distributed model > that allows anyone to maintain most of the pages in the handbook. > > I've heard several people say "well, I'm not on Drupal's core team so > I can't be involved in developing patches." Of course I correct them > that we have no such team and they are empowered to contribute just > like everyone, but the "team/outsider" feeling persists based on false > perceptions of the project. > > I wonder if there's something that can be done to provide greater > recognition/control for individuals in certain areas without erecting > this kind of false barrier. Another alternative would be to try out > the team idea in one area - like i18n - and then re-evaluate for core > in general based on the success of that pilot. > > Greg > > -- > Greg Knaddison > http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com From Greg at GrowingVentureSolutions.com Mon Apr 27 01:27:36 2009 From: Greg at GrowingVentureSolutions.com (Greg Knaddison) Date: Sun, 26 Apr 2009 19:27:36 -0600 Subject: [development] Drupal development maintenance teams In-Reply-To: <2EF72CE8-E70F-40C2-BEFA-54B504C9E4D1@robshouse.net> References: <49F4BC88.3020307@islandnet.com> <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> <2EF72CE8-E70F-40C2-BEFA-54B504C9E4D1@robshouse.net> Message-ID: <3861c6770904261827mc87ae84kcf18d763e9f2fc06@mail.gmail.com> On Sun, Apr 26, 2009 at 7:22 PM, Robert Douglass wrote: > Greg, I totally understand your sentiment about "teams". However, if there > are "leaders" in these areas, and the teams can be ad-hoc, how does that > feel? The important thing, to me, is empowering more of the exceptional > people in the community become stronger leaders (by vesting power and > responsibility in them). That feels great. (But how is that different from the MAINTAINERS.txt we currently have?) Thanks, Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com From darrel.opry at gmail.com Mon Apr 27 01:58:00 2009 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Sun, 26 Apr 2009 21:58:00 -0400 Subject: [development] Very concerned over Drupal's core development In-Reply-To: <49ECBBA2.60300@logrus.com> References: <7e270cea0904191338m6086e39coe8eda9786157f87e@mail.gmail.com> <61bca48a0904201033g3d514a6fm685574f5e8b358b7@mail.gmail.com> <49ECBBA2.60300@logrus.com> Message-ID: On Mon, Apr 20, 2009 at 2:14 PM, Earl Miles wrote: > Dries Buytaert wrote: > >> weigh in and participate in the review process. It is also important >> that you convince other people as why your patch should bubble up -- >> this is something a lot of people can get better at. >> > > This statement right here is what's wrong with Drupal core development. At > this time, you must be better at debate, arguing and general Drupal politics > than you are at actual code design and implementation. > > At one point 'talk is silver, code is gold' was the motto. But this has > changed. Now talk is gold and code is defined by those who talk the best. > The barrier for me isn't the complexity by any means. It's more the politics and sheer stubborness required to implement change. I'm not a politician. I'm a programmer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at garfieldtech.com Mon Apr 27 04:18:35 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Sun, 26 Apr 2009 23:18:35 -0500 Subject: [development] Drupal development maintenance teams In-Reply-To: <3861c6770904261827mc87ae84kcf18d763e9f2fc06@mail.gmail.com> References: <49F4BC88.3020307@islandnet.com> <2EF72CE8-E70F-40C2-BEFA-54B504C9E4D1@robshouse.net> <3861c6770904261827mc87ae84kcf18d763e9f2fc06@mail.gmail.com> Message-ID: <200904262318.35466.larry@garfieldtech.com> On Sunday 26 April 2009 8:27:36 pm Greg Knaddison wrote: > On Sun, Apr 26, 2009 at 7:22 PM, Robert Douglass wrote: > > Greg, I totally understand your sentiment about "teams". However, if > > there are "leaders" in these areas, and the teams can be ad-hoc, how does > > that feel? The important thing, to me, is empowering more of the > > exceptional people in the community become stronger leaders (by vesting > > power and responsibility in them). > > That feels great. (But how is that different from the MAINTAINERS.txt > we currently have?) > > Thanks, > Greg See my replies in this thread and the previous one. Explain to me what MAINTAINERS.txt actually *means* in practice and then we can say how some other proposal would be different. -- Larry Garfield larry at garfieldtech.com From earnie at users.sourceforge.net Mon Apr 27 11:49:15 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 27 Apr 2009 11:49:15 +0000 Subject: [development] Drupal development maintenance teams In-Reply-To: <200904262318.35466.larry@garfieldtech.com> References: <49F4BC88.3020307@islandnet.com> <2EF72CE8-E70F-40C2-BEFA-54B504C9E4D1@robshouse.net> <3861c6770904261827mc87ae84kcf18d763e9f2fc06@mail.gmail.com> <200904262318.35466.larry@garfieldtech.com> Message-ID: <20090427114915.32411koligfn2f28@mail.siebunlimited.com> Quoting Larry Garfield : > On Sunday 26 April 2009 8:27:36 pm Greg Knaddison wrote: >> On Sun, Apr 26, 2009 at 7:22 PM, Robert Douglass wrote: >> > Greg, I totally understand your sentiment about "teams". However, if >> > there are "leaders" in these areas, and the teams can be ad-hoc, how does >> > that feel? The important thing, to me, is empowering more of the >> > exceptional people in the community become stronger leaders (by vesting >> > power and responsibility in them). >> >> That feels great. (But how is that different from the MAINTAINERS.txt >> we currently have?) >> >> Thanks, >> Greg > > See my replies in this thread and the previous one. Explain to me what > MAINTAINERS.txt actually *means* in practice and then we can say how some > other proposal would be different. > Is it a GNU requirement? Or perhaps it is an autoconf one. Or perhaps became popular because of Linux distributions have one. I find no requirement in the GNU standard. So as I see it MAINTAINERS.txt could be instructions for future maintainers of the project. Something that gives direction to future contributors. Or it could be a list of assigned people who have responsibilities in some area of Drupal project management. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From catch56 at googlemail.com Mon Apr 27 13:11:24 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 27 Apr 2009 14:11:24 +0100 Subject: [development] Drupal development maintenance teams In-Reply-To: <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> References: <49F4BC88.3020307@islandnet.com> <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> Message-ID: On Mon, Apr 27, 2009 at 2:03 AM, Greg Knaddison wrote: > FWIW, I really like the current (somewhat chaotic) system without > maintainers and teams. ?Teams in other projects strike me as something > that creates a barrier to entry rather than increasing involvement. I > like how anyone can show up and, with a few days of > commenting/patching intelligently join a "team." I agree with this - when I see other projects which seem to have defined teams for different areas, it puts me off them. If I'm interested in a couple of different areas do I have to join two teams, and possibly issue queues, mailing lists, groups?. That's how Joomla looks to me from the outside from what little I've seen. As soon as you have a team, you have something which requires hurdles in order to join - whether real or psychological. However, MAINTAINERS.txt is about the only place you can go to find out who's responsible for what. In reality you'd generally have to ask on irc or spend several hours trawling through the issue queue to see who's active in the different components - since according to our documentation most of them don't have a specific maintainer at all. That's also a big hurdle. Here's how I see the main issues at the moment: # It's hard or impossible to know who to speak to or where to start if you want to work on core - unless you come onto irc and ask at the right time. # Trying to document what's happening (patch spotlight, Drupal core initiatives) takes work to maintain, and presumably still requires a lot of research for someone new (compared to logging onto #drupal). # Even people who are listed as responsible already don't really know what it means. What I'd like to see, and this is somewhat repeating my comments on the reviews discussion is more stats. At the moment, Greg can scrape the commit logs and see who had the most patches committed - that's pretty much the only core stats we have. What'd be ideal is being able to see: Who's submitting patches. Who's patches are getting committed. Who's reviewing patches. All of these for across core and by component. Once we have that in a database somewhere, then we could also do things like compare within and across releases etc. That'd then give as an idea of who the 'contact module team' is and generally where people's efforts are focused. Most of the people listed in MAINTAINERS.txt are spread out between a lot of different places - this is a result both of core being very interdependent and the way core development works overall. While it's good that the database system has a few specific maintainers, it's also one of our most low-level and self-contained systems (partly a result of it being one of the newest), and it having be rewritten by one or two people from scratch. If you want to work on the areas which are neglected - say forum module, then you're immediately going to get into a tangle of dependent issues with comment, taxonomy, node, tracker, views in core. We list people multiple times in MAINTAINERS.txt - but I don't think this scales well, whether trying to add individual maintainers for those modules or build teams around them. The first step would be a more accurate picture of who's actually doing what where - if that ends up getting codified in MAINTAINERS.txt then fine. Nat From nedjo at islandnet.com Mon Apr 27 15:10:52 2009 From: nedjo at islandnet.com (Nedjo Rogers) Date: Mon, 27 Apr 2009 09:10:52 -0600 Subject: [development] Drupal development maintenance teams In-Reply-To: References: <49F4BC88.3020307@islandnet.com> <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> Message-ID: <49F5CAFC.5040307@islandnet.com> Nathaniel Catchpole wrote: > I agree with this - when I see other projects which seem to have > defined teams for different areas, it puts me off them. If I'm > interested in a couple of different areas do I have to join two teams, > and possibly issue queues, mailing lists, groups?. That's how Joomla > looks to me from the outside from what little I've seen. As soon as > you have a team, you have something which requires hurdles in order to > join - whether real or psychological. > I agree that there are potential problems with formalized teams. I also agree that improved infrastructure for seeing who's most active where would be great. Here's the specific issue as I see it. Currently, we have over 1,700 patches in the D7 queue . For most, the "patch bingo" system is probably a good metaphor for their life cycle--it's largely a question of chance whether their number will come up. If most patches sit there indefinitely, nothing's gone wrong--it's just the way the system works. A few contributions "float to the top", most are never resolved. What I think we need is roles that contributors can grow into that take responsibility for areas of the issue queue. As I'm seeing it, the focus of teams would be managing the issue queue--not guiding development. It would basically be people taking responsibility to review, update, and refine patches in a given area. It would be a role somewhat analogous to documentation admins on drupal.org. Every community member can contribute documentation (can submit patches and participate in the issue queue). A few have taken on the added responsibility of editing and administering. To contribute to development in an area, you'd in no way need to join a team. The relatively small group of contributors who have no problem finding their place and have a handle on most of core dev could continue to do the amazing work they currently do. But the rest of us, who don't spend most of our waking lives in #drupal (or if we do are in observer mode), who don't know everyone and don't have our finger on the pulse of core development, who would like to contribute but find the endless issue queue daunting, who review issues here and there but never feel much of a sense of progress, this rest of us, I believe, could use some limited, simple, welcoming way to plug in. I can't hope to keep up with all of core. But if I and six others took responsibility for managing the core Javascript component issue queue, I could indeed have a good hope of seeing that area's issues well managed. I'd also be willing to be on call for contributors wanting help or reviews of their patches in that area. This approach wouldn't fix all of our challenges. Probably it wouldn't help much in resolving large, complex patches that involve many parts of core. But would this - or some improved proposal - help bring the issue queue into some reasonable shape? Would it reduce the life cycle of the typical patch from "anyone's guess, come back in six months or a year" to "usually dealt with within six weeks"? Would it encourage more community members to step forward and take on specific responsibility for manageable tasks in facilitating core development? I don't know. But I'd like to find out. Nedjo From cxjohnson at gmail.com Mon Apr 27 16:25:36 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 27 Apr 2009 11:25:36 -0500 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: <20090426131735.95771u7vexj717gk@mail.siebunlimited.com> Message-ID: <9ea8d6030904270925v166269cdj18cc24dfca7ef9ff@mail.gmail.com> I have to agree with Nancy. Re-weighting a menu item does not qualify as customized, IMO. Otherwise, I agree it works as designed. ..chris On Sun, Apr 26, 2009 at 3:00 PM, Nancy Wichmann wrote: > I am aware of the overhead. I am using menu_rebuild() but it is not working because just re-weighting a menu item marks it as "customized." From merlin at logrus.com Mon Apr 27 16:36:13 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 27 Apr 2009 09:36:13 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <9ea8d6030904270925v166269cdj18cc24dfca7ef9ff@mail.gmail.com> References: <20090426131735.95771u7vexj717gk@mail.siebunlimited.com> <9ea8d6030904270925v166269cdj18cc24dfca7ef9ff@mail.gmail.com> Message-ID: <49F5DEFD.4040001@logrus.com> Chris Johnson wrote: > I have to agree with Nancy. Re-weighting a menu item does not qualify > as customized, IMO. Otherwise, I agree it works as designed. The thing is, the system can only tell that there's an entry in the table, not what part of the item has been modified. I ran into this in some completely unrelated piece of code, where I ended up storing weights separately so that moving an item up or down didn't constitute modifying it, and it is a lot of extra code just to do that. From earnie at users.sourceforge.net Mon Apr 27 16:54:21 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 27 Apr 2009 16:54:21 +0000 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <49F5DEFD.4040001@logrus.com> References: <20090426131735.95771u7vexj717gk@mail.siebunlimited.com> <9ea8d6030904270925v166269cdj18cc24dfca7ef9ff@mail.gmail.com> <49F5DEFD.4040001@logrus.com> Message-ID: <20090427165421.16143a6zfed1w18g@mail.siebunlimited.com> Quoting Earl Miles : > Chris Johnson wrote: >> I have to agree with Nancy. Re-weighting a menu item does not qualify >> as customized, IMO. Otherwise, I agree it works as designed. > > The thing is, the system can only tell that there's an entry in the > table, not what part of the item has been modified. I ran into this > in some completely unrelated piece of code, where I ended up storing > weights separately so that moving an item up or down didn't > constitute modifying it, and it is a lot of extra code just to do > that. > So the menu item becomes partially disconnected from the module. This isn't a good thing. Thanks, Earl, I think you explained something I noticed with a custom module I'm creating. Drove me nuts until I directly deleted a menu item that shouldn't exist after the module was uninstalled. I couldn't delete it via the menu UI at all. The menu item caused unpredictable actions when the module was reactivated or the menu cache was rebuilt and I was going bonkers trying to fix a problem caused by something as simple as changing the item's weight via the UI. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From prometheus6 at gmail.com Mon Apr 27 18:10:10 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Mon, 27 Apr 2009 14:10:10 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <49F5DEFD.4040001@logrus.com> References: <20090426131735.95771u7vexj717gk@mail.siebunlimited.com> <9ea8d6030904270925v166269cdj18cc24dfca7ef9ff@mail.gmail.com> <49F5DEFD.4040001@logrus.com> Message-ID: Curiosity (and recognizing I'm about to run into the same problem Nancy had) made me look. Each of the menu item editing forms has an ['#item'] element that gets the original menu item. So instead of a more sophisticated test in _menu_navigation_links_rebuild(), maybe a more sophisticated test assigning a value to $item['customized'] just prior to calling menu_link_save() (though there's 17 occurrences of menu_link_save() in core...)? On Mon, Apr 27, 2009 at 12:36 PM, Earl Miles wrote: > Chris Johnson wrote: > >> I have to agree with Nancy. Re-weighting a menu item does not qualify >> as customized, IMO. Otherwise, I agree it works as designed. >> > > The thing is, the system can only tell that there's an entry in the table, > not what part of the item has been modified. I ran into this in some > completely unrelated piece of code, where I ended up storing weights > separately so that moving an item up or down didn't constitute modifying it, > and it is a lot of extra code just to do that. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drupal-devel at webchick.net Mon Apr 27 18:45:55 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Mon, 27 Apr 2009 14:45:55 -0400 Subject: [development] Drupal development maintenance teams In-Reply-To: References: <49F4BC88.3020307@islandnet.com> <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> Message-ID: <37679B4F-C664-41D3-B498-6CB7DB7EF2CF@webchick.net> On 27-Apr-09, at 9:11 AM, Nathaniel Catchpole wrote: > On Mon, Apr 27, 2009 at 2:03 AM, Greg Knaddison wrote: > >> FWIW, I really like the current (somewhat chaotic) system without >> maintainers and teams. Teams in other projects strike me as >> something >> that creates a barrier to entry rather than increasing involvement. I >> like how anyone can show up and, with a few days of >> commenting/patching intelligently join a "team." > > I agree with this - when I see other projects which seem to have > defined teams for different areas, it puts me off them. If I'm > interested in a couple of different areas do I have to join two teams, > and possibly issue queues, mailing lists, groups?. That's how Joomla > looks to me from the outside from what little I've seen. As soon as > you have a team, you have something which requires hurdles in order to > join - whether real or psychological. 200% agreed with this. The fact that it is effectively the community of active participants who draws the roadmap for each release of core by their actions (and that anyone at all can pick up a crayon and start drawing their own little part as well) is key to Drupal's strength as a community, which ties directly to its strength as a platform, imo. We need to keep that barrier to contributing as low as possible, and eliminate it entirely where we can. > However, MAINTAINERS.txt is about the only place you can go to find > out who's responsible for what. In reality you'd generally have to ask > on irc or spend several hours trawling through the issue queue to see > who's active in the different components - since according to our > documentation most of them don't have a specific maintainer at all. > That's also a big hurdle. > > Here's how I see the main issues at the moment: > > # It's hard or impossible to know who to speak to or where to start if > you want to work on core - unless you come onto irc and ask at the > right time. > > # Trying to document what's happening (patch spotlight, Drupal core > initiatives) takes work to maintain, and presumably still requires a > lot of research for someone new (compared to logging onto #drupal). > > # Even people who are listed as responsible already don't really know > what it means. Here's a thought. (Note: I snipped the part about better statistics in catch's reply because although I would *love* to have those, that's an implementation project that's going to take awhile and I'm always more interested in things we can do *right now*.) After about 50 iterations trying to figure out a way to have some sort of a bottom-up "Patch Spotlight"-esque thingy that allowed the community of participants to escalate what they think is important in each of their respective areas of interest, we came up with the Drupal core community initiatives section of the handbook at http://drupal.org/community-initiatives/drupal-core . It's awesome, because it allows me as a core committer to a) see what is on the minds of the people who tend to usability, i18n, JS, etc. so I can prioritize my time accordingly, and b) help guide new contributors who ask "I want to help out with X. Where do I start?" to issues that people in that "space" have identified as those that will have the largest impact. (Of course, the section has its drawbacks as well. I's not promoted nearly enough, maintainers of these pages don't always keep them up to date, there's not a lot of structure (sort of by design, since I want each page to work best for the group of people managing it), and there are no subscription tools to get e-mail notifications and such. But it does have the advantage of actually *existing*! ;)) So what if we simply added a "This initiative is being led by X, Y, Z" line at the top of each page? Then we identify who to go to if you want to start working on i18n stuff, we do not have the concept of formal "teams" to join, anyone could at any time add their own name to the list f people managing X initiative, and we retain the ability for anyone to start their own campaign around improving Blog API module, for example. And FWIW, what being in MAINTAINERS.txt means to me as a committer is that I don't commit patches that impact your area of expertise without talking to you first. If you ping me wanting to bounce around ideas for an hour about your area, barring some sort of client/family emergency, I make the time to talk with you. If someone comes to me and wants to get involved in your area, you're the person I direct them to. If you ping me and say "X has to go in," I move it to the top of my review list (as long as I have mental energy remaining, which has been painfully short as of late.. sorry yched/Barry :\). And so on. I'm definitely NOT perfect, and sometimes I get distracted by other things or for am traveling which means I am not being as conscientious about keeping on top of core as I would normally be, but in general that's how I try and treat it: as giving those in MAINTAINERS.txt a "bat phone" to a core committer (and vice-versa) so that those important areas don't get stalled. -Angie From nan_wich at bellsouth.net Mon Apr 27 20:07:21 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 27 Apr 2009 16:07:21 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: Message-ID: I am not the menu expert here, so I am sure that there is something wrong with my little change: function menu_overview_form_submit($form, &$form_state) { // When dealing with saving menu items, the order in which these items are // saved is critical. If a changed child item is saved before its parent, // the child item could be saved with an invalid path past its immediate // parent. To prevent this, save items in the form in the same order they // are sent by $_POST, ensuring parents are saved first, then their children. // See http://drupal.org/node/181126#comment-632270 $order = array_flip(array_keys($form['#post'])); // Get the $_POST order. $form = array_merge($order, $form); // Update our original form with the new order. $updated_items = array(); $fields = array('expanded', 'weight', 'plid'); foreach (element_children($form) as $mlid) { if (isset($form[$mlid]['#item'])) { $element = $form[$mlid]; // Update any fields that have changed in this menu item. foreach ($fields as $field) { if ($element[$field]['#value'] != $element[$field]['#default_value']) { $element['#item'][$field] = $element[$field]['#value']; $updated_items[$mlid] = $element['#item']; $updated_items[$mlid]['customized'] = $field == 'plid'; // <-- only ?plid? is really customized. } } // Hidden is a special case, the value needs to be reversed. if ($element['hidden']['#value'] != $element['hidden']['#default_value']) { $element['#item']['hidden'] = !$element['hidden']['#value']; $updated_items[$mlid] = $element['#item']; } } } // Save all our changed items to the database. foreach ($updated_items as $item) { // $item['customized'] = 1; menu_link_save($item); } } Frankly, I don?t think ?expanded? is really customized either. I tested this on my dev site and got the results I want. So now Karoly or Earl will tell this ditzy blonde why this is not the solution. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2082 - Release Date: 4/27/2009 6:19 AM From nan_wich at bellsouth.net Mon Apr 27 20:09:56 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 27 Apr 2009 16:09:56 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: Message-ID: BTW, during my testing, I dragged the top menu item to after the next one. This marked BOTH items as customized, even though I only changed one. Is that also the intended behavior? Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2082 - Release Date: 4/27/2009 6:19 AM From merlin at logrus.com Mon Apr 27 20:16:38 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 27 Apr 2009 13:16:38 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: Message-ID: <49F612A6.6000905@logrus.com> Nancy Wichmann wrote: > BTW, during my testing, I dragged the top menu item to after the next > one. This marked BOTH items as customized, even though I only changed > one. Is that also the intended behavior? Yes, tabledrag re-orders everything between an item's new position and old position. Here's an example of why: Original weights: Item A: 1 Item B: 2 Item C: 3 Item D: 4 Item E: 5 Move item D to the 2nd position. New weights: Item A: 1 Item D: 2 [changed] Item B: 3 [changed] Item C: 4 [changed] Item E: 5 From merlin at logrus.com Mon Apr 27 20:17:47 2009 From: merlin at logrus.com (Earl Miles) Date: Mon, 27 Apr 2009 13:17:47 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: Message-ID: <49F612EB.2030504@logrus.com> Nancy Wichmann wrote: > I tested this on my dev site and got the results I want. So now Karoly > or Earl will tell this ditzy blonde why this is not the solution. I don't know enough about the whole menu system to say whether or not this is the solution. It might be, though, or it might be on the track to a solution. From karoly at negyesi.net Mon Apr 27 20:20:13 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 27 Apr 2009 13:20:13 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: Message-ID: <7e270cea0904271320u630c28e5h2748e836add7b709@mail.gmail.com> I would like to gently remind you that the place to get feedback on core changes is in the issue queue, where everyone can participate. From prometheus6 at gmail.com Mon Apr 27 20:42:12 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Mon, 27 Apr 2009 16:42:12 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <7e270cea0904271320u630c28e5h2748e836add7b709@mail.gmail.com> References: <7e270cea0904271320u630c28e5h2748e836add7b709@mail.gmail.com> Message-ID: Thing is, it's not a bug, whether folks want it to work that way or not. It is literally *by design*. So it would have to go under Drupal 7, no? On Mon, Apr 27, 2009 at 4:20 PM, Karoly Negyesi wrote: > I would like to gently remind you that the place to get feedback on > core changes is in the issue queue, where everyone can participate. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nan_wich at bellsouth.net Mon Apr 27 20:56:22 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 27 Apr 2009 16:56:22 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <7e270cea0904271320u630c28e5h2748e836add7b709@mail.gmail.com> Message-ID: I wanted to get laughed at here first... Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2082 - Release Date: 4/27/2009 6:19 AM From karoly at negyesi.net Mon Apr 27 21:18:22 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 27 Apr 2009 14:18:22 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: <7e270cea0904271320u630c28e5h2748e836add7b709@mail.gmail.com> Message-ID: <7e270cea0904271418o258ea1b2lccb851c7cc68964e@mail.gmail.com> You are not being laughed at but this belongs to the issue queue,. It can be a bug.... From nan_wich at bellsouth.net Mon Apr 27 22:02:27 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 27 Apr 2009 18:02:27 -0400 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: <7e270cea0904271418o258ea1b2lccb851c7cc68964e@mail.gmail.com> Message-ID: http://drupal.org/node/446656 Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2082 - Release Date: 4/27/2009 6:19 AM From karoly at negyesi.net Mon Apr 27 22:24:34 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 27 Apr 2009 15:24:34 -0700 Subject: [development] Hook_menu_alter doesn't work if menu item changed In-Reply-To: References: <7e270cea0904271418o258ea1b2lccb851c7cc68964e@mail.gmail.com> Message-ID: <7e270cea0904271524l65e2754cufd6d5697d73e9f7d@mail.gmail.com> Reviewed as promised. From nedjo at islandnet.com Tue Apr 28 02:59:53 2009 From: nedjo at islandnet.com (Nedjo Rogers) Date: Mon, 27 Apr 2009 20:59:53 -0600 Subject: [development] Drupal development maintenance teams In-Reply-To: <37679B4F-C664-41D3-B498-6CB7DB7EF2CF@webchick.net> References: <49F4BC88.3020307@islandnet.com> <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> <37679B4F-C664-41D3-B498-6CB7DB7EF2CF@webchick.net> Message-ID: <49F67129.7070301@islandnet.com> Angela Byron wrote: > > 200% agreed with this. The fact that it is effectively the community > of active participants who draws the roadmap for each release of core > by their actions (and that anyone at all can pick up a crayon and > start drawing their own little part as well) is key to Drupal's > strength as a community, which ties directly to its strength as a > platform, imo. We need to keep that barrier to contributing as low as > possible, and eliminate it entirely where we can. Thanks for your comments Angie. I agree that we don't want formal teams tasked with making roadmaps for given areas of core. So let me rephrase the idea. It's *not* that a maintenance team for e.g. Javascript would draw a roadmap. Rather, that they would take responsibility for maintaining the issue queue--reviewing, improving, and refreshing patches and being available to help issue submitters. Does a list of people taking responsibility for working on an area of the core issue queue still seem like something that could be a barrier? > So what if we simply added a "This initiative is being led by X, Y, Z" > line at the top of each page? Great idea, and basically an initial step towards Drupal development maintenance teams. Nedjo From karoly at negyesi.net Tue Apr 28 03:18:05 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 27 Apr 2009 20:18:05 -0700 Subject: [development] Drupal development maintenance teams In-Reply-To: <49F67129.7070301@islandnet.com> References: <49F4BC88.3020307@islandnet.com> <3861c6770904261803j5ecc3f98s1d4e4076c1453e84@mail.gmail.com> <37679B4F-C664-41D3-B498-6CB7DB7EF2CF@webchick.net> <49F67129.7070301@islandnet.com> Message-ID: <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> > draw a roadmap. Rather, that they would take responsibility for > maintaining the issue queue--reviewing, improving, and refreshing > patches and being available to help issue submitters. Does a list of Wow, see Crell's mail, why? I see the world "responsibility" and frown. From enboig at gmail.com Tue Apr 28 14:21:30 2009 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Tue, 28 Apr 2009 16:21:30 +0200 Subject: [development] modify permissions using hook_menu_alter() Message-ID: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> I am developing a module which will allow users to post certain content-types after 30 days of being registered. I think this is achieved using hook_menu_alter(); but my code freezes drupal with a white screen. Whats is missing in my code? function wu_menu_alter(&$menu) { foreach (node_get_types('types', NULL, TRUE) as $type) { $type_url_str = str_replace('_', '-', $type->type); $menu['node/add/'.$type_url_str]['access callback'] = 'wu_role_access'; $menu['node/add/'.$type_url_str]['access arguments'] = array('create', $type->type); } } function wu_role_access($a='',$b='',$c='',$d='',$e='') { // echo "**************"; //if uncommented this is displayed return true; //when it works I will implement the rest of the function } -- *La vida ?s com una taronja, que esperes a exprimir-la? *Si creus que l'educaci? ?s cara, prova la ignor?ncia. *La vida ?s com una moneda, la pots gastar en el que vulguis per? nom?s una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From drupal at samboyer.org Tue Apr 28 14:24:46 2009 From: drupal at samboyer.org (Sam Boyer) Date: Tue, 28 Apr 2009 09:24:46 -0500 Subject: [development] Drupal development maintenance teams In-Reply-To: <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> Message-ID: <200904280924.51334.drupal@samboyer.org> On Monday 27 April 2009 22:18:05 Karoly Negyesi wrote: > > draw a roadmap. Rather, that they would take responsibility for > > maintaining the issue queue--reviewing, improving, and refreshing > > patches and being available to help issue submitters. Does a list of > > Wow, see Crell's mail, why? I see the world "responsibility" and frown. Same here, chx. While I agree with Angie that low barriers for new contributors are a huge part of what makes us great & who we are, I think Larry's email highlights how we've failed to focus on lowering the barriers for existing contributors, especially the dedicated ones. We tend to come at these problems from the perspective of "how do we make this work for new contributors?", come up with something, then (usually tacitly) ask existing/dedicated contributors to adapt to that solution. I think this is one of those once-in-a-while cases where we need to be ok with reversing that order - think about things from the existing contributors' standpoint, then fit new contributors into that solution. MAINTAINERS.txt is the perfect example. As Larry points out, he's in there twice, but doesn't have a clear idea about what it _means_ to be in there, in practical terms for his day-to-day work as a drupal dev. I'd argue that's because it doesn't have a clear, formal meaning for existing contributors. The only clear meaning is for new folks: it's the list of people to talk to if they have questions/issues/ideas related to a particular subsystem. But most of what we've been talking about for the past week re: subsystem maintenance, core patch workflow, etc., aren't problems that are gonna be solved simply by increasing the eyeballs:code ratio. It's about organizing those new eyeballs - a job that's inevitably done by existing, dedicated contributors. So let's focus on their/our needs first, _then_ figure out how to make those solutions work for new contributors. It's worth noting that this falls into the category of "problems that only healthy communities have." Only communities that with a systemic commitment to open participation, inclusivity, and taking care of new members can have problems like this. But it's also pretty typical for such communities to prize new members at the expense of existing ones, and I think we need to be more cognizant of that. We need to remain open to the energy and excitement of new people, but we also REALLY need to not kneecap the energy and excitement of the contributors we already have. Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From predofaria at gmail.com Tue Apr 28 14:56:17 2009 From: predofaria at gmail.com (Pedro Faria) Date: Tue, 28 Apr 2009 11:56:17 -0300 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> Message-ID: <1240930577.9415.4.camel@pedro> Check at apache errors log. On Tue, 2009-04-28 at 16:21 +0200, Llu?s wrote: > I am developing a module which will allow users to post certain > content-types after 30 days of being registered. > I think this is achieved using hook_menu_alter(); but my code freezes > drupal with a white screen. > > Whats is missing in my code? > > function wu_menu_alter(&$menu) { > foreach (node_get_types('types', NULL, TRUE) as $type) { > $type_url_str = str_replace('_', '-', $type->type); > $menu['node/add/'.$type_url_str]['access callback'] = 'wu_role_access'; > $menu['node/add/'.$type_url_str]['access arguments'] = > array('create', $type->type); > } > } > > function wu_role_access($a='',$b='',$c='',$d='',$e='') { > // echo "**************"; //if uncommented this is displayed > return true; //when it works I will implement the rest of the function > } > > From enboig at gmail.com Tue Apr 28 15:07:01 2009 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Tue, 28 Apr 2009 17:07:01 +0200 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <1240930577.9415.4.camel@pedro> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <1240930577.9415.4.camel@pedro> Message-ID: <45a29f450904280807k3a4c1f65x4fb5f2601f06a0ff@mail.gmail.com> the only error in apache is: [Tue Apr 28 17:04:49 2009] [error] [client 192.168.1.8] File does not exist: /var/www/favicon.ico I solved it adding: $menu['node/add']['access callback'] = TRUE; But I think it has to be a better way On Tue, Apr 28, 2009 at 4:56 PM, Pedro Faria wrote: > Check at apache errors log. > > On Tue, 2009-04-28 at 16:21 +0200, Llu?s wrote: >> I am developing a module which will allow users to post certain >> content-types after 30 days of being registered. >> I think this is achieved using hook_menu_alter(); but my code freezes >> drupal with a white screen. >> >> Whats is missing in my code? >> >> function wu_menu_alter(&$menu) { >> ? foreach (node_get_types('types', NULL, TRUE) as $type) { >> ? ? $type_url_str = str_replace('_', '-', $type->type); >> ? ? $menu['node/add/'.$type_url_str]['access callback'] = 'wu_role_access'; >> ? ? $menu['node/add/'.$type_url_str]['access arguments'] = >> array('create', $type->type); >> ? } >> } >> >> function wu_role_access($a='',$b='',$c='',$d='',$e='') { >> // ?echo "**************"; //if uncommented this is displayed >> ? return true; //when it works I will implement the rest of the function >> } >> >> > > -- *La vida ?s com una taronja, que esperes a exprimir-la? *Si creus que l'educaci? ?s cara, prova la ignor?ncia. *La vida ?s com una moneda, la pots gastar en el que vulguis per? nom?s una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From earnie at users.sourceforge.net Tue Apr 28 15:21:21 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 28 Apr 2009 15:21:21 +0000 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <45a29f450904280807k3a4c1f65x4fb5f2601f06a0ff@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <1240930577.9415.4.camel@pedro> <45a29f450904280807k3a4c1f65x4fb5f2601f06a0ff@mail.gmail.com> Message-ID: <20090428152121.87071r6whnx4m2o0@mail.siebunlimited.com> Quoting Llu?s : > the only error in apache is: > [Tue Apr 28 17:04:49 2009] [error] [client 192.168.1.8] File does not > exist: /var/www/favicon.ico > > I solved it adding: > $menu['node/add']['access callback'] = TRUE; > > But I think it has to be a better way > I would ``touch /var/www/favicon.ico'' and make sure the apache user can read it. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From enboig at gmail.com Tue Apr 28 15:31:28 2009 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Tue, 28 Apr 2009 17:31:28 +0200 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <20090428152121.87071r6whnx4m2o0@mail.siebunlimited.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <1240930577.9415.4.camel@pedro> <45a29f450904280807k3a4c1f65x4fb5f2601f06a0ff@mail.gmail.com> <20090428152121.87071r6whnx4m2o0@mail.siebunlimited.com> Message-ID: <45a29f450904280831v3bc87fe3mf45672b80d8a7dd7@mail.gmail.com> On Tue, Apr 28, 2009 at 5:21 PM, Earnie Boyd wrote: > Quoting Llu?s : > >> the only error in apache is: >> [Tue Apr 28 17:04:49 2009] [error] [client 192.168.1.8] File does not >> exist: /var/www/favicon.ico >> >> I solved it adding: >> ?$menu['node/add']['access callback'] = TRUE; I made a mistake; it isn't solved. Adding this I can access node/add and it lists all content types, but when I try to access them I see a WSOD. If I insert echo "1234";I see the text, so my wu_role_access(...) is called. Any idea of how to debug where is the problem? > > I would ``touch /var/www/favicon.ico'' and make sure the apache user can > read it. > I don't care right now about favicon.ico right now; maybe later... :-) > -- > Earnie > -- http://r-feed.com/ ? ? ? ? ? -- http://for-my-kids.com/ > -- http://www.4offer.biz/ ? ? ? -- http://give-me-an-offer.com/ > > -- *La vida ?s com una taronja, que esperes a exprimir-la? *Si creus que l'educaci? ?s cara, prova la ignor?ncia. *La vida ?s com una moneda, la pots gastar en el que vulguis per? nom?s una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From enboig at gmail.com Tue Apr 28 16:03:28 2009 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Tue, 28 Apr 2009 18:03:28 +0200 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <45a29f450904280831v3bc87fe3mf45672b80d8a7dd7@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <1240930577.9415.4.camel@pedro> <45a29f450904280807k3a4c1f65x4fb5f2601f06a0ff@mail.gmail.com> <20090428152121.87071r6whnx4m2o0@mail.siebunlimited.com> <45a29f450904280831v3bc87fe3mf45672b80d8a7dd7@mail.gmail.com> Message-ID: <45a29f450904280903o5afa60e7pde2062f52e2ce512@mail.gmail.com> After reading og_user_roles I found I was able to modify $user->roles in hook_boot(); so no more changes are necessary It is a completely different approach, but everything is simplier in this way; I just need to create a role with the permissions I want, and then at hook_boot(); add the role to the users I want. On Tue, Apr 28, 2009 at 5:31 PM, Llu?s wrote: > On Tue, Apr 28, 2009 at 5:21 PM, Earnie Boyd > wrote: >> Quoting Llu?s : >> >>> the only error in apache is: >>> [Tue Apr 28 17:04:49 2009] [error] [client 192.168.1.8] File does not >>> exist: /var/www/favicon.ico >>> >>> I solved it adding: >>> ?$menu['node/add']['access callback'] = TRUE; > > I made a mistake; it isn't solved. Adding this I can access node/add > and it lists all content types, but when I try to access them I see a > WSOD. > If I insert echo "1234";I see the text, so my wu_role_access(...) is called. > Any idea of how to debug where is the problem? > >> >> I would ``touch /var/www/favicon.ico'' and make sure the apache user can >> read it. >> > > I don't care right now about favicon.ico right now; maybe later... :-) > > >> -- >> Earnie >> -- http://r-feed.com/ ? ? ? ? ? -- http://for-my-kids.com/ >> -- http://www.4offer.biz/ ? ? ? -- http://give-me-an-offer.com/ >> >> > > > > -- > *La vida ?s com una taronja, que esperes a exprimir-la? > *Si creus que l'educaci? ?s cara, prova la ignor?ncia. > *La vida ?s com una moneda, la pots gastar en el que vulguis per? > nom?s una vegada. > *Abans d'imprimir aquest missatge, pensa en el medi ambient. > -- *La vida ?s com una taronja, que esperes a exprimir-la? *Si creus que l'educaci? ?s cara, prova la ignor?ncia. *La vida ?s com una moneda, la pots gastar en el que vulguis per? nom?s una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From subscribe at courtnage.ca Tue Apr 28 16:16:26 2009 From: subscribe at courtnage.ca (Ryan Courtnage) Date: Tue, 28 Apr 2009 10:16:26 -0600 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> Message-ID: On Tue, Apr 28, 2009 at 8:21 AM, Llu?s wrote: > I am developing a module which will allow users to post certain > content-types after 30 days of being registered. > I think this is achieved using hook_menu_alter(); but my code freezes > drupal with a white screen. > > Whats is missing in my code? > > function wu_menu_alter(&$menu) { > ?foreach (node_get_types('types', NULL, TRUE) as $type) { > ? ?$type_url_str = str_replace('_', '-', $type->type); > ? ?$menu['node/add/'.$type_url_str]['access callback'] = 'wu_role_access'; > ? ?$menu['node/add/'.$type_url_str]['access arguments'] = > array('create', $type->type); > ?} > } > > function wu_role_access($a='',$b='',$c='',$d='',$e='') { > // ?echo "**************"; //if uncommented this is displayed > ?return true; //when it works I will implement the rest of the function > } FYI - I tried your code in my own module, works fine here. Did you clear your menu cache after making changes in hook_menu_alter()? From earnie at users.sourceforge.net Tue Apr 28 16:16:51 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 28 Apr 2009 16:16:51 +0000 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <45a29f450904280903o5afa60e7pde2062f52e2ce512@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <1240930577.9415.4.camel@pedro> <45a29f450904280807k3a4c1f65x4fb5f2601f06a0ff@mail.gmail.com> <20090428152121.87071r6whnx4m2o0@mail.siebunlimited.com> <45a29f450904280831v3bc87fe3mf45672b80d8a7dd7@mail.gmail.com> <45a29f450904280903o5afa60e7pde2062f52e2ce512@mail.gmail.com> Message-ID: <20090428161651.74046xxnf4n46ask@mail.siebunlimited.com> Quoting Llu?s : > After reading og_user_roles I found I was able to modify $user->roles > in hook_boot(); so no more changes are necessary > > It is a completely different approach, but everything is simplier in > this way; I just need to create a role with the permissions I want, > and then at hook_boot(); add the role to the users I want. > Or even easier just add the role to the user via the admin/user/user UI. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From enboig at gmail.com Tue Apr 28 16:24:25 2009 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Tue, 28 Apr 2009 18:24:25 +0200 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <20090428161651.74046xxnf4n46ask@mail.siebunlimited.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <1240930577.9415.4.camel@pedro> <45a29f450904280807k3a4c1f65x4fb5f2601f06a0ff@mail.gmail.com> <20090428152121.87071r6whnx4m2o0@mail.siebunlimited.com> <45a29f450904280831v3bc87fe3mf45672b80d8a7dd7@mail.gmail.com> <45a29f450904280903o5afa60e7pde2062f52e2ce512@mail.gmail.com> <20090428161651.74046xxnf4n46ask@mail.siebunlimited.com> Message-ID: <45a29f450904280924s54aa7889l97ed9afa145d389c@mail.gmail.com> Well, that was an example, the permission of a user to belong to a role or not can change during its session; so I need a way to make it change dynamically during the session. On Tue, Apr 28, 2009 at 6:16 PM, Earnie Boyd wrote: > Quoting Llu?s : > >> After reading og_user_roles I found I was able to modify $user->roles >> in hook_boot(); so no more changes are necessary >> >> It is a completely different approach, but everything is simplier in >> this way; I just need to create a role with the permissions I want, >> and then at hook_boot(); add the role to the users I want. >> > > Or even easier just add the role to the user via the admin/user/user UI. > > -- > Earnie > -- http://r-feed.com/ ? ? ? ? ? -- http://for-my-kids.com/ > -- http://www.4offer.biz/ ? ? ? -- http://give-me-an-offer.com/ > > -- *La vida ?s com una taronja, que esperes a exprimir-la? *Si creus que l'educaci? ?s cara, prova la ignor?ncia. *La vida ?s com una moneda, la pots gastar en el que vulguis per? nom?s una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From drupal at dwwright.net Tue Apr 28 17:54:56 2009 From: drupal at dwwright.net (Derek Wright) Date: Tue, 28 Apr 2009 10:54:56 -0700 Subject: [development] Drupal development maintenance teams In-Reply-To: <200904280924.51334.drupal@samboyer.org> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> <200904280924.51334.drupal@samboyer.org> Message-ID: <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote: > We need to remain open to the energy and excitement of new people, > but we also REALLY need to not kneecap the energy and excitement of > the contributors we already have. Your whole message is right-on, but this is the "money quote". Thanks, -Derek (dww) From drupal-devel at webchick.net Tue Apr 28 18:35:19 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Tue, 28 Apr 2009 14:35:19 -0400 Subject: [development] Drupal development maintenance teams In-Reply-To: <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> <200904280924.51334.drupal@samboyer.org> <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> Message-ID: <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> On 28-Apr-09, at 1:54 PM, Derek Wright wrote: > > On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote: > >> We need to remain open to the energy and excitement of new people, >> but we also REALLY need to not kneecap the energy and excitement of >> the contributors we already have. > > Your whole message is right-on, but this is the "money quote". Sure, I don't think anyone would disagree with that. But can you help me understand how the community initiatives pages are "kneecapping" existing contributors? As far as I'm concerned, they're simply a public place to document all of the regular brainstorming/ organization that naturally happens over IRC, e-mail, and g.d.o anyway among people who already make up the 'teams' that Nedjo is proposing that we formalize in some way. If we add names to the pages, then we get the added benefit of said people being publicly identified, which helps them recruit others who share the same itch are looking for someone to collaborate with. Seems win-win to me? Can you please enlighten me with a clue bat? -Angie From larry at garfieldtech.com Tue Apr 28 18:55:53 2009 From: larry at garfieldtech.com (larry at garfieldtech.com) Date: Tue, 28 Apr 2009 13:55:53 -0500 Subject: [development] Drupal development maintenance teams In-Reply-To: <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> <200904280924.51334.drupal@samboyer.org> <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> Message-ID: <49F75139.7090602@garfieldtech.com> Angela Byron wrote: > > On 28-Apr-09, at 1:54 PM, Derek Wright wrote: > >> >> On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote: >> >>> We need to remain open to the energy and excitement of new people, >>> but we also REALLY need to not kneecap the energy and excitement of >>> the contributors we already have. >> >> Your whole message is right-on, but this is the "money quote". > > Sure, I don't think anyone would disagree with that. > > But can you help me understand how the community initiatives pages are > "kneecapping" existing contributors? As far as I'm concerned, they're > simply a public place to document all of the regular > brainstorming/organization that naturally happens over IRC, e-mail, and > g.d.o anyway among people who already make up the 'teams' that Nedjo is > proposing that we formalize in some way. If we add names to the pages, > then we get the added benefit of said people being publicly identified, > which helps them recruit others who share the same itch are looking for > someone to collaborate with. > > Seems win-win to me? Can you please enlighten me with a clue bat? > > -Angie Sure, there's nothing wrong with clarifying who the "point people" are for a given initiative. But that's not quite the point being raised. chx's original email raised the issue that for any given subsystem in Drupal, there's only a handful of people who REALLY know it well enough to support it long term and we've done a rather poor job of adding people to that list overall. How many people besides chx and eaton *really* grok FAPI? There's what, 2-3 people who have any idea how Field API works? DB API is up to *gasp* 5 people who should know it well, if we assume that those in MAINTAINERS.txt know a system well, which is quite high. That means a very low "bus number", which is bad. I countered with "what incentive is there for someone to grok a core system to that level of detail unless they've written it themselves?" (which is how all of the current domain experts, myself included, ended up with that level of knowledge). Aside from the ego trip of saying "*I* have my name in MAINTAINERS.txt", there's little incentive for anyone else to become, say, a total theme system innards ninja. OK if they need it specifically for their job they'll learn just enough for what they need by running through it in a debugger, but then they are unlikely to become a leader in that realm unless there's something in it for them. To Sam's point, we focus on getting developers past the "I suck" threshold, but there's really not much encouragement to get people past the "I kick ass" threshold. (See the chart below for what that means.) And it's the people above that threshold who can act as leaders and teachers to increase our bus number. http://buytaert.net/drupal-learning-curve Your earlier email about the "bat phone to the branch maintainer" was actually the first semi-official statement of what being a submaintainer actually means that I've heard since I became one. OK, cool, so part of the incentive to become a domain expert is a quasi-veto on major changes to that area, and the ability to cut in line when vying for webchick's time. How many people not reading this thread know that? Are there other things we can do to encourage people to become domain experts besides give them a bat phone? I'm not sure off hand, but that's the root of the problem that chx raised that has still not been addressed. (Forks in the thread about moving things out of core to contrib are well and good but don't really address that problem.) --Larry Garfield From earnie at users.sourceforge.net Tue Apr 28 19:29:24 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 28 Apr 2009 19:29:24 +0000 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <45a29f450904280924s54aa7889l97ed9afa145d389c@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <1240930577.9415.4.camel@pedro> <45a29f450904280807k3a4c1f65x4fb5f2601f06a0ff@mail.gmail.com> <20090428152121.87071r6whnx4m2o0@mail.siebunlimited.com> <45a29f450904280831v3bc87fe3mf45672b80d8a7dd7@mail.gmail.com> <45a29f450904280903o5afa60e7pde2062f52e2ce512@mail.gmail.com> <20090428161651.74046xxnf4n46ask@mail.siebunlimited.com> <45a29f450904280924s54aa7889l97ed9afa145d389c@mail.gmail.com> Message-ID: <20090428192924.59044lpma5cqmtk4@mail.siebunlimited.com> Quoting Llu?s : > Well, that was an example, the permission of a user to belong to a > role or not can change during its session; so I need a way to make it > change dynamically during the session. > If you want to trap the user to a new set of permissions during the session you would need to use hook_form_alter and reload the global $user. Something like the untested function function foo_form_alter(&$form, &$form_state, $form_id) { global $user $user = user_load(array('uid' => $user->uid)); } This would reload the $user object for each form modifying the roles to the current set. If you only want certain forms to do this you can filter with the form id. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From earnie at users.sourceforge.net Tue Apr 28 19:35:19 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 28 Apr 2009 19:35:19 +0000 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> Message-ID: <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> Quoting Ryan Courtnage : > On Tue, Apr 28, 2009 at 8:21 AM, Llu?s wrote: >> I am developing a module which will allow users to post certain >> content-types after 30 days of being registered. >> I think this is achieved using hook_menu_alter(); but my code freezes >> drupal with a white screen. >> >> Whats is missing in my code? >> >> function wu_menu_alter(&$menu) { >> foreach (node_get_types('types', NULL, TRUE) as $type) { >> $type_url_str = str_replace('_', '-', $type->type); >> $menu['node/add/'.$type_url_str]['access callback'] = 'wu_role_access'; >> $menu['node/add/'.$type_url_str]['access arguments'] = >> array('create', $type->type); >> } >> } >> You actually want to put this code in wu_menu() instead. Sorry, I missed the first post. >> function wu_role_access($a='',$b='',$c='',$d='',$e='') { >> // echo "**************"; //if uncommented this is displayed >> return true; //when it works I will implement the rest of the function >> } > > FYI - I tried your code in my own module, works fine here. Did you > clear your menu cache after making changes in hook_menu_alter()? > We don't want to be building the menu cache dynamically. It is an expensive operation. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From karoly at negyesi.net Tue Apr 28 19:47:42 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 28 Apr 2009 12:47:42 -0700 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> Message-ID: <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> Now, enough of this. There is no menu cache as it was in D5. There is the router table that can be rebuilt and the navigation trees are cached but this caching does not affect routing. From victorkane at gmail.com Tue Apr 28 19:56:53 2009 From: victorkane at gmail.com (Victor Kane) Date: Tue, 28 Apr 2009 16:56:53 -0300 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> Message-ID: If this were the support mail group, I would shut up. But here on dev, I have to say it... Drupal is getting soooooooo complicated... it's an unkiss. Victor Kane http://awebfactory.com.ar http://projectflowandtracker.com On Tue, Apr 28, 2009 at 4:47 PM, Karoly Negyesi wrote: > Now, enough of this. There is no menu cache as it was in D5. There is > the router table that can be rebuilt and the navigation trees are > cached but this caching does not affect routing. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karoly at negyesi.net Tue Apr 28 20:09:28 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 28 Apr 2009 13:09:28 -0700 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> Message-ID: <7e270cea0904281309v4d221bbq5c9a91d955fb1087@mail.gmail.com> Excellent mail. Try throwing a match into a barrel full of gasoline next time. http://drupal4hu.com/node/137 a year old but on the spot: "People come to me months after a release and complain that they do not like how feature X is implemented. " I was talking about menu to anyone who wanted to listen since 2006 fall (ask the unfortunate attendedees of the Brussels DrupalCon where I talked even to some of those who did not want to listen :p). Every single line of code I wrote was not sneaken into core behind you guys back. It was in the open. From victorkane at gmail.com Tue Apr 28 20:25:39 2009 From: victorkane at gmail.com (Victor Kane) Date: Tue, 28 Apr 2009 17:25:39 -0300 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <7e270cea0904281309v4d221bbq5c9a91d955fb1087@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> <7e270cea0904281309v4d221bbq5c9a91d955fb1087@mail.gmail.com> Message-ID: I don't mean anything against your excellent contributions. I am saying that the famous "code debt" is growing, and that instead of so much pressure being placed on more and more features, which has nothing to do with you, quite the contrary, the emphasis should be on refactoring. There is nothing wrong with the menu system or anything else. The code is excellent. It's the whole kit-and-kaboodle that should be refactored, as per the spirit of several threads, in the interest of simplicity, and the code debt acknowledged, which it never is. That's my emphasis. Victor Kane http://awebfactory.com.ar http://projectflowandtracker.com On Tue, Apr 28, 2009 at 5:09 PM, Karoly Negyesi wrote: > Excellent mail. Try throwing a match into a barrel full of gasoline next > time. > > http://drupal4hu.com/node/137 a year old but on the spot: "People come > to me months after a release and complain that they do not like how > feature X is implemented. " > > I was talking about menu to anyone who wanted to listen since 2006 > fall (ask the unfortunate attendedees of the Brussels DrupalCon where > I talked even to some of those who did not want to listen :p). Every > single line of code I wrote was not sneaken into core behind you guys > back. It was in the open. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nan_wich at bellsouth.net Tue Apr 28 20:39:15 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Tue, 28 Apr 2009 16:39:15 -0400 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <7e270cea0904281309v4d221bbq5c9a91d955fb1087@mail.gmail.com> Message-ID: Chx, I did not, and will not, accuse anyone of sneaking things into core. For the function that started this thread, I have already done something similar and it works fine. BTW, hook_menu_alter is called while the router table is being rebuilt, so it need not be rebuilt. In my other thread, it was something totally new to me, but fashioned on something that someone else had done in D5. I started out doing it the "right" way and it would have worked except for a detail I never could envision in your original plans for menu (which I vaguely remember now). When I stumbled upon it, yes, it upset me. I sort of understand why it was done and I have submitted a patch to try to make it work more like what I think makes more sense (to me). No one is perfect, and I suspect that you had not envisioned the problem I ran into. That's okay. I accept that part of the blame is mine for not providing input at design time. As I mature in Drupal, I hope to be more helpful before a release hits the streets. I also hope that I will be less surprised after they do. We can only hope that everyone does the same. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.6/2084 - Release Date: 4/28/2009 6:15 AM From sivaji2009 at gmail.com Tue Apr 28 20:58:09 2009 From: sivaji2009 at gmail.com (sivaji j.g) Date: Wed, 29 Apr 2009 02:28:09 +0530 Subject: [development] node_delete on module specific node Message-ID: Hello folks I am a gsoc student working on quiz module. Quiz module treats quiz and its question types (multichoice, true/false etc) as a Drupal nodes. I would like to know whether i can delete a nodes specific to quiz module in hook_uninstall. My mentor and current maintainer of quiz module mbutcher is not sure about this. I have already asked this question in #drupal and came to know that core modules never deletes thier node with type story, page etc but nobody is sure about nodes specific modules. If you suggest me to leave quiz nodes untouched like core modules imagine the situation where i have some primary links to quiz nodes and quiz nodes promoted to front page they remains active even if i uninstall quiz module, how should i handle this situation ? or shall i unpublish the quiz nodes to tackle this situation ? -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From earnie at users.sourceforge.net Tue Apr 28 21:02:01 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 28 Apr 2009 21:02:01 +0000 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> Message-ID: <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> Quoting Karoly Negyesi : > Now, enough of this. There is no menu cache as it was in D5. There is > the router table that can be rebuilt and the navigation trees are > cached but this caching does not affect routing. > But the routing is built only when visiting some pages or after emptying the cache. It isn't built dynamically from hook_menu so therefore even though you call it routing that table and not the result of hook_menu is what is used to create the dynamic links on the pages. During development of a module, if I add a menu item without visiting the menu page I don't get to see the menu unless I empty the cache. Therefore I call it a cache (right or wrong) since I see the results of the new menu item after clearing that cache. I don't think the idea bad, on the contrary it is very good. It just needs a new understanding of the functionality. What I miss though is some method to dynamically change the menu item before the page is displayed. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From karoly at negyesi.net Tue Apr 28 21:06:39 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 28 Apr 2009 14:06:39 -0700 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> Message-ID: <7e270cea0904281406y4283d698ye9ed46b8fdd0238d@mail.gmail.com> > But the routing is built only when visiting some pages or after emptying the > cache. Wrong. No matter how much cache you clear, the menu_router table won't be rebuilt. This is why I stepped in: I do not want false information to be spread. Indeed specific admin pages trigger a menu rebuild and that's it. From drupal-devel at webchick.net Tue Apr 28 21:07:27 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Tue, 28 Apr 2009 17:07:27 -0400 Subject: [development] Drupal development maintenance teams In-Reply-To: <49F75139.7090602@garfieldtech.com> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> <200904280924.51334.drupal@samboyer.org> <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> <49F75139.7090602@garfieldtech.com> Message-ID: <3DAC232D-DBD2-4CF4-A063-4BB717A25DBA@webchick.net> On 28-Apr-09, at 2:55 PM, larry at garfieldtech.com wrote: > Your earlier email about the "bat phone to the branch maintainer" > was actually the first semi-official statement of what being a > submaintainer actually means that I've heard since I became one. > OK, cool, so part of the incentive to become a domain expert is a > quasi-veto on major changes to that area, and the ability to cut in > line when vying for webchick's time. How many people not reading > this thread know that? I'm happy to add it to the handbook, if you want. Though I'm not sure I can speak for all core maintainers. > Are there other things we can do to encourage people to become > domain experts besides give them a bat phone? I'm not sure off > hand, but that's the root of the problem that chx raised that has > still not been addressed. (Forks in the thread about moving things > out of core to contrib are well and good but don't really address > that problem.) Well now we're really into a big philosophical discussion around why people contribute to open source projects. And there are a variety of reasons, each unique to each individual. Here are mine: * I get a thrill out of collaborating together with other people smarter than me, and constantly learning new things as a result. Nothing else quite scratches that itch quite like Drupal core development. * I have made lots of friends in the Drupal community, and want to continue to foster those relationships and build new ones. * Drupal is the basis of my livelihood so I want to do whatever I can to make sure it continues to kick ass so I can stay fed. :) As such, you'll find that almost everything I do outside of reviewing and committing patches is centered around leading initiatives to help grow the base of new contributors, raise visibility around the work going on in core, and provide better tools to help existing contributors to keep kicking ass. Community initiative pages are part of those tools. Blogging around core development best practices is part of those tools. Keeping myself accessible 16-18 hours a day in IRC is part of those tools. All are focused on helping new contributors who are "core-curious" to get started, combined with increased visibility of various efforts so fewer things fall through the cracks, both of which lead to existing contributors getting a constant infusion of "new" blood and interest in their areas, which helps keep their morale/motivation/interest in the project high. Or, that's the theory, anyway. By far, the most effective tool I've found so far is the patch review sprint. A funny thing happened over the weekend. With basically zero planning (a Drupal Planet post on Thursday night that said, "Hey, everyone. Show up in IRC this weekend!"), about 50 of us, including both core committers, knocked through 100+ patches that needed review. But the numbers, while impressive, are far less significant to me than what happened "on the ground" during the sprint. What I noticed over and over again were those existing genius-level contributors hanging out, asking each other for the detailed technical reviews their patches were solely missing, and getting them. When new people would join and say, "Hey! I'm new! I'd like a patch to review, please!" the existing contributors would go get one of their long- lingering patches and say, "Great! Check this one out. Let me know if you have questions." All of a sudden, you saw these patches that had been stagnating have new life breathed into them by virtue of someone else paying attention. You also saw lots of mentorship taking place: "I don't really get how DBTNG works here. Can you explain it to me?" "Sure, how that works is..." You saw rapid turnaround from needs review -> needs work -> needs review -> RTBC -> commit. It was, in short, Drupal core development at its very best. So given the choice between: a) completely uprooting our community's current way of doing things, spending lots of time/resources/energy on additional infrastructure to support this, and then debating ad infinitum what guidelines we need to put in place around these changes, all in the hopes that at the end we *might* provide some additional incentive for existing contributors -or- b) simply doing some basic community-building things that help facilitate getting good reviewers to look at good patches, which has the *demonstrated* effect of motivating existing contributors ...I prefer to do the latter. -Angie From karoly at negyesi.net Tue Apr 28 21:09:57 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 28 Apr 2009 14:09:57 -0700 Subject: [development] node_delete on module specific node In-Reply-To: References: Message-ID: <7e270cea0904281409h32b11914q6fe7468d109c4254@mail.gmail.com> Hi, You won't be able to the complete cleanup yourself -- what about existing views for example? -- and deleting nodes en masse is a recipe for catastrophe. Just IMO. Regards NK From cwgordon7 at gmail.com Tue Apr 28 21:12:39 2009 From: cwgordon7 at gmail.com (Charlie Gordon) Date: Tue, 28 Apr 2009 17:12:39 -0400 Subject: [development] node_delete on module specific node In-Reply-To: References: Message-ID: <49F77147.9060500@cwgordon.com> In order to delete nodes of a certain type (say, "quiz"), you can execute a database query of the following form: $result = db_query("SELECT nid FROM {node} WHERE type = '%s'", 'quiz'); while ($node = db_fetch_object($result)) { node_delete($node->nid); } However, this will encounter several scaling problems for sites with many quiz nodes. You may want to investigate using the batch API for something of this scale. On the other hand, you probably shouldn't be deleting the nodes quiz module created - "uninstalling" a module means removing any module settings or data stored within the module: core poll module, for example, does not delete its nodes upon uninstalling. You seem to be aware of this in your message, and express concern that quiz nodes promoted to the front page still exist; I would argue that it's not the quiz module's place to be handling this problem. This opens up a larger debate over whether node-type modules should delete their own nodes upon deletion. In this case, I'd advise following core's example and not worrying about orphaned quiz nodes. -Charlie sivaji j.g wrote: > Hello folks > > I am a gsoc student working on quiz module. Quiz module treats quiz > and its question types (multichoice, true/false etc) as a Drupal > nodes. I would like to know whether i can delete a nodes specific to > quiz module in hook_uninstall. My mentor and current maintainer of > quiz module mbutcher is not sure about this. I have already asked this > question in #drupal and came to know that core modules never deletes > thier node with type story, page etc but nobody is sure about nodes > specific modules. > > If you suggest me to leave quiz nodes untouched like core modules > imagine the situation where i have some primary links to quiz nodes > and quiz nodes promoted to front page they remains active even if i > uninstall quiz module, how should i handle this situation ? or shall i > unpublish the quiz nodes to tackle this situation ? > > > > -- > Thanks a lot > ----------------------------------------- > http://ubuntuslave.blogspot.com/ > From kb at 2bits.com Tue Apr 28 21:22:52 2009 From: kb at 2bits.com (Khalid Baheyeldin) Date: Tue, 28 Apr 2009 17:22:52 -0400 Subject: [development] node_delete on module specific node In-Reply-To: References: Message-ID: <4a9fdc630904281422nc1a1211q5fccabd72654daa3@mail.gmail.com> Check how Delete All does it http://drupal.org/project/delete_all -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci -------------- next part -------------- An HTML attachment was scrubbed... URL: From sepeck at gmail.com Tue Apr 28 21:32:41 2009 From: sepeck at gmail.com (Steven Peck) Date: Tue, 28 Apr 2009 14:32:41 -0700 Subject: [development] Drupal development maintenance teams In-Reply-To: <49F75139.7090602@garfieldtech.com> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> <200904280924.51334.drupal@samboyer.org> <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> <49F75139.7090602@garfieldtech.com> Message-ID: There is actually a written statement that is quite old about what the MAINTAINERS.txt file is for. It has not been changed other then minor edits for years Created 2005, but existed before then). This page in it's original form was part of a longer page that Puregin created when we were breaking up the larger single pages that had existed previous to 2005. http://drupal.org/node/21778 Maintainer. Though not directly making decisions, maintainers have informal responsibility for a designated portion of the core (for example, a particular core module). Individual areas of responsibility are listed in the file MAINTAINERS.txt. Maintainers are appointed by Dries. Core contributors who have made substantive contributions (particularly to a core component not individually maintained) may apply for Maintainer status by writing to Dries. Dries may also individually invite them. So, Larry, now you know what historically had been expected from those listed in the Maintainers.txt. If this changes of course it will need to be updated to reflect those changes. I just noticed that someone changed the title recently. The title doesn't accurately reflect the contents and there is an issue regarding some other information on the page I am looking at. Steven On Tue, Apr 28, 2009 at 11:55 AM, larry at garfieldtech.com wrote: > Angela Byron wrote: >> >> On 28-Apr-09, at 1:54 PM, Derek Wright wrote: >> >>> >>> On Apr 28, 2009, at 7:24 AM, Sam Boyer wrote: >>> >>>> We need to remain open to the energy and excitement of new people, but >>>> we also REALLY need to not kneecap the energy and excitement of the >>>> contributors we already have. >>> >>> Your whole message is right-on, but this is the "money quote". >> >> Sure, I don't think anyone would disagree with that. >> >> But can you help me understand how the community initiatives pages are >> "kneecapping" existing contributors? As far as I'm concerned, they're simply >> a public place to document all of the regular brainstorming/organization >> that naturally happens over IRC, e-mail, and g.d.o anyway among people who >> already make up the 'teams' that Nedjo is proposing that we formalize in >> some way. If we add names to the pages, then we get the added benefit of >> said people being publicly identified, which helps them recruit others who >> share the same itch are looking for someone to collaborate with. >> >> Seems win-win to me? Can you please enlighten me with a clue bat? >> >> -Angie > > Sure, there's nothing wrong with clarifying who the "point people" are for a > given initiative. ?But that's not quite the point being raised. > > chx's original email raised the issue that for any given subsystem in > Drupal, there's only a handful of people who REALLY know it well enough to > support it long term and we've done a rather poor job of adding people to > that list overall. ?How many people besides chx and eaton *really* grok > FAPI? ?There's what, 2-3 people who have any idea how Field API works? ?DB > API is up to *gasp* 5 people who should know it well, if we assume that > those in MAINTAINERS.txt know a system well, which is quite high. > > That means a very low "bus number", which is bad. > > I countered with "what incentive is there for someone to grok a core system > to that level of detail unless they've written it themselves?" (which is how > all of the current domain experts, myself included, ended up with that level > of knowledge). ?Aside from the ego trip of saying "*I* have my name in > MAINTAINERS.txt", there's little incentive for anyone else to become, say, a > total theme system innards ninja. ?OK if they need it specifically for their > job they'll learn just enough for what they need by running through it in a > debugger, but then they are unlikely to become a leader in that realm unless > there's something in it for them. > > To Sam's point, we focus on getting developers past the "I suck" threshold, > but there's really not much encouragement to get people past the "I kick > ass" threshold. ?(See the chart below for what that means.) ?And it's the > people above that threshold who can act as leaders and teachers to increase > our bus number. > > http://buytaert.net/drupal-learning-curve > > Your earlier email about the "bat phone to the branch maintainer" was > actually the first semi-official statement of what being a submaintainer > actually means that I've heard since I became one. ?OK, cool, so part of the > incentive to become a domain expert is a quasi-veto on major changes to that > area, and the ability to cut in line when vying for webchick's time. ?How > many people not reading this thread know that? > > Are there other things we can do to encourage people to become domain > experts besides give them a bat phone? ?I'm not sure off hand, but that's > the root of the problem that chx raised that has still not been addressed. > ?(Forks in the thread about moving things out of core to contrib are well > and good but don't really address that problem.) > > --Larry Garfield > From nan_wich at bellsouth.net Tue Apr 28 21:35:42 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Tue, 28 Apr 2009 17:35:42 -0400 Subject: [development] node_delete on module specific node In-Reply-To: Message-ID: IMHO, if you want to see a really good node module in action, check the FAQ module, which IIRC does delete its nodes on uninstall. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]On Behalf Of sivaji j.g Sent: Tuesday, April 28, 2009 4:58 PM To: development at drupal.org Subject: [development] node_delete on module specific node Hello folks I am a gsoc student working on quiz module. Quiz module treats quiz and its question types (multichoice, true/false etc) as a Drupal nodes. I would like to know whether i can delete a nodes specific to quiz module in hook_uninstall. My mentor and current maintainer of quiz module mbutcher is not sure about this. I have already asked this question in #drupal and came to know that core modules never deletes thier node with type story, page etc but nobody is sure about nodes specific modules. If you suggest me to leave quiz nodes untouched like core modules imagine the situation where i have some primary links to quiz nodes and quiz nodes promoted to front page they remains active even if i uninstall quiz module, how should i handle this situation ? or shall i unpublish the quiz nodes to tackle this situation ? -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.6/2084 - Release Date: 4/28/2009 6:15 AM From nan_wich at bellsouth.net Tue Apr 28 21:38:11 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Tue, 28 Apr 2009 17:38:11 -0400 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> Message-ID: http://api.drupal.org/api/function/menu_rebuild/6 Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.6/2084 - Release Date: 4/28/2009 6:15 AM From earnie at users.sourceforge.net Tue Apr 28 22:26:24 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 28 Apr 2009 22:26:24 +0000 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <7e270cea0904281406y4283d698ye9ed46b8fdd0238d@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> <7e270cea0904281406y4283d698ye9ed46b8fdd0238d@mail.gmail.com> Message-ID: <20090428222624.19541in7n7i1wcys@mail.siebunlimited.com> Quoting Karoly Negyesi : >> But the routing is built only when visiting some pages or after emptying the >> cache. > > Wrong. No matter how much cache you clear, the menu_router table won't > be rebuilt. This is why I stepped in: I do not want false information > to be spread. Indeed specific admin pages trigger a menu rebuild and > that's it. > So when is hook_menu called? I use the devel module to ``Empty Cache'' to cause new items in my custom module to be generated on the menu. The hook_menu isn't called until I ``Empty Cache''. So it appears to from the DX perspective that emptying the cache rebuilds the menu. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From enboig at gmail.com Tue Apr 28 22:34:37 2009 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Wed, 29 Apr 2009 00:34:37 +0200 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <20090428222624.19541in7n7i1wcys@mail.siebunlimited.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> <7e270cea0904281406y4283d698ye9ed46b8fdd0238d@mail.gmail.com> <20090428222624.19541in7n7i1wcys@mail.siebunlimited.com> Message-ID: <45a29f450904281534l2f2c64e7n345ee6eed1eeb03@mail.gmail.com> Returning to the original post which was mine; I post what I have and what I want to do, and then discuss the best way to do that, If lot of people have the same needs as I do, then new drupal version "could" be implemented to make things easy. I have implemented a module with a functionally similar to OG, but using $_SESSION to save the active group. After this node records and node grants are done according to $_SESSION (and saved to a table to allow permission rebuild). Now I want to give a user permission to post when he have some groups active and not for some others, so I created a role with posting permissions and I have to put it in $user->roles just when $_SESSION tells me to do this. I make it in hook_boot because another module with similar functionality for OG was doing this way. Is this a good way to do this? I think its better than doing this in hook_menu or hook_menu_alter because "new" groups are available from the beginning; but I will gladly listen to any constructive comments. And thanks to eveyone On Wed, Apr 29, 2009 at 12:26 AM, Earnie Boyd wrote: > Quoting Karoly Negyesi : > >>> But the routing is built only when visiting some pages or after emptying >>> the >>> cache. >> >> Wrong. No matter how much cache you clear, the menu_router table won't >> be rebuilt. This is why I stepped in: I do not want false information >> to be spread. Indeed specific admin pages trigger a menu rebuild and >> that's it. >> > > So when is hook_menu called? ?I use the devel module to ``Empty Cache'' to > cause new items in my custom module to be generated on the menu. ?The > hook_menu isn't called until I ``Empty Cache''. ?So it appears to from the > DX perspective that emptying the cache rebuilds the menu. > > -- > Earnie > -- http://r-feed.com/ ? ? ? ? ? -- http://for-my-kids.com/ > -- http://www.4offer.biz/ ? ? ? -- http://give-me-an-offer.com/ > > > -- *La vida ?s com una taronja, que esperes a exprimir-la? *Si creus que l'educaci? ?s cara, prova la ignor?ncia. *La vida ?s com una moneda, la pots gastar en el que vulguis per? nom?s una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From karoly at negyesi.net Tue Apr 28 22:35:06 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 28 Apr 2009 15:35:06 -0700 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <20090428222624.19541in7n7i1wcys@mail.siebunlimited.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> <7e270cea0904281406y4283d698ye9ed46b8fdd0238d@mail.gmail.com> <20090428222624.19541in7n7i1wcys@mail.siebunlimited.com> Message-ID: <7e270cea0904281535x342aa4b5v160bf6a27f21ff91@mail.gmail.com> The devel needs a bug report. From drupal at dave-cohen.com Tue Apr 28 23:52:01 2009 From: drupal at dave-cohen.com (David Cohen) Date: Tue, 28 Apr 2009 16:52:01 -0700 Subject: [development] hook_user('categories') Message-ID: <1240962721.15991.1312811499@webmail.messagingengine.com> Sometime in the 5.x-6.x timeframe, the API for hook_user($op == 'categories') changed in a major way. No longer is the $account parameter passed in, and I think the data structure to be returned gained a lot of options. But I can't find the documentation for this. Its not in the 5.x to 6.x page on d.o (http://drupal.org/node/114774), nor is it reflected on http://api.drupal.org/api/function/hook_user/6. Can someone point me to general doc, or an example of how to emulate the following logic in D6. The logic is basically to show the user an edit category only if they have permission to change their own settings. if ($op == 'categories') { if (user_access('edit own extended permissions') && $user->uid == $account->uid) { // build the data structure } } The above logic wont apply in D6 because $account is not passed in, and the return value is expected to have new menu data structure elements which take the place of that logic. But I'm struggle to figure out, in part because I can't find the doc. thanks. From news at unleashedmind.com Wed Apr 29 00:07:10 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Wed, 29 Apr 2009 02:07:10 +0200 Subject: [development] Very concerned over Drupal's core development In-Reply-To: Message-ID: <01dd01c9c85e$718fa490$0200a8c0@structworks.com> I agree with Earl and Darrel, many patches are derailed with endless debates. The question is whether that is good or bad, because the context is missing. I can't speak much about the past, but is it possible that core's development process changed drastically? We introduced an awesome testing framework that ought to increase the quality of code that is committed to core. However, we are still introducing new core bugs (take "FAIL." [1] as an example), despite being reviewed by many eyeballs and having tests. I think this is caused by the steadily increasing complexity of Drupal core - and - by a lack of reviewers that *really* understand core, use-cases in contrib, many sub-systems (not one), and all implications of a core patch. This is the real issue (I believe) Karoly wanted to raise originally. I am not sure whether sub-system maintenance teams will lead to an improvement of this situation. Completely contrary to this proposal, I think our issue is that we are lacking the opposite of domain experts: Drupal core contributors/maintainers/reviewers who understand every single bit of core and potential implications of a changed bit. For the sake of clarity, I have revised Dries' "Drupal learning curve" graph, because I think the important part - the part we are really talking about - is missing: http://www.unleashedmind.com/files/drupal-learning-curve.png Adding new people above the "Core contributor" threshold is what we are mostly doing currently. However, it is my impression that there are very, very few people above the "Trustworthy for core maintainers" treshold. Even less, if you only count people who are known to be "trustworthy" for more than one sub-system. It is possible that you counted only one person (or less?) when climbing up the further tresholds. Maybe that is the issue we are facing? Patches languish in the queue for ages, because some sub-system maintainers subsequently chime in, each one needs own treatment, other contributors chime in, trying to understand the issue, the patch is re-rolled all over again, a branch maintainer shows up who questions the entire approach, and finally the patch may or may not be committed -- still lacking review by someone who understands all changes and implications of the patch. Given all other proposals in this thread, my guess is that adding more maintainers to core might really be a step in the right direction: Handing out responsibility (that comes with a fair amount of power) to core contributors who are already known to be trustworthy (in more than one area) will most likely let them advance in other areas, climbing up the "treshold-ladder" - not only, because people will start to ask about reviews/commits for arbitrary patches. Equally, this action could be done now. [1] http://drupal.org/node/446742 Thanks, sun (who hopes to have reached macro-level with these thoughts) From matt at aleph-null.tv Wed Apr 29 02:07:38 2009 From: matt at aleph-null.tv (Matt) Date: Tue, 28 Apr 2009 21:07:38 -0500 Subject: [development] node_delete on module specific node In-Reply-To: <49F77147.9060500@cwgordon.com> References: <49F77147.9060500@cwgordon.com> Message-ID: <70fbbb000904281907u1847f471yd0f105d8265108c9@mail.gmail.com> The question isn't *how* to delete them. The question is *should* we delete them. It does seem a little presumptuous to just delete all of the user-entered content. On the other hand, we can't really uninstall the schema if we are leaving the nodes -- that just leaves a heap of semi-functional (or non-functional) detritus. I'm imagining irate users who try re-installing the module only to discover that they have lost hundreds of quiz question nodes. On the other hand, uninstalling the schema (which, for quiz, includes tables for fields that augment the standard node fields) will cripple the nodes anyway. If that is going to cause irritation, then we might as well just delete the entire node. So the question is quite simply this: Should modules that provide their own content types delete all content of said types when the module is uninstalled? I'm remembering a particularly frustrating experience trying to uninstall a desktop application. The uninstaller was broken, and I had all kinds of mostly broken junk left on my system that I couldn't get rid of. I would hate to impose that experience on any Drupal user. As chx points out, removing all of the content may leave a site with broken views. As sivaji points out, it can mess with menus and other Drupal structures as well. So we have cases where removing nodes is going to have negative side-effects. And then, again, we have the case where we leave the nodes, but remove the module-specific data that is stored in the module-specific tables. That, too, leaves Drupal broken. So which kind of broken do we want? Matt On Tue, Apr 28, 2009 at 4:12 PM, Charlie Gordon wrote: > In order to delete nodes of a certain type (say, "quiz"), you can execute a > database query of the following form: > > $result = db_query("SELECT nid FROM {node} WHERE type = '%s'", 'quiz'); > while ($node = db_fetch_object($result)) { > ?node_delete($node->nid); > } > > However, this will encounter several scaling problems for sites with many > quiz nodes. You may want to investigate using the batch API for something of > this scale. > > On the other hand, you probably shouldn't be deleting the nodes quiz module > created - "uninstalling" a module means removing any module settings or data > stored within the module: core poll module, for example, does not delete its > nodes upon uninstalling. You seem to be aware of this in your message, and > express concern that quiz nodes promoted to the front page still exist; I > would argue that it's not the quiz module's place to be handling this > problem. > > This opens up a larger debate over whether node-type modules should delete > their own nodes upon deletion. In this case, I'd advise following core's > example and not worrying about orphaned quiz nodes. > > -Charlie > > sivaji j.g wrote: >> >> Hello folks >> >> I am a gsoc student working on quiz module. Quiz module treats quiz and >> its question types (multichoice, true/false etc) as a Drupal nodes. I would >> like to know whether i can delete a nodes specific to quiz module in >> hook_uninstall. My mentor and current maintainer of quiz module mbutcher is >> not sure about this. I have already asked this question in #drupal and came >> to know that core modules never deletes thier node with type story, page etc >> but nobody is sure about nodes specific modules. >> >> If you suggest me to leave quiz nodes untouched like core modules imagine >> the situation where i have some primary links to quiz nodes and quiz nodes >> promoted to front page they remains active even if i uninstall quiz module, >> how should i handle this situation ? or shall i unpublish the quiz nodes to >> tackle this situation ? >> >> >> >> -- >> Thanks a lot >> ----------------------------------------- >> http://ubuntuslave.blogspot.com/ >> > > -- http://technosophos.com http://querypath.org From wilco at nurf.com Wed Apr 29 02:14:35 2009 From: wilco at nurf.com (William Roboly) Date: Tue, 28 Apr 2009 22:14:35 -0400 Subject: [development] hook_user('categories') In-Reply-To: <1240962721.15991.1312811499@webmail.messagingengine.com> References: <1240962721.15991.1312811499@webmail.messagingengine.com> Message-ID: <20090428221435.179776vcoe8i5kaz@users.openject.com> Hi David, I hope this helps you out: You'll now note this function _user_categories($account) which invokes the hook_categories(), so you can in fact simply build your categories that way. Here is an example of some code from a project I was working on (it will give you an idea of what you can do with it): ====== function custom_categories($uid, $type, $type_name) { $content = array(); if (user_access('edit own extended permissions')) { $content['content_profile_'. $type] = array( '#theme' => 'content_profile_display_view', '#edit_link' => content_profile_get_settings($type, 'edit_link'), '#uid' => $uid, '#style' => $style, '#content_type' => $type, '#weight' => content_profile_get_settings($type, 'weight'), '#suffix' => '
', ); // Working around the bug described at http://drupal.org/node/302873 module_load_include('inc', 'content_profile', 'content_profile.theme'); } $content['#prefix'] = '

'; $content['#suffix'] = '

'; return $content; } ====== I'm also using the content_profile module as an API for added functions. But those can be replaced with whatever functions you want. I hope that is of use to you. -wilco Quoting "David Cohen" : > Sometime in the 5.x-6.x timeframe, the API for hook_user($op == > 'categories') changed in a major way. No longer is the $account > parameter passed in, and I think the data structure to be returned > gained a lot of options. But I can't find the documentation for this. > Its not in the 5.x to 6.x page on d.o (http://drupal.org/node/114774), > nor is it reflected on http://api.drupal.org/api/function/hook_user/6. > > Can someone point me to general doc, or an example of how to emulate the > following logic in D6. The logic is basically to show the user an edit > category only if they have permission to change their own settings. > > if ($op == 'categories') { > if (user_access('edit own extended permissions') && > $user->uid == $account->uid) { > // build the data structure > } > } > > The above logic wont apply in D6 because $account is not passed in, and > the return value is expected to have new menu data structure elements > which take the place of that logic. But I'm struggle to figure out, in > part because I can't find the doc. > > thanks. > > From mike at mikeyp.net Wed Apr 29 02:35:10 2009 From: mike at mikeyp.net (Michael Prasuhn) Date: Tue, 28 Apr 2009 19:35:10 -0700 Subject: [development] node_delete on module specific node In-Reply-To: <70fbbb000904281907u1847f471yd0f105d8265108c9@mail.gmail.com> References: <49F77147.9060500@cwgordon.com> <70fbbb000904281907u1847f471yd0f105d8265108c9@mail.gmail.com> Message-ID: <4F4E4BCF-F2D3-49D3-98BF-638DE75F4053@mikeyp.net> On Apr 28, 2009, at 7:07 PM, Matt wrote: > I'm imagining irate users who try re-installing the module only to > discover that they have lost hundreds of quiz question nodes. On the > other hand, uninstalling the schema (which, for quiz, includes tables > for fields that augment the standard node fields) will cripple the > nodes anyway. If that is going to cause irritation, then we might as > well just delete the entire node. [snip] > And then, again, we have the case where we leave the nodes, but remove > the module-specific data that is stored in the module-specific tables. > That, too, leaves Drupal broken. > > So which kind of broken do we want? Neither. If you are really using Drupal's APIs properly, the amount of breakage is rather small. Here's a poll node I made: http://img.skitch.com/20090429-c13tjq8uijniq4twrxrxxxkdxd.png Here's the same poll node after turning off the poll module: http://img.skitch.com/20090429-kpkhegfackipiqbdjas26hqcud.png Not too bad. The only error I could find was from attempting to edit the poll. If you are disabling modules on your site and not smart enough to go and delete or unpublish the content created, I don't know if that's something we should watch for. It's not inconceivable that a user could disable or un-install a module unintentionally, so I think core has already adopted the best approach here. -Mike __________________ Michael Prasuhn mike at mikeyp.net http://mikeyp.net From matt at aleph-null.tv Wed Apr 29 02:44:38 2009 From: matt at aleph-null.tv (Matt) Date: Tue, 28 Apr 2009 21:44:38 -0500 Subject: [development] node_delete on module specific node In-Reply-To: <4F4E4BCF-F2D3-49D3-98BF-638DE75F4053@mikeyp.net> References: <49F77147.9060500@cwgordon.com> <70fbbb000904281907u1847f471yd0f105d8265108c9@mail.gmail.com> <4F4E4BCF-F2D3-49D3-98BF-638DE75F4053@mikeyp.net> Message-ID: <70fbbb000904281944g6e0f5a75gacde01aa6566360@mail.gmail.com> We're not talking about *disabled* modules. We're talking about *uninstalled* modules. >> So which kind of broken do we want? > > Neither. > > If you are really using Drupal's APIs properly, the amount of breakage is > rather small. That's not "neither" -- if there is still breakage, it is (by definition) broken. Quiz, like many other modules, has tight integration with views and other modules. Once I start deleting things upon uninstallation, I have all kinds of new issues to worry about. What do I do about that view of quiz nodes? Do I start scanning the Views and attempting to alter or delete those? (Earl, don't kill me. That was rhetorical.) There are many issues closely wrapped up here, but again, we're talking about what should be deleted when the module is uninstalled (Uninstalled -- not disabled. I'd be an idiot to delete content when a module was merely disabled.) Matt On Tue, Apr 28, 2009 at 9:35 PM, Michael Prasuhn wrote: > > On Apr 28, 2009, at 7:07 PM, Matt wrote: >> >> I'm imagining irate users who try re-installing the module only to >> discover that they have lost hundreds of quiz question nodes. On the >> other hand, uninstalling the schema (which, for quiz, includes tables >> for fields that augment the standard node fields) will cripple the >> nodes anyway. If that is going to cause irritation, then we might as >> well just delete the entire node. > > [snip] > >> And then, again, we have the case where we leave the nodes, but remove >> the module-specific data that is stored in the module-specific tables. >> That, too, leaves Drupal broken. >> >> So which kind of broken do we want? > > Neither. > > If you are really using Drupal's APIs properly, the amount of breakage is > rather small. > > Here's a poll node I made: > http://img.skitch.com/20090429-c13tjq8uijniq4twrxrxxxkdxd.png > > Here's the same poll node after turning off the poll module: > http://img.skitch.com/20090429-kpkhegfackipiqbdjas26hqcud.png > > Not too bad. The only error I could find was from attempting to edit the > poll. > > If you are disabling modules on your site and not smart enough to go and > delete or unpublish the content created, I don't know if that's something we > should watch for. It's not inconceivable that a user could disable or > un-install a module unintentionally, so I think core has already adopted the > best approach here. > > -Mike > > __________________ > Michael Prasuhn > mike at mikeyp.net > http://mikeyp.net > > > > > > -- http://technosophos.com http://querypath.org From cxjohnson at gmail.com Wed Apr 29 03:12:02 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 28 Apr 2009 22:12:02 -0500 Subject: [development] node_delete on module specific node In-Reply-To: <70fbbb000904281944g6e0f5a75gacde01aa6566360@mail.gmail.com> References: <49F77147.9060500@cwgordon.com> <70fbbb000904281907u1847f471yd0f105d8265108c9@mail.gmail.com> <4F4E4BCF-F2D3-49D3-98BF-638DE75F4053@mikeyp.net> <70fbbb000904281944g6e0f5a75gacde01aa6566360@mail.gmail.com> Message-ID: <9ea8d6030904282012o3b854f32rdc6937b891e28ec7@mail.gmail.com> Perhaps warning the user that they have N nodes of the content type supported by the module which is about to be uninstalled would be one idea? ..chris On Tue, Apr 28, 2009 at 9:44 PM, Matt wrote: > We're not talking about *disabled* modules. We're talking about > *uninstalled* modules. > >>> So which kind of broken do we want? >> >> Neither. >> >> If you are really using Drupal's APIs properly, the amount of breakage is >> rather small. > > That's not "neither" -- if there is still breakage, it is (by > definition) broken. > > Quiz, like many other modules, has tight integration with views and > other modules. Once I start deleting things upon uninstallation, I > have all kinds of new issues to worry about. What do I do about that > view of quiz nodes? Do I start scanning the Views and attempting to > alter or delete those? (Earl, don't kill me. That was rhetorical.) > > There are many issues closely wrapped up here, but again, we're > talking about what should be deleted when the module is uninstalled > (Uninstalled -- not disabled. I'd be an idiot to delete content when a > module was merely disabled.) > > Matt > > On Tue, Apr 28, 2009 at 9:35 PM, Michael Prasuhn wrote: >> >> On Apr 28, 2009, at 7:07 PM, Matt wrote: >>> >>> I'm imagining irate users who try re-installing the module only to >>> discover that they have lost hundreds of quiz question nodes. On the >>> other hand, uninstalling the schema (which, for quiz, includes tables >>> for fields that augment the standard node fields) will cripple the >>> nodes anyway. If that is going to cause irritation, then we might as >>> well just delete the entire node. >> >> [snip] >> >>> And then, again, we have the case where we leave the nodes, but remove >>> the module-specific data that is stored in the module-specific tables. >>> That, too, leaves Drupal broken. >>> >>> So which kind of broken do we want? >> >> Neither. >> >> If you are really using Drupal's APIs properly, the amount of breakage is >> rather small. >> >> Here's a poll node I made: >> http://img.skitch.com/20090429-c13tjq8uijniq4twrxrxxxkdxd.png >> >> Here's the same poll node after turning off the poll module: >> http://img.skitch.com/20090429-kpkhegfackipiqbdjas26hqcud.png >> >> Not too bad. The only error I could find was from attempting to edit the >> poll. >> >> If you are disabling modules on your site and not smart enough to go and >> delete or unpublish the content created, I don't know if that's something we >> should watch for. It's not inconceivable that a user could disable or >> un-install a module unintentionally, so I think core has already adopted the >> best approach here. >> >> -Mike >> >> __________________ >> Michael Prasuhn >> mike at mikeyp.net >> http://mikeyp.net >> >> >> >> >> >> > > > > -- > http://technosophos.com > http://querypath.org > From nikstar at gmail.com Wed Apr 29 03:39:28 2009 From: nikstar at gmail.com (Nik Derewianka) Date: Wed, 29 Apr 2009 13:39:28 +1000 Subject: [development] Guidance on OS X dev setup Message-ID: <19882B58-72EC-4E87-9854-317152EBD8AC@gmail.com> Hi all, Relatively new to drupal + php, but not to programming and would like a bit of recommendation in tools to use on OSX for drupal development. Tools - Textmate/Coda etc or more full blown eclipse, other ?? Recommended ways to debug drupal so that i can see how things work. Is CVS the only revision control system in use for drupal ? Any plans for a modern CVS/DCVS any time soon ? Slightly more specific to Services + AMFPHP (yes i will be checking out g.d.o soon): With flex the uid property on a serialised object is reserved for flex's tracking of objects so it inevitably clobbers the uid properties being returned by the various user objects in drupal. Currently the amfphp module gets around this by doing: /* * ugly! ugly! ugly! * we need to use a method call wrapper here to convert all 'uid' values in the result * to 'userid'. this is because flex uses the property 'uid' in objects and will overwrite * anything we send with its own value. */ function amfphp_method_call($method_name, $args) { // convert all userid to uid $args = amfphp_fix_uid($args, 0); $result = services_method_call($method_name, $args); // convert all uid to userid $result = amfphp_fix_uid($result); return $result; } /* * ugly! ugly! ugly! */ function amfphp_fix_uid($data, $direction = 1) { $uid = 's:3:"uid";'; $userid = 's:6:"userid";'; $from = ($direction) ? $uid : $userid; $to = (!$direction) ? $uid : $userid; $data = serialize($data); $data = str_replace($from, $to, $data); $data = unserialize($data); return $data; } Ideally, it would be better to expose a duplicate property of userid in user/node/etc classes instead of the huge refactoring task of changing uid to userid etc, but understandably this may not be the ideal solution. Can anyone recommend a possibly different approach than the one taken above ?? (And apologies if this has been already discussed elsewhere, kindly point me to it so that i can read up on it). Thanks, Nik From recidive at gmail.com Wed Apr 29 03:40:53 2009 From: recidive at gmail.com (Henrique Recidive) Date: Wed, 29 Apr 2009 00:40:53 -0300 Subject: [development] node_delete on module specific node In-Reply-To: <9ea8d6030904282012o3b854f32rdc6937b891e28ec7@mail.gmail.com> References: <49F77147.9060500@cwgordon.com> <70fbbb000904281907u1847f471yd0f105d8265108c9@mail.gmail.com> <4F4E4BCF-F2D3-49D3-98BF-638DE75F4053@mikeyp.net> <70fbbb000904281944g6e0f5a75gacde01aa6566360@mail.gmail.com> <9ea8d6030904282012o3b854f32rdc6937b891e28ec7@mail.gmail.com> Message-ID: <841684fe0904282040m47e881fdkdfb257f28ee58dd6@mail.gmail.com> 2009/4/29 Chris Johnson : > Perhaps warning the user that they have N nodes of the content type > supported by the module which is about to be uninstalled would be one > idea? That's exactly what core does when deleting a custom content type: "Warning: there are currently @count %type posts on your site. They may not be able to be displayed or edited correctly, once you have removed this content type." So I guess modules doing the same thing on uninstall is a good practice. Henrique > > ..chris > > On Tue, Apr 28, 2009 at 9:44 PM, Matt wrote: >> We're not talking about *disabled* modules. We're talking about >> *uninstalled* modules. >> >>>> So which kind of broken do we want? >>> >>> Neither. >>> >>> If you are really using Drupal's APIs properly, the amount of breakage is >>> rather small. >> >> That's not "neither" -- if there is still breakage, it is (by >> definition) broken. >> >> Quiz, like many other modules, has tight integration with views and >> other modules. Once I start deleting things upon uninstallation, I >> have all kinds of new issues to worry about. What do I do about that >> view of quiz nodes? Do I start scanning the Views and attempting to >> alter or delete those? (Earl, don't kill me. That was rhetorical.) >> >> There are many issues closely wrapped up here, but again, we're >> talking about what should be deleted when the module is uninstalled >> (Uninstalled -- not disabled. I'd be an idiot to delete content when a >> module was merely disabled.) >> >> Matt >> >> On Tue, Apr 28, 2009 at 9:35 PM, Michael Prasuhn wrote: >>> >>> On Apr 28, 2009, at 7:07 PM, Matt wrote: >>>> >>>> I'm imagining irate users who try re-installing the module only to >>>> discover that they have lost hundreds of quiz question nodes. On the >>>> other hand, uninstalling the schema (which, for quiz, includes tables >>>> for fields that augment the standard node fields) will cripple the >>>> nodes anyway. If that is going to cause irritation, then we might as >>>> well just delete the entire node. >>> >>> [snip] >>> >>>> And then, again, we have the case where we leave the nodes, but remove >>>> the module-specific data that is stored in the module-specific tables. >>>> That, too, leaves Drupal broken. >>>> >>>> So which kind of broken do we want? >>> >>> Neither. >>> >>> If you are really using Drupal's APIs properly, the amount of breakage is >>> rather small. >>> >>> Here's a poll node I made: >>> http://img.skitch.com/20090429-c13tjq8uijniq4twrxrxxxkdxd.png >>> >>> Here's the same poll node after turning off the poll module: >>> http://img.skitch.com/20090429-kpkhegfackipiqbdjas26hqcud.png >>> >>> Not too bad. The only error I could find was from attempting to edit the >>> poll. >>> >>> If you are disabling modules on your site and not smart enough to go and >>> delete or unpublish the content created, I don't know if that's something we >>> should watch for. It's not inconceivable that a user could disable or >>> un-install a module unintentionally, so I think core has already adopted the >>> best approach here. >>> >>> -Mike >>> >>> __________________ >>> Michael Prasuhn >>> mike at mikeyp.net >>> http://mikeyp.net >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> http://technosophos.com >> http://querypath.org >> > From nik at artofmultimedia.com.au Wed Apr 29 04:59:14 2009 From: nik at artofmultimedia.com.au (Nik Derewianka) Date: Wed, 29 Apr 2009 14:59:14 +1000 Subject: [development] node_delete on module specific node In-Reply-To: <841684fe0904282040m47e881fdkdfb257f28ee58dd6@mail.gmail.com> References: <49F77147.9060500@cwgordon.com> <70fbbb000904281907u1847f471yd0f105d8265108c9@mail.gmail.com> <4F4E4BCF-F2D3-49D3-98BF-638DE75F4053@mikeyp.net> <70fbbb000904281944g6e0f5a75gacde01aa6566360@mail.gmail.com> <9ea8d6030904282012o3b854f32rdc6937b891e28ec7@mail.gmail.com> <841684fe0904282040m47e881fdkdfb257f28ee58dd6@mail.gmail.com> Message-ID: <2E1AA8C9-5A31-4C4F-A0DA-9C44AEDB128C@artofmultimedia.com.au> On 29/04/2009, at 1:40 PM, Henrique Recidive wrote: > 2009/4/29 Chris Johnson : >> Perhaps warning the user that they have N nodes of the content type >> supported by the module which is about to be uninstalled would be one >> idea? > > That's exactly what core does when deleting a custom content type: > > "Warning: there are currently @count %type posts on your > site. They may not be able to be displayed or edited correctly, once > you have removed this content type." > > So I guess modules doing the same thing on uninstall is a good > practice. Could also be helpful to have a link in that message to admin/content/ node with the type= filter set so that they can easily review the impact/scope of their change. Regards, Nik From jpetso at gmx.at Wed Apr 29 06:14:15 2009 From: jpetso at gmx.at (Jakob Petsovits) Date: Wed, 29 Apr 2009 08:14:15 +0200 Subject: [development] hook_user('categories') In-Reply-To: <1240962721.15991.1312811499@webmail.messagingengine.com> References: <1240962721.15991.1312811499@webmail.messagingengine.com> Message-ID: <200904290814.16685.jpetso@gmx.at> On Wednesday 29 April 2009, David Cohen wrote: > Can someone point me to general doc, or an example of how to emulate the > following logic in D6. The logic is basically to show the user an edit > category only if they have permission to change their own settings. > > if ($op == 'categories') { > if (user_access('edit own extended permissions') && > $user->uid == $account->uid) { > // build the data structure > } > } First up, hook_user($op='categories') is one giant hack, and results in nothing else than inserting a couple of menu items. In Drupal 6 it adapted to the new menu system, which means you don't return categories depending on dynamic permission tests. Instead, use access callbacks to check for permissions. Something like this worked for me (another hack, so to say): function versioncontrol_user($type, &$edit, &$user, $category = NULL) { switch ($type) { case 'categories': $categories = array(); $categories[] = array( 'name' => 'versioncontrol', // user_menu() pipes 'title' though check_plain() already. 'title' => 'Repository accounts', 'weight' => 99, ); return $categories; } } function versioncontrol_menu() { (...) $items['user/%versioncontrol_user_accounts/edit/versioncontrol'] = array( 'title callback' => 'versioncontrol_user_accounts_title_callback', 'title arguments' => array(1), 'page callback' => 'versioncontrol_account_page', 'page arguments' => array(1), 'access callback' => 'versioncontrol_private_account_access', 'access arguments' => array(1), 'file' => 'versioncontrol.pages.inc', 'weight' => 99, 'type' => MENU_LOCAL_TASK, ); (...) } Somehow, these two are getting merged in the end. (I guess they aren't really getting merged but my item is preferred so it works. Probably hook_menu_alter() is a cleaner solution and would result in a genuinely merged item.) I'd prefer to skip hook_user() altogether, but that results in bugs with tab display. If someone has a proper solution for this common piece of functionality, I'm all ears. Cheers, Jakob From nuppla at zites.net Wed Apr 29 10:12:49 2009 From: nuppla at zites.net (fago) Date: Wed, 29 Apr 2009 12:12:49 +0200 Subject: [development] hook_user('categories') In-Reply-To: <200904290814.16685.jpetso@gmx.at> References: <1240962721.15991.1312811499@webmail.messagingengine.com> <200904290814.16685.jpetso@gmx.at> Message-ID: <1240999969.4600.2.camel@butterfly> > Somehow, these two are getting merged in the end. (I guess they aren't > really getting merged but my item is preferred so it works. Probably > hook_menu_alter() is a cleaner solution and would result in a genuinely merged > item.) I'd prefer to skip hook_user() altogether, but that results in bugs > with tab display. I had the same problem with content profile. I also worked around it by adding the (unwanted) user categories and I altered the menu items - works fine. Here is more background: http://drupal.org/node/367202#comment-1246922 regards, fago -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From drupal at dwwright.net Wed Apr 29 11:20:25 2009 From: drupal at dwwright.net (Derek Wright) Date: Wed, 29 Apr 2009 04:20:25 -0700 Subject: [development] Drupal development maintenance teams In-Reply-To: <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> <200904280924.51334.drupal@samboyer.org> <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> Message-ID: <3A9BAD71-28E2-46BB-9E5B-F15BA87E89B6@dwwright.net> On Apr 28, 2009, at 11:35 AM, Angela Byron wrote: > can you help me understand how the community initiatives pages are > "kneecapping" existing contributors? For starters, because they're impossible to find. Maybe it's because it's after 4am and I've been rolling update.module patches[1] for the last few hours, but I just spent literally 10 minutes clicking around the handbooks, and I can't find these pages anywhere. That "Current Drupal core initiatives" link in the Contributor links block? Useless. No where under "Contribute", nor "Documentation", etc, etc. I only spent that long clicking around because not even googling for "site:drupal.org core initiatives" turns up anything (at least not in the first few pages). How is this helping anyone if I can't even find the pages to add one for update module? Much less how is anyone else going to help me with update module if they can't find the pages, either? -Derek (dww) p.s. Oh, google finally wins on "community initiatives" and I found it: http://drupal.org/community-initiatives *sigh* ;) Oh well, my energy to start an initiative page is totally spent for the night, hopefully in the near future... [1] for the interested reader: http://drupal.org/node/220592#comment-1532940 http://drupal.org/node/448268 From earnie at users.sourceforge.net Wed Apr 29 12:55:50 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 29 Apr 2009 12:55:50 +0000 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <7e270cea0904281535x342aa4b5v160bf6a27f21ff91@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> <7e270cea0904281406y4283d698ye9ed46b8fdd0238d@mail.gmail.com> <20090428222624.19541in7n7i1wcys@mail.siebunlimited.com> <7e270cea0904281535x342aa4b5v160bf6a27f21ff91@mail.gmail.com> Message-ID: <20090429125550.10755wkmreyjpaww@mail.siebunlimited.com> Quoting Karoly Negyesi : > The devel needs a bug report. > I don't understand what is wrong with devel to open a report. The callback just does /** * Menu callback; clears all caches, then redirects to the previous page. */ function devel_cache_clear() { // If you used to implement our own cache clear hook, implement hook_flush_caches instead. See drupal_flush_all_caches() drupal_flush_all_caches(); drupal_set_message('Cache cleared.'); drupal_goto(); } And http://api.drupal.org/api/function/drupal_flush_all_caches/6 calls menu_rebuild(). -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From drupal at rocktreesky.com Wed Apr 29 13:07:52 2009 From: drupal at rocktreesky.com (Addison Berry) Date: Wed, 29 Apr 2009 09:07:52 -0400 Subject: [development] Drupal development maintenance teams In-Reply-To: <3A9BAD71-28E2-46BB-9E5B-F15BA87E89B6@dwwright.net> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> <200904280924.51334.drupal@samboyer.org> <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> <3A9BAD71-28E2-46BB-9E5B-F15BA87E89B6@dwwright.net> Message-ID: <1094C5C2-4589-46C1-928F-C8D46C4E7DA7@rocktreesky.com> This has been sitting in the queue to add a proper link in the sidebar for quite a long while: http://drupal.org/node/341070 - Addi On Apr 29, 2009, at 7:20 AM, Derek Wright wrote: > > On Apr 28, 2009, at 11:35 AM, Angela Byron wrote: > >> can you help me understand how the community initiatives pages are >> "kneecapping" existing contributors? > > For starters, because they're impossible to find. Maybe it's > because it's after 4am and I've been rolling update.module > patches[1] for the last few hours, but I just spent literally 10 > minutes clicking around the handbooks, and I can't find these pages > anywhere. That "Current Drupal core initiatives" link in the > Contributor links block? Useless. No where under "Contribute", nor > "Documentation", etc, etc. I only spent that long clicking around > because not even googling for "site:drupal.org core initiatives" > turns up anything (at least not in the first few pages). > > How is this helping anyone if I can't even find the pages to add one > for update module? Much less how is anyone else going to help me > with update module if they can't find the pages, either? > > -Derek (dww) > > > p.s. Oh, google finally wins on "community initiatives" and I found > it: > > http://drupal.org/community-initiatives > > *sigh* ;) Oh well, my energy to start an initiative page is totally > spent for the night, hopefully in the near future... > > > [1] for the interested reader: > http://drupal.org/node/220592#comment-1532940 > http://drupal.org/node/448268 > > From gabor at hojtsy.hu Wed Apr 29 14:39:22 2009 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Wed, 29 Apr 2009 16:39:22 +0200 Subject: [development] Drupal development maintenance teams In-Reply-To: <3A9BAD71-28E2-46BB-9E5B-F15BA87E89B6@dwwright.net> References: <49F4BC88.3020307@islandnet.com> <49F67129.7070301@islandnet.com> <7e270cea0904272018w78016110hc53b8448695bdcc8@mail.gmail.com> <200904280924.51334.drupal@samboyer.org> <7197A749-934D-4857-96DF-493EAF750B4F@dwwright.net> <85D8ABA9-F21C-4FD8-AECB-BBCF436F6760@webchick.net> <3A9BAD71-28E2-46BB-9E5B-F15BA87E89B6@dwwright.net> Message-ID: <86ca3ccb0904290739s56fb496btf3989fd06a103d8e@mail.gmail.com> On Wed, Apr 29, 2009 at 1:20 PM, Derek Wright wrote: > On Apr 28, 2009, at 11:35 AM, Angela Byron wrote: >> can you help me understand how the community initiatives pages are >> "kneecapping" existing contributors? > > For starters, because they're impossible to find. ?Maybe it's because it's > after 4am and I've been rolling update.module patches[1] for the last few > hours, but I just spent literally 10 minutes clicking around the handbooks, > and I can't find these pages anywhere. ?That "Current Drupal core > initiatives" link in the Contributor links block? ?Useless. ?No where under > "Contribute", nor "Documentation", etc, etc. ?I only spent that long > clicking around because not even googling for "site:drupal.org core > initiatives" turns up anything (at least not in the first few pages). > > How is this helping anyone if I can't even find the pages to add one for > update module? ?Much less how is anyone else going to help me with update > module if they can't find the pages, either? I think the reason it is not properly linked in is that it does not have a huge history. It gained popularity when we introduced status level coloring and reporting in issue links as well as assignee info. Which makes assembling and maintaining such initiative pages much easier. They are after all organized and documented flows of issue links. G?bor From karoly at negyesi.net Wed Apr 29 15:14:28 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed, 29 Apr 2009 08:14:28 -0700 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <20090429125550.10755wkmreyjpaww@mail.siebunlimited.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> <7e270cea0904281406y4283d698ye9ed46b8fdd0238d@mail.gmail.com> <20090428222624.19541in7n7i1wcys@mail.siebunlimited.com> <7e270cea0904281535x342aa4b5v160bf6a27f21ff91@mail.gmail.com> <20090429125550.10755wkmreyjpaww@mail.siebunlimited.com> Message-ID: <7e270cea0904290814j5eeef776ydf7d7e2ed192e2ee@mail.gmail.com> Then core needs fixing too. Or people need understanding? Because when you say "emptying the cache" some might think that's simply TRUNCATE cache. Which, accidentally, DID rebuild the menu in Drupal 5. From earnie at users.sourceforge.net Wed Apr 29 17:58:31 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 29 Apr 2009 17:58:31 +0000 Subject: [development] modify permissions using hook_menu_alter() In-Reply-To: <7e270cea0904290814j5eeef776ydf7d7e2ed192e2ee@mail.gmail.com> References: <45a29f450904280721s701c6ee8wbbe692c463e51232@mail.gmail.com> <20090428193519.12266hjlfcajnfs4@mail.siebunlimited.com> <7e270cea0904281247x32fc8debjcd2934648b5b4c01@mail.gmail.com> <20090428210201.13287ak2l1coocw8@mail.siebunlimited.com> <7e270cea0904281406y4283d698ye9ed46b8fdd0238d@mail.gmail.com> <20090428222624.19541in7n7i1wcys@mail.siebunlimited.com> <7e270cea0904281535x342aa4b5v160bf6a27f21ff91@mail.gmail.com> <20090429125550.10755wkmreyjpaww@mail.siebunlimited.com> <7e270cea0904290814j5eeef776ydf7d7e2ed192e2ee@mail.gmail.com> Message-ID: <20090429175831.59271awi95yips94@mail.siebunlimited.com> Quoting Karoly Negyesi : > Then core needs fixing too. Or people need understanding? Because when > you say "emptying the cache" some might think that's simply TRUNCATE > cache. Which, accidentally, DID rebuild the menu in Drupal 5. > Yes, I understand and agree. The rebuild is triggered simply by adding a menu_rebuild_needed with a boolean TRUE and executing cron.php or by calling menu_rebuild directly which is where the actions occur and what the hook_cron implementation calls. I'm not sure how to title an issue the drupal_flush_all_caches calls rebuild_menu, drupal_rebuild_theme_registry, node_types_rebuild. For an API that is dealing with flushing caches does it have business rebuilding non cache tables? I've created #448750 for continued discussion. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/ From pierre.rineau at makina-corpus.com Thu Apr 30 08:15:31 2009 From: pierre.rineau at makina-corpus.com (Pierre Rineau) Date: Thu, 30 Apr 2009 10:15:31 +0200 Subject: [development] Custom module, do you think I should add it to cvs.drupal.org ? Message-ID: <1241079331.6217.7.camel@guinevere.makina-nantes.net> Hi folks, I made a really, really simple module (3 lines and a JS file). It uses the "title" HTML attribute on text and textarea HTML inputs to display an empty value in the input, which disappear on focus, and re-appear on focus out if input is still empty. This is simple, I saw something like 10 or 20 different JS implementations; I choosed one of them, (one I saw on Drupal.org's forums), adapted it a bit the JS file to be more coherent with Drupal6. The real module just does a "drupal_add_js()" in hook_init() (which should be compatible with aggressive caching). Do you think this is a good idea to commit it in the Drupal CVS, as a new project? Or do you known some modules which already does the same thing, in a better way? Regards, Pierre. From kb at 2bits.com Thu Apr 30 14:29:08 2009 From: kb at 2bits.com (Khalid Baheyeldin) Date: Thu, 30 Apr 2009 10:29:08 -0400 Subject: [development] Custom module, do you think I should add it to cvs.drupal.org ? In-Reply-To: <1241079331.6217.7.camel@guinevere.makina-nantes.net> References: <1241079331.6217.7.camel@guinevere.makina-nantes.net> Message-ID: <4a9fdc630904300729p13bd89fcp184803d41544c37e@mail.gmail.com> No. A 3 line module is not worth its own project and issue queue and such. This module is best posted in the snippets here http://drupal.org/node/23220 See also here http://drupal.org/handbook/customization/php-snippets On Thu, Apr 30, 2009 at 4:15 AM, Pierre Rineau < pierre.rineau at makina-corpus.com> wrote: > Hi folks, > > I made a really, really simple module (3 lines and a JS file). > > It uses the "title" HTML attribute on text and textarea HTML inputs to > display an empty value in the input, which disappear on focus, and > re-appear on focus out if input is still empty. > > This is simple, I saw something like 10 or 20 different JS > implementations; I choosed one of them, (one I saw on Drupal.org's > forums), adapted it a bit the JS file to be more coherent with Drupal6. > > The real module just does a "drupal_add_js()" in hook_init() (which > should be compatible with aggressive caching). > > Do you think this is a good idea to commit it in the Drupal CVS, as a > new project? > > Or do you known some modules which already does the same thing, in a > better way? > > Regards, > Pierre. > > -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.rineau at makina-corpus.com Thu Apr 30 15:17:02 2009 From: pierre.rineau at makina-corpus.com (Pierre Rineau) Date: Thu, 30 Apr 2009 17:17:02 +0200 Subject: [development] Custom module, do you think I should add it to cvs.drupal.org ? In-Reply-To: <4a9fdc630904300729p13bd89fcp184803d41544c37e@mail.gmail.com> References: <1241079331.6217.7.camel@guinevere.makina-nantes.net> <4a9fdc630904300729p13bd89fcp184803d41544c37e@mail.gmail.com> Message-ID: <1241104622.6217.14.camel@guinevere.makina-nantes.net> Ok, so I won't. Thanks for your answer. Le jeudi 30 avril 2009 ? 10:29 -0400, Khalid Baheyeldin a ?crit : > No. A 3 line module is not worth its own project and issue queue and > such. > > This module is best posted in the snippets here > http://drupal.org/node/23220 > > See also here http://drupal.org/handbook/customization/php-snippets > > On Thu, Apr 30, 2009 at 4:15 AM, Pierre Rineau > wrote: > Hi folks, > > I made a really, really simple module (3 lines and a JS file). > > It uses the "title" HTML attribute on text and textarea HTML > inputs to > display an empty value in the input, which disappear on focus, > and > re-appear on focus out if input is still empty. > > This is simple, I saw something like 10 or 20 different JS > implementations; I choosed one of them, (one I saw on > Drupal.org's > forums), adapted it a bit the JS file to be more coherent with > Drupal6. > > The real module just does a "drupal_add_js()" in hook_init() > (which > should be compatible with aggressive caching). > > Do you think this is a good idea to commit it in the Drupal > CVS, as a > new project? > > Or do you known some modules which already does the same > thing, in a > better way? > > Regards, > Pierre. > > > > > -- > Khalid M. Baheyeldin > 2bits.com, Inc. > http://2bits.com > Drupal optimization, development, customization and consulting. > Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra > Simplicity is the ultimate sophistication. -- Leonardo da Vinci From drothstein at gmail.com Thu Apr 30 16:16:04 2009 From: drothstein at gmail.com (David Rothstein) Date: Thu, 30 Apr 2009 12:16:04 -0400 Subject: [development] Custom module, do you think I should add it to cvs.drupal.org ? In-Reply-To: <1241104622.6217.14.camel@guinevere.makina-nantes.net> References: <1241079331.6217.7.camel@guinevere.makina-nantes.net> <4a9fdc630904300729p13bd89fcp184803d41544c37e@mail.gmail.com> <1241104622.6217.14.camel@guinevere.makina-nantes.net> Message-ID: <27ad04850904300916r67d6ae53p35c73f1b32b978a@mail.gmail.com> I disagree. I don't think the initial number of lines of code is a good indicator of anything (and also, it's not just 3 lines in this case, but rather 3 lines plus an entire file, right?). In my opinion, a better measure is whether or not the code is written in a way that is generically useful. If it can be meaningfully used by a variety of sites without them needing to edit the code, then posting it as a module makes sense. Modules are accessible to a much broader audience than PHP snippets are. However, in this case, if I understand the description correctly, it sounds like it might have a lot in common with an existing project ( http://drupal.org/project/compact_forms)? If so, then you should contribute your work to that project rather than starting a new one. Good luck! David Rothstein On Thu, Apr 30, 2009 at 11:17 AM, Pierre Rineau < pierre.rineau at makina-corpus.com> wrote: > Ok, so I won't. > > Thanks for your answer. > > Le jeudi 30 avril 2009 ? 10:29 -0400, Khalid Baheyeldin a ?crit : > > No. A 3 line module is not worth its own project and issue queue and > > such. > > > > This module is best posted in the snippets here > > http://drupal.org/node/23220 > > > > See also here http://drupal.org/handbook/customization/php-snippets > > > > On Thu, Apr 30, 2009 at 4:15 AM, Pierre Rineau > > wrote: > > Hi folks, > > > > I made a really, really simple module (3 lines and a JS file). > > > > It uses the "title" HTML attribute on text and textarea HTML > > inputs to > > display an empty value in the input, which disappear on focus, > > and > > re-appear on focus out if input is still empty. > > > > This is simple, I saw something like 10 or 20 different JS > > implementations; I choosed one of them, (one I saw on > > Drupal.org's > > forums), adapted it a bit the JS file to be more coherent with > > Drupal6. > > > > The real module just does a "drupal_add_js()" in hook_init() > > (which > > should be compatible with aggressive caching). > > > > Do you think this is a good idea to commit it in the Drupal > > CVS, as a > > new project? > > > > Or do you known some modules which already does the same > > thing, in a > > better way? > > > > Regards, > > Pierre. > > > > > > > > > > -- > > Khalid M. Baheyeldin > > 2bits.com, Inc. > > http://2bits.com > > Drupal optimization, development, customization and consulting. > > Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra > > Simplicity is the ultimate sophistication. -- Leonardo da Vinci > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sivaji2009 at gmail.com Thu Apr 30 19:08:53 2009 From: sivaji2009 at gmail.com (sivaji j.g) Date: Fri, 1 May 2009 00:38:53 +0530 Subject: [development] node_delete on module specific node In-Reply-To: <2E1AA8C9-5A31-4C4F-A0DA-9C44AEDB128C@artofmultimedia.com.au> References: <49F77147.9060500@cwgordon.com> <70fbbb000904281907u1847f471yd0f105d8265108c9@mail.gmail.com> <4F4E4BCF-F2D3-49D3-98BF-638DE75F4053@mikeyp.net> <70fbbb000904281944g6e0f5a75gacde01aa6566360@mail.gmail.com> <9ea8d6030904282012o3b854f32rdc6937b891e28ec7@mail.gmail.com> <841684fe0904282040m47e881fdkdfb257f28ee58dd6@mail.gmail.com> <2E1AA8C9-5A31-4C4F-A0DA-9C44AEDB128C@artofmultimedia.com.au> Message-ID: On Wed, Apr 29, 2009 at 10:29 AM, Nik Derewianka wrote: >> "Warning: there are currently @count %type posts on your >> site. They may not be able to be displayed or edited correctly, once >> you have removed this content type." >> >> So I guess modules doing the same thing on uninstall is a good practice. > > Could also be helpful to have a link in that message to admin/content/node > with the type= filter set so that they can > easily review the impact/scope of their change. Thanks we like to go with this idea, *no* node_delete on uninstall :P -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/ From pierre.rineau at makina-corpus.com Thu Apr 30 20:02:19 2009 From: pierre.rineau at makina-corpus.com (Pierre Rineau) Date: Thu, 30 Apr 2009 22:02:19 +0200 Subject: [development] Custom module, do you think I should add it to cvs.drupal.org ? In-Reply-To: <27ad04850904300916r67d6ae53p35c73f1b32b978a@mail.gmail.com> References: <1241079331.6217.7.camel@guinevere.makina-nantes.net> <4a9fdc630904300729p13bd89fcp184803d41544c37e@mail.gmail.com> <1241104622.6217.14.camel@guinevere.makina-nantes.net> <27ad04850904300916r67d6ae53p35c73f1b32b978a@mail.gmail.com> Message-ID: <1241121739.2153.9.camel@blaster> In fact, empty text in form inputs is a really common feature! But it won't be useful if there is no advertisement and if no people use it. In my company, for each project, we have to write manually the snippet, maybe for other people it wont help, but here, we are really going to use it. What I'm really looking for commiting it, is the community to help to get some more cool features and more configurability around this stuff. If anyone seems interested to help me evolving such module, tell me, and I will commit it, else I won't. Pierre. On Thu, 2009-04-30 at 12:16 -0400, David Rothstein wrote: > I disagree. I don't think the initial number of lines of code is a > good indicator of anything (and also, it's not just 3 lines in this > case, but rather 3 lines plus an entire file, right?). In my opinion, > a better measure is whether or not the code is written in a way that > is generically useful. If it can be meaningfully used by a variety of > sites without them needing to edit the code, then posting it as a > module makes sense. Modules are accessible to a much broader audience > than PHP snippets are. > > However, in this case, if I understand the description correctly, it > sounds like it might have a lot in common with an existing project > (http://drupal.org/project/compact_forms)? If so, then you should > contribute your work to that project rather than starting a new one. > > Good luck! > David Rothstein > > > On Thu, Apr 30, 2009 at 11:17 AM, Pierre Rineau > wrote: > Ok, so I won't. > > Thanks for your answer. > > Le jeudi 30 avril 2009 ? 10:29 -0400, Khalid Baheyeldin a > ?crit : > > > No. A 3 line module is not worth its own project and issue > queue and > > such. > > > > This module is best posted in the snippets here > > http://drupal.org/node/23220 > > > > See also here > http://drupal.org/handbook/customization/php-snippets > > > > On Thu, Apr 30, 2009 at 4:15 AM, Pierre Rineau > > wrote: > > Hi folks, > > > > I made a really, really simple module (3 lines and a > JS file). > > > > It uses the "title" HTML attribute on text and > textarea HTML > > inputs to > > display an empty value in the input, which disappear > on focus, > > and > > re-appear on focus out if input is still empty. > > > > This is simple, I saw something like 10 or 20 > different JS > > implementations; I choosed one of them, (one I saw > on > > Drupal.org's > > forums), adapted it a bit the JS file to be more > coherent with > > Drupal6. > > > > The real module just does a "drupal_add_js()" in > hook_init() > > (which > > should be compatible with aggressive caching). > > > > Do you think this is a good idea to commit it in the > Drupal > > CVS, as a > > new project? > > > > Or do you known some modules which already does the > same > > thing, in a > > better way? > > > > Regards, > > Pierre. > > > > > > > > > > -- > > Khalid M. Baheyeldin > > 2bits.com, Inc. > > http://2bits.com > > Drupal optimization, development, customization and > consulting. > > Simplicity is prerequisite for reliability. -- Edsger > W.Dijkstra > > Simplicity is the ultimate sophistication. -- Leonardo da > Vinci > > > From news at unleashedmind.com Thu Apr 30 20:15:21 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Thu, 30 Apr 2009 22:15:21 +0200 Subject: [development] Custom module, do you think I should add it to cvs.drupal.org ? In-Reply-To: <1241121739.2153.9.camel@blaster> Message-ID: <088e01c9c9d0$63ee6c40$0200a8c0@structworks.com> I'll happily review your patches for http://drupal.org/project/compact_forms sun > -----Original Message----- > From: development-bounces at drupal.org > [mailto:development-bounces at drupal.org] On Behalf Of Pierre Rineau > Sent: Thursday, April 30, 2009 10:02 PM > To: development at drupal.org > Subject: Re: [development] Custom module, do you think I > should add it to cvs.drupal.org ? > > In fact, empty text in form inputs is a really common > feature! But it won't be useful if there is no advertisement > and if no people use it. > > In my company, for each project, we have to write manually > the snippet, maybe for other people it wont help, but here, > we are really going to use it. > > What I'm really looking for commiting it, is the community to > help to get some more cool features and more configurability > around this stuff. > > If anyone seems interested to help me evolving such module, > tell me, and I will commit it, else I won't. > > Pierre. > From pierre.rineau at makina-corpus.com Thu Apr 30 20:32:32 2009 From: pierre.rineau at makina-corpus.com (Pierre Rineau) Date: Thu, 30 Apr 2009 22:32:32 +0200 Subject: [development] Custom module, do you think I should add it to cvs.drupal.org ? In-Reply-To: <088e01c9c9d0$63ee6c40$0200a8c0@structworks.com> References: <088e01c9c9d0$63ee6c40$0200a8c0@structworks.com> Message-ID: <1241123552.2153.10.camel@blaster> Nice! I did not found it because I was looking for D6 module. If you don't have a working D6 version and you want a port, private mail me, I'll do it. Thanks. On Thu, 2009-04-30 at 22:15 +0200, Daniel F. Kudwien wrote: > I'll happily review your patches for http://drupal.org/project/compact_forms > > sun > > > -----Original Message----- > > From: development-bounces at drupal.org > > [mailto:development-bounces at drupal.org] On Behalf Of Pierre Rineau > > Sent: Thursday, April 30, 2009 10:02 PM > > To: development at drupal.org > > Subject: Re: [development] Custom module, do you think I > > should add it to cvs.drupal.org ? > > > > In fact, empty text in form inputs is a really common > > feature! But it won't be useful if there is no advertisement > > and if no people use it. > > > > In my company, for each project, we have to write manually > > the snippet, maybe for other people it wont help, but here, > > we are really going to use it. > > > > What I'm really looking for commiting it, is the community to > > help to get some more cool features and more configurability > > around this stuff. > > > > If anyone seems interested to help me evolving such module, > > tell me, and I will commit it, else I won't. > > > > Pierre. > > > From andrewberry at sentex.net Thu Apr 30 20:37:38 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Thu, 30 Apr 2009 16:37:38 -0400 Subject: [development] Custom module, do you think I should add it to cvs.drupal.org ? In-Reply-To: <1241123552.2153.10.camel@blaster> References: <088e01c9c9d0$63ee6c40$0200a8c0@structworks.com> <1241123552.2153.10.camel@blaster> Message-ID: On 30-Apr-09, at 4:32 PM, Pierre Rineau wrote: > Nice! I did not found it because I was looking for D6 module. If you > don't have a working D6 version and you want a port, private mail me, > I'll do it. http://drupal.org/node/243952 This is great, yet another case where my custom code can be eliminated :) --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available URL: