From metzlerd at metzlerd.com  Sat Nov  1 03:55:45 2008
From: metzlerd at metzlerd.com (David Metzler)
Date: Fri, 31 Oct 2008 20:55:45 -0700
Subject: [development] The static $perm variable in user_access reset
	erroneously
In-Reply-To: <11608131.23371225478321991.JavaMail.root@zimbra.thefiengroup.com>
References: <11608131.23371225478321991.JavaMail.root@zimbra.thefiengroup.com>
Message-ID: <83F0D76B-A453-4B3A-BC4C-60816D0A6B08@metzlerd.com>

I downloaded and looked at the code for user_access and I have one  
idea.  I've had some problem intializing static structures to arrays  
or objects in certain versions of php.  Try changing the definition  
of $perm as follows:

static $perm = '';
if (!$perm) $perm = array();

See if that changes the caching behavior in your php rev.

Dave


On Oct 31, 2008, at 11:38 AM, Ron Parker wrote:

> On Fri, Oct 31, 2008 at 12:27 AM, David Metzler  
> <metzlerd at metzlerd.com>wrote:
>
> > It sounds like you're suggesting that $perm, a static variable  
> within
> > user_access() is being modified without user_access being called,  
> but within
> > a single page load.   That doesn't seem possible in PHP, unless  
> there is a
> > PHP bug.  Static variables are supposed to be local in scope to the
> > functions that create them. To prove beyond a shadow of doubt,  
> put a $debug
> > statement in at the very beginning of the function user_access  
> and another
> > at the very end of the function.  (just before the return).  If  
> what you're
>
> This is exactly what I'm suggesting.  I put debug statements in  
> user_access, node_content_access, and my OGUR function so that I  
> would see every time they were accessed, and what was in them.
>
> To briefly summarize, I have a role "GroupAdmin" which is  
> dynamically added to the $user object.  It contains the "create  
> story content" permission.
>
> I issue the command to clear the $perm cache: user_access 
> ('ClearCache', NULL, TRUE)
>
> This is followed by a module_invoke command (which, in turn will  
> again call user_access):
> module_invoke('node_content', 'access', 'create', 'story', $user)
>
> The problem is that the $perm variable in the second user_access  
> call should contain the values from the first user_access call, and  
> it doesn't.  It is still set, as it should be, but the variables  
> are different.  Here are the results of my debugging:
>
> I noticed that even when my hook_init() clears the $perm variable:
> user_access('', NULL, TRUE)
> ogur roles loaded into user object (hook_init)
> user_access | string =
> user_access | static $perm is NOT already set
> user_access | $perm set for uid 3 (test01)
> user_access | string = | $perm values =  
> 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4
> user_access | roles returned: (authenticated user,Devel,Group  
> Member,Group Contributor,Group Admin)
> user_access | permissions returned: (access comments,access  
> content,view uploaded files,view advanced help index,view advanced  
> help popup,view advanced help topic,post comments,post comments  
> without approval,search content,use advanced search,subscribe to  
> newsletters,view links in block,create page content,create story  
> content,delete own page content,delete own story content,edit own  
> page content,edit own story content,upload files,configure member  
> roles,access devel information,display source code,execute php  
> code,switch users,view devel_node_access information)
> The very next call to user_access does NOT contain the correct  
> permissions:
> user_access('access content')
> user_access | string = access content | $perm values =  
> 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4 (note that all the permmissions  
> from above are NOT here - the only ones missing are those granted  
> by the dynamically assigned roles)
> user_access | static $perm is already set
> user_access | roles returned: (authenticated user,Devel,Group  
> Member,Group Contributor,Group Admin)
> user_access | permissions returned: (view advanced help index,view  
> advanced help popup,view advanced help topic,access comments,post  
> comments,post comments without approval,access content,search  
> content,use advanced search,subscribe to newsletters,view links in  
> block,access devel information,display source code,execute php  
> code,switch users,view devel_node_access information)
> Another test:
>
> This is the page loaded:
>
> http://mysite.com/node/ognodeadd?type=story&gids[]=24
>
> User should be able to create story. This is what debug returns:
> ogur roles loaded into user object (ognodeadd)
> ogur | ognodeadd roles returned: (authenticated user,Devel,Group  
> Member,Group Contributor,Group Admin)  These are the correct roles  
> for this user in this group.
> ogur | module to call = node_content | type = story
> ogur | Preparing to call module_invoke
> ogur | Calling user_access('ClearCache', NULL, TRUE)
> user_access | string = ClearCache
> user_access | static $perm is NOT already set
> user_access | $perm set for uid 3 (test01)
> user_access | string = ClearCache | $perm values =  
> 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4
> user_access | roles returned: (authenticated user,Devel,Group  
> Member,Group Contributor,Group Admin)  This is correct.
> user_access | permissions returned: (access comments,access  
> content,view uploaded files,view advanced help index,view advanced  
> help popup,view advanced help topic,post comments,post comments  
> without approval,search content,use advanced search,subscribe to  
> newsletters,view links in block,create page content,create story  
> content,delete own page content,delete own story content,edit own  
> page content,edit own story content,upload files,configure member  
> roles,access devel information,display source code,execute php  
> code,switch users,view devel_node_access information)
>
> The above are the permissions that $perm should have the next time  
> user_access is ran.  It will run again when module_invoke() is  
> called. Below is what comes back the very next time user_access is  
> called.
> ogur | Calling module_invoke('node_content', 'access', 'create',  
> 'story', $user)
> node_content_access | type = story | op = create
> node_content_access | roles returned: (authenticated  
> user,Devel,Group Member,Group Contributor,Group Admin)
> user_access | string = create story content | $perm values =  
> 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4
> user_access | static $perm is already set
> user_access | roles returned: (authenticated user,Devel,Group  
> Member,Group Contributor,Group Admin) This is correct.
> user_access | permissions returned: (view advanced help index,view  
> advanced help popup,view advanced help topic,access comments,post  
> comments,post comments without approval,access content,search  
> content,use advanced search,subscribe to newsletters,view links in  
> block,access devel information,display source code,execute php  
> code,switch users,view devel_node_access information)
> Note that the "Group Admin" role permissions are not included here.  
> They should be the same as from from the ClearCache user_access  
> command above. It appears that the above permissions have been  
> cached somewhere else.
> ogur | module_invoke called
> ogur | ognodeadd roles returned: (authenticated user,Devel,Group  
> Member,Group Contributor,Group Admin)
> ogur | module_invoke access returns false
> Access should be true here.
> Installed devel module.  There are four user_access SQL queries  
> that appear on this page:
> 1.16	1	user_access	SELECT p.perm FROM role r INNER JOIN permission  
> p ON p.rid = r.rid WHERE r.rid IN (2,8)
> 0.77	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
> 0.76	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
> 0.72	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
>
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081031/c22756a9/attachment-0001.htm 

From metzlerd at metzlerd.com  Sat Nov  1 04:27:05 2008
From: metzlerd at metzlerd.com (David Metzler)
Date: Fri, 31 Oct 2008 21:27:05 -0700
Subject: [development] The static $perm variable in user_access reset
	erroneously
In-Reply-To: <83F0D76B-A453-4B3A-BC4C-60816D0A6B08@metzlerd.com>
References: <11608131.23371225478321991.JavaMail.root@zimbra.thefiengroup.com>
	<83F0D76B-A453-4B3A-BC4C-60816D0A6B08@metzlerd.com>
Message-ID: <53886F1B-D0A6-4729-9C17-F3CA8219C05A@metzlerd.com>

Another minor point regarding this debug,  Since you're not dumping  
all of the $perm variable, we don't really know that the user_id is  
the same. What if the user_id was being checked?  (we know which was  
being modified) Would recommend debugging print_r($account,1) and  
print_r($perm,1) after the reset line.


On Oct 31, 2008, at 8:55 PM, David Metzler wrote:

> I downloaded and looked at the code for user_access and I have one  
> idea.  I've had some problem intializing static structures to  
> arrays or objects in certain versions of php.  Try changing the  
> definition of $perm as follows:
>
> static $perm = '';
> if (!$perm) $perm = array();
>
> See if that changes the caching behavior in your php rev.
>
> Dave
>
>
> On Oct 31, 2008, at 11:38 AM, Ron Parker wrote:
>
>> On Fri, Oct 31, 2008 at 12:27 AM, David Metzler  
>> <metzlerd at metzlerd.com>wrote:
>>
>> > It sounds like you're suggesting that $perm, a static variable  
>> within
>> > user_access() is being modified without user_access being  
>> called, but within
>> > a single page load.   That doesn't seem possible in PHP, unless  
>> there is a
>> > PHP bug.  Static variables are supposed to be local in scope to the
>> > functions that create them. To prove beyond a shadow of doubt,  
>> put a $debug
>> > statement in at the very beginning of the function user_access  
>> and another
>> > at the very end of the function.  (just before the return).  If  
>> what you're
>>
>> This is exactly what I'm suggesting.  I put debug statements in  
>> user_access, node_content_access, and my OGUR function so that I  
>> would see every time they were accessed, and what was in them.
>>
>> To briefly summarize, I have a role "GroupAdmin" which is  
>> dynamically added to the $user object.  It contains the "create  
>> story content" permission.
>>
>> I issue the command to clear the $perm cache: user_access 
>> ('ClearCache', NULL, TRUE)
>>
>> This is followed by a module_invoke command (which, in turn will  
>> again call user_access):
>> module_invoke('node_content', 'access', 'create', 'story', $user)
>>
>> The problem is that the $perm variable in the second user_access  
>> call should contain the values from the first user_access call,  
>> and it doesn't.  It is still set, as it should be, but the  
>> variables are different.  Here are the results of my debugging:
>>
>> I noticed that even when my hook_init() clears the $perm variable:
>> user_access('', NULL, TRUE)
>> ogur roles loaded into user object (hook_init)
>> user_access | string =
>> user_access | static $perm is NOT already set
>> user_access | $perm set for uid 3 (test01)
>> user_access | string = | $perm values =  
>> 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4
>> user_access | roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)
>> user_access | permissions returned: (access comments,access  
>> content,view uploaded files,view advanced help index,view advanced  
>> help popup,view advanced help topic,post comments,post comments  
>> without approval,search content,use advanced search,subscribe to  
>> newsletters,view links in block,create page content,create story  
>> content,delete own page content,delete own story content,edit own  
>> page content,edit own story content,upload files,configure member  
>> roles,access devel information,display source code,execute php  
>> code,switch users,view devel_node_access information)
>> The very next call to user_access does NOT contain the correct  
>> permissions:
>> user_access('access content')
>> user_access | string = access content | $perm values =  
>> 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4 (note that all the permmissions  
>> from above are NOT here - the only ones missing are those granted  
>> by the dynamically assigned roles)
>> user_access | static $perm is already set
>> user_access | roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)
>> user_access | permissions returned: (view advanced help index,view  
>> advanced help popup,view advanced help topic,access comments,post  
>> comments,post comments without approval,access content,search  
>> content,use advanced search,subscribe to newsletters,view links in  
>> block,access devel information,display source code,execute php  
>> code,switch users,view devel_node_access information)
>> Another test:
>>
>> This is the page loaded:
>>
>> http://mysite.com/node/ognodeadd?type=story&gids[]=24
>>
>> User should be able to create story. This is what debug returns:
>> ogur roles loaded into user object (ognodeadd)
>> ogur | ognodeadd roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)  These are the correct roles  
>> for this user in this group.
>> ogur | module to call = node_content | type = story
>> ogur | Preparing to call module_invoke
>> ogur | Calling user_access('ClearCache', NULL, TRUE)
>> user_access | string = ClearCache
>> user_access | static $perm is NOT already set
>> user_access | $perm set for uid 3 (test01)
>> user_access | string = ClearCache | $perm values =  
>> 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4
>> user_access | roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)  This is correct.
>> user_access | permissions returned: (access comments,access  
>> content,view uploaded files,view advanced help index,view advanced  
>> help popup,view advanced help topic,post comments,post comments  
>> without approval,search content,use advanced search,subscribe to  
>> newsletters,view links in block,create page content,create story  
>> content,delete own page content,delete own story content,edit own  
>> page content,edit own story content,upload files,configure member  
>> roles,access devel information,display source code,execute php  
>> code,switch users,view devel_node_access information)
>>
>> The above are the permissions that $perm should have the next time  
>> user_access is ran.  It will run again when module_invoke() is  
>> called. Below is what comes back the very next time user_access is  
>> called.
>> ogur | Calling module_invoke('node_content', 'access', 'create',  
>> 'story', $user)
>> node_content_access | type = story | op = create
>> node_content_access | roles returned: (authenticated  
>> user,Devel,Group Member,Group Contributor,Group Admin)
>> user_access | string = create story content | $perm values =  
>> 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4
>> user_access | static $perm is already set
>> user_access | roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin) This is correct.
>> user_access | permissions returned: (view advanced help index,view  
>> advanced help popup,view advanced help topic,access comments,post  
>> comments,post comments without approval,access content,search  
>> content,use advanced search,subscribe to newsletters,view links in  
>> block,access devel information,display source code,execute php  
>> code,switch users,view devel_node_access information)
>> Note that the "Group Admin" role permissions are not included  
>> here. They should be the same as from from the ClearCache  
>> user_access command above. It appears that the above permissions  
>> have been cached somewhere else.
>> ogur | module_invoke called
>> ogur | ognodeadd roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)
>> ogur | module_invoke access returns false
>> Access should be true here.
>> Installed devel module.  There are four user_access SQL queries  
>> that appear on this page:
>> 1.16	1	user_access	SELECT p.perm FROM role r INNER JOIN permission  
>> p ON p.rid = r.rid WHERE r.rid IN (2,8)
>> 0.77	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
>> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
>> 0.76	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
>> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
>> 0.72	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
>> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
>>
>>
>>
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081031/622a5af2/attachment.htm 

From crystalcube at yahoo.com  Sat Nov  1 09:28:27 2008
From: crystalcube at yahoo.com (Vivek Puri)
Date: Sat, 1 Nov 2008 02:28:27 -0700 (PDT)
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
Message-ID: <743096.84735.qm@web65711.mail.ac4.yahoo.com>

voting will not solve the problem , popularity factor is already one of causes of problem. The problem stems from lack of fair way of defining how critical a given issue is. Right now everything to do with D7 currently gets most attention, leaving the bugs in production releases with lack of attention from the community. 

There should be a queue based on a factor which defines fairness something like this ,
 Secuity > known bug/patch > issue
 core > module
 Current Stable version ( 6) > last stable version (5) > development version (7)

Of course there is also a need for some kind of accountability as why a patch for a bug in production version has not been committed for x.y.z time period. But we can ignore that ...being an open source project ;) . Currently new release is favored over resolving bugs in current release. 


      

From larry at garfieldtech.com  Sat Nov  1 09:37:55 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Sat, 1 Nov 2008 04:37:55 -0500
Subject: [development] How to post bug reports and patches
In-Reply-To: <1225495316.12554.25.camel@localhost>
References: <200810301400.26316.markus.kalkbrenner@arcor.de>
	<1AE9533B-4E76-415D-8D3B-2CE4782064B0@sidepotsinternational.com>
	<1225495316.12554.25.camel@localhost>
Message-ID: <200811010437.56175.larry@garfieldtech.com>

On Friday 31 October 2008 6:21:55 pm David Sterratt wrote:
> On Thu, 2008-10-30 at 11:07 -0400, Darren Oh wrote:
> > There are four bottlenecks in project maintenance:
> >
> > 1. People who complain outnumber people to read complaints.
> > 2. People who read complaints outnumber people who provide patches.
> > 3. People who provide patches outnumber people who review patches.
> > 4. People who review patches outnumber people who commit patches.
>
> A thought about widening bottleneck #3 that requires no technological
> innovation: Suppose I've submitted a patch that I'm keen to see reviewed
> and committed. Would it be socially acceptable to review two other
> patches (preferably related in some way and of a similar level of
> complexity) and ask the submitters of those patches to review my patch
> in return?
>
> You scratch my patch, I'll scratch yours.
>
> Although there would be no guarantee of my patch being reviewed by the
> other patch submitters, the fact that it might happen would give me more
> motivation to review patches.

Such a thing already happens from time to time informally in IRC, especially 
between active "known" developers.  It would probably be a bit gauche to try 
to do so in the issue queue directly, but "review swapping" via IRC is 
already common and could probably stand to become more so.

The underlying problem I see is that in the case of many many patches, most 
people are simply not qualified to give a decent review.  The amazing work 
that has gone into the automated testing server and simpletest module 
recently has, ironically, removed one of the main places where "random 
members of the crowd" can offer useful feedback; that is, "does this break 
stuff?"  Coding style reviews most people can do if they're picky enough (and 
if you're not, then you should be), but substantive reviews of non-trivial 
patches requires a knowledge of the system being modified, whether it's a bug 
or a feature request.  That's why the few people who seem to be able to 
intelligently review patches all over the system (and have time to do so) are 
worth their weight in gold.

I've actually felt for some time that Drupal has reached a size and complexity 
where we need a more tiered maintainer system.  Right now, Dries and Angie 
are the maintainers for D7, and based on the length of the recent-commit 
log[1] are doing a bang-up job.  However, they keep saying that what we need 
is to not send stuff to them until it's *really* ready, vis, RTBC should be 
rock solid and not require effort on their part anymore.  There is no one 
besides them, really, who is in a position to say when something really 
is "ready to be committed".

That's where most projects bring in subsystem maintainers.

As database system maintainer for D7, I read and respond to almost every issue 
that comes through the DB component queue.  I've also spent time with Angie 
trying to work out a good way to optimize the workflow from me to her, so 
that patches that get past me bubble up to her quickly, she knows they're 
ready, she knows where we need feedback before we can continue, etc.  I think 
we've got a decent system, but I'm sure it could be improved.  The result, 
though, is that the pace at which work is getting done in the DB layer is 
improving.

We need that for the rest of core, too.

Now, I'm not saying that to in any way malign the other people listed in 
MAINTAINERS.txt.  I am saying that there are far too people in 
MAINTAINERS.txt.  Right now, there's 12 entries in MAINTAINERS.txt[2], and 
some are the same people repeated multiple times.  There are 60 
separate "components" listed for Drupal, most of them specific modules or 
subsystems.  That leaves (oh I hate arithmetic) 48 sub-pieces of core that 
fall under the "The rest: Dries Buytaert", that is, left to random passers by 
to not just review but also keep consistent and uncrufty.  Not all of those 
components needs a dedicated person just for that piece, of course, but right 
now there's simply far too many people taking "ownership" over parts of core, 
in any version.  Hell, I can't even find someone to take ownership of the 
Postgres driver. :-)

As an extreme example, Linus Torvalds almost never reviews individual patches 
anymore.  The subsystem maintainers maintain their pieces, and then send 
rollups to Linus that he reviews en masse and/or accepts that the subsystem 
maintainer knows what he's doing and just commits it.  Of course, Linux has 
an order (or two) of magnitude more code than Drupal and they're also using a 
distributed VCS that is designed for that workflow (and no, I am NOT trying 
to bring that debate up again so don't even start), but it is a datapoint we 
should consider.

So the question then becomes how do we get more people willing to long-term 
adopt parts of core and actively maintain it, to the point that the core 
committers work mostly with the subsystem maintainers who in turn work with 
the issue queue for their part of core?  How do we streamline that process, 
*and* attract the people who can handle that job?

I don't have an answer for those questions yet (if I did, we'd have a Postgres 
maintainer by now), but I do believe those are the important questions to be 
asking.

[1] http://drupal.org/project/issues?projects=3060&states=2
[2] http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=markup

-- 
Larry Garfield
larry at garfieldtech.com

From mail at webthatworks.it  Sat Nov  1 10:04:30 2008
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Sat, 1 Nov 2008 11:04:30 +0100
Subject: [development] How to post bug reports and patches
In-Reply-To: <490B2603.7050100@webchick.net>
References: <200810301400.26316.markus.kalkbrenner@arcor.de>
	<F3D50D71-74CD-43AF-8307-A3E140D9EBF8@sidepotsinternational.com>
	<593475f90810310510w228803berc6c0ba391cd064@mail.gmail.com>
	<490B2603.7050100@webchick.net>
Message-ID: <20081101110430.5f77c269@dawn.webthatworks.it>

On Fri, 31 Oct 2008 11:36:35 -0400
Angela Byron <drupal-devel at webchick.net> wrote:

> If you have better ideas on how to manage the process more
> efficiently, obviously we'd love to hear them.

Does anyone has some numbers about reviewers, maintainers and
"patchers" behaviour?

- Do most people prefer to submit/review patches to stable
versions rather than development version?

- Do maintainer respond quicker to patches submitted for the
development version?

- What is the average number of patches/review for each developer?

I'm going to assume that:
1) proposed patches to stable are more than development
2) patchers are much more than reviewer
3) patches to development are committed faster

Am I right?

I think:
1) happens because people find easier to "live" on a stable release
and they are writing a patch for a reasonably static code base that
won't make their patch obsolete easily. And there is no chance that
less than 20 maintainers can keep up with all the proposed patches
before a new UNSTABLE hits the street.
BTW I take this chances to say UNSTABLE releases are a very welcome
addition. Thanks!!!

2) happens because a) it's more fun to write code than reviewing it
b) it takes more responsibility to say "it works" than "it works for
me".

3) It takes less responsibility to commit to a development version
and... it is more fun. After all if you're a maintainer what's the
fun of taking the responsibility of applying a patch to a problem
that: is a feature but expose you to the risk of breaking something
or is a fix to a bug you didn't experience?

While a development version will always have its drawback maybe
making easier to build up a development/testing environment and
letting people understand where the "steering committee" and the
development is going would help increasing the numbers of people
getting involved in the new releases.
A more detailed guide on "how to put up your testing environment for
Drupal development" would help. That should take into account that
development version is a moving target and suggest how to cope with
it. I think learning how to cope with Drupal development branch is
particularly important for a project like Drupal since it is used to
make "great leap forward". That includes how to get information on
what's going on. That's a place where DVCS may help...

Reviewers live in limbo.
Their work is important but there is no filter and there is no
credit. Everybody can be a reviewer.
In spite of increasing the number of reviewers I'd decrease them but
give them more trust, credit and power.
Patch queues frequently becomes very long democratic discussions...
but very long... maybe there are too few BDFL.
A voting system or just counting how many people are subscribed to
an issue may give an idea to reviewers what are the hottest issues.
I'd say that counting how many people are subscribed to an issue is
a better thermometer. If you don't even want to be informed about
what's going on for an issue I wouldn't say you're really interested.

Somehow if the responsibility to commit to a stable version would be
more shared across trustworthy credited people, maintainers may
commit more frequently to stable.

I think the project is missing "middle management". "Middle
management" will also increase feedback to patcher. Even if their
patch won't reach core at least there will be someone more
"authoritative" explaining why.

Ups this post was waiting in my draft queue... but it looks as a bad
copy of what Larry just wrote...

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it


From catch56 at googlemail.com  Sat Nov  1 11:27:25 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Sat, 1 Nov 2008 11:27:25 +0000
Subject: [development] How to post bug reports and patches
In-Reply-To: <1225495316.12554.25.camel@localhost>
References: <200810301400.26316.markus.kalkbrenner@arcor.de>
	<6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com>
	<200810301518.26766.m.kruisselbrink@student.tue.nl>
	<7FD2DE06-838D-4518-A498-7791F967004A@sidepotsinternational.com>
	<1AE9533B-4E76-415D-8D3B-2CE4782064B0@sidepotsinternational.com>
	<1225495316.12554.25.camel@localhost>
Message-ID: <fa5724270811010427o7319196ftc7be4cc5e34986e1@mail.gmail.com>

On Fri, Oct 31, 2008 at 11:21 PM, David Sterratt > wrote:.


>
>
> A thought about widening bottleneck #3 that requires no technological
> innovation: Suppose I've submitted a patch that I'm keen to see reviewed
> and committed. Would it be socially acceptable to review two other
> patches (preferably related in some way and of a similar level of
> complexity) and ask the submitters of those patches to review my patch
> in return?
>
> You scratch my patch, I'll scratch yours.
>
>
A very large proportion (I wouldn't dare to say how many) of core patches
are reviewed because a handful of us who hang out in irc trade patch reviews
with each other on a regular basis. Sometimes this is a straight trade, more
generally there's a handful of people who can be relied upon for decent
reviews of core patches they might not have a personal interest in, and
those people tend to get their patches reviewed faster too based on
reputation (although our patches can still sit in the queue for weeks and
weeks like anyone else's, that's how bad it is). If this sounds a bit
cliquey, then that's because it is, but only by necessity. With over 400
issues needing review against Drupal 7 at the moment (and some of those
issues might have 20 individual patches posted on them), it's one of few
available ways to filter - and I say this as someone who's probably reviewed
quite a bit more than 400 patches against Drupal 6 and 7.

If you come into #drupal, and say 'I've got a few minutes spare to review
patches, want to trade?", you'll find many willing and able people.

While reviewing patches doesn't have the same obvious visibility as posting
a new module for example, you'll get copious thanks if you review core
patches, or patches against any of the major contributed modules - because
development on both core and contrib is actively held up, sometimes stalled,
by the lack of reviewers (see Daniel Kudwein's post to this list asking for
reviews of Views 1.x patches - who reading this has used Views? How many
have reviewed any patches in the Views issue queue? How many reading would
like to get attention from one of the Views maintainers next time they have
a support request?). So while it might appear a thankless task, this a
misconception that we need to stamp out. We have more than enough
contributed modules, we have a real shortage of people actively working on
the ones that most people actually use.

In answer to the original poster, while it's already been covered a bit, the
main reason we don't appear to give much attention to the stable Drupal 5
and 6 branches, is because there's a policy of ensuring that bugs are fixed
in  HEAD (Drupal 7) first, then backported. This ensures that bugs fixed in
5 and 6 won't reappear when Drupal 7 is released, that changes made are
consistent between all three branches, and that the bulk of work reviewing
and refining patches can be done where there's the most active development
going on. I'm not sure where this particular policy is documented, so for
now at least, I've updated http://drupal.org/patch/submit to reflect it a
bit.

Having said that, there's still a shortage of people reviewing patches
against Drupal 7, and even more against 5 and 6 - including the ones
backported from 7. One thing which might help with 5/6 would be additional
links to the issue queues from the 'contributors block' - at least
critical/needs review. I don't know about everyone else, but those links are
where I find patches to review unless I'm pointed to them directly, and
patches for 5 and 6 don't show up there.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081101/953c916e/attachment.htm 

From tomi at vacilando.org  Sat Nov  1 12:19:55 2008
From: tomi at vacilando.org (Tomas Fulopp)
Date: Sat, 1 Nov 2008 13:19:55 +0100
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <743096.84735.qm@web65711.mail.ac4.yahoo.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<743096.84735.qm@web65711.mail.ac4.yahoo.com>
Message-ID: <593475f90811010519y5879a03eo6e128ebc2e17a66d@mail.gmail.com>

The on-going debate of pros and cons of issue/post/patch voting or
subscription is largely hypothetical: neither camp has strong proofs they
are right. (It is further clouded by the other part of the patch delay
problem, which is lack of superbly experienced Drupal coders who actually
are able to understand and intelligently review the more complicated
patches.)
But remember the other reason to install at least subscription to individual
issues: we would get rid of all the "+1" and "subscribing" little posts that
plague many threads and make them hardly readable.
If then we had a way of selecting posts with patches sorted by number of
subscribers, we'd be able to see what patches are most sorely needed to be
reviewed and committed. Linking that to the d.o. menu would help a lot, too.

In 6 months we can evaluate whether or not such issue subscription sorting
helped the whole patch stalling situation. I believe it will, but even if it
won't, it will be extremely useful.




On Sat, Nov 1, 2008 at 10:28 AM, Vivek Puri <crystalcube at yahoo.com> wrote:

> voting will not solve the problem , popularity factor is already one of
> causes of problem. The problem stems from lack of fair way of defining how
> critical a given issue is. Right now everything to do with D7 currently gets
> most attention, leaving the bugs in production releases with lack of
> attention from the community.
>
> There should be a queue based on a factor which defines fairness something
> like this ,
>  Secuity > known bug/patch > issue
>  core > module
>  Current Stable version ( 6) > last stable version (5) > development
> version (7)
>
> Of course there is also a need for some kind of accountability as why a
> patch for a bug in production version has not been committed for x.y.z time
> period. But we can ignore that ...being an open source project ;) .
> Currently new release is favored over resolving bugs in current release.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081101/d6a80c67/attachment.htm 

From eric.schaefer at eas-consulting.de  Sat Nov  1 14:40:28 2008
From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer)
Date: Sat, 01 Nov 2008 15:40:28 +0100
Subject: [development] CVS-Messages
Message-ID: <490C6A5C.8090401@eas-consulting.de>

Hi List,

wasn't there a book page about how a cvs message is supposed to look like?

Regards,
Eric

From news at unleashedmind.com  Sat Nov  1 15:10:17 2008
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Sat, 1 Nov 2008 16:10:17 +0100
Subject: [development] CVS-Messages
In-Reply-To: <490C6A5C.8090401@eas-consulting.de>
Message-ID: <08b901c93c33$f36e4aa0$0200a8c0@structworks.com>

http://drupal.org/node/52287 

> -----Original Message-----
> From: development-bounces at drupal.org 
> [mailto:development-bounces at drupal.org] On Behalf Of 
> Eric-Alexander Schaefer
> Sent: Saturday, November 01, 2008 3:40 PM
> To: development at drupal.org
> Subject: [development] CVS-Messages
> 
> Hi List,
> 
> wasn't there a book page about how a cvs message is supposed 
> to look like?
> 
> Regards,
> Eric
> 


From eric.schaefer at eas-consulting.de  Sat Nov  1 17:49:02 2008
From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer)
Date: Sat, 01 Nov 2008 18:49:02 +0100
Subject: [development] module upgrade
Message-ID: <490C968E.6070407@eas-consulting.de>

Hi List,

for some reason the scheduler.module recorded the time for publish and 
unpublish in local time of the user with an additional timezone column 
for translation to utc or whatever. Some time ago I changed it, so that 
it would store the times in utc and removed the timezone column. This 
was done for both 5.x and 6.x. Now when upgrading from a current 5.x 
release to 6.x scheduler_update_6100() gets called and tries to adjust 
already stored times by their respective timezone values and then 
removes the timezone column.

function scheduler_update_6100() {
   $ret[] = update_sql("UPDATE {scheduler} SET 
publish_on=publish_on-timezone WHERE publish_on<>0");
   $ret[] = update_sql("UPDATE {scheduler} SET 
unpublish_on=unpublish_on-timezone WHERE unpublish_on<>0");
   $ret[] = update_sql("ALTER TABLE {scheduler} DROP COLUMN timezone");
   return $ret;
}

Since the timezone column does not exists in current 5.x releases the 
update fails. To avoid it I would check for the existence of the 
timezone column. But: How?

Regards,
Eric

From dmitrig01 at gmail.com  Sat Nov  1 17:51:18 2008
From: dmitrig01 at gmail.com (Dmitri Gaskin)
Date: Sat, 1 Nov 2008 10:51:18 -0700
Subject: [development] module upgrade
In-Reply-To: <490C968E.6070407@eas-consulting.de>
References: <490C968E.6070407@eas-consulting.de>
Message-ID: <BB32F214-C03F-4BE7-BAEF-BB8CA2F5C1D7@gmail.com>

db_field_exists or db_column_exists (can't remember which)

Dmitri

On Nov 1, 2008, at 10:49 AM, Eric-Alexander Schaefer wrote:

> Hi List,
>
> for some reason the scheduler.module recorded the time for publish  
> and unpublish in local time of the user with an additional timezone  
> column for translation to utc or whatever. Some time ago I changed  
> it, so that it would store the times in utc and removed the timezone  
> column. This was done for both 5.x and 6.x. Now when upgrading from  
> a current 5.x release to 6.x scheduler_update_6100() gets called and  
> tries to adjust already stored times by their respective timezone  
> values and then removes the timezone column.
>
> function scheduler_update_6100() {
>  $ret[] = update_sql("UPDATE {scheduler} SET publish_on=publish_on- 
> timezone WHERE publish_on<>0");
>  $ret[] = update_sql("UPDATE {scheduler} SET  
> unpublish_on=unpublish_on-timezone WHERE unpublish_on<>0");
>  $ret[] = update_sql("ALTER TABLE {scheduler} DROP COLUMN timezone");
>  return $ret;
> }
>
> Since the timezone column does not exists in current 5.x releases  
> the update fails. To avoid it I would check for the existence of the  
> timezone column. But: How?
>
> Regards,
> Eric


From mistknight at gmail.com  Mon Nov  3 14:40:40 2008
From: mistknight at gmail.com (Ashraf Amayreh)
Date: Mon, 3 Nov 2008 16:40:40 +0200
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <593475f90811010519y5879a03eo6e128ebc2e17a66d@mail.gmail.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<743096.84735.qm@web65711.mail.ac4.yahoo.com>
	<593475f90811010519y5879a03eo6e128ebc2e17a66d@mail.gmail.com>
Message-ID: <a53d1b3b0811030640v7d1b16a0mbb0845e7e0165aa7@mail.gmail.com>

I kind of remember the solution in priority queues, the problem was
starvation, when an issue just keeps being pushed back indefinitely.

Adding age of issue creation as a factor in the issue exposure should
make sure this problem doesn't happen. After some time even the most
uninteresting issue will eventually float above all others because
it's been there for long.

On Sat, Nov 1, 2008 at 2:19 PM, Tomas Fulopp <tomi at vacilando.org> wrote:
> The on-going debate of pros and cons of issue/post/patch voting or
> subscription is largely hypothetical: neither camp has strong proofs they
> are right. (It is further clouded by the other part of the patch delay
> problem, which is lack of superbly experienced Drupal coders who actually
> are able to understand and intelligently review the more complicated
> patches.)
> But remember the other reason to install at least subscription to individual
> issues: we would get rid of all the "+1" and "subscribing" little posts that
> plague many threads and make them hardly readable.
> If then we had a way of selecting posts with patches sorted by number of
> subscribers, we'd be able to see what patches are most sorely needed to be
> reviewed and committed. Linking that to the d.o. menu would help a lot, too.
> In 6 months we can evaluate whether or not such issue subscription sorting
> helped the whole patch stalling situation. I believe it will, but even if it
> won't, it will be extremely useful.
>
>
>
>
> On Sat, Nov 1, 2008 at 10:28 AM, Vivek Puri <crystalcube at yahoo.com> wrote:
>>
>> voting will not solve the problem , popularity factor is already one of
>> causes of problem. The problem stems from lack of fair way of defining how
>> critical a given issue is. Right now everything to do with D7 currently gets
>> most attention, leaving the bugs in production releases with lack of
>> attention from the community.
>>
>> There should be a queue based on a factor which defines fairness something
>> like this ,
>>  Secuity > known bug/patch > issue
>>  core > module
>>  Current Stable version ( 6) > last stable version (5) > development
>> version (7)
>>
>> Of course there is also a need for some kind of accountability as why a
>> patch for a bug in production version has not been committed for x.y.z time
>> period. But we can ignore that ...being an open source project ;) .
>> Currently new release is favored over resolving bugs in current release.
>>
>
>



-- 
Ashraf Amayreh
http://aamayreh.org

From Kevin.Sookocheff at cbsa-asfc.gc.ca  Mon Nov  3 17:22:33 2008
From: Kevin.Sookocheff at cbsa-asfc.gc.ca (Sookocheff, Kevin)
Date: Mon, 3 Nov 2008 12:22:33 -0500
Subject: [development] Error running SimpleTest on new installation
In-Reply-To: <490B5AC1.8060605@davereid.net>
References: <mailman.14325.1225479934.9743.development@drupal.org>
	<490B5AC1.8060605@davereid.net>
Message-ID: <1B49F1E3B3E5CE4C8CAD37EB15E549AF01108245@SD01ITMP02.PROD.NET>

Hi Dave,

This is not the same scenario that I have encountered.  Your patch does
remove the specific error Undefined index: test_id in
_simpletest_batch_finished().  However, I still receive the message "The
tests did not successfully finish" even though _all_ of the individual
tests are listed as passed.  Some of the tests do not set the input
parameters to _simpletest_batch_finished correctly, even though they
report that they have passed.  To reproduce this, I run SimpleTest on
the BootStrap module and always receive a message saying that all
individual tests have passed but still receive a message "The tests did
not successfully finish".

So far, I haven't been able to find any place where the variable
$success is ever set.  I have filed a bug report about this and will
continue to investigate.


Kevin



-----Original Message-----
From: development-bounces at drupal.org
[mailto:development-bounces at drupal.org] On Behalf Of Dave Reid
Sent: October 31, 2008 2:22 PM
To: development at drupal.org
Subject: Re: [development] Error running SimpleTest on new installation

That SimpleTest error happens when the first test fails. Since the test 
didn't complete, it's test_id does not get saved. If more than one tests

pass, a valid test_id is saved. I have an issue report for this bug at 
http://drupal.org/node/325824*.
*
Dave*
*
> That particular error is usually caused by a bug in one of the unit
tests you ran causing simpletest to hiccup.  I've seen it a couple of
times, and it's sometimes sporadic, unfortunately.  It could be a bug in
simpletest itself.  I've not ruled that out yet.
>
> See if you can narrow it down to a single test that's causing the
problem.  If you can establish a pattern (a particular test, more than X
tests, some particular phase of the moon, etc.) then file a bug report
for the appropriate module (which could be simpletest itself).  If you
need more help narrowing it down, stop by #Drupal on IRC.  Simpletest is
high in the mind of most core devs of late, so there's a good chance
you'll find someone who can give you more detailed help tracking down
the problem.
>
> Thank you for helping make Drupal better!
>
> --Larry Garfield
>
> On Thu, 30 Oct 2008 13:16:11 -0400, "Sookocheff, Kevin"
<Kevin.Sookocheff at cbsa-asfc.gc.ca> wrote:
>   
>> Hello,
>>
>> I had checked out a fresh version of Drupal from CVS this morning and
>> each time I run some SimpleTest test cases I receive the following
>> error:
>>
>> Undefined index: test_id in _simpletest_batch_finished() (line 423 of
>> E:\xampp\htdocs\drupal_test\modules\simpletest\simpletest.module).
>>
>> I am new to Drupal development and want to get started by writing
some
>> tests and reviewing patches.  Does anyone have an idea about fixing
the
>> above problem so that I can get started?
>>
>> Thanks,
>> Kevin

From eric.schaefer at eas-consulting.de  Mon Nov  3 17:35:07 2008
From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer)
Date: Mon, 03 Nov 2008 18:35:07 +0100
Subject: [development] module upgrade
In-Reply-To: <BB32F214-C03F-4BE7-BAEF-BB8CA2F5C1D7@gmail.com>
References: <490C968E.6070407@eas-consulting.de>
	<BB32F214-C03F-4BE7-BAEF-BB8CA2F5C1D7@gmail.com>
Message-ID: <490F364B.9060604@eas-consulting.de>

Dmitri Gaskin schrieb:
> db_field_exists or db_column_exists (can't remember which)

It's db_column_exists().

Thanks,
Eric

From eric.schaefer at eas-consulting.de  Mon Nov  3 17:38:08 2008
From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer)
Date: Mon, 03 Nov 2008 18:38:08 +0100
Subject: [development] CVS-Messages
In-Reply-To: <08b901c93c33$f36e4aa0$0200a8c0@structworks.com>
References: <08b901c93c33$f36e4aa0$0200a8c0@structworks.com>
Message-ID: <490F3700.8060906@eas-consulting.de>

Daniel F. Kudwien schrieb:
> http://drupal.org/node/52287 

That's exactly what I was looking for.

For some reason I did not receive my own mail. Mailman-Hicup?

Thanks,
Eric

From sysop at scbbs.com  Mon Nov  3 19:46:34 2008
From: sysop at scbbs.com (Ron Parker)
Date: Mon, 3 Nov 2008 11:46:34 -0800 (PST)
Subject: [development] The static $perm variable in user_access reset
	erroneously
In-Reply-To: <11395337.24981225741524030.JavaMail.root@zimbra.thefiengroup.com>
Message-ID: <14292028.25001225741594427.JavaMail.root@zimbra.thefiengroup.com>



David Metzler wrote: 




"I downloaded and looked at the code for user_access and I have one 
idea. I've had some problem intializing static structures to arrays 
or objects in certain versions of php. Try changing the definition 
of $perm as follows: 

static $perm = ''; 
if (!$perm) $perm = array(); 

See if that changes the caching behavior in your php rev." 



"Another minor point regarding this debug, Since you're not dumping 
all of the $perm variable, we don't really know that the user_id is 
the same. What if the user_id was being checked? (we know which was 
being modified) Would recommend debugging print_r($account,1) and 
print_r($perm,1) after the reset line. " 


I've added a var_export command to dump the values from both $account and $var . I'm also using the $perm definition suggested above. 




This is the initial call to user_access to flush the $perm variable: 

    ? ogur | module to call = node_content | type = story 
    ? ogur | Preparing to call module_invoke 
    ? ogur | Calling user_access('ClearCache', NULL, TRUE) 
    ? user_access | string = ClearCache 
    ? user_access | static $perm is NOT already set 
    ? user_access | $perm set for uid 3 (test01) 
    ? user_access | string = ClearCache | $perm values = 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4 
    ? user_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) 
    ? user_access | permissions returned (end of function): (access comments,access content,view uploaded files,view advanced help index,view advanced help popup,view advanced help topic,post comments,post comments without approval,search content,use advanced search,subscribe to newsletters,view links in block,create page content,create story content,delete own page content,delete own story content,edit own page content,edit own story content,upload files,configure member roles,access devel information,display source code,execute php code,switch users,view devel_node_access information) 
    ? user_access | $account : class stdClass { var $uid = '3'; var $name = 'test01'; var $pass = ''; var $mail = ''; var $mode = '0'; var $sort = '0'; var $threshold = '0'; var $theme = ''; var $signature = ''; var $created = '1214004001'; var $access = '1225742808'; var $login = '1225218681'; var $status = '1'; var $timezone = NULL; var $language = ''; var $picture = ''; var $init = 'test01 at scbbs.com'; var $data = 'a:3:{s:13:"form_build_id";s:37:"form-828fb54ceb43bf0d467b9dcc20cebfd7";s:21:"og_user_roles_regcode";s:0:"";s:8:"og_email";s:1:"1";}'; var $timezone_id = '0'; var $form_build_id = 'form-828fb54ceb43bf0d467b9dcc20cebfd7'; var $og_user_roles_regcode = ''; var $og_email = '1'; var $roles = array ( 2 => 'authenticated user', 8 => 'Devel', 3 => 'Group Member', 4 => 'Group Contributor', 7 => 'Group Admin', ); var $og_groups = array ( 24 => array ( 'title' => 'USADance LA', 'type' => 'group', 'status' => '1', 'nid' => '24', 'og_role' => '0', 'is_active' => '1', 'is_admin' => '0', 'uid' => '3', 'mail_type' => NULL, 'created' => '1225139825', 'changed' => '1225139825', ), ); } 
    ? user_access | $perm : array ( 3 => array ( 'access comments' => 0, 'access content' => 1, 'view uploaded files' => 2, 'view advanced help index' => 0, 'view advanced help popup' => 1, 'view advanced help topic' => 2, 'post comments' => 4, 'post comments without approval' => 5, 'search content' => 7, 'use advanced search' => 8, 'subscribe to newsletters' => 9, 'view links in block' => 10, 'create page content' => 4, 'create story content' => 5, 'delete own page content' => 6, 'delete own story content' => 7, 'edit own page content' => 8, 'edit own story content' => 9, 'upload files' => 10, 'configure member roles' => 0, 'access devel information' => 0, 'display source code' => 1, 'execute php code' => 2, 'switch users' => 3, 'view devel_node_access information' => 4, ), ) 


This is the next call to user_access should contain the values of $perm from above, but don't. 

    ? ogur | Calling module_invoke('node_content', 'access', 'create', 'story', $user) 
    ? node_content_access | type = story | op = create 
    ? node_content_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) 
    ? user_access | string = create story content 
    ? user_access | static $perm is already set 
    ? user_access | string = create story content | $perm values = 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4 
    ? user_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) 
    ? user_access | permissions returned (end of function): (view advanced help index,view advanced help popup,view advanced help topic,access comments,post comments,post comments without approval,access content,search content,use advanced search,subscribe to newsletters,view links in block,access devel information,display source code,execute php code,switch users,view devel_node_access information) 
    ? user_access | $account : class stdClass { var $uid = '3'; var $name = 'test01'; var $pass = ''; var $mail = ''; var $mode = '0'; var $sort = '0'; var $threshold = '0'; var $theme = ''; var $signature = ''; var $created = '1214004001'; var $access = '1225742808'; var $login = '1225218681'; var $status = '1'; var $timezone = NULL; var $language = ''; var $picture = ''; var $init = 'test01 at scbbs.com'; var $data = 'a:3:{s:13:"form_build_id";s:37:"form-828fb54ceb43bf0d467b9dcc20cebfd7";s:21:"og_user_roles_regcode";s:0:"";s:8:"og_email";s:1:"1";}'; var $timezone_id = '0'; var $form_build_id = 'form-828fb54ceb43bf0d467b9dcc20cebfd7'; var $og_user_roles_regcode = ''; var $og_email = '1'; var $roles = array ( 2 => 'authenticated user', 8 => 'Devel', 3 => 'Group Member', 4 => 'Group Contributor', 7 => 'Group Admin', ); var $og_groups = array ( 24 => array ( 'title' => 'USADance LA', 'type' => 'group', 'status' => '1', 'nid' => '24', 'og_role' => '0', 'is_active' => '1', 'is_admin' => '0', 'uid' => '3', 'mail_type' => NULL, 'created' => '1225139825', 'changed' => '1225139825', ), ); } 
    ? user_access | $perm : array ( 3 => array ( 'view advanced help index' => 0, 'view advanced help popup' => 1, 'view advanced help topic' => 2, 'access comments' => 3, 'post comments' => 4, 'post comments without approval' => 5, 'access content' => 6, 'search content' => 7, 'use advanced search' => 8, 'subscribe to newsletters' => 9, 'view links in block' => 10, 'access devel information' => 0, 'display source code' => 1, 'execute php code' => 2, 'switch users' => 3, 'view devel_node_access information' => 4, ), ) 
    ? ogur | module_invoke called 
    ? ogur | ognodeadd roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) 
    ? ogur | module_invoke access returns false 


Again, this problem only occurs, so far, when I have one of these modules installed along with OGUR: tac_lite, taxonomy_access, menu_breadcrumb and admin_menu . Other modules with which I'm told this problem occurs: 

    ? Content Permissions 
    ? Localization client 

I've searched the code of these modules for some indication of their modifying the $perm variable, but can find none. 

I do really appreciate the help. This is driving me nuts! I can find no logical explanation for this modification, thus I'm unable to figure out a way around it. 

-ron 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081103/511df441/attachment-0001.htm 

From damz at prealable.org  Mon Nov  3 20:27:08 2008
From: damz at prealable.org (Damien Tournoud)
Date: Mon, 3 Nov 2008 21:27:08 +0100
Subject: [development] The static $perm variable in user_access reset
	erroneously
In-Reply-To: <14292028.25001225741594427.JavaMail.root@zimbra.thefiengroup.com>
References: <11395337.24981225741524030.JavaMail.root@zimbra.thefiengroup.com>
	<14292028.25001225741594427.JavaMail.root@zimbra.thefiengroup.com>
Message-ID: <e821df550811031227t9f879d1h2932495f2c009f11@mail.gmail.com>

On Mon, Nov 3, 2008 at 8:46 PM, Ron Parker <sysop at scbbs.com> wrote:

>
> I do really appreciate the help.  This is driving me nuts!  I can find no
> logical explanation for this modification, thus I'm unable to figure out a
> way around it.
>
> -ron
>

This is nothing more than a bug. Please see http://drupal.org/node/329646.

Damien Tournoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081103/dc5bdb6e/attachment.htm 

From markus.kalkbrenner at arcor.de  Mon Nov  3 21:58:28 2008
From: markus.kalkbrenner at arcor.de (Markus Kalkbrenner)
Date: Mon, 3 Nov 2008 22:58:28 +0100
Subject: [development] How to post bug reports and patches
In-Reply-To: <fa5724270811010427o7319196ftc7be4cc5e34986e1@mail.gmail.com>
References: <200810301400.26316.markus.kalkbrenner@arcor.de>
	<1225495316.12554.25.camel@localhost>
	<fa5724270811010427o7319196ftc7be4cc5e34986e1@mail.gmail.com>
Message-ID: <200811032258.28801.markus.kalkbrenner@arcor.de>

On Saturday 01 November 2008 12:27:25 Nathaniel Catchpole wrote:
> In answer to the original poster, while it's already been covered a bit,
> the main reason we don't appear to give much attention to the stable Drupal
> 5 and 6 branches, is because there's a policy of ensuring that bugs are
> fixed in  HEAD (Drupal 7) first, then backported. This ensures that bugs
> fixed in 5 and 6 won't reappear when Drupal 7 is released, that changes
> made are consistent between all three branches, and that the bulk of work
> reviewing and refining patches can be done where there's the most active
> development going on.

Like I already said I'll respect that and I understand the motivation behind 
it.

But there's also a different point of view which you should be aware of (and 
which is not limited to drupal).

Over the years I met a lot of very skilled developers in the companies I 
worked for and I always encouraged them to not just fix bugs of open source 
components they use but to prepare patches and give their improvements back to 
the community.
Every project should be lucky to receive patches from these kind of people 
with years of experience in software development. Especially if they use open 
source components in large scale environments a "normal" developer in an open 
source project probably never has a chance to face. They address issues  
especially in stable versions regarding performance, scalability or 
robustness.
But in commercial projects you're always in a hurry. In such a situation you 
can't expect that someone who's willed to provide a patch reads a lot of 
howtos first, checks out an unstable development version which probably doesn't 
work, learns about all the api changes since the last stable release and 
finally tweaks the patch until it meets a project's style guide or keep it up 
to date until it gets applied.
It's more like fire and forget. And it's up to the project to deal with this 
patch in terms of modifying it to meet the style guide or to find out if it's 
still relevant for the current development branch.

And not everyone who posts a patch is interested to gain personal popularity 
from it. In this case it's not like that a maintainer does a favor to someone 
who provides a patch by accepting it. It's the other way around.

More than once I got feedback that "it's not worth the effort" or that "it 
takes to much time" to give something back to the community which is 
disapointing.
 
Again, please don't get me wrong. I really respect your work and understand 
the problems coming up with such a big community. And I'm absolutely not of 
the opinion that personally I'm a better developer than anybody else here!
I just wanted to share my thoughts and the experiences I made over the years. 
And sometimes it's interesting to get some ideas from someone who's not so 
deeply involved.
But unfortunately I also don't have a perfect solution in place ...

BTW Damien Tournoud turned http://drupal.org/node/298768 from a D6 into a D7 
issue. So sometimes it seems to work ;-)

Markus


From tomi at vacilando.org  Tue Nov  4 11:18:42 2008
From: tomi at vacilando.org (Tomas Fulopp)
Date: Tue, 4 Nov 2008 12:18:42 +0100
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <a53d1b3b0811030640v7d1b16a0mbb0845e7e0165aa7@mail.gmail.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<743096.84735.qm@web65711.mail.ac4.yahoo.com>
	<593475f90811010519y5879a03eo6e128ebc2e17a66d@mail.gmail.com>
	<a53d1b3b0811030640v7d1b16a0mbb0845e7e0165aa7@mail.gmail.com>
Message-ID: <593475f90811040318m82c3942m7bfc304d24c9176e@mail.gmail.com>

I think you've made an excellent point, Ashraf. This really would solve the
problem of "uninteresting" issues getting solved as well. We'd only have to
find a way or relating votes and time. Some kind of rigorous and simple
equation. Any experience/suggestion there?



On Mon, Nov 3, 2008 at 3:40 PM, Ashraf Amayreh <mistknight at gmail.com> wrote:

> I kind of remember the solution in priority queues, the problem was
> starvation, when an issue just keeps being pushed back indefinitely.
>
> Adding age of issue creation as a factor in the issue exposure should
> make sure this problem doesn't happen. After some time even the most
> uninteresting issue will eventually float above all others because
> it's been there for long.
>
> On Sat, Nov 1, 2008 at 2:19 PM, Tomas Fulopp <tomi at vacilando.org> wrote:
> > The on-going debate of pros and cons of issue/post/patch voting or
> > subscription is largely hypothetical: neither camp has strong proofs they
> > are right. (It is further clouded by the other part of the patch delay
> > problem, which is lack of superbly experienced Drupal coders who actually
> > are able to understand and intelligently review the more complicated
> > patches.)
> > But remember the other reason to install at least subscription to
> individual
> > issues: we would get rid of all the "+1" and "subscribing" little posts
> that
> > plague many threads and make them hardly readable.
> > If then we had a way of selecting posts with patches sorted by number of
> > subscribers, we'd be able to see what patches are most sorely needed to
> be
> > reviewed and committed. Linking that to the d.o. menu would help a lot,
> too.
> > In 6 months we can evaluate whether or not such issue subscription
> sorting
> > helped the whole patch stalling situation. I believe it will, but even if
> it
> > won't, it will be extremely useful.
> >
> >
> >
> >
> > On Sat, Nov 1, 2008 at 10:28 AM, Vivek Puri <crystalcube at yahoo.com>
> wrote:
> >>
> >> voting will not solve the problem , popularity factor is already one of
> >> causes of problem. The problem stems from lack of fair way of defining
> how
> >> critical a given issue is. Right now everything to do with D7 currently
> gets
> >> most attention, leaving the bugs in production releases with lack of
> >> attention from the community.
> >>
> >> There should be a queue based on a factor which defines fairness
> something
> >> like this ,
> >>  Secuity > known bug/patch > issue
> >>  core > module
> >>  Current Stable version ( 6) > last stable version (5) > development
> >> version (7)
> >>
> >> Of course there is also a need for some kind of accountability as why a
> >> patch for a bug in production version has not been committed for x.y.z
> time
> >> period. But we can ignore that ...being an open source project ;) .
> >> Currently new release is favored over resolving bugs in current release.
> >>
> >
> >
>
>
>
> --
> Ashraf Amayreh
> http://aamayreh.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/7168f589/attachment.htm 

From darrenoh at sidepotsinternational.com  Tue Nov  4 14:59:13 2008
From: darrenoh at sidepotsinternational.com (Darren Oh)
Date: Tue, 4 Nov 2008 09:59:13 -0500
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <593475f90811040318m82c3942m7bfc304d24c9176e@mail.gmail.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<743096.84735.qm@web65711.mail.ac4.yahoo.com>
	<593475f90811010519y5879a03eo6e128ebc2e17a66d@mail.gmail.com>
	<a53d1b3b0811030640v7d1b16a0mbb0845e7e0165aa7@mail.gmail.com>
	<593475f90811040318m82c3942m7bfc304d24c9176e@mail.gmail.com>
Message-ID: <360E975A-523C-46A5-83E4-F1F056397472@sidepotsinternational.com>

Letting people re-vote after a period of time might be better than an  
automated system. However, the idea of an equation was interesting, so  
I had to come up with one:

(days x M + 1) x votes = weight

M can be tuned to control the effect of time on an issue's weight. An  
M value of zero would mean that time does not affect the weight of an  
issue. Negative values of M would reduce the weight, and positive  
values would increase it.

On Nov 4, 2008, at 6:18 AM, Tomas Fulopp wrote:

> I think you've made an excellent point, Ashraf. This really would  
> solve the problem of "uninteresting" issues getting solved as well.  
> We'd only have to find a way or relating votes and time. Some kind  
> of rigorous and simple equation. Any experience/suggestion there?

From chad at apartmentlines.com  Tue Nov  4 15:01:24 2008
From: chad at apartmentlines.com (Chad Phillips -- Apartment Lines)
Date: Tue, 4 Nov 2008 10:01:24 -0500
Subject: [development] drupal.org scheduled maintenance
In-Reply-To: <mailman.14477.1225743244.9743.development@drupal.org>
References: <mailman.14477.1225743244.9743.development@drupal.org>
Message-ID: <A443F355-1403-4006-844A-001AD6E66D61@apartmentlines.com>

following discussions with killes, i've scheduled a brief maintenance  
window for drupal.org.  Details here:

http://drupal.org/node/329973

From drupal at ryancross.com  Tue Nov  4 15:11:03 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Wed, 5 Nov 2008 02:11:03 +1100
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <360E975A-523C-46A5-83E4-F1F056397472@sidepotsinternational.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<743096.84735.qm@web65711.mail.ac4.yahoo.com>
	<593475f90811010519y5879a03eo6e128ebc2e17a66d@mail.gmail.com>
	<a53d1b3b0811030640v7d1b16a0mbb0845e7e0165aa7@mail.gmail.com>
	<593475f90811040318m82c3942m7bfc304d24c9176e@mail.gmail.com>
	<360E975A-523C-46A5-83E4-F1F056397472@sidepotsinternational.com>
Message-ID: <4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>

On Wed, Nov 5, 2008 at 1:59 AM, Darren Oh <
darrenoh at sidepotsinternational.com> wrote:

> Letting people re-vote after a period of time might be better than an
> automated system. However, the idea of an equation was interesting, so I had
> to come up with one:
>
> (days x M + 1) x votes = weight
>
> M can be tuned to control the effect of time on an issue's weight. An M
> value of zero would mean that time does not affect the weight of an issue.
> Negative values of M would reduce the weight, and positive values would
> increase it.
>
>
I would suggest adding a delay, such that the time doesn't contribute to the
weight until some grace period (for example after the first week). I also
wonder whether "days" should be since reported or since last updated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081105/7d2bb83b/attachment-0001.htm 

From darrenoh at sidepotsinternational.com  Tue Nov  4 15:29:01 2008
From: darrenoh at sidepotsinternational.com (Darren Oh)
Date: Tue, 4 Nov 2008 10:29:01 -0500
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<743096.84735.qm@web65711.mail.ac4.yahoo.com>
	<593475f90811010519y5879a03eo6e128ebc2e17a66d@mail.gmail.com>
	<a53d1b3b0811030640v7d1b16a0mbb0845e7e0165aa7@mail.gmail.com>
	<593475f90811040318m82c3942m7bfc304d24c9176e@mail.gmail.com>
	<360E975A-523C-46A5-83E4-F1F056397472@sidepotsinternational.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
Message-ID: <34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>

On Nov 4, 2008, at 10:11 AM, Ryan Cross wrote:

> On Wed, Nov 5, 2008 at 1:59 AM, Darren Oh <darrenoh at sidepotsinternational.com 
> > wrote:
> Letting people re-vote after a period of time might be better than  
> an automated system. However, the idea of an equation was  
> interesting, so I had to come up with one:
>
> (days x M + 1) x votes = weight
>
> M can be tuned to control the effect of time on an issue's weight.  
> An M value of zero would mean that time does not affect the weight  
> of an issue. Negative values of M would reduce the weight, and  
> positive values would increase it.
>
>
> I would suggest adding a delay, such that the time doesn't  
> contribute to the weight until some grace period (for example after  
> the first week). I also wonder whether "days" should be since  
> reported or since last updated.

The modified equation would be

(M x (days - G) + 1) x votes = weight

where G is the grace period in days. However, the point of voting is  
to give the community a way to promote issues, so I still think  
allowing people to re-vote periodically might be a better solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/f34da8ee/attachment.htm 

From jpetso at gmx.at  Tue Nov  4 16:04:06 2008
From: jpetso at gmx.at (Jakob Petsovits)
Date: Tue, 4 Nov 2008 17:04:06 +0100
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
Message-ID: <200811041704.07618.jpetso@gmx.at>

On Tuesday, 4. November 2008, Darren Oh wrote:
> However, the point of voting is
> to give the community a way to promote issues, so I still think
> allowing people to re-vote periodically might be a better solution.

One possible way to achieve that goal:
Bugzilla (at least in the version used on bugs.kde.org) grants each user a 
limited amount of votes for each project which the user can then assign as 
desired. If the user doesn't have any votes left, she needs to take them back 
from unimportant issues and reassign these votes to the more pressing ones.

Combined with age multipliers, I think this might make for a voting system 
with a reasonable trade-off between popularity and necessity.


From catch56 at googlemail.com  Tue Nov  4 16:17:54 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Tue, 4 Nov 2008 16:17:54 +0000
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <200811041704.07618.jpetso@gmx.at>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
Message-ID: <fa5724270811040817t932f33ah606898607f808691@mail.gmail.com>

On Tue, Nov 4, 2008 at 4:04 PM, Jakob Petsovits  wrote:

>
> One possible way to achieve that goal:
> Bugzilla (at least in the version used on bugs.kde.org) grants each user a
> limited amount of votes for each project which the user can then assign as
> desired. If the user doesn't have any votes left, she needs to take them
> back
> from unimportant issues and reassign these votes to the more pressing ones.
>
> Combined with age multipliers, I think this might make for a voting system
> with a reasonable trade-off between popularity and necessity.
>
>
This has been discussed elsewhere in the project metrics and redesign
groups, and I think it's a good model to follow for this (and project
reviews/voting if we introduce this later on).

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/a14c0bc3/attachment.htm 

From catch56 at googlemail.com  Tue Nov  4 16:47:59 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Tue, 4 Nov 2008 16:47:59 +0000
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <fa5724270811040817t932f33ah606898607f808691@mail.gmail.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
	<fa5724270811040817t932f33ah606898607f808691@mail.gmail.com>
Message-ID: <fa5724270811040847w6601f94cp4dc0f9c0af9ddca5@mail.gmail.com>

Just to make it clear, I think voting with the restriction of one person N
votes is a good idea. I don't think prioritising issues by age is a good
idea at all.

Old issues are usually:
1.Not valid any more
2. Not interesting to many people
3. An absolute pig to fix requiring vast amounts of effort.

And I say this as someone who personally has gone through many hundreds of
old issues trying to sort the good from the bad in the past 18 months, not
just for core, but for views, cck, location and panels.

If you want to find old issues, you can look at any patch queue, and click
on the last link of the pager, and there they'll be.

If we have a sensible voting system, then some old issues will rise to the
top, we don't need an extra 'how old it is' weight to this.

For example, I personally don't care if user's can delete their old accounts
or not, nor do all that many people given the relative number of responses
vs. age for http://drupal.org/node/8 - an average of 14 posts per year.

Nat

On Tue, Nov 4, 2008 at 4:17 PM, Nathaniel Catchpole  wrote:

>
>
> On Tue, Nov 4, 2008 at 4:04 PM, Jakob Petsovits  wrote:
>
>>
>> One possible way to achieve that goal:
>> Bugzilla (at least in the version used on bugs.kde.org) grants each user
>> a
>> limited amount of votes for each project which the user can then assign as
>> desired. If the user doesn't have any votes left, she needs to take them
>> back
>> from unimportant issues and reassign these votes to the more pressing
>> ones.
>>
>> Combined with age multipliers, I think this might make for a voting system
>> with a reasonable trade-off between popularity and necessity.
>>
>>
> This has been discussed elsewhere in the project metrics and redesign
> groups, and I think it's a good model to follow for this (and project
> reviews/voting if we introduce this later on).
>
> Nat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/351e321a/attachment.htm 

From drupal at dwwright.net  Tue Nov  4 16:51:10 2008
From: drupal at dwwright.net (Derek Wright)
Date: Tue, 4 Nov 2008 08:51:10 -0800
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <200811041704.07618.jpetso@gmx.at>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
Message-ID: <BFC7C139-581D-4649-8BFF-79793011DA8A@dwwright.net>


On Nov 4, 2008, at 8:04 AM, Jakob Petsovits wrote:

> Bugzilla (at least in the version used on bugs.kde.org) grants each  
> user a
> limited amount of votes for each project which the user can then  
> assign as
> desired. If the user doesn't have any votes left, she needs to take  
> them back
> from unimportant issues and reassign these votes to the more  
> pressing ones.

That's exactly how project_issue_voting.module already works.

Age modifiers seem like needless complication, and something that's  
bound to make whatever performance concerns we have about running  
this on d.o even worse.  Let's not over-complicate this problem to  
the point of making it infeasible to deploy...

Cheers,
-Derek (dww)




From drupal at dwwright.net  Tue Nov  4 17:00:00 2008
From: drupal at dwwright.net (Derek Wright)
Date: Tue, 4 Nov 2008 09:00:00 -0800
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <fa5724270811040847w6601f94cp4dc0f9c0af9ddca5@mail.gmail.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
	<fa5724270811040817t932f33ah606898607f808691@mail.gmail.com>
	<fa5724270811040847w6601f94cp4dc0f9c0af9ddca5@mail.gmail.com>
Message-ID: <E883B02B-0FD5-4BAE-88FA-504FFD2E1D93@dwwright.net>


On Nov 4, 2008, at 8:47 AM, Nathaniel Catchpole wrote:

> Just to make it clear, I think voting with the restriction of one  
> person N votes is a good idea. I don't think prioritising issues by  
> age is a good idea at all.

Good. ;)

> If you want to find old issues, you can look at any patch queue,  
> and click on the last link of the pager, and there they'll be.

Or click on the little grey arrow next to the "Last updated" column  
header to reverse the sort order.  tablesort_sql(), you know...

Cheers,
-Derek (dww)




From tjfulopp at gmail.com  Tue Nov  4 17:09:07 2008
From: tjfulopp at gmail.com (Tomas Fulopp)
Date: Tue, 4 Nov 2008 18:09:07 +0100
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <BFC7C139-581D-4649-8BFF-79793011DA8A@dwwright.net>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
	<BFC7C139-581D-4649-8BFF-79793011DA8A@dwwright.net>
Message-ID: <593475f90811040909i39fcb056i55ddd7a00becd54d@mail.gmail.com>

I disagree with Derek, Nat (nothing personal, I am sure you know that) and
Bugzilla who prefer the limited vote number system. It introduces the need
for an arbitrary value (how many votes per person is fair?) and discussions
that would stem from it.
Simple accumulative voting on issues (+1 system, one per user per issue) is
a) simpler and therefore more elegant, and even more importantly:
b) people use it intuitively already - they add those cluttering
"Subscribing" messages because they have no other way of doing this. If
limited vote was applied, bumping the issue by saying "Subscribing" would
continue whenever one runs out of votes (even if such messages would not be
counted as votes).

Also, I think that old issues, even if they rise up due to accumulated votes
(or age) can still be easily dismissed if necessary - by saying they need to
be re-done against another version, etc, so I don't think that's a problem.

Important - if age is included somehow as discussed above, it should be age
since last comment in that thread. Means if somebody reacts in some way the
added weight based on time is re-set to zero, which is fair because the
patch contributors need to react on it. Otherwise even useless patches /
issues would keep rising in the queue, despite all critique.

Keep up the good ideas flowing, let's make the best system possible.




On Tue, Nov 4, 2008 at 5:51 PM, Derek Wright <drupal at dwwright.net> wrote:

>
> On Nov 4, 2008, at 8:04 AM, Jakob Petsovits wrote:
>
>  Bugzilla (at least in the version used on bugs.kde.org) grants each user
>> a
>> limited amount of votes for each project which the user can then assign as
>> desired. If the user doesn't have any votes left, she needs to take them
>> back
>> from unimportant issues and reassign these votes to the more pressing
>> ones.
>>
>
> That's exactly how project_issue_voting.module already works.
>
> Age modifiers seem like needless complication, and something that's bound
> to make whatever performance concerns we have about running this on d.o even
> worse.  Let's not over-complicate this problem to the point of making it
> infeasible to deploy...
>
> Cheers,
> -Derek (dww)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/58ffcbbb/attachment-0001.htm 

From drupal at dwwright.net  Tue Nov  4 17:23:44 2008
From: drupal at dwwright.net (Derek Wright)
Date: Tue, 4 Nov 2008 09:23:44 -0800
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <593475f90811040909i39fcb056i55ddd7a00becd54d@mail.gmail.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
	<BFC7C139-581D-4649-8BFF-79793011DA8A@dwwright.net>
	<593475f90811040909i39fcb056i55ddd7a00becd54d@mail.gmail.com>
Message-ID: <590726BC-830C-4812-97CC-99F7888F1254@dwwright.net>


On Nov 4, 2008, at 9:09 AM, Tomas Fulopp wrote:

> Simple accumulative voting on issues (+1 system, one per user per  
> issue) is
> a) simpler and therefore more elegant, and even more importantly:

Not necessarily true.  That's just your opinion.

> b) people use it intuitively already - they add those cluttering  
> "Subscribing" messages because they have no other way of doing  
> this. If limited vote was applied, bumping the issue by saying  
> "Subscribing" would continue whenever one runs out of votes (even  
> if such messages would not be counted as votes).

That's going to happen anyway.  Even if we add a way to subscribe or  
vote on issues without commenting, people will continue to post  
meaningless comments.  This isn't an argument for or against any of  
the proposed changes.

> Keep up the good ideas flowing, let's make the best system possible.

The best system possible is one that people can actually use. ;)  Far  
too many threads about improving d.o in some way die at exactly this  
stage -- endless discussion, no action.  In this case, there's  
already code that exists, was written by members of the security  
team, works, and is ready to deploy.  If we go back to the drawing  
board now for another few months of speculation and bike-shedding  
about "the best system possible", I'll bet $20 that the code never  
materializes and none of it, even the stuff that already works, will  
be used.

I'm not trying to be defeatist or stifle anyone's initiative, but in  
this case, I think it's time to invoke one of Drupal's oldest  
mantras: "Talk is silver, code is gold".  Or something along the  
lines of "let not perfection be the barrier of progress" (or however  
that goes).

How about we get the current thing running and see how it goes for a  
few months, and then have some actual data and experience to use to  
discuss further improvements?  That approach seems to have served the  
"make the handbooks a wiki" experiment well, let's do it again.

Cheers,
-Derek (dww)




From catch56 at googlemail.com  Tue Nov  4 17:30:33 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Tue, 4 Nov 2008 17:30:33 +0000
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <590726BC-830C-4812-97CC-99F7888F1254@dwwright.net>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
	<BFC7C139-581D-4649-8BFF-79793011DA8A@dwwright.net>
	<593475f90811040909i39fcb056i55ddd7a00becd54d@mail.gmail.com>
	<590726BC-830C-4812-97CC-99F7888F1254@dwwright.net>
Message-ID: <fa5724270811040930m1dc88d90u3d8d030b46bb9510@mail.gmail.com>

Derek Wright wrote:

>
> How about we get the current thing running and see how it goes for a few
> months, and then have some actual data and experience to use to discuss
> further improvements?  That approach seems to have served the "make the
> handbooks a wiki" experiment well, let's do it again.
>

Yep, and if we need to increase votes per user, or add some weighting or
something, we'll be much better informed after seeing how it's worked for a
while.

So this begs the question, what remains to do before it gets deployed?


Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/b83be9b4/attachment.htm 

From tjfulopp at gmail.com  Tue Nov  4 17:32:47 2008
From: tjfulopp at gmail.com (Tomas Fulopp)
Date: Tue, 4 Nov 2008 18:32:47 +0100
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <590726BC-830C-4812-97CC-99F7888F1254@dwwright.net>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
	<BFC7C139-581D-4649-8BFF-79793011DA8A@dwwright.net>
	<593475f90811040909i39fcb056i55ddd7a00becd54d@mail.gmail.com>
	<590726BC-830C-4812-97CC-99F7888F1254@dwwright.net>
Message-ID: <593475f90811040932n4c582b36t33b4e26f4acc44eb@mail.gmail.com>

I've weighed my worries.. and the heaviest one is indeed that continued
discussion (though I don't think it's been bike-shedding) will stifle the
action. I admire the body of your work and comments, Derek, so if there are
no better quickly achievable solutions I can agree with your proposal of
going with what we have and improve further later.
How can it be done and when?




On Tue, Nov 4, 2008 at 6:23 PM, Derek Wright <drupal at dwwright.net> wrote:

>
> On Nov 4, 2008, at 9:09 AM, Tomas Fulopp wrote:
>
>  Simple accumulative voting on issues (+1 system, one per user per issue)
>> is
>> a) simpler and therefore more elegant, and even more importantly:
>>
>
> Not necessarily true.  That's just your opinion.
>
>  b) people use it intuitively already - they add those cluttering
>> "Subscribing" messages because they have no other way of doing this. If
>> limited vote was applied, bumping the issue by saying "Subscribing" would
>> continue whenever one runs out of votes (even if such messages would not be
>> counted as votes).
>>
>
> That's going to happen anyway.  Even if we add a way to subscribe or vote
> on issues without commenting, people will continue to post meaningless
> comments.  This isn't an argument for or against any of the proposed
> changes.
>
>  Keep up the good ideas flowing, let's make the best system possible.
>>
>
> The best system possible is one that people can actually use. ;)  Far too
> many threads about improving d.o in some way die at exactly this stage --
> endless discussion, no action.  In this case, there's already code that
> exists, was written by members of the security team, works, and is ready to
> deploy.  If we go back to the drawing board now for another few months of
> speculation and bike-shedding about "the best system possible", I'll bet $20
> that the code never materializes and none of it, even the stuff that already
> works, will be used.
>
> I'm not trying to be defeatist or stifle anyone's initiative, but in this
> case, I think it's time to invoke one of Drupal's oldest mantras: "Talk is
> silver, code is gold".  Or something along the lines of "let not perfection
> be the barrier of progress" (or however that goes).
>
> How about we get the current thing running and see how it goes for a few
> months, and then have some actual data and experience to use to discuss
> further improvements?  That approach seems to have served the "make the
> handbooks a wiki" experiment well, let's do it again.
>
> Cheers,
> -Derek (dww)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/fd72d21b/attachment.htm 

From drupal at dwwright.net  Tue Nov  4 17:46:30 2008
From: drupal at dwwright.net (Derek Wright)
Date: Tue, 4 Nov 2008 09:46:30 -0800
Subject: [development] Voting on issues (was Re: How to post bug reports
	andpatches)
In-Reply-To: <fa5724270811040930m1dc88d90u3d8d030b46bb9510@mail.gmail.com>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>
	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>
	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>
	<200811041704.07618.jpetso@gmx.at>
	<BFC7C139-581D-4649-8BFF-79793011DA8A@dwwright.net>
	<593475f90811040909i39fcb056i55ddd7a00becd54d@mail.gmail.com>
	<590726BC-830C-4812-97CC-99F7888F1254@dwwright.net>
	<fa5724270811040930m1dc88d90u3d8d030b46bb9510@mail.gmail.com>
Message-ID: <3B0DD087-B398-485C-A766-8B1E7D08FD98@dwwright.net>


On Nov 4, 2008, at 9:30 AM, Nathaniel Catchpole wrote:

> So this begs the question, what remains to do before it gets deployed?

I already mentioned it earlier in the thread, but to reiterate:

Get killes and/or Dries to say "yes" in this issue:

http://drupal.org/node/42232

I have no idea what it would take to get them to say that, since to  
date, neither one has commented on the issue with any objections  
(other than when killes reclassified it to the "redesign" component  
without any accompanying text).

/me shrugs

-Derek (dww)




From news at unleashedmind.com  Tue Nov  4 17:50:34 2008
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Tue, 4 Nov 2008 18:50:34 +0100
Subject: [development] Voting on issues (was Re: How to post bug
	reportsandpatches)
In-Reply-To: <E883B02B-0FD5-4BAE-88FA-504FFD2E1D93@dwwright.net>
Message-ID: <004801c93ea5$d69cb550$0200a8c0@structworks.com>

Thought about this some more.

Allowing users to vote on issues is probably good for novice users, who do
not deal with many issues at the same time.  However, for the rest of us,
who work on plenty of issues, it would take a considerable amount of time to
constantly removing votes from closed issues and thinking about where to
place votes next.  Considering this, I would predict that this will be too
much overhead for me.

Furthermore, I would most probably like to see approx. 90% of all issues
resolved, which I follow-up on or (re-)roll patches for.

Long story short: I'd prefer a simple "flag" solution. Just collect flags
(and also re-use them for "subscribing"), count them, and done.  That way,
everyone could flag the issues of interest, without having aforementioned
overhead.  Just a simple flag corresponding to "+1, good issue, me too,
let's get this fixed".

This would also account for the previously mentioned edge-cases:

- Issues languishing in the queue for years are most probably flagged by
*many* users (such as 8 or daylight saving time).

- Same for killer features like DBTNG.

- Same for critical bugs in stable releases like
http://drupal.org/node/311626 or http://drupal.org/node/305653

Also, if users were allowed to place more than one vote on one issue and
each user gets a fixed contingent of votes, the contingent would have to be
per project IMO.  With flags, we would not need such complex logic to allow
a certain amount of votes per project.

Lastly, if we re-use those flags to extend the "My issues" list, we would
finally fix the "subscribing" issue-derailing issue.

Daniel


From gerhard at killesreiter.de  Tue Nov  4 17:53:00 2008
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Tue, 04 Nov 2008 18:53:00 +0100
Subject: [development] Voting on issues (was Re: How to post bug reports
 andpatches)
In-Reply-To: <3B0DD087-B398-485C-A766-8B1E7D08FD98@dwwright.net>
References: <215a89c90810311245m10d86a9ci316e9e4c3c14466a@mail.gmail.com>	<4e983be00811040711y4c6efefco90d90778cf43c000@mail.gmail.com>	<34DD1E9E-023A-4FFC-BD9A-AA035EF205B5@sidepotsinternational.com>	<200811041704.07618.jpetso@gmx.at>	<BFC7C139-581D-4649-8BFF-79793011DA8A@dwwright.net>	<593475f90811040909i39fcb056i55ddd7a00becd54d@mail.gmail.com>	<590726BC-830C-4812-97CC-99F7888F1254@dwwright.net>	<fa5724270811040930m1dc88d90u3d8d030b46bb9510@mail.gmail.com>
	<3B0DD087-B398-485C-A766-8B1E7D08FD98@dwwright.net>
Message-ID: <49108BFC.9070800@killesreiter.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Wright schrieb:
> 
> On Nov 4, 2008, at 9:30 AM, Nathaniel Catchpole wrote:
> 
>> So this begs the question, what remains to do before it gets deployed?
> 
> I already mentioned it earlier in the thread, but to reiterate:
> 
> Get killes and/or Dries to say "yes" in this issue:
> 
> http://drupal.org/node/42232

I am deferring this to Dries, since he's the one who has to work with
the outcome of this.

> I have no idea what it would take to get them to say that, since to
> date, neither one has commented on the issue with any objections (other
> than when killes reclassified it to the "redesign" component without any
> accompanying text).
> 

I was under the impression that we shouldn't complicate the redesign
with adding such things now and rather look at it within the scope of
the redesign.

Cheers,
	Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkQi/wACgkQfg6TFvELooQ/kQCeK1V/q14tIvGdgdA0JWEdHEjU
lGkAniqwEzAX68Ps3kBAfxou++eG8ckt
=+1hg
-----END PGP SIGNATURE-----

From catch56 at googlemail.com  Tue Nov  4 17:56:34 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Tue, 4 Nov 2008 17:56:34 +0000
Subject: [development] Voting on issues (was Re: How to post bug
	reportsandpatches)
In-Reply-To: <004801c93ea5$d69cb550$0200a8c0@structworks.com>
References: <E883B02B-0FD5-4BAE-88FA-504FFD2E1D93@dwwright.net>
	<004801c93ea5$d69cb550$0200a8c0@structworks.com>
Message-ID: <fa5724270811040956j56c90dbh15678b5151a1a2fc@mail.gmail.com>

On Tue, Nov 4, 2008 at 5:50 PM, Daniel F. Kudwien wrote:

> Thought about this some more.
>
> Allowing users to vote on issues is probably good for novice users, who do
> not deal with many issues at the same time.  However, for the rest of us,
> who work on plenty of issues, it would take a considerable amount of time
> to
> constantly removing votes from closed issues and thinking about where to
> place votes next.  Considering this, I would predict that this will be too
> much overhead for me.
> ssue.
>
> Daniel
>
> Personally I'd continue to work on issues pretty much the same as I do now,
and would likely ignore both voting for issues, and the votes on them 99% of
the time. I'd like to see the flag/subscriptions/my issues thing sorted -
but that's a different thing entirely.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/3984cfb0/attachment-0001.htm 

From news at unleashedmind.com  Tue Nov  4 18:18:35 2008
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Tue, 4 Nov 2008 19:18:35 +0100
Subject: [development] Voting on issues (was Re: How to post bug
	reportsandpatches)
In-Reply-To: <590726BC-830C-4812-97CC-99F7888F1254@dwwright.net>
Message-ID: <004c01c93ea9$c0811550$0200a8c0@structworks.com>

> -----Original Message-----
> From: Derek Wright
> Sent: Tuesday, November 04, 2008 6:24 PM
> 
> The best system possible is one that people can actually use. 
> ;)  Far too many threads about improving d.o in some way die 
> at exactly this stage -- endless discussion, no action.  In 
> this case, there's already code that exists, was written by 
> members of the security team, works, and is ready to deploy.  
> If we go back to the drawing board now for another few months 
> of speculation and bike-shedding about "the best system 
> possible", I'll bet $20 that the code never materializes and 
> none of it, even the stuff that already works, will be used.
> 
> I'm not trying to be defeatist or stifle anyone's initiative, 
> but in this case, I think it's time to invoke one of Drupal's oldest
> mantras: "Talk is silver, code is gold".  Or something along 
> the lines of "let not perfection be the barrier of progress" 
> (or however that goes).

Not necessarily true either: http://drupal.org/project/flag

Flag would also open up the possibility to use other flags for different
purposes in the future.  Think handbook pages, flagging comments for
moderation, etc.  It comes with decent Views integration, and is already
available for 6.x, too.

Lastly, if you really want to weigh flags like votes:
http://drupal.org/project/flag_weights

It is possible that a separate glue module might be required to integrate
Flag with project* the same way like Project Issue Voting does.  However,
I'd be up for coding this simple helper, if required.

Daniel


From slc at publicus.net  Tue Nov  4 18:24:16 2008
From: slc at publicus.net (Steven Clift)
Date: Tue, 04 Nov 2008 12:24:16 -0600
Subject: [development] Place, Geotagging
Message-ID: <49109350.1060401@publicus.net>


I am interested in your Drupal developer take on two related ideas:

1. Place - Many of the sites hosted on Drupal are local organizations 
with local content. What do you think of having a standard way Drupal 
(and other open source CMSes) allow sites to assign the geographic place 
name (or perhaps a point) that best represents either where their 
organization is based? How about an automatic map of Drupal sites or 
listings by hierarchical placename? Perhaps a connection to 
http://gaze.mysociety.org would work.

2. GeoTagging - What do you think of defaulting or at least having the 
ability to assign a point, bounded place, or "global" geo-tag in terms 
of the general scope of individual content items created? An option 
changeable near a save/post button.

It seems to me that as long as geotagging is an afterthought, the 
ability to aggregate/navigate much of the newer and dynamic content on 
Drupal hosted sites by geographic relevancy will be quite limited. 
Imagine the power of just a few CMSes adopting a similar way to describe 
the place of sites (which could be "earth" for those who think the 
Internet is best when viewed as narrowly "global") and even more 
granular meta-data on specific content items as a default rather than an 
add-on.

Please also reply to: clift at publicus.net

Steven Clift
http://stevenclift.com

P.S. I am gathering feedback on this idea as part of an exploration 
commissioned by a major U.S. foundation.

From sysop at scbbs.com  Tue Nov  4 18:25:18 2008
From: sysop at scbbs.com (Ron Parker)
Date: Tue, 4 Nov 2008 10:25:18 -0800 (PST)
Subject: [development] The static $perm variable in user_access reset
	erroneously
Message-ID: <24523838.271225823118233.JavaMail.root@zimbra.thefiengroup.com>

Damien Tournoud wrote: 

"This is nothing more than a bug. Please see http://drupal.org/node/329646 ." 

Yes, that's it. Applied the patch and getting expected behaviour now. Thank you! 

-ron 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/7b81e31f/attachment.htm 

From earnie at users.sourceforge.net  Tue Nov  4 18:47:34 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 04 Nov 2008 13:47:34 -0500
Subject: [development] Voting on issues (was Re: How to post
	bug	reportsandpatches)
In-Reply-To: <004c01c93ea9$c0811550$0200a8c0@structworks.com>
References: <004c01c93ea9$c0811550$0200a8c0@structworks.com>
Message-ID: <20081104134734.qrxghdc9e70g0w0g@mail.progw.org>

Quoting "Daniel F. Kudwien" <news at unleashedmind.com>:

>
> Not necessarily true either: http://drupal.org/project/flag
>

The best flag for issues is RTBC status.

> Flag would also open up the possibility to use other flags for different
> purposes in the future.  Think handbook pages, flagging comments for
> moderation, etc.  It comes with decent Views integration, and is already
> available for 6.x, too.
>
> Lastly, if you really want to weigh flags like votes:
> http://drupal.org/project/flag_weights
>

Priority already gives a weight, we don't need another.

> It is possible that a separate glue module might be required to integrate
> Flag with project* the same way like Project Issue Voting does.  However,
> I'd be up for coding this simple helper, if required.
>

You ppl have wasted enough time on this.  Go check a favorite issue, 
test it, then change the status as appropriate.

Earnie -- http://r-feed.com -   subscribe for email notice of a review 
waiting to happen.

From darrenoh at sidepotsinternational.com  Tue Nov  4 18:54:19 2008
From: darrenoh at sidepotsinternational.com (Darren Oh)
Date: Tue, 4 Nov 2008 13:54:19 -0500
Subject: [development] Voting on issues (was Re: How to post
	bug	reportsandpatches)
In-Reply-To: <20081104134734.qrxghdc9e70g0w0g@mail.progw.org>
References: <004c01c93ea9$c0811550$0200a8c0@structworks.com>
	<20081104134734.qrxghdc9e70g0w0g@mail.progw.org>
Message-ID: <155BD0C4-6363-49A7-9A9D-FCE69206454E@sidepotsinternational.com>

On Nov 4, 2008, at 1:47 PM, Earnie Boyd wrote:

> Quoting "Daniel F. Kudwien" <news at unleashedmind.com>:
>
>>
>> Not necessarily true either: http://drupal.org/project/flag
>>
>
> The best flag for issues is RTBC status.

Could work, if RTBC were a vote rather than a flag that is either on  
or off for the whole issue.

From drupal at dwwright.net  Tue Nov  4 18:58:18 2008
From: drupal at dwwright.net (Derek Wright)
Date: Tue, 4 Nov 2008 10:58:18 -0800
Subject: [development] Voting on issues (was Re: How to post
	bug	reportsandpatches)
In-Reply-To: <20081104134734.qrxghdc9e70g0w0g@mail.progw.org>
References: <004c01c93ea9$c0811550$0200a8c0@structworks.com>
	<20081104134734.qrxghdc9e70g0w0g@mail.progw.org>
Message-ID: <47E25E78-71C3-4E8C-8A97-A5D1780A510C@dwwright.net>


On Nov 4, 2008, at 10:47 AM, Earnie Boyd wrote:

> The best flag for issues is RTBC status.

You completely misunderstand what flag.module does and how it's  
relevant to this discussion.  flag.module is  the current candidate  
for best solution to http://drupal.org/node/34496 ("Allow (un) 
subscription to individual project issue").

-Derek (dww)




From arancaytar.ilyaran at gmail.com  Tue Nov  4 19:20:42 2008
From: arancaytar.ilyaran at gmail.com (Arancaytar Ilyaran)
Date: Tue, 04 Nov 2008 20:20:42 +0100
Subject: [development] Place, Geotagging
In-Reply-To: <49109350.1060401@publicus.net>
References: <49109350.1060401@publicus.net>
Message-ID: <4910A08A.9030009@gmail.com>

Steven Clift wrote:

> 1. Place - Many of the sites hosted on Drupal are local organizations
> with local content. What do you think of having a standard way Drupal
> (and other open source CMSes) allow sites to assign the geographic place
> name (or perhaps a point) that best represents either where their
> organization is based? How about an automatic map of Drupal sites or
> listings by hierarchical placename? Perhaps a connection to
> http://gaze.mysociety.org would work.
> 
> 2. GeoTagging - What do you think of defaulting or at least having the
> ability to assign a point, bounded place, or "global" geo-tag in terms
> of the general scope of individual content items created? An option
> changeable near a save/post button.
> 
> It seems to me that as long as geotagging is an afterthought, the
> ability to aggregate/navigate much of the newer and dynamic content on
> Drupal hosted sites by geographic relevancy will be quite limited.
> Imagine the power of just a few CMSes adopting a similar way to describe
> the place of sites (which could be "earth" for those who think the
> Internet is best when viewed as narrowly "global") and even more
> granular meta-data on specific content items as a default rather than an
> add-on.

1. There is a standard for geographical metadata. However, note that Drupal.org
isn't really in the business of networking individual Drupal sites, so any
website map would need to be hosted somewhere else on its own.

But if there were some kind of aggregating module for geodata, then a Drupal
site could provide exactly the service you're suggesting. The best part is that
it could map any website that implements the standard, not just other Drupal
sites. I don't think an aggregating module like this exists yet, but it could be
an interesting idea (perhaps for a GSoC 2009 project?).

2. Geotagging for individual posts already exists in the form of a contributed
module. I believe it is named "Location" (http://drupal.org/project/location).
It provides a good API and as far as I know there is a whole range of modules
working with it to give you anything from Google Map mashups to KML feeds that
can be imported into Google Earth.

-- 
Arancaytar
----------------------
Nothing beside remains: Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away...
----------------------
PGP:   http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x27CA5C74
XMPP:  arancaytar.ilyaran at gmail.com
AOL:   282026638 / RealArancaytar
URL:   http://ermarian.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/development/attachments/20081104/6b95ae78/attachment.pgp 

From anselm_list at netuxo.co.uk  Tue Nov  4 19:30:58 2008
From: anselm_list at netuxo.co.uk (Anselm)
Date: Tue, 4 Nov 2008 19:30:58 +0000
Subject: [development] Reviewing patches and making decisions
Message-ID: <200811041930.58199.anselm_list@netuxo.co.uk>

Hello,

Having followed this thread for a while, I decided to do my bit, and start 
reviewing patches. I didn't get very far ; I stopped at the first patch.

Not because of the code - I could understand what the original code did, and 
what the patched code did - but because there are two decisions to be made :

1. In that case - and I guess this is not uncomon - the old behaviour might be 
a bug, but it might have been by design. I have no way of telling.

2. Changing the old behaviour to the new one could break old modules that 
implicitely relied on the old behaviour. Again, this is probably not uncomon. 
How do I weight the importance of the patch vs stability of old modules ?

So what do I do next ? I don't have a sufficient overview of that part of 
Drupal to make such decisions myself. Should I mark it as reviewed, and add 
as a note what the potential implications are ? Or is there another process 
to follow in such situations ?

Best,
Anselm





From catch56 at googlemail.com  Tue Nov  4 19:38:49 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Tue, 4 Nov 2008 19:38:49 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <200811041930.58199.anselm_list@netuxo.co.uk>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
Message-ID: <fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>

On Tue, Nov 4, 2008 at 7:30 PM, Anselm  wrote:

> Hello,
>
> Having followed this thread for a while, I decided to do my bit, and start
> reviewing patches. I didn't get very far ; I stopped at the first patch.
>
> Not because of the code - I could understand what the original code did,
> and
> what the patched code did - but because there are two decisions to be made
> :
>
> 1. In that case - and I guess this is not uncomon - the old behaviour might
> be
> a bug, but it might have been by design. I have no way of telling.


A lot of core patches are trying to improve the API (or some other
improvement) rather than fix a bug per se.


>
>
> 2. Changing the old behaviour to the new one could break old modules that
> implicitely relied on the old behaviour. Again, this is probably not
> uncomon.
> How do I weight the importance of the patch vs stability of old modules ?


In general we don't maintain backwards compatibility of code between major
releases (although neither do we break it just for fun) - every release has
detailed upgrade instructions for module maintainers as
http://drupal.org/update/modules

So changing function names, function parameters - this is all fair game as
long as there's a tangible improvement to doing so.





> So what do I do next ? I don't have a sufficient overview of that part of
> Drupal to make such decisions myself. Should I mark it as reviewed, and add
> as a note what the potential implications are ?


Making a note of what the potential implications are is sensible where
you're not sure where something should go - this will help the next person
looking at the issue to make sense of what specific questions need to be
answered in relation to the patch.

The other thing you can do is join #drupal on irc and try to find someone
more familiar with that part of Drupal - if you say 'I'm reviewing a patch
about x but I have some questions' you'll usually get help.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/d23f141d/attachment-0001.htm 

From catch56 at googlemail.com  Tue Nov  4 19:38:49 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Tue, 4 Nov 2008 19:38:49 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <200811041930.58199.anselm_list@netuxo.co.uk>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
Message-ID: <fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>

On Tue, Nov 4, 2008 at 7:30 PM, Anselm  wrote:

> Hello,
>
> Having followed this thread for a while, I decided to do my bit, and start
> reviewing patches. I didn't get very far ; I stopped at the first patch.
>
> Not because of the code - I could understand what the original code did,
> and
> what the patched code did - but because there are two decisions to be made
> :
>
> 1. In that case - and I guess this is not uncomon - the old behaviour might
> be
> a bug, but it might have been by design. I have no way of telling.


A lot of core patches are trying to improve the API (or some other
improvement) rather than fix a bug per se.


>
>
> 2. Changing the old behaviour to the new one could break old modules that
> implicitely relied on the old behaviour. Again, this is probably not
> uncomon.
> How do I weight the importance of the patch vs stability of old modules ?


In general we don't maintain backwards compatibility of code between major
releases (although neither do we break it just for fun) - every release has
detailed upgrade instructions for module maintainers as
http://drupal.org/update/modules

So changing function names, function parameters - this is all fair game as
long as there's a tangible improvement to doing so.





> So what do I do next ? I don't have a sufficient overview of that part of
> Drupal to make such decisions myself. Should I mark it as reviewed, and add
> as a note what the potential implications are ?


Making a note of what the potential implications are is sensible where
you're not sure where something should go - this will help the next person
looking at the issue to make sense of what specific questions need to be
answered in relation to the patch.

The other thing you can do is join #drupal on irc and try to find someone
more familiar with that part of Drupal - if you say 'I'm reviewing a patch
about x but I have some questions' you'll usually get help.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/d23f141d/attachment-0002.htm 

From catch56 at googlemail.com  Tue Nov  4 19:38:49 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Tue, 4 Nov 2008 19:38:49 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <200811041930.58199.anselm_list@netuxo.co.uk>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
Message-ID: <fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>

On Tue, Nov 4, 2008 at 7:30 PM, Anselm  wrote:

> Hello,
>
> Having followed this thread for a while, I decided to do my bit, and start
> reviewing patches. I didn't get very far ; I stopped at the first patch.
>
> Not because of the code - I could understand what the original code did,
> and
> what the patched code did - but because there are two decisions to be made
> :
>
> 1. In that case - and I guess this is not uncomon - the old behaviour might
> be
> a bug, but it might have been by design. I have no way of telling.


A lot of core patches are trying to improve the API (or some other
improvement) rather than fix a bug per se.


>
>
> 2. Changing the old behaviour to the new one could break old modules that
> implicitely relied on the old behaviour. Again, this is probably not
> uncomon.
> How do I weight the importance of the patch vs stability of old modules ?


In general we don't maintain backwards compatibility of code between major
releases (although neither do we break it just for fun) - every release has
detailed upgrade instructions for module maintainers as
http://drupal.org/update/modules

So changing function names, function parameters - this is all fair game as
long as there's a tangible improvement to doing so.





> So what do I do next ? I don't have a sufficient overview of that part of
> Drupal to make such decisions myself. Should I mark it as reviewed, and add
> as a note what the potential implications are ?


Making a note of what the potential implications are is sensible where
you're not sure where something should go - this will help the next person
looking at the issue to make sense of what specific questions need to be
answered in relation to the patch.

The other thing you can do is join #drupal on irc and try to find someone
more familiar with that part of Drupal - if you say 'I'm reviewing a patch
about x but I have some questions' you'll usually get help.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/d23f141d/attachment-0003.htm 

From drupal-devel at webchick.net  Tue Nov  4 23:32:52 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Tue, 04 Nov 2008 18:32:52 -0500
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <200811041930.58199.anselm_list@netuxo.co.uk>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
Message-ID: <4910DBA4.8050109@webchick.net>

On 11/4/08 2:30 PM, Anselm wrote:
> Hello,
>
> Having followed this thread for a while, I decided to do my bit, and start
> reviewing patches. I didn't get very far ; I stopped at the first patch.
>
> Not because of the code - I could understand what the original code did, and
> what the patched code did - but because there are two decisions to be made :
>
> 1. In that case - and I guess this is not uncomon - the old behaviour might be
> a bug, but it might have been by design. I have no way of telling.
>
> 2. Changing the old behaviour to the new one could break old modules that
> implicitely relied on the old behaviour. Again, this is probably not uncomon.
> How do I weight the importance of the patch vs stability of old modules ?
>
> So what do I do next ? I don't have a sufficient overview of that part of
> Drupal to make such decisions myself. Should I mark it as reviewed, and add
> as a note what the potential implications are ? Or is there another process
> to follow in such situations ?
>
> Best,
> Anselm

First of all, YAY!! Thank you for stepping up to fill a gigantic, gaping 
need. :) You rock!!

Catch is right that we generally disregard backwards compatibility if 
the improvement makes Drupal faster, more flexible, and/or easier to 
understand. Since there's no specific issue to look at (probably by 
design), what I would do in this situation and any others like it is 
leave a comment to the effect of:

"I reviewed this patch and upon visual inspection it looks good, and I 
was able to confirm that it does what's expected when applied. However, 
I was left with a couple questions that maybe you could help me with. 
This behaviour change is going to break $thingy in modules; are we sure 
the benefit is worth the cost? Further, it also seems like it might be 
desirable for the old behaviour to work the way it currently is, for 
example $scenario. This patch reverts that behaviour. Could you provide 
more information as to why this is necessary?"

(This assumes there wasn't already an explanation earlier in the issue; 
definitely *don't* ask questions that were already painstakingly 
explained because that makes people cranky. :D)

It's perfectly fine and valid to ask clarifying questions to patch 
creators, and they're normally very happy to answer them since you're 
giving their patch what they desire most: focused attention.

Don't be shy to expose "ignorance" or something. You'd be amazed how 
many "dumb" questions I ask about each and every patch that goes into 
core (just ask the cabal in #drupal), and they went and gave me the keys 
to D7. :P If the patch leaves you with questions (esp. if you can read 
the code fine and it makes sense to you), it's normally a good 
indication that either the issue needs a better description and/or 
(usually and) it requires more inline comments to explain why the 
behaviour is desirable so that we don't switch it again later in the 
future and break BC once more.

Making code understandable and fleshing out functionality and use cases 
is just as vital to patch review as optimizing algorithms, and fresh 
eyes are a strong asset that will bring unique perspectives that the 
rest of us miss.

-Angie

From larry at garfieldtech.com  Wed Nov  5 07:54:36 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Wed, 5 Nov 2008 01:54:36 -0600
Subject: [development] Voting on issues (was Re: How to post bug
	reportsandpatches)
In-Reply-To: <004801c93ea5$d69cb550$0200a8c0@structworks.com>
References: <004801c93ea5$d69cb550$0200a8c0@structworks.com>
Message-ID: <200811050154.36139.larry@garfieldtech.com>

On Tuesday 04 November 2008 11:50:34 am Daniel F. Kudwien wrote:
> Thought about this some more.
>
> Allowing users to vote on issues is probably good for novice users, who do
> not deal with many issues at the same time.  However, for the rest of us,
> who work on plenty of issues, it would take a considerable amount of time
> to constantly removing votes from closed issues and thinking about where to
> place votes next.  Considering this, I would predict that this will be too
> much overhead for me.

That's an easy fix.  Any time an issue is marked closed by cron, clear all 
votes on that issue.  Then you get them back to reallocate elsewhere.

It is probably possible (although probably annoying to do in project* D5) to 
also provide a page where you can see all of the votes you've cast on what 
issues and provide an easy way for you to modify them.  

-- 
Larry Garfield
larry at garfieldtech.com

From drupal at dwwright.net  Wed Nov  5 08:30:23 2008
From: drupal at dwwright.net (Derek Wright)
Date: Wed, 5 Nov 2008 00:30:23 -0800
Subject: [development] Voting on issues (was Re: How to post bug
	reportsandpatches)
In-Reply-To: <200811050154.36139.larry@garfieldtech.com>
References: <004801c93ea5$d69cb550$0200a8c0@structworks.com>
	<200811050154.36139.larry@garfieldtech.com>
Message-ID: <F0CA9470-2524-41D4-8918-E70143A3D91F@dwwright.net>


On Nov 4, 2008, at 11:54 PM, Larry Garfield wrote:

> That's an easy fix.  Any time an issue is marked closed by cron,  
> clear all
> votes on that issue.  Then you get them back to reallocate elsewhere.

We decided not to do it that way for a few reasons:

a) If an issue was accidentally or prematurely marked 'closed', you'd  
lose all the vote data.  Granted, the 2-week cron closer would rule  
out the accidental ones, so I guess it's less of a concern if you do  
it via cron.  However, what about issues marked "duplicate", "won't  
fix", etc?  If people aren't used to reclaiming their votes, then  
people will probably forget about votes "lost" to these other states...

b) Dries said it would be a sense of accomplishment to visit the  
"issues you voted on" page, see stuff that was fixed/closed, and  
reclaim your votes.

> It is probably possible (although probably annoying to do in  
> project* D5) to
> also provide a page where you can see all of the votes you've cast  
> on what
> issues and provide an easy way for you to modify them.

It already does this.  Currently hard-coded and somewhat ugly:

http://project.drupal.org/user/46549/project-issue-votes

Easily converted into a view if someone was motivated to spend time  
on it:

http://drupal.org/node/328689


Cheers,
-Derek (dww)




From anselm_list at netuxo.co.uk  Wed Nov  5 10:51:17 2008
From: anselm_list at netuxo.co.uk (Anselm)
Date: Wed, 5 Nov 2008 10:51:17 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
Message-ID: <200811051051.17243.anselm_list@netuxo.co.uk>

Hi,

Thanks for your answers !

>
> In general we don't maintain backwards compatibility of code between major
> releases (although neither do we break it just for fun) - every release has
> detailed upgrade instructions for module maintainers as
> http://drupal.org/update/modules
>

So the implication here is that if a patch potentially causes backward 
compatibility problems with existing modules, then it should be moved to the 
next major release, while issues that are clearly fixing bugs can remain in 
the current release.

Right, well I'll get back to that first patch then :)

Thanks,
Anselm

-- 

(to send me personal email, remove the _list from this address)


From catch56 at googlemail.com  Wed Nov  5 12:35:51 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 5 Nov 2008 12:35:51 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <200811051051.17243.anselm_list@netuxo.co.uk>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
Message-ID: <fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>

On Wed, Nov 5, 2008 at 10:51 AM, Anselm wrote:

>
> >
>
> So the implication here is that if a patch potentially causes backward
> compatibility problems with existing modules, then it should be moved to
> the
> next major release, while issues that are clearly fixing bugs can remain in
> the current release.
>

Almost. Issues fixing bugs that are still bugs in the next major release
should always be fixed in that release first, then backported to Drupal 6
and/or Drupal 5.

That way, we don't have bugs fixed in Drupal 6 which then crop up again in
Drupal 7, and there's also much more active development there, which
generally means more people available to review and refine proposed fixes
for any given issue.

When this works well, it means that fixing the bug in Drupal 6 can be as
simple as committing the same patch to that branch, or a quick re-roll and
commit - this is much harder to do the other way 'round.

If the code has completely changed in the next release up, then it's fine to
keep them where they are of course - but that's also worth noting in the
issue. If you find patches posted against Drupal 6 which ought to be fixed
in Drupal 7 first, moving them up a release is valuable in itself - the
'patch queue' defaults to Drupal 7, so those of us who rely on that to keep
with things only see stuff that's in there unless we're pointed to something
specifically.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081105/d4bfb4cd/attachment.htm 

From earnie at users.sourceforge.net  Wed Nov  5 13:16:04 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Wed, 05 Nov 2008 08:16:04 -0500
Subject: [development] Voting on issues (was Re: How to post
	bug	reportsandpatches)
In-Reply-To: <47E25E78-71C3-4E8C-8A97-A5D1780A510C@dwwright.net>
References: <004c01c93ea9$c0811550$0200a8c0@structworks.com>
	<20081104134734.qrxghdc9e70g0w0g@mail.progw.org>
	<47E25E78-71C3-4E8C-8A97-A5D1780A510C@dwwright.net>
Message-ID: <20081105081604.h6abgbzb6p8gwgg4@mail.progw.org>

Quoting Derek Wright <drupal at dwwright.net>:

>
> On Nov 4, 2008, at 10:47 AM, Earnie Boyd wrote:
>
>> The best flag for issues is RTBC status.
>
> You completely misunderstand what flag.module does and how it's  
> relevant to this discussion.  flag.module is  the current candidate  
> for best solution to http://drupal.org/node/34496 ("Allow (un) 
> subscription to individual project issue").
>

Ok, but the discussion is using flag to help prioritize the workflow.  
I don't disagree with that in total but unless more are willing to 
review, test and participate in the issues then this discussion is 
pointless.  There are some bugs that just require a quick review of the 
coding to say this makes too much sense to not patch it and 
prioritization for this type of bug fix using flag makes no sense at 
all.  We just need to get the sucker committed; therefore, the best 
flag for issues is RTBC.

Using a socialization voting flag for feature requests would definitely 
be the thing to do.  As long as the feature request doesn't already 
have a patch.  Once an issue has a patch the reviewing and testing the 
patch is the only course of action that should be taken.  Patches need 
reviewed, not voted on.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/


From cxjohnson at gmail.com  Wed Nov  5 14:59:40 2008
From: cxjohnson at gmail.com (Chris Johnson)
Date: Wed, 5 Nov 2008 08:59:40 -0600
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
Message-ID: <9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>

On Wed, Nov 5, 2008 at 6:35 AM, Nathaniel Catchpole
<catch56 at googlemail.com> wrote:

> Almost. Issues fixing bugs that are still bugs in the next major release
> should always be fixed in that release first, then backported to Drupal 6
> and/or Drupal 5.
>
> That way, we don't have bugs fixed in Drupal 6 which then crop up again in
> Drupal 7, and there's also much more active development there, which
> generally means more people available to review and refine proposed fixes
> for any given issue.


This has always been the assumption -- that there is more development
in the newest version than in older versions.  But it has always just
been an assumption without proof -- and even I feel it was probably
true most of the time, or in the past.

If one only measures core development, than of course it's true,
simply because past core releases are essentially frozen except
security fixes.

But right now, I would bet far more effort is being spent on Drupal 6
development than on Drupal 7 development.  And it's part of this
topic's problem.

Issues and patches are piling up in the Drupal 6 issue queues, but the
push is to look at Drupal 7 development.

For example, I'm spending 100% of my effort to build Drupal 6
websites.  I find a bunch of bugs in D6.  I write issues and post
patches.  My motivation to check for the same problem in D7 and then
develop a D7 patch, is going to be considerably less than my
motivation for D6.  I might not even be able to do that, if the D7
code is not sufficiently ready or stable.  If I'm already waiting for
patches to be applied to D6 modules, I'm not going to be interested in
waiting even longer to have them applied to D7 and then get backported
to D6.  I need the fix yesterday, not next year.

Really it's all about every member of the community having a different
agenda, and everyone is negotiating with the community to get as much
support for their own agenda as possible.  Some people have more
influence than others or more power than others in these negotiations
(the Drupal community is much like the rest of life in this regard,
after all).

The question is whether the majority should continue to be facilitate
the agenda of the minority, or if the majority should stand up, notice
that it is the majority, and push more strongly for what they want.

From drupal at ryancross.com  Wed Nov  5 15:21:06 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Thu, 6 Nov 2008 02:21:06 +1100
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
	<9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
Message-ID: <4e983be00811050721l5d43641ctb61f1db0a51ef9aa@mail.gmail.com>

umm.... HERE! HERE!

On Thu, Nov 6, 2008 at 1:59 AM, Chris Johnson <cxjohnson at gmail.com> wrote:

>
> This has always been the assumption -- that there is more development
> in the newest version than in older versions.  But it has always just
> been an assumption without proof -- and even I feel it was probably
> true most of the time, or in the past.
>

I bet there could be some of those keen on statistics could easily write a
few queries to determine which is the case. It would be important to also
consider contrib too.


>
> If one only measures core development, than of course it's true,
> simply because past core releases are essentially frozen except
> security fixes.
>
> But right now, I would bet far more effort is being spent on Drupal 6
> development than on Drupal 7 development.  And it's part of this
> topic's problem.
>
> Issues and patches are piling up in the Drupal 6 issue queues, but the
> push is to look at Drupal 7 development.
>
> For example, I'm spending 100% of my effort to build Drupal 6
> websites.  I find a bunch of bugs in D6.  I write issues and post
> patches.  My motivation to check for the same problem in D7 and then
> develop a D7 patch, is going to be considerably less than my
> motivation for D6.  I might not even be able to do that, if the D7
> code is not sufficiently ready or stable.  If I'm already waiting for
> patches to be applied to D6 modules, I'm not going to be interested in
> waiting even longer to have them applied to D7 and then get backported
> to D6.  I need the fix yesterday, not next year.


I understand the rationale for expecting all patches to be addressed in head
and then back ported. However, sometimes I wonder whether it would be also
effective to have the patches ported forward. This *is* one point of having
a version stated as maintained. It could be argued it is less efficient, but
if it helps people work more I would argue it is a more effective approach
in some areas.


>
> Really it's all about every member of the community having a different
> agenda, and everyone is negotiating with the community to get as much
> support for their own agenda as possible.  Some people have more
> influence than others or more power than others in these negotiations
> (the Drupal community is much like the rest of life in this regard,
> after all).
>
> The question is whether the majority should continue to be facilitate
> the agenda of the minority, or if the majority should stand up, notice
> that it is the majority, and push more strongly for what they want.


I think this is a strong point, and it also reflects the changing nature of
the Drupal community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081106/bda75433/attachment.htm 

From catch56 at googlemail.com  Wed Nov  5 16:01:20 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 5 Nov 2008 16:01:20 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
	<9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
Message-ID: <fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>

On Wed, Nov 5, 2008 at 2:59 PM, Chris Johnson
>
>
>
> This has always been the assumption -- that there is more development
> in the newest version than in older versions.  But it has always just
> been an assumption without proof -- and even I feel it was probably
> true most of the time, or in the past.
>
> If one only measures core development, than of course it's true,
> simply because past core releases are essentially frozen except
> security fixes.


Exactly, and we're talking about core patches. Most active contrib
development is happening in Drupal 6, I generally don't see many patches
posted for Drupal 4.7 versions of contrib modules, or even Drupal 5
depending on which module it is.


>
> But right now, I would bet far more effort is being spent on Drupal 6
> development than on Drupal 7 development.  And it's part of this
> topic's problem.
>
> Issues and patches are piling up in the Drupal 6 issue queues, but the
> push is to look at Drupal 7 development.
>
> For example, I'm spending 100% of my effort to build Drupal 6
> websites.  I find a bunch of bugs in D6.  I write issues and post
> patches.  My motivation to check for the same problem in D7 and then
> develop a D7 patch, is going to be considerably less than my
> motivation for D6.


Well you could post the patch against D7 without verifying, someone watching
that queue will take a look (if they have time), and if it doesn't apply to
D7, move it back to D6, or re-roll for Drupal 7. This happens regularly,
stating that the patch was rolled against Drupal 6 is all you need to do
here.



>  I might not even be able to do that, if the D7
> code is not sufficiently ready or stable.


D7 is exceptionally stable due to many hundreds of automated tests. Getting
tests written to prevent bugs reappearing is one of the many reasons that
doing active development there is useful. Since the tests verify that the
bug is fixed  (assuming they're written properly), then in general you're
more likely to get a decent fix, and one that doesn't cause regressions
elsewhere. And supplying patches with tests gets them committed much, much
faster.



>  If I'm already waiting for
> patches to be applied to D6 modules, I'm not going to be interested in
> waiting even longer to have them applied to D7 and then get backported
> to D6.  I need the fix yesterday, not next year.


Patches can get applied to Drupal 7 in as little as a few hours, depending
on the patch, the availability of reviewers and core maintainers.

An example from this week:
http://drupal.org/node/329646 opened on third november.

Fixed in both Drupal 6 and Drupal 7 on 4th November
http://drupal.org/cvs?commit=151247
http://drupal.org/cvs?commit=151248

In which way is this slower than ignoring advice, posting a patch to the
Drupal 6 queue, then trying to cajole a small number of over-stretched
volunteers to change their workflow?


> Really it's all about every member of the community having a different
> agenda, and everyone is negotiating with the community to get as much
> support for their own agenda as possible.  Some people have more
> influence than others or more power than others in these negotiations
> (the Drupal community is much like the rest of life in this regard,
> after all).
>
> The question is whether the majority should continue to be facilitate
> the agenda of the minority, or if the majority should stand up, notice
> that it is the majority, and push more strongly for what they want.


Well, the smallest minority is the core maintainers. There's two for Drupal
7, two for Drupal 6 (obviously Dries gets counted twice, so that's actually
three people for both branches). Since only Dries can commit to both
branches (like the example above), something has the best chance of being
fixed in both branches if it's submitted to the Drupal 7 queue first of all.
Also, webchick has a lot more time allocated to core development than Gabor,
since Drupal 6 is in maintenance. If a patch goes through the review and
RTBC cycle in Drupal 7, then more times than not it's a quick look over and
commit for Drupal 6 - expecting all the back and forth of a core commit to
happen in a maintenance release is asking too much IMO - Drupal 6 is likely
to have a 2-3 year release cycle, after all.

The other minority you're talking about is those actively working on core
development on a regular (i.e. daily) basis - i.e. the people who are
actually reviewing and RTBC-ing those patches. As far as I know , the
majority of that minority prefers the current workflow too. This is
volunteer project, and the ony real power as such lies with those with
commit access - people can make their voices heard by complaining on the
development list, or by getting stuck in, and change gets made on the
strength of arguments. I've not actually seen any arguments put forward for
changing the current workflow, except that some people 'don't have time'.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081105/20ba716c/attachment-0001.htm 

From catch56 at googlemail.com  Wed Nov  5 16:15:01 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 5 Nov 2008 16:15:01 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
	<9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
	<fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>
Message-ID: <fa5724270811050815x75e00a87q23f55d615ca6f672@mail.gmail.com>

One more thing ;)

If you want to see more active development on outstanding Drupal 6 issues,
feedback on adding the Drupal 6 patch queue links back to the contributors
block would go a long way - see here http://drupal.org/node/221510

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081105/ec2cebb1/attachment.htm 

From darrenoh at sidepotsinternational.com  Wed Nov  5 16:23:26 2008
From: darrenoh at sidepotsinternational.com (Darren Oh)
Date: Wed, 5 Nov 2008 11:23:26 -0500
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <fa5724270811050815x75e00a87q23f55d615ca6f672@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
	<9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
	<fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>
	<fa5724270811050815x75e00a87q23f55d615ca6f672@mail.gmail.com>
Message-ID: <ECB3D2B6-77CF-43A2-B436-8B38D78290AF@sidepotsinternational.com>

Persuading the DRUPAL-5 and DRUPAL-6 branch maintainers to change  
their policy of not fixing bugs in their branch until they've been  
fixed in the development branch is what's important.

On Nov 5, 2008, at 11:15 AM, Nathaniel Catchpole wrote:

> One more thing ;)
>
> If you want to see more active development on outstanding Drupal 6  
> issues, feedback on adding the Drupal 6 patch queue links back to  
> the contributors block would go a long way - see here http://drupal.org/node/221510
>
> Nat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081105/8df78106/attachment.htm 

From catch56 at googlemail.com  Wed Nov  5 16:26:35 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 5 Nov 2008 16:26:35 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <ECB3D2B6-77CF-43A2-B436-8B38D78290AF@sidepotsinternational.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
	<9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
	<fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>
	<fa5724270811050815x75e00a87q23f55d615ca6f672@mail.gmail.com>
	<ECB3D2B6-77CF-43A2-B436-8B38D78290AF@sidepotsinternational.com>
Message-ID: <fa5724270811050826t4ee6fd39i9b7a90a9b14369d9@mail.gmail.com>

On Wed, Nov 5, 2008 at 4:23 PM, Darren Oh wrote:

> Persuading the DRUPAL-5 and DRUPAL-6 branch maintainers to change their
> policy of not fixing bugs in their branch until they've been fixed in the
> development branch is what's important.
>

This is an accurate summary of what I barely managed to say in a couple
hundred words.

Having said that, issues fixed in 7 often still need
backporting/testing/reviews against Drupal 6, and there's not a one-click
way to see those issues at the moment, which is what
http://drupal.org/node/221510 is for.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081105/c7b79a83/attachment.htm 

From cxjohnson at gmail.com  Wed Nov  5 20:51:38 2008
From: cxjohnson at gmail.com (Chris Johnson)
Date: Wed, 5 Nov 2008 14:51:38 -0600
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
	<9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
	<fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>
Message-ID: <9ea8d6030811051251u5e576b60ja99cbac0cc2fa36e@mail.gmail.com>

On Wed, Nov 5, 2008 at 10:01 AM, Nathaniel Catchpole

> Exactly, and we're talking about core patches. Most active contrib
> development is happening in Drupal 6, I generally don't see many patches
> posted for Drupal 4.7 versions of contrib modules, or even Drupal 5
> depending on which module it is.


We were?  (talking about core patches?)

I don't see that in this thread.  We were talking about all patches,
as far as I could tell.

The arguments are indeed very different for core and contrib.

I was positing primarily about contrib, since that's where most of the
need is.  Still, there is a problem with core issue queues
languishing, too.  I can't remember the last time I posted a patch to
core; it's become too hard for me to contribute meaningful new core
code and get attention to it.

From catch56 at googlemail.com  Wed Nov  5 21:03:40 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 5 Nov 2008 21:03:40 +0000
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <9ea8d6030811051251u5e576b60ja99cbac0cc2fa36e@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
	<9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
	<fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>
	<9ea8d6030811051251u5e576b60ja99cbac0cc2fa36e@mail.gmail.com>
Message-ID: <fa5724270811051303r40f176d4h94ec986886defd79@mail.gmail.com>

On Wed, Nov 5, 2008 at 8:51 PM, Chris Johnson  wrote:

> On Wed, Nov 5, 2008 at 10:01 AM, Nathaniel Catchpole
>
> > Exactly, and we're talking about core patches. Most active contrib
> > development is happening in Drupal 6, I generally don't see many patches
> > posted for Drupal 4.7 versions of contrib modules, or even Drupal 5
> > depending on which module it is.
>
>
> We were?  (talking about core patches?)
>
> I don't see that in this thread.  We were talking about all patches,
> as far as I could tell.
>
> The arguments are indeed very different for core and contrib.
>
> Oh I see! Well I think the argument stands for contrib in a lot of cases,
except that the release cycles are so much shorter (usually) that the most
recent release is likely to be much closer to what you're actually using.
Since very, very few contrib modules have D7 compatible versions that issue
comes up a lot less, and in those cases, you'd probably want to forward-port
patches until at least Beta/RC stage for the associated core release. So
maybe we agree after all. Of course this all depends on the individual
module, and individual maintainer.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081105/68f4c6b8/attachment.htm 

From tz at it-arts.org  Wed Nov  5 21:01:32 2008
From: tz at it-arts.org (Thomas Zahreddin)
Date: Wed, 5 Nov 2008 22:01:32 +0100
Subject: [development] Reviewing patches and making decisions ->
	Sociocracy could be a way to go!
In-Reply-To: <200811041930.58199.anselm_list@netuxo.co.uk>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
Message-ID: <200811052201.32496.tz@it-arts.org>

Hallo,

thank you for bringing this topic up.

Since a long time I'm unsatisfied with this process.

(@ Dries:  this is the e-mail i announced to you in Szeged)


> Hello,
>
> Having followed this thread for a while, I decided to do my bit, and start
> reviewing patches. I didn't get very far ; I stopped at the first patch.
>
> Not because of the code - I could understand what the original code did,
> and what the patched code did - but because there are two decisions to be
> made :
>
> 1. In that case - and I guess this is not uncomon - the old behaviour might
> be a bug, but it might have been by design. I have no way of telling.
>

(caution: Ironical!) Oh, I can't count how often i heard: "the code tells it 
all!" or "read my code first" or "only code counts, not the words about it" ..

Yes I can read the code but the question above can not be answered by reading 
the code - much more helpful would be a comment what the _aim_ of some lines 
of code is.

And maybe the group working on and with that particular module has a list of 
decisions (not a mailinglist) and why they where made - so one could go back 
to the original decision (should be referenced in the code) and look up what 
the original intention was. 

Do you agree that these information could help a lot in similar situaltions?


> 2. Changing the old behaviour to the new one could break old modules that
> implicitely relied on the old behaviour. Again, this is probably not
> uncomon. How do I weight the importance of the patch vs stability of old
> modules ?

IMHO persons, interested in a module (like programmers and users of this or a 
compatible module), shall have the possiblity to be heard with their 
requirements. It is up to the maintainer (or moderater) to listen to all and 
their arguments what is urgent and /or important and to come up with 
suggestions to which most (if not all) people can agree. The final decision is 
up to the maintainer (keeping in mind the long term goals, all persons 
interested in the module and the available resources) in cooperation with the 
person willing to contribute (e.g. code).

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 modul.

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 Sociocratic Principles and Methods. Sociocracy.info 
Press. ISBN 978-0-9792827-0-6.


>
> So what do I do next ? I don't have a sufficient overview of that part of
> Drupal to make such decisions myself. Should I mark it as reviewed, and add
> as a note what the potential implications are ? Or is there another process
> to follow in such situations ?

I agree absoluty: We do not have approriate structures in the drupal community 
to work efficently, make decissions traceable, keeping the teamspirit up and 
stay open for new developers to join.

I'm aware of: there are ca. one million notes on drupal.org, some IRC-
channels, conferences, groups.drupal.org, mailinglists like this one, a CVS-
Repository ... 
- but you can imagin alone by this list how hard it is to follow all relevant 
information / decissions.

So I suggest to read a little about Sociocracy and start discussing our 
decision making process.

Best

Thomas Zahreddin
cofounder of http://VoiceHero.net

>
> Best,
> Anselm


From drupal at samboyer.org  Thu Nov  6 01:36:02 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Wed, 5 Nov 2008 19:36:02 -0600
Subject: [development] Reviewing patches and making decisions ->
	Sociocracy could be a way to go!
In-Reply-To: <200811052201.32496.tz@it-arts.org>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<200811052201.32496.tz@it-arts.org>
Message-ID: <200811051936.06984.drupal@samboyer.org>

On Wednesday 05 November 2008 15:01:32 Thomas Zahreddin wrote:
> Hallo,
>
> thank you for bringing this topic up.
>
> Since a long time I'm unsatisfied with this process.
>
> (@ Dries:  this is the e-mail i announced to you in Szeged)
>
> > Hello,
> >
> > Having followed this thread for a while, I decided to do my bit, and
> > start reviewing patches. I didn't get very far ; I stopped at the first
> > patch.
> >
> > Not because of the code - I could understand what the original code did,
> > and what the patched code did - but because there are two decisions to be
> > made :
> >
> > 1. In that case - and I guess this is not uncomon - the old behaviour
> > might be a bug, but it might have been by design. I have no way of
> > telling.
>
> (caution: Ironical!) Oh, I can't count how often i heard: "the code tells
> it all!" or "read my code first" or "only code counts, not the words about
> it" ..
>
> Yes I can read the code but the question above can not be answered by
> reading the code - much more helpful would be a comment what the _aim_ of
> some lines of code is.
>
> And maybe the group working on and with that particular module has a list
> of decisions (not a mailinglist) and why they where made - so one could go
> back to the original decision (should be referenced in the code) and look
> up what the original intention was.
>
> Do you agree that these information could help a lot in similar
> situaltions?
>
> > 2. Changing the old behaviour to the new one could break old modules that
> > implicitely relied on the old behaviour. Again, this is probably not
> > uncomon. How do I weight the importance of the patch vs stability of old
> > modules ?
>
> IMHO persons, interested in a module (like programmers and users of this or
> a compatible module), shall have the possiblity to be heard with their
> requirements. It is up to the maintainer (or moderater) to listen to all
> and their arguments what is urgent and /or important and to come up with
> suggestions to which most (if not all) people can agree. The final decision
> is up to the maintainer (keeping in mind the long term goals, all persons
> interested in the module and the available resources) in cooperation with
> the person willing to contribute (e.g. code).
>
> 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
> modul.
>
> 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_Organizati
>on.pdf
>
> A longer description is in
> Buck, John and Sharon Villines (2007). We the People: Consenting to a
> Deeper Democracy, A Guide to Sociocratic Principles and Methods.
> Sociocracy.info Press. ISBN 978-0-9792827-0-6.
>
> > So what do I do next ? I don't have a sufficient overview of that part of
> > Drupal to make such decisions myself. Should I mark it as reviewed, and
> > add as a note what the potential implications are ? Or is there another
> > process to follow in such situations ?
>
> I agree absoluty: We do not have approriate structures in the drupal
> community to work efficently, make decissions traceable, keeping the
> teamspirit up and stay open for new developers to join.

http://groups.drupal.org/node/14775

The implementation of the API described in that proposal is considerably more 
heavy-duty than what's being talked about here, but that (will be) the beauty 
of the API - slim-down versions would be quite possible, too.

It's a good thing that the Decisionmaking API hasn't gotten started yet, 
though, because I do think that there'd need to be quite a bit of discussion 
first about what people would actually want/use, and how to know when such a 
system begins to hinder more than it helps.

cheers
sam

>
> I'm aware of: there are ca. one million notes on drupal.org, some IRC-
> channels, conferences, groups.drupal.org, mailinglists like this one, a
> CVS- Repository ...
> - but you can imagin alone by this list how hard it is to follow all
> relevant information / decissions.
>
> So I suggest to read a little about Sociocracy and start discussing our
> decision making process.
>
> Best
>
> Thomas Zahreddin
> cofounder of http://VoiceHero.net
>
> > Best,
> > Anselm
-------------- 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 : http://lists.drupal.org/pipermail/development/attachments/20081105/41986f86/attachment-0001.pgp 

From fernandoparedesgarcia at gmail.com  Thu Nov  6 02:20:16 2008
From: fernandoparedesgarcia at gmail.com (=?ISO-8859-1?Q?=22Fernando_P=2E_Garc=EDa=22?=)
Date: Wed, 05 Nov 2008 21:20:16 -0500
Subject: [development] Voting on issues (was Re: How to post bug
	reportsandpatches)
In-Reply-To: <F0CA9470-2524-41D4-8918-E70143A3D91F@dwwright.net>
References: <004801c93ea5$d69cb550$0200a8c0@structworks.com>	<200811050154.36139.larry@garfieldtech.com>
	<F0CA9470-2524-41D4-8918-E70143A3D91F@dwwright.net>
Message-ID: <49125460.3010808@gmail.com>

Derek Wright wrote:
>
> On Nov 4, 2008, at 11:54 PM, Larry Garfield wrote:
>> It is probably possible (although probably annoying to do in project* 
>> D5) to
>> also provide a page where you can see all of the votes you've cast on 
>> what
>> issues and provide an easy way for you to modify them.
> It already does this.  Currently hard-coded and somewhat ugly:
>
> http://project.drupal.org/user/46549/project-issue-votes
>
> Easily converted into a view if someone was motivated to spend time on 
> it:
>
> http://drupal.org/node/328689
I'm motivated to do it :), where can I start?

Blessings!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fernandoparedesgarcia.vcf
Type: text/x-vcard
Size: 359 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081105/91bacf50/attachment.vcf 

From drupal-devel at webchick.net  Thu Nov  6 05:06:14 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Thu, 06 Nov 2008 00:06:14 -0500
Subject: [development] Reviewing patches and making decisions
 ->	Sociocracy could be a way to go!
In-Reply-To: <200811052201.32496.tz@it-arts.org>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<200811052201.32496.tz@it-arts.org>
Message-ID: <49127B46.6080107@webchick.net>


> Yes I can read the code but the question above can not be answered by reading 
> the code - much more helpful would be a comment what the _aim_ of some lines 
> of code is.
> 
> And maybe the group working on and with that particular module has a list of 
> decisions (not a mailinglist) and why they where made - so one could go back 
> to the original decision (should be referenced in the code) and look up what 
> the original intention was. 
> 
> Do you agree that these information could help a lot in similar situaltions?

This is actually a feature built into CVS (and most other version 
control systems) called CVS Annotate that does exactly that:
http://www.lullabot.com/articles/cvs_annotate_or_what_the_heck_were_they_thinking

For every line of code, you can discover who made the change, when they 
made it, and why. Assuming the maintainer is following standard commit 
message patterns, you can also reference the original issue that has all 
the background information on discussions on the code that were had, the 
development evolution of the feature over time, and why the decision was 
ultimately made to commit it.

It's a pretty awesome resource because it's automatically updated with 
every commit, without the need for any manual intervention or extra 
overhead.

-Angie


From dries.buytaert at gmail.com  Thu Nov  6 06:33:37 2008
From: dries.buytaert at gmail.com (Dries Buytaert)
Date: Thu, 6 Nov 2008 07:33:37 +0100
Subject: [development] Voting on issues (was Re: How to post bug
	reportsandpatches)
In-Reply-To: <49125460.3010808@gmail.com>
References: <004801c93ea5$d69cb550$0200a8c0@structworks.com>
	<200811050154.36139.larry@garfieldtech.com>
	<F0CA9470-2524-41D4-8918-E70143A3D91F@dwwright.net>
	<49125460.3010808@gmail.com>
Message-ID: <61bca48a0811052233w6be44d66yf08195cfdfe7939e@mail.gmail.com>

I don't have a need for issue voting at this point.  A subscribe
feature would be more useful.

Either way, I'd rather enable new features after we upgraded
drupal.org to Drupal 6.  I'd prefer to see new efforts go into the
Drupal 6 version of the module.  Upgrading drupal.org to Drupal 6 is
going to have a much bigger impact that voting.



2008/11/6 "Fernando P. Garc?a" <fernandoparedesgarcia at gmail.com>:
> Derek Wright wrote:
>>
>> On Nov 4, 2008, at 11:54 PM, Larry Garfield wrote:
>>>
>>> It is probably possible (although probably annoying to do in project* D5)
>>> to
>>> also provide a page where you can see all of the votes you've cast on
>>> what
>>> issues and provide an easy way for you to modify them.
>>
>> It already does this.  Currently hard-coded and somewhat ugly:
>>
>> http://project.drupal.org/user/46549/project-issue-votes
>>
>> Easily converted into a view if someone was motivated to spend time on it:
>>
>> http://drupal.org/node/328689
>
> I'm motivated to do it :), where can I start?
>
> Blessings!
>



-- 
Dries Buytaert :: http://buytaert.net/

From dries.buytaert at gmail.com  Thu Nov  6 06:56:04 2008
From: dries.buytaert at gmail.com (Dries Buytaert)
Date: Thu, 6 Nov 2008 07:56:04 +0100
Subject: [development] The static $perm variable in user_access reset
	erroneously
In-Reply-To: <24523838.271225823118233.JavaMail.root@zimbra.thefiengroup.com>
References: <24523838.271225823118233.JavaMail.root@zimbra.thefiengroup.com>
Message-ID: <61bca48a0811052256m68752badx3201d90fec8e75d@mail.gmail.com>

Committed to CVS HEAD and DRUPAL-6 too. :-)

On Tue, Nov 4, 2008 at 7:25 PM, Ron Parker <sysop at scbbs.com> wrote:
> Damien Tournoud wrote:
>
> "This is nothing more than a bug. Please see http://drupal.org/node/329646."
>
> Yes, that's it. Applied the patch and getting expected behaviour now.  Thank
> you!

-- 
Dries Buytaert :: http://buytaert.net/

From tz at it-arts.org  Thu Nov  6 11:19:43 2008
From: tz at it-arts.org (Thomas Zahreddin)
Date: Thu, 6 Nov 2008 12:19:43 +0100
Subject: [development]
 =?iso-8859-1?q?Reviewing_patches_and_making_decisio?=
 =?iso-8859-1?q?ns_-=3E_=09Sociocracy_could_be_a_way_to_go!?=
In-Reply-To: <49127B46.6080107@webchick.net>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<200811052201.32496.tz@it-arts.org> <49127B46.6080107@webchick.net>
Message-ID: <200811061219.43428.tz@it-arts.org>

Hi Angie,

thank you for answering the first third of my mail. I think we are not on the 
same page:

in the last third I wrote explicit, that I know all the tools and places where 
to find informations - but i also mention that it is impossible to follow all 
relevant information.

To lower the workload for us all we need a summery on a much higher level than 
CVS-messages (btw how many do we count a day - my estimation is two a minute).

My request is for that higher level: For Core the policy and a handbook is 
avialable; but you can find modules in contrib that even don't have a README - 
sure you can go to the sourcecode and look what they do - but this is not 
efficient.

The documentation is only the result of a process that happens before: the 
process of making decisions - this is what i want to discuss.


Are you willing to give me a feedback what you understood? - Because I want to 
be sure we are on the same page.

Best 
Thomas

Am Donnerstag 06 November 2008 06:06:14 schrieb Angela Byron:
> > Yes I can read the code but the question above can not be answered by
> > reading the code - much more helpful would be a comment what the _aim_ of
> > some lines of code is.
> >
> > And maybe the group working on and with that particular module has a list
> > of decisions (not a mailinglist) and why they where made - so one could
> > go back to the original decision (should be referenced in the code) and
> > look up what the original intention was.
> >
> > Do you agree that these information could help a lot in similar
> > situaltions?
>
> This is actually a feature built into CVS (and most other version
> control systems) called CVS Annotate that does exactly that:
> http://www.lullabot.com/articles/cvs_annotate_or_what_the_heck_were_they_th
>inking
>
> For every line of code, you can discover who made the change, when they
> made it, and why. Assuming the maintainer is following standard commit
> message patterns, you can also reference the original issue that has all
> the background information on discussions on the code that were had, the
> development evolution of the feature over time, and why the decision was
> ultimately made to commit it.
>
> It's a pretty awesome resource because it's automatically updated with
> every commit, without the need for any manual intervention or extra
> overhead.
>
> -Angie


From earnie at users.sourceforge.net  Thu Nov  6 12:41:19 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 06 Nov 2008 07:41:19 -0500
Subject: [development] Reviewing patches and making decisions ->
	Sociocracy could be a way to go!
In-Reply-To: <200811061219.43428.tz@it-arts.org>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<200811052201.32496.tz@it-arts.org> <49127B46.6080107@webchick.net>
	<200811061219.43428.tz@it-arts.org>
Message-ID: <20081106074119.kht1tqz71soc4sks@mail.progw.org>

Quoting Thomas Zahreddin <tz at it-arts.org>:

>
> My request is for that higher level: For Core the policy and a handbook is
> avialable; but you can find modules in contrib that even don't have a 
> README -
> sure you can go to the sourcecode and look what they do - but this is not
> efficient.
>

I'm confused, are you discussing policy for core or for contrib?  I 
don't think anyone enforces core policy on contrib much.  Encourages 
it, yes, but doesn't enforce it.  Each contrib maintainer chooses their 
own rules.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/


From earnie at users.sourceforge.net  Thu Nov  6 13:16:24 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 06 Nov 2008 08:16:24 -0500
Subject: [development] Reviewing patches and making decisions
	->	Sociocracy could be a way to go!
In-Reply-To: <200811052201.32496.tz@it-arts.org>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<200811052201.32496.tz@it-arts.org>
Message-ID: <20081106081624.3g5adhjz2z7u8s0c@mail.progw.org>

Quoting Thomas Zahreddin <tz at it-arts.org>:

>>
>> Not because of the code - I could understand what the original code did,
>> and what the patched code did - but because there are two decisions to be
>> made :
>>
>> 1. In that case - and I guess this is not uncomon - the old behaviour might
>> be a bug, but it might have been by design. I have no way of telling.
>>
>

If it is by design then the code should be documented as to why.  If no 
comments then we can assume that the patch is either fixing a bug or 
create a new feature.  If this is a new feature and the issue is marked 
as a bug, change the information to feature request from bug report.  
Feature requests always go to the next release so be sure to change the 
version and ask the patch be rolled for HEAD as well as give 
information about the patch itself.

Bug reports usually go to HEAD, you may find an instance of an API call 
that has been removed so HEAD can't contain the patch.  Once applied to 
HEAD then the patch can roll backward to other versions.

> (caution: Ironical!) Oh, I can't count how often i heard: "the code tells it
> all!" or "read my code first" or "only code counts, not the words 
> about it" ..
>

Don't forget about common sense.

> Yes I can read the code but the question above can not be answered by reading
> the code - much more helpful would be a comment what the _aim_ of some lines
> of code is.
>

But it can be answered by looking at the source.  If no comment is 
present then there is no reason to think that anything special was 
being done by the previous code.

> And maybe the group working on and with that particular module has a list of
> decisions (not a mailinglist) and why they where made - so one could go back
> to the original decision (should be referenced in the code) and look up what
> the original intention was.
>

Again, common sense.  If decisions aren't documented in an issue 
somewhere based on the policies already set forth for Drupal core then 
a patch isn't really warranted or the decisions have to be stated again 
in the issue.  The issue is the communication point for the patch.  And 
as a matter of policy Drupal core patches are never committed without 
an issue.

> Do you agree that these information could help a lot in similar situaltions?
>

Not always.

>
>> 2. Changing the old behaviour to the new one could break old modules that
>> implicitely relied on the old behaviour. Again, this is probably not
>> uncomon. How do I weight the importance of the patch vs stability of old
>> modules ?
>
> IMHO persons, interested in a module (like programmers and users of this or a
> compatible module), shall have the possiblity to be heard with their
> requirements. It is up to the maintainer (or moderater) to listen to all and
> their arguments what is urgent and /or important and to come up with
> suggestions to which most (if not all) people can agree. The final 
> decision is
> up to the maintainer (keeping in mind the long term goals, all persons
> interested in the module and the available resources) in cooperation with the
> person willing to contribute (e.g. code).
>

It is also up to the interested persons to provide patches for the 
modules.  Everyone can be a patch creator.

> 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 modul.
>

Contrib modules are of a different breed of issue.  There is no 
enforcement of Drupal policy on the contrib module.

>
>>
>> So what do I do next ? I don't have a sufficient overview of that part of
>> Drupal to make such decisions myself. Should I mark it as reviewed, and add
>> as a note what the potential implications are ? Or is there another process
>> to follow in such situations ?
>

Leave it as needs review but leave your comments.

> I agree absoluty: We do not have approriate structures in the drupal 
> community
> to work efficently, make decissions traceable, keeping the teamspirit up and
> stay open for new developers to join.
>

I highly disagree.  Yes, people will get their feelings hurt as we 
paint the bike sheds our favorite color but we need to understand that 
in a community that is supporting an open source package that not 
everything will be accepted.  New developers can join by being 
participating as well as learning.  Test out the new patches and give 
review.

>
> So I suggest to read a little about Sociocracy and start discussing our
> decision making process.
>

The decisions have been made.  Now it is time to review, test, patch 
again, re-review and retest.  Find an interesting patch to review.  Be 
notified of a patch waiting for review by subscribing to the review tag 
at r-feed.com.

--
Earnie
   http://r-feed.com
   Make a Drupal difference and review core patches.

From earnie at users.sourceforge.net  Thu Nov  6 13:33:32 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 06 Nov 2008 08:33:32 -0500
Subject: [development] Reviewing patches and making decisions
In-Reply-To: <9ea8d6030811051251u5e576b60ja99cbac0cc2fa36e@mail.gmail.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<fa5724270811041138w7b6c9cffy79fe1c7d95686bc2@mail.gmail.com>
	<200811051051.17243.anselm_list@netuxo.co.uk>
	<fa5724270811050435sb6f8a1ex91c9d6f9817955eb@mail.gmail.com>
	<9ea8d6030811050659r51eb40b5qfb3ee686b982d1e9@mail.gmail.com>
	<fa5724270811050801g230ab1c1p6e2c73f426d55bbb@mail.gmail.com>
	<9ea8d6030811051251u5e576b60ja99cbac0cc2fa36e@mail.gmail.com>
Message-ID: <20081106083332.go6kdpogqcoooco0@mail.progw.org>

Quoting Chris Johnson <cxjohnson at gmail.com>:

> On Wed, Nov 5, 2008 at 10:01 AM, Nathaniel Catchpole
>
>> Exactly, and we're talking about core patches. Most active contrib
>> development is happening in Drupal 6, I generally don't see many patches
>> posted for Drupal 4.7 versions of contrib modules, or even Drupal 5
>> depending on which module it is.
>
>
> We were?  (talking about core patches?)
>
> I don't see that in this thread.  We were talking about all patches,
> as far as I could tell.
>

Until today, I've been talking about core patches.

> The arguments are indeed very different for core and contrib.
>

Indeed they are and the mechanism for contrib isn't the same nor as 
strong a force as core either.

> I was positing primarily about contrib, since that's where most of the
> need is.  Still, there is a problem with core issue queues
> languishing, too.

There are patches for core that are months, years old.  Yes, they 
languish because no one tests and marks RTBC.  So, naturally there are 
contrib patches that are also old.  But those are more maintainer time 
related.  However if those interested in a contrib patch reviewed and 
tested it then maybe the maintainer would be more willing to commit it.

> I can't remember the last time I posted a patch to
> core; it's become too hard for me to contribute meaningful new core
> code and get attention to it.
>

Is that due to lack of reviewers?  It seems people think there is a 
vast set of developers for core, that just isn't true.  There are a few 
that know the ins and outs of core by heart but you only need a hand 
full of fingers to count those.  Find a bug submit a patch, hope for a 
reviewer, don't be offended by any action of any reviewer, press 
forward and patch.

Earnie  http://r-feed.com
  Make a Drupal difference and review core patches.

From darrel.opry at gmail.com  Thu Nov  6 14:34:28 2008
From: darrel.opry at gmail.com (Darrel O'Pry)
Date: Thu, 6 Nov 2008 09:34:28 -0500
Subject: [development] Reviewing patches and making decisions ->
	Sociocracy could be a way to go!
In-Reply-To: <200811052201.32496.tz@it-arts.org>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<200811052201.32496.tz@it-arts.org>
Message-ID: <bfcbb6230811060634v2b867cfg9e6d2a713ab5f2a6@mail.gmail.com>

On Wed, Nov 5, 2008 at 4:01 PM, Thomas Zahreddin <tz at it-arts.org> wrote:

> Hallo,
>
> thank you for bringing this topic up.
>
> Since a long time I'm unsatisfied with this process.
>
> (@ Dries:  this is the e-mail i announced to you in Szeged)
>
>
> > Hello,
> >
> > Having followed this thread for a while, I decided to do my bit, and
> start
> > reviewing patches. I didn't get very far ; I stopped at the first patch.
> >
> > Not because of the code - I could understand what the original code did,
> > and what the patched code did - but because there are two decisions to be
> > made :
> >
> > 1. In that case - and I guess this is not uncomon - the old behaviour
> might
> > be a bug, but it might have been by design. I have no way of telling.
> >
>
> (caution: Ironical!) Oh, I can't count how often i heard: "the code tells
> it
> all!" or "read my code first" or "only code counts, not the words about it"
> ..
>
> Yes I can read the code but the question above can not be answered by
> reading
> the code - much more helpful would be a comment what the _aim_ of some
> lines
> of code is.
>
> And maybe the group working on and with that particular module has a list
> of
> decisions (not a mailinglist) and why they where made - so one could go
> back
> to the original decision (should be referenced in the code) and look up
> what
> the original intention was.
>
> Do you agree that these information could help a lot in similar
> situaltions?


This is what proper commenting is for.  Compare the two leading lines below.

//  iterate over items and trim away any whitespace.
//  trim items, whitespace coming in as a part of user input was breaking
sorting later. see #889844
foreach($items as $i => $j) {
  $items[$i] = trim($j);
}

again something you can't do anything about besides trying to grok the code
and comment it or ask the original developer.

> 2. Changing the old behaviour to the new one could break old modules that
> > implicitely relied on the old behaviour. Again, this is probably not
> > uncomon. How do I weight the importance of the patch vs stability of old
> > modules ?
>
> IMHO persons, interested in a module (like programmers and users of this or
> a
> compatible module), shall have the possiblity to be heard with their
> requirements. It is up to the maintainer (or moderater) to listen to all
> and
> their arguments what is urgent and /or important and to come up with
> suggestions to which most (if not all) people can agree. The final decision
> is
> up to the maintainer (keeping in mind the long term goals, all persons
> interested in the module and the available resources) in cooperation with
> the
> person willing to contribute (e.g. code).
>
> 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
> modul.
>
> 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 Sociocratic Principles and Methods. Sociocracy.info
> Press. ISBN 978-0-9792827-0-6.
>

Maintainers are already pressed for time... at least in contrib, I seriously
doubt you will convince maintainers to keep such a list separate from inline
comments.

> So what do I do next ? I don't have a sufficient overview of that part of
> > Drupal to make such decisions myself. Should I mark it as reviewed, and
> add
> > as a note what the potential implications are ? Or is there another
> process
> > to follow in such situations ?
>
> I agree absoluty: We do not have approriate structures in the drupal
> community
> to work efficently, make decissions traceable, keeping the teamspirit up
> and
> stay open for new developers to join.
>
> I'm aware of: there are ca. one million notes on drupal.org, some IRC-
> channels, conferences, groups.drupal.org, mailinglists like this one, a
> CVS-
> Repository ...
> - but you can imagin alone by this list how hard it is to follow all
> relevant
> information / decissions.
>
> So I suggest to read a little about Sociocracy and start discussing our
> decision making process.


IMHO: too much overhead , too few concrete suggestions, something that will
get talked about a lot and nothing will come of it.

google + api.drupal.org + inline comments + test cases  should provide
sufficient information to make most of your decisions. Nothing can replace a
solid understanding of the code you're reviewing.

.darrel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081106/6e259dc3/attachment.htm 

From eric.schaefer at eas-consulting.de  Thu Nov  6 16:01:04 2008
From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer)
Date: Thu, 06 Nov 2008 17:01:04 +0100
Subject: [development] Voting on issues (was Re: How to post
	bug	reportsandpatches)
In-Reply-To: <61bca48a0811052233w6be44d66yf08195cfdfe7939e@mail.gmail.com>
References: <004801c93ea5$d69cb550$0200a8c0@structworks.com>	<200811050154.36139.larry@garfieldtech.com>	<F0CA9470-2524-41D4-8918-E70143A3D91F@dwwright.net>	<49125460.3010808@gmail.com>
	<61bca48a0811052233w6be44d66yf08195cfdfe7939e@mail.gmail.com>
Message-ID: <491314C0.1090301@eas-consulting.de>

Dries Buytaert schrieb:
> I don't have a need for issue voting at this point.  A subscribe
> feature would be more useful.

+1 (for easy issue subscription w/o a new comment)

Eric

From catch56 at googlemail.com  Thu Nov  6 16:08:17 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 6 Nov 2008 16:08:17 +0000
Subject: [development] Voting on issues (was Re: How to post bug
	reportsandpatches)
In-Reply-To: <491314C0.1090301@eas-consulting.de>
References: <004801c93ea5$d69cb550$0200a8c0@structworks.com>
	<200811050154.36139.larry@garfieldtech.com>
	<F0CA9470-2524-41D4-8918-E70143A3D91F@dwwright.net>
	<49125460.3010808@gmail.com>
	<61bca48a0811052233w6be44d66yf08195cfdfe7939e@mail.gmail.com>
	<491314C0.1090301@eas-consulting.de>
Message-ID: <fa5724270811060808s2d2d98aey6adc9674fe7ff154@mail.gmail.com>

For issue subscriptions, there's a  patch, which needs review (of course)
here: http://drupal.org/node/34496

On Thu, Nov 6, 2008 at 4:01 PM, Eric-Alexander Schaefer  wrote:

> Dries Buytaert schrieb:
>
>> I don't have a need for issue voting at this point.  A subscribe
>> feature would be more useful.
>>
>
> +1 (for easy issue subscription w/o a new comment)
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081106/70ddf0ee/attachment.htm 

From fsilva.pt at gmail.com  Thu Nov  6 16:35:44 2008
From: fsilva.pt at gmail.com (Fernando Silva)
Date: Thu, 6 Nov 2008 16:35:44 +0000
Subject: [development] Change menu structure at runtime
Message-ID: <e8e8c0a80811060835v348c684ft4b00f371cb3b39f3@mail.gmail.com>

Hi,

I want to do a "strange" thing with the (Drupal 6) menu system.

After defining a menu structure, let's assume that it is a "primary
navigation", when viewing a node page I want that page to be under a
specific menu item in the menu "primary links".

See this:
- primary navigation
-- menu 1
-- menu 2
-- menu 3
---- node/80 (this will be changed at runtime)

That "node/80" path will be the child of a menu item, according to
some conditionals that I have in hook_nodeapi. So the question is: can
I alter the menu structure at runtime, while not changing database or
persisting those changes?

Or perhaps there is another solution...

Thanks,
  Fernando

From news at unleashedmind.com  Thu Nov  6 16:50:41 2008
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Thu, 6 Nov 2008 17:50:41 +0100
Subject: [development] Change menu structure at runtime
In-Reply-To: <e8e8c0a80811060835v348c684ft4b00f371cb3b39f3@mail.gmail.com>
Message-ID: <02a001c9402f$cdfcff00$0200a8c0@structworks.com>

http://drupal.org/project/menutrails 

> -----Original Message-----
> From: development-bounces at drupal.org 
> [mailto:development-bounces at drupal.org] On Behalf Of Fernando Silva
> Sent: Thursday, November 06, 2008 5:36 PM
> To: development at drupal.org
> Subject: [development] Change menu structure at runtime
> 
> Hi,
> 
> I want to do a "strange" thing with the (Drupal 6) menu system.
> 
> After defining a menu structure, let's assume that it is a 
> "primary navigation", when viewing a node page I want that 
> page to be under a specific menu item in the menu "primary links".
> 
> See this:
> - primary navigation
> -- menu 1
> -- menu 2
> -- menu 3
> ---- node/80 (this will be changed at runtime)
> 
> That "node/80" path will be the child of a menu item, 
> according to some conditionals that I have in hook_nodeapi. 
> So the question is: can I alter the menu structure at 
> runtime, while not changing database or persisting those changes?
> 
> Or perhaps there is another solution...
> 
> Thanks,
>   Fernando
> 


From winborn at advomatic.com  Thu Nov  6 14:36:18 2008
From: winborn at advomatic.com (Aaron Winborn)
Date: Thu, 06 Nov 2008 09:36:18 -0500
Subject: [development] Reviewing patches and making decisions
 ->	Sociocracy could be a way to go!
In-Reply-To: <49127B46.6080107@webchick.net>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<200811052201.32496.tz@it-arts.org> <49127B46.6080107@webchick.net>
Message-ID: <491300E2.3070202@advomatic.com>

What's the 'standard commit message pattern'? I thought I read once it 
was something like '#nid/username: comment', but can't find that 
anywhere. For readability, I just copy the comments from my changelogs, 
which usually follows something like 'Month, Year\n-----------\n * #nid: 
comment (username).' (Leaving out the M/Y obviously, since that's 
already present in the CVS logs). But I'd like to do this properly in 
the future.

Thanks,
Aaron

Angela Byron wrote:
>
> This is actually a feature built into CVS (and most other version 
> control systems) called CVS Annotate that does exactly that:
> http://www.lullabot.com/articles/cvs_annotate_or_what_the_heck_were_they_thinking 
>
>
> For every line of code, you can discover who made the change, when 
> they made it, and why. Assuming the maintainer is following standard 
> commit message patterns, you can also reference the original issue 
> that has all the background information on discussions on the code 
> that were had, the development evolution of the feature over time, and 
> why the decision was ultimately made to commit it.
>
> It's a pretty awesome resource because it's automatically updated with 
> every commit, without the need for any manual intervention or extra 
> overhead.
>
> -Angie
>


-- 
Aaron Winborn

Advomatic, LLC
http://advomatic.com/

Drupal Multimedia Available Now!
http://www.packtpub.com/create-multimedia-website-with-drupal/book

My blog:
http://aaronwinborn.com/


From news at unleashedmind.com  Thu Nov  6 17:06:11 2008
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Thu, 6 Nov 2008 18:06:11 +0100
Subject: [development] Reviewing patches and making decisions
	->	Sociocracy could be a way to go!
In-Reply-To: <491300E2.3070202@advomatic.com>
Message-ID: <02a701c94031$f86f7900$0200a8c0@structworks.com>

http://www.google.de/search?q=commit+messages+site%3Adrupal.org 

> -----Original Message-----
> From: development-bounces at drupal.org 
> [mailto:development-bounces at drupal.org] On Behalf Of Aaron Winborn
> Sent: Thursday, November 06, 2008 3:36 PM
> To: development at drupal.org
> Subject: Re: [development] Reviewing patches and making 
> decisions -> Sociocracy could be a way to go!
> 
> What's the 'standard commit message pattern'? I thought I 
> read once it was something like '#nid/username: comment', but 
> can't find that anywhere. For readability, I just copy the 
> comments from my changelogs, which usually follows something 
> like 'Month, Year\n-----------\n * #nid: 
> comment (username).' (Leaving out the M/Y obviously, since 
> that's already present in the CVS logs). But I'd like to do 
> this properly in the future.
> 
> Thanks,
> Aaron
> 
> Angela Byron wrote:
> >
> > This is actually a feature built into CVS (and most other version 
> > control systems) called CVS Annotate that does exactly that:
> > 
> http://www.lullabot.com/articles/cvs_annotate_or_what_the_heck_were_th
> > ey_thinking
> >
> >
> > For every line of code, you can discover who made the change, when 
> > they made it, and why. Assuming the maintainer is following 
> standard 
> > commit message patterns, you can also reference the original issue 
> > that has all the background information on discussions on the code 
> > that were had, the development evolution of the feature 
> over time, and 
> > why the decision was ultimately made to commit it.
> >
> > It's a pretty awesome resource because it's automatically 
> updated with 
> > every commit, without the need for any manual intervention or extra 
> > overhead.
> >
> > -Angie
> >
> 
> 
> --
> Aaron Winborn
> 
> Advomatic, LLC
> http://advomatic.com/
> 
> Drupal Multimedia Available Now!
> http://www.packtpub.com/create-multimedia-website-with-drupal/book
> 
> My blog:
> http://aaronwinborn.com/
> 


From justin.randell at gmail.com  Fri Nov  7 03:50:07 2008
From: justin.randell at gmail.com (justin randell)
Date: Fri, 7 Nov 2008 14:50:07 +1100
Subject: [development] opt-in performance benchmarking on d.o.
Message-ID: <34a99ab40811061950g45228b75t3c1ab3733cb91d67@mail.gmail.com>

hi all,

i've been watching the inspiring work to integrate testing patches
against HEAD at testing.drupal.org, and wondering if it would be
useful/possible/desirable to have benchmarking integrated into d.o. as
well?

like the testing stuff, but maybe opt-in?

i'd be willing to do some dev/sysadmin work, and i'd hope there would
be enough dev resources, but we'd need some hardware dedicated to it.

thoughts? suggestions? flames?

cheers
justin

From drupal-devel at webchick.net  Fri Nov  7 04:21:25 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Thu, 06 Nov 2008 23:21:25 -0500
Subject: [development] Reviewing patches and making decisions ->
 Sociocracy could be a way to go!
In-Reply-To: <200811061219.43428.tz@it-arts.org>
References: <200811041930.58199.anselm_list@netuxo.co.uk>	<200811052201.32496.tz@it-arts.org>
	<49127B46.6080107@webchick.net> <200811061219.43428.tz@it-arts.org>
Message-ID: <4913C245.5040808@webchick.net>

On 11/6/08 6:19 AM, Thomas Zahreddin wrote:
> Hi Angie,
>
> thank you for answering the first third of my mail. I think we are not on the
> same page:
>
> in the last third I wrote explicit, that I know all the tools and places where
> to find informations - but i also mention that it is impossible to follow all
> relevant information.
>
> To lower the workload for us all we need a summery on a much higher level than
> CVS-messages (btw how many do we count a day - my estimation is two a minute).

I answered the first third, because it seemed to me that the last two 
thirds were based on the presumption that the information you seek is 
not readily available. But CVS annotate seems to do exactly what you 
request and it requires no manual effort on the part of our already 
over-burdened maintainers to keep up to date, since it's updated 
automatically with every commit.

In what specific ways does CVS annotate not get you what you're asking 
for? That would probably help the justification for your proposal be a 
bit more clear.

-Angie

From metzlerd at metzlerd.com  Fri Nov  7 05:28:13 2008
From: metzlerd at metzlerd.com (David Metzler)
Date: Thu, 6 Nov 2008 21:28:13 -0800
Subject: [development] Reviewing patches and making decisions ->
	Sociocracy could be a way to go!
In-Reply-To: <4913C245.5040808@webchick.net>
References: <200811041930.58199.anselm_list@netuxo.co.uk>	<200811052201.32496.tz@it-arts.org>
	<49127B46.6080107@webchick.net> <200811061219.43428.tz@it-arts.org>
	<4913C245.5040808@webchick.net>
Message-ID: <D2E5ADB7-7088-41EF-ABF6-65D08B652AB4@metzlerd.com>

Funny that I was having just this discussion with my Dev team at work  
today.  How shall we document how/why something works.   I think most  
of the folks agreed that closer to the code is better. So comments is  
the best answer but it's often difficult to document how disparate  
modules connect in code comments.

Another resource that we have that's not used as much as it could be  
is the API module and it's document generation techniques.  It  
already documents much of the bigger picture with core modules.   
Correct me if I'm wrong, but cannot developers maintain "extra"  
technical documentation in a separate document along with their  
modules in CVS?  That might be a good thing to version control, but  
keep a static document, that feeds api documentation. I know this is  
possible with other modules such as Doxygen, but am not sure that it  
works in API module. (but I bet it could). This is the solution we  
landed on in my dev shop.

That way rational/design info could(should?) be supplied with  
patches.  In separate documentation and it would help those who do  
patch review understand how/why something is supposed to work before  
it gets committed.

You see that's the one problem with using CVS annotate.  The commiter  
provides that message, but the patch submitter is the one who needs  
to supply the documentation :).  And remember our goal here is to  
make it easier for the review/commit phase, so adding doc work to the  
commiter is counter productive.

So I like using CVS for why something changed, but not how something  
is supposed to work.  That needs to be in code comments or lean text  
base documentation that goes with the code.

But perhaps we near exhausting all that can be said on this issue.

On Nov 6, 2008, at 8:21 PM, Angela Byron wrote:

> On 11/6/08 6:19 AM, Thomas Zahreddin wrote:
>> Hi Angie,
>>
>> thank you for answering the first third of my mail. I think we are  
>> not on the
>> same page:
>>
>> in the last third I wrote explicit, that I know all the tools and  
>> places where
>> to find informations - but i also mention that it is impossible to  
>> follow all
>> relevant information.
>>
>> To lower the workload for us all we need a summery on a much  
>> higher level than
>> CVS-messages (btw how many do we count a day - my estimation is  
>> two a minute).
>
> I answered the first third, because it seemed to me that the last  
> two thirds were based on the presumption that the information you  
> seek is not readily available. But CVS annotate seems to do exactly  
> what you request and it requires no manual effort on the part of  
> our already over-burdened maintainers to keep up to date, since  
> it's updated automatically with every commit.
>
> In what specific ways does CVS annotate not get you what you're  
> asking for? That would probably help the justification for your  
> proposal be a bit more clear.
>
> -Angie


From drupal at ryancross.com  Fri Nov  7 09:13:14 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Fri, 7 Nov 2008 20:13:14 +1100
Subject: [development] opt-in performance benchmarking on d.o.
In-Reply-To: <34a99ab40811061950g45228b75t3c1ab3733cb91d67@mail.gmail.com>
References: <34a99ab40811061950g45228b75t3c1ab3733cb91d67@mail.gmail.com>
Message-ID: <4e983be00811070113i3b8d152br4d931c5d599146f4@mail.gmail.com>

I think it is an interesting idea and having performance benchmarking
hardware available could be quite useful.
However, I think it would have to be opt-in at the very least since I think
benchmarking really needs to be addressed as a whole instead of on a
patch-by-patch basis. I think it also has the potential to bias our work to
one particular setup when we know that there are many variations in the
stack that can have a big effect on performance (OS, hardware, php versions,
Web server, db, etc)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081107/f7d87efe/attachment.htm 

From catch56 at googlemail.com  Fri Nov  7 10:18:09 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Fri, 7 Nov 2008 10:18:09 +0000
Subject: [development] Reviewing patches and making decisions ->
	Sociocracy could be a way to go!
In-Reply-To: <D2E5ADB7-7088-41EF-ABF6-65D08B652AB4@metzlerd.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<200811052201.32496.tz@it-arts.org> <49127B46.6080107@webchick.net>
	<200811061219.43428.tz@it-arts.org> <4913C245.5040808@webchick.net>
	<D2E5ADB7-7088-41EF-ABF6-65D08B652AB4@metzlerd.com>
Message-ID: <fa5724270811070218t6d89d323o3e40eea60be1f0b@mail.gmail.com>

Just quickly on committing api.module documentation along with patches - I
started an issue here to have the hook_* documentation committed to core:
http://drupal.org/node/314870 - which I think goes at least some way towards
what you're describing.

Nat

On Fri, Nov 7, 2008 at 5:28 AM, David Metzler  wrote:

> Funny that I was having just this discussion with my Dev team at work
> today.  How shall we document how/why something works.   I think most of the
> folks agreed that closer to the code is better. So comments is the best
> answer but it's often difficult to document how disparate modules connect in
> code comments.
>
>
> That way rational/design info could(should?) be supplied with patches.  In
> separate documentation and it would help those who do patch review
> understand how/why something is supposed to work before it gets committed.
>
> You see that's the one problem with using CVS annotate.  The commiter
> provides that message, but the patch submitter is the one who needs to
> supply the documentation :).  And remember our goal here is to make it
> easier for the review/commit phase, so adding doc work to the commiter is
> counter productive.
>
> So I like using CVS for why something changed, but not how something is
> supposed to work.  That needs to be in code comments or lean text base
> documentation that goes with the code.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081107/cbeb24aa/attachment-0001.htm 

From chad at apartmentlines.com  Fri Nov  7 16:36:20 2008
From: chad at apartmentlines.com (Chad Phillips -- Apartment Lines)
Date: Fri, 7 Nov 2008 09:36:20 -0700
Subject: [development] d.o schedule maintenance, time correction
In-Reply-To: <mailman.14850.1226053093.9743.development@drupal.org>
References: <mailman.14850.1226053093.9743.development@drupal.org>
Message-ID: <08435AAF-CB50-4C10-9AAA-5F273076FB43@apartmentlines.com>

apologies, folks, the maintenance window for drupal.org is sat, nov.  
8th at 2am, not today the 7th as i had originally posted.

i've corrected the announcement on the front page of d.o.

sorry for the misunderstanding.  i hate timezones.

chad

From gordon at heydon.com.au  Sun Nov  9 23:31:07 2008
From: gordon at heydon.com.au (Gordon Heydon)
Date: Mon, 10 Nov 2008 10:31:07 +1100
Subject: [development] jQuery Gradient Plugin
Message-ID: <3136A75C-54C1-413D-A7CE-FA7A1920179F@heydon.com.au>

Hi,

I was wondering if anyone has used this plugin http://plugins.jquery.com/project/gradient 
  as part of the theming on their site.

I have been trying to get it going but it is breaking all the Drupal  
js and other things. I was wondering if any has any ideas.

Gordon.

From gabor at hojtsy.hu  Mon Nov 10 12:00:31 2008
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Mon, 10 Nov 2008 13:00:31 +0100
Subject: [development] Outstanding issues with .htaccess,
	settings.php or robots.txt on Drupal 6?
Message-ID: <86ca3ccb0811100400w465c59b7lfa403664840f5032@mail.gmail.com>

Hi,

With each Drupal 6 release, we made it a best practice to include a
note in the related SA that "the settings.php, robots.txt and
.htaccess files have not changed and can be left as they are if
upgrading from the current version of Drupal".

As part of my usual Drupal 6 branch maintenance, I've worked down the
RTBC queue for Drupal 6 to two issues:

 - http://drupal.org/node/28776 - Protect svn files in .htaccess
(which also protects .test files on the Drupal 6 patch)
 - http://drupal.org/node/299582 - Update robots.txt to remove
obsolete items and order existing ones in alphabetical order

If we do change any of the three files, I think it is better to do
them all at once and then try to stay away from touching them for
another lengthy period to help people apply changes to these three
files which are most likely patched on a considerable number of Drupal
installs.

Therefore I am asking if you have any issues with these existing two
patches to sound your concerns before they are committed (avoid the
next Drupal version to come with changes to these files). Also, if you
have other issues against these files, which you think should be
resolved sooner then later, it is the time to put them into the
spotlight.

G?bor

From z.stolar at gmail.com  Mon Nov 10 12:51:31 2008
From: z.stolar at gmail.com (=?UTF-8?B?15bXlNeoINeh15jXldec16ggLSDXnNeZ16DXldeV15nXmdeY?=)
Date: Mon, 10 Nov 2008 14:51:31 +0200
Subject: [development] Outstanding issues with .htaccess,
 settings.php or robots.txt on Drupal 6?
In-Reply-To: <86ca3ccb0811100400w465c59b7lfa403664840f5032@mail.gmail.com>
References: <86ca3ccb0811100400w465c59b7lfa403664840f5032@mail.gmail.com>
Message-ID: <49182E53.4050202@linnovate.net>



G?bor Hojtsy wrote:

> Therefore I am asking if you have any issues with these existing two
> patches to sound your concerns before they are committed (avoid the
> next Drupal version to come with changes to these files). Also, if you
> have other issues against these files, which you think should be
> resolved sooner then later, it is the time to put them into the
> spotlight.
>   
If user-friendliness is a desired goal, then maybe it's the opportunity 
to uncomment one of the suggestions in .htaccess, regarding the access 
to the site with/without the www prefix (preferably keeping the one WITH 
www).
Having them both creates duplicates (any seo expert around here to 
explain the effect of that?), and by default it is not sharing session 
cookies (last time I checked at least), which leads to confusions ("hey! 
why am I thrown out of that site?!").
Probably many of the mentioned patches to this file, are in these lines.
Savvy users will probably know how to change the values, if they really 
need to.


From gabor at hojtsy.hu  Mon Nov 10 13:07:35 2008
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Mon, 10 Nov 2008 14:07:35 +0100
Subject: [development] Outstanding issues with .htaccess,
	settings.php or robots.txt on Drupal 6?
In-Reply-To: <49182E53.4050202@linnovate.net>
References: <86ca3ccb0811100400w465c59b7lfa403664840f5032@mail.gmail.com>
	<49182E53.4050202@linnovate.net>
Message-ID: <86ca3ccb0811100507r1175e788p996a12f57aaa6a4b@mail.gmail.com>

On what Drupal project issue URL is this suggestion tracked?

G?bor

On Mon, Nov 10, 2008 at 1:51 PM, ??? ????? - ????????
<z.stolar at gmail.com> wrote:
>
>
> G?bor Hojtsy wrote:
>
>> Therefore I am asking if you have any issues with these existing two
>> patches to sound your concerns before they are committed (avoid the
>> next Drupal version to come with changes to these files). Also, if you
>> have other issues against these files, which you think should be
>> resolved sooner then later, it is the time to put them into the
>> spotlight.
>>
>
> If user-friendliness is a desired goal, then maybe it's the opportunity to
> uncomment one of the suggestions in .htaccess, regarding the access to the
> site with/without the www prefix (preferably keeping the one WITH www).
> Having them both creates duplicates (any seo expert around here to explain
> the effect of that?), and by default it is not sharing session cookies (last
> time I checked at least), which leads to confusions ("hey! why am I thrown
> out of that site?!").
> Probably many of the mentioned patches to this file, are in these lines.
> Savvy users will probably know how to change the values, if they really need
> to.
>
>

From z.stolar at gmail.com  Mon Nov 10 13:34:42 2008
From: z.stolar at gmail.com (Zohar Stolar - Linnovate)
Date: Mon, 10 Nov 2008 15:34:42 +0200
Subject: [development] Outstanding issues with .htaccess,
 settings.php or robots.txt on Drupal 6?
In-Reply-To: <86ca3ccb0811100507r1175e788p996a12f57aaa6a4b@mail.gmail.com>
References: <86ca3ccb0811100400w465c59b7lfa403664840f5032@mail.gmail.com>	
	<49182E53.4050202@linnovate.net>
	<86ca3ccb0811100507r1175e788p996a12f57aaa6a4b@mail.gmail.com>
Message-ID: <49183872.5020803@linnovate.net>


I was uncertain (still am) about the necessity of this modification, so 
I didn't create an issue yet.

Here's where it is now: http://drupal.org/node/332439


I also came across this one: http://drupal.org/node/69262



G?bor Hojtsy wrote:

> On what Drupal project issue URL is this suggestion tracked?
>
> G?bor
>
> On Mon, Nov 10, 2008 at 1:51 PM, ??? ????? - ????????
> <z.stolar at gmail.com> wrote:
>   
>> G?bor Hojtsy wrote:
>>
>>     
>>> Therefore I am asking if you have any issues with these existing two
>>> patches to sound your concerns before they are committed (avoid the
>>> next Drupal version to come with changes to these files). Also, if you
>>> have other issues against these files, which you think should be
>>> resolved sooner then later, it is the time to put them into the
>>> spotlight.
>>>
>>>       
>> If user-friendliness is a desired goal, then maybe it's the opportunity to
>> uncomment one of the suggestions in .htaccess, regarding the access to the
>> site with/without the www prefix (preferably keeping the one WITH www).
>> Having them both creates duplicates (any seo expert around here to explain
>> the effect of that?), and by default it is not sharing session cookies (last
>> time I checked at least), which leads to confusions ("hey! why am I thrown
>> out of that site?!").
>> Probably many of the mentioned patches to this file, are in these lines.
>> Savvy users will probably know how to change the values, if they really need
>> to.
>>
>>
>>     



From adam.j.cooper at gmail.com  Mon Nov 10 15:39:50 2008
From: adam.j.cooper at gmail.com (Adam Cooper)
Date: Mon, 10 Nov 2008 15:39:50 +0000
Subject: [development] Outstanding issues with .htaccess,
	settings.php or robots.txt on Drupal 6?
In-Reply-To: <86ca3ccb0811100400w465c59b7lfa403664840f5032@mail.gmail.com>
References: <86ca3ccb0811100400w465c59b7lfa403664840f5032@mail.gmail.com>
Message-ID: <52E27947-8F9B-4784-83DE-9513FC13A958@gmail.com>

I've had an issue open for a long while now that I hoped would help  
people with multisite and www/non-www domains.

http://drupal.org/node/158445

It's been open since pre Drupal 6 and has had a few re-rolls. I've not  
done promotion of it because I'm the type of person to let sleeping  
dogs lie but I think that it should probably be considered with these  
other issues.

Hopefully this can be moved forward.

Thanks
Adam

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.


From myown.linux at gmail.com  Mon Nov 10 17:20:31 2008
From: myown.linux at gmail.com (My Own Linux)
Date: Mon, 10 Nov 2008 22:50:31 +0530
Subject: [development] how to start a drupal like project
Message-ID: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>

I want to write my own open source web application and make it as flexible
and usable as drupal. I have no experience with a project this size. How do
I go about it ? What do I need to do first and how do I plan the project ? I
dont know where to start. I need to know the core technical side of project
planning (not the hosting, cvs, etc..)

data structures
file system layouts
theme, modules support, etc..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081110/6fff6817/attachment.htm 

From anthony at thrillist.com  Mon Nov 10 17:21:25 2008
From: anthony at thrillist.com (Anthony Wlodarski)
Date: Mon, 10 Nov 2008 12:21:25 -0500
Subject: [development] how to start a drupal like project
In-Reply-To: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
Message-ID: <49186D95.20201@thrillist.com>

Why not just use Drupal?

-Anthony

My Own Linux wrote:
> I want to write my own open source web application and make it as 
> flexible and usable as drupal. I have no experience with a project 
> this size. How do I go about it ? What do I need to do first and how 
> do I plan the project ? I dont know where to start. I need to know the 
> core technical side of project planning (not the hosting, cvs, etc..)
>
> data structures
> file system layouts
> theme, modules support, etc..
>
>
>


From sysop at scbbs.com  Mon Nov 10 20:09:14 2008
From: sysop at scbbs.com (Ron Parker)
Date: Mon, 10 Nov 2008 12:09:14 -0800 (PST)
Subject: [development] Display Search Results as they are Located
Message-ID: <13856418.5951226347754448.JavaMail.root@zimbra.thefiengroup.com>




I have a custom search. Right now, the search results page is displayed after the search is completed. 

Is there a way to display the search results as they are located? 




For example, in the hook_search api http://api.drupal.org/api/function/hook_search/5 , this is how the results are located in a generic custom search: 

<?php 
case 'search' : 
$find = do_search ( $keys , 'node' , 'INNER JOIN {node} n ON n.nid = i.sid ' . node_access_join_sql () . ' INNER JOIN {users} u ON n.uid = u.uid' , 'n.status = 1 AND ' . node_access_where_sql ()); 
$results = array(); 
foreach ( $find as $item ) { 
$node = node_load (array( 'nid' => $item )); 
$extra = node_invoke_nodeapi ( $node , 'search result' ); 
$results [] = array( 'link' => url ( 'node/' . $item ), 
'type' => node_invoke ( $node , 'node_name' ), 
'title' => $node -> title , 
'user' => theme ( 'username' , $node ), 
'date' => $node -> changed , 
'extra' => $extra , 
'snippet' => search_excerpt ( $keys , check_output ( $node -> body , $node -> format ))); 
} 
return $results ; 
?> 
What I am asking: Is there a way to print each $result[] item as it is located rather than returning the $results array to print the page after the search is completed? 




My problem is that my custom search uses a 3rd party search, then I have to parse the those results using a query to a Drupal table. Then, I populate the $results array. This is taking a very long time, but I don't see a lot of ways round it. What would give the impression of it not taking so long would be if the search results started popping up immediately. 




Thanks for any suggestions. 





-ron 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081110/16d9d995/attachment.htm 

From citizenofgnu at gmail.com  Mon Nov 10 20:17:56 2008
From: citizenofgnu at gmail.com (=?UTF-8?B?4K6k4K6/4K6v4K6+4K6V4K6w4K6+4K6c4K6p4K+N?=)
Date: Tue, 11 Nov 2008 01:47:56 +0530
Subject: [development] how to start a drupal like project
In-Reply-To: <49186D95.20201@thrillist.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<49186D95.20201@thrillist.com>
Message-ID: <ed2d3c000811101217y35d74b91t4f75cf575d4960a7@mail.gmail.com>

Hi,
Not to discourage you in your efforts, IMHO, It will be nice if you
contribute your efforts with Drupal.


just to quote an old saying "Re-inventing a wheel is crime".

cheers,
Thyagarajan Shanmugham

From anton.list at gmail.com  Mon Nov 10 20:21:17 2008
From: anton.list at gmail.com (Anton)
Date: Tue, 11 Nov 2008 09:21:17 +1300
Subject: [development] how to start a drupal like project
In-Reply-To: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
Message-ID: <45811f70811101221ld59376ege02d21b08d1c98c8@mail.gmail.com>

2008/11/11 My Own Linux <myown.linux at gmail.com>:
> I want to write my own open source web application and make it as flexible
> and usable as drupal. I have no experience with a project this size. How do
> I go about it ? What do I need to do first and how do I plan the project ? I
> dont know where to start. I need to know the core technical side of project
> planning (not the hosting, cvs, etc..)

1. Scratch an itch you care about
2. Inspire other people to join in and help you out
3. Keep improving your codebase
4. Repeat the above steps for 5-10 years
5. ???
6. Profit

Seriously though, if you start out to write a project the size and
scope of Drupal with the same amount of flexibility by yourself in
your spare time you will never finish it. You need to make something
much smaller and simpler that is still useful, then build a community
around it to help you incrementally build it to something bigger over
time.

If you want to see how Drupal or other projects do stuff for
inspiration, just look at their code.

But you're far better off just joining an existing project.

-- 
Cheers
Anton

From tz at it-arts.org  Mon Nov 10 21:09:58 2008
From: tz at it-arts.org (Thomas Zahreddin)
Date: Mon, 10 Nov 2008 22:09:58 +0100
Subject: [development] how to start a drupal like project
In-Reply-To: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
Message-ID: <200811102209.58998.tz@it-arts.org>

Am Montag 10 November 2008 18:20:31 schrieb My Own Linux:
> I want to write my own open source web application and make it as flexible
> and usable as drupal. I have no experience with a project this size. How do
> I go about it ? What do I need to do first and how do I plan the project ?
> I dont know where to start. I need to know the core technical side of
> project planning (not the hosting, cvs, etc..)
>
> data structures
> file system layouts
> theme, modules support, etc..

I can't imagen any project you could not write as a drupal module (and there 
exist realy big modules with for example 30 MB).

your Application can use drupal as a Framework.

- so what answer do you expect here ;-)


Best 
Thomas Zahreddin
Cofounder of http://VoiceHero.net

From drupal at samboyer.org  Mon Nov 10 21:53:29 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Mon, 10 Nov 2008 15:53:29 -0600
Subject: [development] Reviewing patches and making decisions ->
	Sociocracy could be a way to go!
In-Reply-To: <D2E5ADB7-7088-41EF-ABF6-65D08B652AB4@metzlerd.com>
References: <200811041930.58199.anselm_list@netuxo.co.uk>
	<4913C245.5040808@webchick.net>
	<D2E5ADB7-7088-41EF-ABF6-65D08B652AB4@metzlerd.com>
Message-ID: <200811101553.33649.drupal@samboyer.org>

drumm and I talked a fair bit about this in Szeged, and I have a todo list 
gathering dust on my desk for writing up some of the specifics pertaining to 
this, but...

api.module has several areas that need working on - the large-scale priority 
list was a) rewrite the parser using php's tokenizer (we have also talked 
about the possibility of a Reflection-based parser, which has some problems 
but could be stupidly easy to extend), then b) port to d6. Neil/somebody, 
please do correct me if this is no longer accurate. And imo, those are top 
priority because api.module's lack of support for classes is debilitating for 
D7.

However, there are some really interesting possibilities for including 
'static' documentation, as David has suggested below. Doxygen does make it 
possible, although it's quite awkward. The Panels API documentation is done 
with doxygen, for example, and uses some such static documentation: 
http://doxy.samboyer.org/panels2/panels_api_plugins.html

I wrote that reference with the intention of it being reminiscent of 
http://api.drupal.org/api/file/developer/topics/forms_api_reference.html, 
except that it's generated directly from documentation files that are checked 
in to Panels CVS here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/panels/docs/sample_plugin_ct.inc?revision=1.1.2.3&view=markup&pathrev=DRUPAL-5--2

then generated by doxygen using the doxyfile here: 
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/panels/panels2.doxy?revision=1.1.2.8&view=markup&pathrev=DRUPAL-5--2
(the ALIASES section is the substantive, and horrifying, part)

I wouldn't wish the pain of that approach on anyone else, especially because I 
think there are a lot of better ways to do it. In particular, we might create 
our own @tags extending the standard set recognized by either phpdoc or 
doxygen. The value of an @invokes tag will be immediately obvious to most 
devs, but the potential for something like, say, @glossary tags for building 
up a network of terms for autolinking within api docs is really interesting. 
There are other possible avenues for expansion too, of course, but drumm's 
been rightfully hesitant to throw new @tags in willy-nilly. More importantly, 
though, ALL such discussion is moot until the basic rewrites and porting is 
taken care of.

cheers

Sam 

On Thursday 06 November 2008 23:28:13 David Metzler wrote:
> Funny that I was having just this discussion with my Dev team at work
> today.  How shall we document how/why something works.   I think most
> of the folks agreed that closer to the code is better. So comments is
> the best answer but it's often difficult to document how disparate
> modules connect in code comments.
>
> Another resource that we have that's not used as much as it could be
> is the API module and it's document generation techniques.  It
> already documents much of the bigger picture with core modules.
> Correct me if I'm wrong, but cannot developers maintain "extra"
> technical documentation in a separate document along with their
> modules in CVS?  That might be a good thing to version control, but
> keep a static document, that feeds api documentation. I know this is
> possible with other modules such as Doxygen, but am not sure that it
> works in API module. (but I bet it could). This is the solution we
> landed on in my dev shop.
>
> That way rational/design info could(should?) be supplied with
> patches.  In separate documentation and it would help those who do
> patch review understand how/why something is supposed to work before
> it gets committed.
>
> You see that's the one problem with using CVS annotate.  The commiter
> provides that message, but the patch submitter is the one who needs
> to supply the documentation :).  And remember our goal here is to
> make it easier for the review/commit phase, so adding doc work to the
> commiter is counter productive.
>
> So I like using CVS for why something changed, but not how something
> is supposed to work.  That needs to be in code comments or lean text
> base documentation that goes with the code.
>
> But perhaps we near exhausting all that can be said on this issue.
>
> On Nov 6, 2008, at 8:21 PM, Angela Byron wrote:
> > On 11/6/08 6:19 AM, Thomas Zahreddin wrote:
> >> Hi Angie,
> >>
> >> thank you for answering the first third of my mail. I think we are
> >> not on the
> >> same page:
> >>
> >> in the last third I wrote explicit, that I know all the tools and
> >> places where
> >> to find informations - but i also mention that it is impossible to
> >> follow all
> >> relevant information.
> >>
> >> To lower the workload for us all we need a summery on a much
> >> higher level than
> >> CVS-messages (btw how many do we count a day - my estimation is
> >> two a minute).
> >
> > I answered the first third, because it seemed to me that the last
> > two thirds were based on the presumption that the information you
> > seek is not readily available. But CVS annotate seems to do exactly
> > what you request and it requires no manual effort on the part of
> > our already over-burdened maintainers to keep up to date, since
> > it's updated automatically with every commit.
> >
> > In what specific ways does CVS annotate not get you what you're
> > asking for? That would probably help the justification for your
> > proposal be a bit more clear.
> >
> > -Angie


-------------- 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 : http://lists.drupal.org/pipermail/development/attachments/20081110/a856598e/attachment-0001.pgp 

From chad at apartmentlines.com  Mon Nov 10 23:06:22 2008
From: chad at apartmentlines.com (Chad Phillips -- Apartment Lines)
Date: Mon, 10 Nov 2008 16:06:22 -0700
Subject: [development] automated patch testing comes to drupal.org
Message-ID: <B3B523A6-4605-4BDC-861E-DA3F92B9E4F8@apartmentlines.com>

the automated patch testing framework has been enabled, and is  
currently working through the backlog of 7.x patches for the Drupal  
project on drupal.org

to avoid any surprises or frustrations that this new workflow brings  
to the development cycle, i encourage everyone to read http://drupal.org/node/332678

for issues related to the framework itself use the appropriate project  
issue queues.

for issues related to the sending and receiving of patches, display,  
auto status changes, etc:
http://drupal.org/project/issues/project_issue_file_test

for issues related to the automated testing itself:
http://drupal.org/project/issues/project_issue_file_review



From kieran at acquia.com  Mon Nov 10 23:37:34 2008
From: kieran at acquia.com (Kieran Lal)
Date: Mon, 10 Nov 2008 15:37:34 -0800
Subject: [development] automated patch testing comes to drupal.org
In-Reply-To: <B3B523A6-4605-4BDC-861E-DA3F92B9E4F8@apartmentlines.com>
References: <B3B523A6-4605-4BDC-861E-DA3F92B9E4F8@apartmentlines.com>
Message-ID: <d1d28e390811101537i148f1154r84e0d4e08877311c@mail.gmail.com>

If you have a spare server, virtual or otherwise, that can contribute
to automated patch testing please contact me off-list.

The latest version of the install instructions are here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project_issue_file_review/INSTALL.txt?revision=1.13&view=markup

Cheers,
Kieran

On Mon, Nov 10, 2008 at 3:06 PM, Chad Phillips -- Apartment Lines
<chad at apartmentlines.com> wrote:
> the automated patch testing framework has been enabled, and is currently
> working through the backlog of 7.x patches for the Drupal project on
> drupal.org
>
> to avoid any surprises or frustrations that this new workflow brings to the
> development cycle, i encourage everyone to read
> http://drupal.org/node/332678
>
> for issues related to the framework itself use the appropriate project issue
> queues.
>
> for issues related to the sending and receiving of patches, display, auto
> status changes, etc:
> http://drupal.org/project/issues/project_issue_file_test
>
> for issues related to the automated testing itself:
> http://drupal.org/project/issues/project_issue_file_review
>
>
>

From starbow at citris-uc.org  Mon Nov 10 23:50:45 2008
From: starbow at citris-uc.org (Tao Starbow)
Date: Mon, 10 Nov 2008 15:50:45 -0800
Subject: [development] automated patch testing comes to drupal.org
In-Reply-To: <B3B523A6-4605-4BDC-861E-DA3F92B9E4F8@apartmentlines.com>
References: <B3B523A6-4605-4BDC-861E-DA3F92B9E4F8@apartmentlines.com>
Message-ID: <4918C8D5.8090908@citris-uc.org>

Congratulations to everyone involved with this.  It is a huge step 
forward for Drupal as a project.

cheers,
-tao

Chad Phillips -- Apartment Lines wrote:
> the automated patch testing framework has been enabled, and is 
> currently working through the backlog of 7.x patches for the Drupal 
> project on drupal.org
>
> to avoid any surprises or frustrations that this new workflow brings 
> to the development cycle, i encourage everyone to read 
> http://drupal.org/node/332678
>
> for issues related to the framework itself use the appropriate project 
> issue queues.
>
> for issues related to the sending and receiving of patches, display, 
> auto status changes, etc:
> http://drupal.org/project/issues/project_issue_file_test
>
> for issues related to the automated testing itself:
> http://drupal.org/project/issues/project_issue_file_review
>
>

From yang_yi_cn at yahoo.com  Tue Nov 11 01:37:09 2008
From: yang_yi_cn at yahoo.com (yi yang)
Date: Mon, 10 Nov 2008 17:37:09 -0800 (PST)
Subject: [development] Project usage stats
In-Reply-To: <d1d28e390811101537i148f1154r84e0d4e08877311c@mail.gmail.com>
Message-ID: <124648.37677.qm@web52503.mail.re2.yahoo.com>

Is there anybody noticing that the project usage on Drupal.org is not updated since Oct 12th?


http://drupal.org/project/usage/drupal

Weekly project usage
Week	7.x	6.x	5.x
November 2nd	0	0	0
October 26th	0	0	0
October 19th	0	0	0
October 12th	208	63,885	20,891
October 5th	173	63,702	20,778


Regards,
Yi Yang

From fernandoparedesgarcia at gmail.com  Tue Nov 11 06:23:10 2008
From: fernandoparedesgarcia at gmail.com (=?ISO-8859-1?Q?=22Fernando_P=2E_Garc=EDa=22?=)
Date: Tue, 11 Nov 2008 01:23:10 -0500
Subject: [development] how to start a drupal like project
In-Reply-To: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
Message-ID: <491924CE.8080303@gmail.com>

you forget o mention the money :), so perhaps it helps 
http://www.damnsmalllinux.org/income-guide/intro.html

Blessings!

My Own Linux wrote:
> I want to write my own open source web application and make it as 
> flexible and usable as drupal. I have no experience with a project 
> this size. How do I go about it ? What do I need to do first and how 
> do I plan the project ? I dont know where to start. I need to know the 
> core technical side of project planning (not the hosting, cvs, etc..)
>
> data structures
> file system layouts
> theme, modules support, etc..
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fernandoparedesgarcia.vcf
Type: text/x-vcard
Size: 359 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081111/3bee76d3/attachment.vcf 

From drupal at ryancross.com  Tue Nov 11 06:39:53 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Tue, 11 Nov 2008 17:39:53 +1100
Subject: [development] how to start a drupal like project
In-Reply-To: <491924CE.8080303@gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<491924CE.8080303@gmail.com>
Message-ID: <4e983be00811102239j47c3e9beqead16ac835c4e765@mail.gmail.com>

I believe what you are looking for is mostly covered here:
http://producingoss.com

The first step is to write code that fixes the problem you're trying to
solve. Then use that link to help you release it and grow it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081111/7e518eae/attachment.htm 

From victorkane at gmail.com  Tue Nov 11 09:32:23 2008
From: victorkane at gmail.com (Victor Kane)
Date: Tue, 11 Nov 2008 07:32:23 -0200
Subject: [development] how to start a drupal like project
In-Reply-To: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
Message-ID: <ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>

Read http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

This guy did it with fetchmail. Tells you the whole story.

And you might gain valuable insight into how "I" isn't exactly as
powerful as the Gillette razor commercials try to sell you into
believing, isn't quite as powerful as a whole community, working,
testing, using, posting issues, fixing issues, over the space of, say,
a decade. "I" isn't exactly the "I" Sara Palin means when it's
actually the "we" and the nature, the character of the exploitation of
the labor force.

<offtopic>Which doesn't mean of course that Open Source is not just
another form of exploitation. It's just a "better" one in that it
makes for a better product, etc., etc., etc. But of course you didn't
ask about that.</offtopic>

Microsoft found out with Vista that the "I" business model is inferior
to the open source business model, which is why it may be looking into
webroot for IE8.

Ay, ay, ay...

Victor Kane
http://awebfactory.com.ar

On Mon, Nov 10, 2008 at 3:20 PM, My Own Linux <myown.linux at gmail.com> wrote:
> I want to write my own open source web application and make it as flexible
> and usable as drupal. I have no experience with a project this size. How do
> I go about it ? What do I need to do first and how do I plan the project ? I
> dont know where to start. I need to know the core technical side of project
> planning (not the hosting, cvs, etc..)
>
> data structures
> file system layouts
> theme, modules support, etc..
>
>
>
>

From myown.linux at gmail.com  Tue Nov 11 12:56:06 2008
From: myown.linux at gmail.com (My Own Linux)
Date: Tue, 11 Nov 2008 18:26:06 +0530
Subject: [development] how to start a drupal like project
In-Reply-To: <ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
Message-ID: <a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>

Firstly thanks to all those who replied. I would like to clear the point
that what I am making is not a CMS. I just want to make a php based web app
that is scalable like drupal and has support for themes, modules, etc.

I was looking for some pointers on the design aspect of a similar php -
mysql based projects. How to design the database, what parts of code can be
reused, how to make a project theme-able, module-able, how to design the
filesystem layouts, how to make sure its secure, structures for admin area -
user area, how to design the class and functions, how to design the page
structures, etc

ps : I have read both the books (esr, producing foss) - but they dont have
any answers for what I am looking for.

I hope this will make my question more clear :)

Excuse me for my bad english.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081111/ef7b98ad/attachment.htm 

From myown.linux at gmail.com  Tue Nov 11 13:02:45 2008
From: myown.linux at gmail.com (My Own Linux)
Date: Tue, 11 Nov 2008 18:32:45 +0530
Subject: [development] how to start a drupal like project
In-Reply-To: <a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
Message-ID: <a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>

I am asking this because I was working on a FOSS project for many months and
few bad initial design decisions and I had to spend a lot of time rewriting
a lot things, and basically the project has come to a dead halt because it
just not possible to fix those things now !

I dont want to repeat the same mistakes again  :) I want to be more careful
this time.

I just to know what the provable things and the best approaches for such
projects - reinventing the wheel and repeating the same stupid mistakes is
just not fun :)

:D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081111/e8740813/attachment-0001.htm 

From earnie at users.sourceforge.net  Tue Nov 11 13:51:56 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 11 Nov 2008 08:51:56 -0500
Subject: [development] [OT] how to start a drupal like project
In-Reply-To: <a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
	<a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
Message-ID: <20081111085156.pl8c5jszzcoww04k@mail.progw.org>

Quoting My Own Linux <myown.linux at gmail.com>:

> I am asking this because I was working on a FOSS project for many months and
> few bad initial design decisions and I had to spend a lot of time rewriting
> a lot things, and basically the project has come to a dead halt because it
> just not possible to fix those things now !
>
> I dont want to repeat the same mistakes again  :) I want to be more careful
> this time.
>
> I just to know what the provable things and the best approaches for such
> projects - reinventing the wheel and repeating the same stupid mistakes is
> just not fun :)
>

How is your post related to _Drupal development_?  You're asking about 
project management and a google for 
http://www.google.com/search?q=open+source+%22project+management will 
give you correct results.

Earnie  http://r-feed.com
  Make a Drupal difference and review core patches.

-- http://for-my-kids.com/  -- http://give-me-an-offer.com/


From mathews.kyle at gmail.com  Tue Nov 11 14:21:38 2008
From: mathews.kyle at gmail.com (Kyle Mathews)
Date: Tue, 11 Nov 2008 07:21:38 -0700
Subject: [development] [OT] how to start a drupal like project
In-Reply-To: <20081111085156.pl8c5jszzcoww04k@mail.progw.org>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
	<a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
	<20081111085156.pl8c5jszzcoww04k@mail.progw.org>
Message-ID: <efeed12d0811110621i3fb13e5er2ab135b05de9c777@mail.gmail.com>

I think you want books on design patterns.
http://www.amazon.com/s/ref=nb_ss_gw?url=search-alias%3Daps&field-keywords=design+patterns&x=0&y=0

Design patterns are just what you're looking for -- proven best practices
for designing architectures.

Kyle

Research Assistant
eBusiness Center @ BYU
kyle.mathews2000.com/blog


On Tue, Nov 11, 2008 at 6:51 AM, Earnie Boyd
<earnie at users.sourceforge.net>wrote:

> Quoting My Own Linux <myown.linux at gmail.com>:
>
>  I am asking this because I was working on a FOSS project for many months
>> and
>> few bad initial design decisions and I had to spend a lot of time
>> rewriting
>> a lot things, and basically the project has come to a dead halt because it
>> just not possible to fix those things now !
>>
>> I dont want to repeat the same mistakes again  :) I want to be more
>> careful
>> this time.
>>
>> I just to know what the provable things and the best approaches for such
>> projects - reinventing the wheel and repeating the same stupid mistakes is
>> just not fun :)
>>
>>
> How is your post related to _Drupal development_?  You're asking about
> project management and a google for
> http://www.google.com/search?q=open+source+%22project+management will give
> you correct results.
>
> Earnie  http://r-feed.com
>  Make a Drupal difference and review core patches.
>
> -- http://for-my-kids.com/  -- http://give-me-an-offer.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081111/75b0b455/attachment.htm 

From amystephen at gmail.com  Tue Nov 11 14:42:37 2008
From: amystephen at gmail.com (Amy Stephen)
Date: Tue, 11 Nov 2008 08:42:37 -0600
Subject: [development] how to start a drupal like project
In-Reply-To: <a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
	<a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
Message-ID: <979e7e490811110642y1f37066cocdc36934dc9b438b@mail.gmail.com>

You might try this title, although I have not read it. ->
http://www.packtpub.com/PHP-5-CMS-Framework-Development/book

Your points about "reinventing the wheel" and "repeating the same stupid
mistakes" are good ones. One of the most important benefits of adopting a
community based solution is having access to the work of many, many
intelligent people - that has been tested by time and diverse install base -
and has been improved with that experience.

I recommend you use Drupal and direct your creative energies towards
bringing improvements to that project. What you'll begin with is quite
amazing. Why reinvent the wheel or start over at the beginning?

Anyway - all the best!

On Tue, Nov 11, 2008 at 7:02 AM, My Own Linux <myown.linux at gmail.com> wrote:

> I am asking this because I was working on a FOSS project for many months
> and few bad initial design decisions and I had to spend a lot of time
> rewriting a lot things, and basically the project has come to a dead halt
> because it just not possible to fix those things now !
>
> I dont want to repeat the same mistakes again  :) I want to be more careful
> this time.
>
> I just to know what the provable things and the best approaches for such
> projects - reinventing the wheel and repeating the same stupid mistakes is
> just not fun :)
>
> :D
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081111/51b2f849/attachment.htm 

From mathews.kyle at gmail.com  Tue Nov 11 14:50:47 2008
From: mathews.kyle at gmail.com (Kyle Mathews)
Date: Tue, 11 Nov 2008 07:50:47 -0700
Subject: [development] how to start a drupal like project
In-Reply-To: <979e7e490811110642y1f37066cocdc36934dc9b438b@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
	<a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
	<979e7e490811110642y1f37066cocdc36934dc9b438b@mail.gmail.com>
Message-ID: <efeed12d0811110650w45cf722eja7b188f78acb34d4@mail.gmail.com>

One other option -- Drupal is open source of course. You're welcome to
borrow code from Drupal or any of the other innumerable php frameworks out
there. But like the others said, are you sure you can't build what you want
on Drupal -- it'd save you gobs of time provided there's not some fatal
incompatibility.

Kyle

Research Assistant
eBusiness Center @ BYU
kyle.mathews2000.com/blog


On Tue, Nov 11, 2008 at 7:42 AM, Amy Stephen <amystephen at gmail.com> wrote:

> You might try this title, although I have not read it. ->
> http://www.packtpub.com/PHP-5-CMS-Framework-Development/book
>
> Your points about "reinventing the wheel" and "repeating the same stupid
> mistakes" are good ones. One of the most important benefits of adopting a
> community based solution is having access to the work of many, many
> intelligent people - that has been tested by time and diverse install base -
> and has been improved with that experience.
>
> I recommend you use Drupal and direct your creative energies towards
> bringing improvements to that project. What you'll begin with is quite
> amazing. Why reinvent the wheel or start over at the beginning?
>
> Anyway - all the best!
>
>
> On Tue, Nov 11, 2008 at 7:02 AM, My Own Linux <myown.linux at gmail.com>wrote:
>
>> I am asking this because I was working on a FOSS project for many months
>> and few bad initial design decisions and I had to spend a lot of time
>> rewriting a lot things, and basically the project has come to a dead halt
>> because it just not possible to fix those things now !
>>
>> I dont want to repeat the same mistakes again  :) I want to be more
>> careful this time.
>>
>> I just to know what the provable things and the best approaches for such
>> projects - reinventing the wheel and repeating the same stupid mistakes is
>> just not fun :)
>>
>> :D
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081111/49c459dd/attachment.htm 

From syscrusher at 4th.com  Tue Nov 11 14:57:00 2008
From: syscrusher at 4th.com (Syscrusher)
Date: Tue, 11 Nov 2008 09:57:00 -0500
Subject: [development] how to start a drupal like project
In-Reply-To: <a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
Message-ID: <1226415420.8440.640.camel@marcus>

On Tue, 2008-11-11 at 18:26 +0530, My Own Linux wrote:
> Firstly thanks to all those who replied. I would like to clear the
> point that what I am making is not a CMS. I just want to make a php
> based web app that is scalable like drupal and has support for themes,
> modules, etc.


Drupal is a lot more than just a CMS -- it's a pretty darned good web
application platform as well. My company uses an intranet web
application for many of our accounting and workflow needs. I wrote it as
a series of Drupal modules, so I didn't have to reinvent wheels for
themes, modules, authentication, user authorization, logging, menus,
input cleansing, localization.....etc. There is essentially no "content"
on this Drupal installation -- just the custom modules.

It sounds as if the things you don't want to reinvent are the things
Drupal already provides. The only thing better than reusing proven
design patterns is reusing proven *code.* :-)

You will write your best code if you are focused on the parts of the
application that are most interesting to you. Use off-the-shelf Open
Source code for the parts that are necessary but are not part of what
makes your application unique.

Kind regards,

Scott

-- 
Syscrusher <syscrusher at 4th.com>


From niels at madcap.nl  Tue Nov 11 15:46:56 2008
From: niels at madcap.nl (Niels van Mourik)
Date: Tue, 11 Nov 2008 16:46:56 +0100
Subject: [development] how to start a drupal like project
In-Reply-To: <1226415420.8440.640.camel@marcus>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
	<1226415420.8440.640.camel@marcus>
Message-ID: <200811111646.56469.niels@madcap.nl>

On Tuesday 11 November 2008 15:57:00 Syscrusher wrote:
> On Tue, 2008-11-11 at 18:26 +0530, My Own Linux wrote:
> > Firstly thanks to all those who replied. I would like to clear the
> > point that what I am making is not a CMS. I just want to make a php
> > based web app that is scalable like drupal and has support for themes,
> > modules, etc.
>
> Drupal is a lot more than just a CMS -- it's a pretty darned good web
> application platform as well. My company uses an intranet web
> application for many of our accounting and workflow needs. I wrote it as
> a series of Drupal modules, so I didn't have to reinvent wheels for
> themes, modules, authentication, user authorization, logging, menus,
> input cleansing, localization.....etc. There is essentially no "content"
> on this Drupal installation -- just the custom modules.
>
> It sounds as if the things you don't want to reinvent are the things
> Drupal already provides. The only thing better than reusing proven
> design patterns is reusing proven *code.* :-)
>
> You will write your best code if you are focused on the parts of the
> application that are most interesting to you. Use off-the-shelf Open
> Source code for the parts that are necessary but are not part of what
> makes your application unique.
>
> Kind regards,
>
> Scott

A good example for this is testing.drupal.org: http://testing.drupal.org/

All the website at essentially does is iterating all modules and making nice 
charts out of it. The Drupal framework has been used to write the 
'application' while all the 'CMS' features are disabled or not in use.

Therefore I've got to agree with Scott here, Drupal is a darn good application 
framework and eases lots of things like input validation, themes, forms and so 
on.

Niels

-- 
Met vriendelijke groet,
Niels van Mourik
Software Ontwikkelaar

MADCAP
Schapedrift 89
3371 JJ Hardinxveld-Giessendam

Mob 06 159 632 70
Tel 088 99 088 99
Fax 088 99 088 98

pgp 63399E566EBB7C1C
fp  9802 027D 61E3 1E7C 803B 5ED6 6339 9E56 6EBB 7C1C

www.madcap.nl / open.madcap.nl

-------------------------------------------------------------------------------------
Save a tree...please don't print this e-mail unless you really need to.
-------------- 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 : http://lists.drupal.org/pipermail/development/attachments/20081111/51d0e730/attachment-0001.pgp 

From drupal at dwwright.net  Tue Nov 11 23:47:55 2008
From: drupal at dwwright.net (Derek Wright)
Date: Tue, 11 Nov 2008 15:47:55 -0800
Subject: [development] Project usage stats
In-Reply-To: <124648.37677.qm@web52503.mail.re2.yahoo.com>
References: <124648.37677.qm@web52503.mail.re2.yahoo.com>
Message-ID: <FEC80339-B4AC-4AA8-9272-E15E4F2F9C01@dwwright.net>


On Nov 10, 2008, at 5:37 PM, yi yang wrote:

> Is there anybody noticing that the project usage on Drupal.org is  
> not updated since Oct 12th?

Yes, we know: http://drupal.org/node/326197

-Derek (dww)





From dmitrig01 at gmail.com  Wed Nov 12 01:17:05 2008
From: dmitrig01 at gmail.com (Dmitri Gaskin)
Date: Tue, 11 Nov 2008 17:17:05 -0800
Subject: [development] how to start a drupal like project
In-Reply-To: <200811111646.56469.niels@madcap.nl>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
	<1226415420.8440.640.camel@marcus>
	<200811111646.56469.niels@madcap.nl>
Message-ID: <1DBE0884-229F-4A29-ACCF-BC57FCA66069@gmail.com>

Minor Point: That is not at all what testing.drupal.org does.

What testing.drupal.org does is download patches from the queue, run  
the test suite on them, and report the results back to drupal.org

However, systems like this take tons of time to code. If you use  
Drupal, it's coded for you :-)

Dmitri

On Nov 11, 2008, at 7:46 AM, Niels van Mourik wrote:

> On Tuesday 11 November 2008 15:57:00 Syscrusher wrote:
>> On Tue, 2008-11-11 at 18:26 +0530, My Own Linux wrote:
>>> Firstly thanks to all those who replied. I would like to clear the
>>> point that what I am making is not a CMS. I just want to make a php
>>> based web app that is scalable like drupal and has support for  
>>> themes,
>>> modules, etc.
>>
>> Drupal is a lot more than just a CMS -- it's a pretty darned good web
>> application platform as well. My company uses an intranet web
>> application for many of our accounting and workflow needs. I wrote  
>> it as
>> a series of Drupal modules, so I didn't have to reinvent wheels for
>> themes, modules, authentication, user authorization, logging, menus,
>> input cleansing, localization.....etc. There is essentially no  
>> "content"
>> on this Drupal installation -- just the custom modules.
>>
>> It sounds as if the things you don't want to reinvent are the things
>> Drupal already provides. The only thing better than reusing proven
>> design patterns is reusing proven *code.* :-)
>>
>> You will write your best code if you are focused on the parts of the
>> application that are most interesting to you. Use off-the-shelf Open
>> Source code for the parts that are necessary but are not part of what
>> makes your application unique.
>>
>> Kind regards,
>>
>> Scott
>
> A good example for this is testing.drupal.org: http://testing.drupal.org/
>
> All the website at essentially does is iterating all modules and  
> making nice
> charts out of it. The Drupal framework has been used to write the
> 'application' while all the 'CMS' features are disabled or not in use.
>
> Therefore I've got to agree with Scott here, Drupal is a darn good  
> application
> framework and eases lots of things like input validation, themes,  
> forms and so
> on.
>
> Niels
>
> -- 
> Met vriendelijke groet,
> Niels van Mourik
> Software Ontwikkelaar
>
> MADCAP
> Schapedrift 89
> 3371 JJ Hardinxveld-Giessendam
>
> Mob 06 159 632 70
> Tel 088 99 088 99
> Fax 088 99 088 98
>
> pgp 63399E566EBB7C1C
> fp  9802 027D 61E3 1E7C 803B 5ED6 6339 9E56 6EBB 7C1C
>
> www.madcap.nl / open.madcap.nl
>
> -------------------------------------------------------------------------------------
> Save a tree...please don't print this e-mail unless you really need  
> to.


From syscrusher at 4th.com  Thu Nov 13 00:19:06 2008
From: syscrusher at 4th.com (Syscrusher)
Date: Wed, 12 Nov 2008 19:19:06 -0500
Subject: [development] Beta release CVS tagging
Message-ID: <1226535546.8440.726.camel@marcus>

Hmmmm....I *thought* I had RTFM and was following the instructions, but
CVS thinks otherwise.

I have, in CVS HEAD, a module that has been committed with current
changes. I want to make an official release for Drupal 6.x
compatibility, first release of this module for that core API level, and
a "beta" level of stability.

According to http://drupal.org/node/94155 and
http://drupal.org/handbook/cvs/branches-and-tags/contributions
I thought I needed to do this:

$ cvs tag DRUPAL-6--1-0-BETA

However, this returns the following error:

cvs tag: Pre-tag check failed
** See http://drupal.org/node/93999 for the format of valid release
tags.** ERROR: invalid tag for this directory:

Can someone tell me what I'm doing wrong here? It's been a long time
since I needed to do an actual release, and I think things may have
changed since the last time I did one of these.

Thanks.

Kind regards,

Scott
-- 
Syscrusher <syscrusher at 4th.com>


From starbow at citris-uc.org  Thu Nov 13 00:32:54 2008
From: starbow at citris-uc.org (Tao Starbow)
Date: Wed, 12 Nov 2008 16:32:54 -0800
Subject: [development] Beta release CVS tagging
In-Reply-To: <1226535546.8440.726.camel@marcus>
References: <1226535546.8440.726.camel@marcus>
Message-ID: <491B75B6.2040607@citris-uc.org>

It needs a number:

DRUPAL-6--1-0-BETA1


Syscrusher wrote:
> Hmmmm....I *thought* I had RTFM and was following the instructions, but
> CVS thinks otherwise.
>
> I have, in CVS HEAD, a module that has been committed with current
> changes. I want to make an official release for Drupal 6.x
> compatibility, first release of this module for that core API level, and
> a "beta" level of stability.
>
> According to http://drupal.org/node/94155 and
> http://drupal.org/handbook/cvs/branches-and-tags/contributions
> I thought I needed to do this:
>
> $ cvs tag DRUPAL-6--1-0-BETA
>
> However, this returns the following error:
>
> cvs tag: Pre-tag check failed
> ** See http://drupal.org/node/93999 for the format of valid release
> tags.** ERROR: invalid tag for this directory:
>
> Can someone tell me what I'm doing wrong here? It's been a long time
> since I needed to do an actual release, and I think things may have
> changed since the last time I did one of these.
>
> Thanks.
>
> Kind regards,
>
> Scott
>   

From syscrusher at 4th.com  Thu Nov 13 01:09:31 2008
From: syscrusher at 4th.com (Syscrusher)
Date: Wed, 12 Nov 2008 20:09:31 -0500
Subject: [development] Beta release CVS tagging
In-Reply-To: <491B75B6.2040607@citris-uc.org>
References: <1226535546.8440.726.camel@marcus> <491B75B6.2040607@citris-uc.org>
Message-ID: <1226538571.8440.728.camel@marcus>

On Wed, 2008-11-12 at 16:32 -0800, Tao Starbow wrote:
> It needs a number:
> 
> DRUPAL-6--1-0-BETA1

Bingo...that was it. And it is documented, I just overlooked it. My tag
now works fine. Thanks a bunch!

Scott

-- 
Syscrusher <syscrusher at 4th.com>


From fernandoparedesgarcia at gmail.com  Thu Nov 13 05:55:38 2008
From: fernandoparedesgarcia at gmail.com (=?ISO-8859-1?Q?=22Fernando_P=2E_Garc=EDa=22?=)
Date: Thu, 13 Nov 2008 00:55:38 -0500
Subject: [development] Drupal Framework or Toolkit DFK/DTK (was: how to
 start a drupal like project)
In-Reply-To: <a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
Message-ID: <491BC15A.7060402@gmail.com>

Again, you have not to duplicate the whole work, that is why I propose 
to do same as GIMP, they released GTK as a separate library, why not 
drupal? and this is not about the core, is about FAPI, Database 
Abstraction layer and so...

weird ? :/

Blessings!

My Own Linux wrote:
> Firstly thanks to all those who replied. I would like to clear the 
> point that what I am making is not a CMS. I just want to make a php 
> based web app that is scalable like drupal and has support for themes, 
> modules, etc.
>
> I was looking for some pointers on the design aspect of a similar php 
> - mysql based projects. How to design the database, what parts of code 
> can be reused, how to make a project theme-able, module-able, how to 
> design the filesystem layouts, how to make sure its secure, structures 
> for admin area - user area, how to design the class and functions, how 
> to design the page structures, etc
>
> ps : I have read both the books (esr, producing foss) - but they dont 
> have any answers for what I am looking for.
>
> I hope this will make my question more clear :)
>
> Excuse me for my bad english.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fernandoparedesgarcia.vcf
Type: text/x-vcard
Size: 359 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081113/a50aeff2/attachment.vcf 

From fernandoparedesgarcia at gmail.com  Thu Nov 13 06:06:38 2008
From: fernandoparedesgarcia at gmail.com (=?ISO-8859-1?Q?=22Fernando_P=2E_Garc=EDa=22?=)
Date: Thu, 13 Nov 2008 01:06:38 -0500
Subject: [development] [OT] how to start a drupal like project
In-Reply-To: <979e7e490811110642y1f37066cocdc36934dc9b438b@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>	<a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
	<979e7e490811110642y1f37066cocdc36934dc9b438b@mail.gmail.com>
Message-ID: <491BC3EE.60809@gmail.com>

Yes! a success example is the drupal module ubercart[1], which competes 
with "specialized" FLOSS ecommerce packages.
This topic is OT from this point so pleace place project details at 
group Contributed Modules Ideas[2]*.*

/[1]http://drupal.org/project/ubercart/
[2]http://groups.drupal.org/contributed-module-ideas//*

*Blessings!*
*
Amy Stephen wrote:
> You might try this title, although I have not read it. -> 
> http://www.packtpub.com/PHP-5-CMS-Framework-Development/book
>
> Your points about "reinventing the wheel" and "repeating the same 
> stupid mistakes" are good ones. One of the most important benefits of 
> adopting a community based solution is having access to the work of 
> many, many intelligent people - that has been tested by time and 
> diverse install base - and has been improved with that experience.
>
> I recommend you use Drupal and direct your creative energies towards 
> bringing improvements to that project. What you'll begin with is quite 
> amazing. Why reinvent the wheel or start over at the beginning?
>
> Anyway - all the best!
>
> On Tue, Nov 11, 2008 at 7:02 AM, My Own Linux <myown.linux at gmail.com 
> <mailto:myown.linux at gmail.com>> wrote:
>
>     I am asking this because I was working on a FOSS project for many
>     months and few bad initial design decisions and I had to spend a
>     lot of time rewriting a lot things, and basically the project has
>     come to a dead halt because it just not possible to fix those
>     things now !
>
>     I dont want to repeat the same mistakes again  :) I want to be
>     more careful this time.
>
>     I just to know what the provable things and the best approaches
>     for such projects - reinventing the wheel and repeating the same
>     stupid mistakes is just not fun :)
>
>     :D
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081113/7b11fbd3/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fernandoparedesgarcia.vcf
Type: text/x-vcard
Size: 359 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081113/7b11fbd3/attachment-0001.vcf 

From drupal-devel at webchick.net  Thu Nov 13 08:19:42 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Thu, 13 Nov 2008 03:19:42 -0500
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-3
Message-ID: <491BE31E.6020605@webchick.net>

Hello, devel list! :)

Due to travel and other factors, it has been about a month since our 
last unstable release. There are some really exciting, big patches 
coming down the pipe, so I wanted to roll this interim release so 
contributed module developers interested in chasing HEAD have something 
a bit more current to build from. See 
http://drupal.org/node/224333#UNSTABLE-3 for the full list of API 
changes this release.

Here are some of the things we've been up to for the last month. Once 
again, I encourage contributors to use 
http://groups.drupal.org/patch-spotlight as a place to organize, 
prioritize, and coordinate on patches they'd like to see in Drupal 7.

For developers:
===============
- drupal_set_title() now check_plain()s by default, which should help 
developers prevent XSS.

- Performance improvements: the registry now keeps a record of all 
modules that implement a given hook, and caches registry lookups.

- Taxonomy gets some love, with new 
hook_taxonomy_term_load/insert/update/delete() hooks and various 
standardization/consistency improvements.

- SimpleTest now remembers the tests that were last selected so they can 
be re-run (WOOHOO) and can catch errors and warnings that come up during 
test runs, even if they're not part of an actual assertion.

- Improvements to drupal_add_js(), which now has some cleaned-up 
parameters and a full-on weighting system for scripts. More 
drupal_add_js() improvements are in the pipeline, and expect them to 
make it over to drupal_add_css() as well.

- Ground work has been laid in the database system for supporting of 
more exotic database drivers. Expect to see SQLite support in UNSTABLE-4!

- Also on the database side of things, numerous files and modules have 
been converted from legacy syntax to the new DBTNG syntax. A great place 
to help out if you're interested in learning this stuff hands-on in 
advance of when you are forced to. ;)

For users:
==========
- New, swanky password checker during installation and on the my account 
page.

- Cron is automatically run once upon installation so that Drupal 
doesn't immediately clobber you with a nasty error as a way of saying 
"Welcome."

- The content types administration screen shrinks down the 
"in-your-face-ness" of the machine name of the type.

- It is now possible (though not easy ;)) to upgrade from Drupal 6 to 
Drupal 7! Unfortunately, this currently still requires some manual 
futzing with settings.php. See http://drupal.org/node/304163 if you'd 
like to help.

Looking forward to your patches/reviews in the issue queue! :)

-Angie

-- 
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com

From myown.linux at gmail.com  Thu Nov 13 08:54:10 2008
From: myown.linux at gmail.com (My Own Linux)
Date: Thu, 13 Nov 2008 14:24:10 +0530
Subject: [development] [OT] how to start a drupal like project
In-Reply-To: <491BC3EE.60809@gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
	<a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
	<979e7e490811110642y1f37066cocdc36934dc9b438b@mail.gmail.com>
	<491BC3EE.60809@gmail.com>
Message-ID: <a7f2fa510811130054l3b9b4973g6ee279cb36560be6@mail.gmail.com>

cool !

>> Drupal is a lot more than just a CMS -- it's a pretty darned good web
application platform as well. My company uses an intranet web
application for many of our accounting and workflow needs. I wrote it as
a series of Drupal modules, so I didn't have to reinvent wheels for
themes, modules, authentication, user authorization, logging, menus,
input cleansing, localization.....etc. There is essentially no "content"
on this Drupal installation -- just the custom modules.

this is exactly what I was looking for ! i wanted to make a web application
for freelance projects where people can post projects, bid on it, etc.
something like

http://www.elance.com/p/landing/buyer.html

will drupal work for such projects ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081113/764f5869/attachment.htm 

From darrel.opry at gmail.com  Thu Nov 13 14:57:57 2008
From: darrel.opry at gmail.com (Darrel O'Pry)
Date: Thu, 13 Nov 2008 09:57:57 -0500
Subject: [development] [OT] how to start a drupal like project
In-Reply-To: <a7f2fa510811130054l3b9b4973g6ee279cb36560be6@mail.gmail.com>
References: <a7f2fa510811100920u68292cbct4faeb2ddb4f6612d@mail.gmail.com>
	<ff176450811110132l54c050f7wd249fa0e6aaf88ef@mail.gmail.com>
	<a7f2fa510811110456o44528cebr42a088adf534f782@mail.gmail.com>
	<a7f2fa510811110502v549e3c5cv352410bc269bc430@mail.gmail.com>
	<979e7e490811110642y1f37066cocdc36934dc9b438b@mail.gmail.com>
	<491BC3EE.60809@gmail.com>
	<a7f2fa510811130054l3b9b4973g6ee279cb36560be6@mail.gmail.com>
Message-ID: <bfcbb6230811130657p1332cfa5o73c50c4668d9a7aa@mail.gmail.com>

yes, but carry it to another thread and start reading the drupal handbook to
get a grip on how to implement what you want.

On Thu, Nov 13, 2008 at 3:54 AM, My Own Linux <myown.linux at gmail.com> wrote:

> cool !
>
> >> Drupal is a lot more than just a CMS -- it's a pretty darned good web
> application platform as well. My company uses an intranet web
> application for many of our accounting and workflow needs. I wrote it as
> a series of Drupal modules, so I didn't have to reinvent wheels for
> themes, modules, authentication, user authorization, logging, menus,
> input cleansing, localization.....etc. There is essentially no "content"
> on this Drupal installation -- just the custom modules.
>
> this is exactly what I was looking for ! i wanted to make a web application
> for freelance projects where people can post projects, bid on it, etc.
> something like
>
> http://www.elance.com/p/landing/buyer.html
>
> will drupal work for such projects ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081113/72593b5e/attachment.htm 

From drupal at dwwright.net  Thu Nov 13 17:27:40 2008
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 13 Nov 2008 09:27:40 -0800
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-3
In-Reply-To: <491BE31E.6020605@webchick.net>
References: <491BE31E.6020605@webchick.net>
Message-ID: <81C71206-3CAB-4EFD-82D1-4CF4B106C058@dwwright.net>

Nice to see more unstable releases coming, this (coupled with the  
advances in automated patch testing) is really moving core development  
to a new level of maturity.  Yay.

However...

On Nov 13, 2008, at 12:19 AM, Angela Byron wrote:

> - Cron is automatically run once upon installation so that Drupal  
> doesn't immediately clobber you with a nasty error as a way of  
> saying "Welcome."

Where's the issue nid for this change?  This seems like a regression  
to me (this means the requirement check for cron not running is now  
totally useless, since cron will always have run once, giving site  
admins a false sense that everything's ok).  However, I'd like to  
argue about this in the appropriate venue. ;)

Thanks,
-Derek (dww)




From Greg at growingventuresolutions.com  Thu Nov 13 17:37:33 2008
From: Greg at growingventuresolutions.com (Greg Knaddison - GVS)
Date: Thu, 13 Nov 2008 10:37:33 -0700
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-3
In-Reply-To: <81C71206-3CAB-4EFD-82D1-4CF4B106C058@dwwright.net>
References: <491BE31E.6020605@webchick.net>
	<81C71206-3CAB-4EFD-82D1-4CF4B106C058@dwwright.net>
Message-ID: <3861c6770811130937w18d90689ree73309f6fe7cbff@mail.gmail.com>

On Thu, Nov 13, 2008 at 10:27 AM, Derek Wright <drupal at dwwright.net> wrote:
> Where's the issue nid for this change?  This seems like a regression to me

http://drupal.org/node/93509

It seems like your concern is at least somewhat addressed in the
discussion and implementation of the issue.

I found this with:

cvs-release-notes.php DRUPAL-7-0-UNSTABLE-2 DRUPAL-7-0-UNSTABLE-3 | grep cron
<li>- Patch <a href="/node/296321">#296321</a> by pwolanin, swentel:
link to cron.php broken when clean URLs are disabled.</li>
<li>- Patch <a href="/node/93509">#93509</a> by catch: automatically
run cron after installation, improve the cron notifications.</li>

Yay cvs-release-notes.php!

@Webchick - maybe when you make these announcements you could put the
results of cvs-release-notes.php at the end of the announcement?

Thanks,
Greg

-- 
Greg Knaddison
Denver, CO | http://knaddison.com | 303-800-5623
Growing Venture Solutions, LLC | http://growingventuresolutions.com

From arancaytar.ilyaran at gmail.com  Thu Nov 13 17:38:22 2008
From: arancaytar.ilyaran at gmail.com (Arancaytar Ilyaran)
Date: Thu, 13 Nov 2008 18:38:22 +0100
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-3
In-Reply-To: <81C71206-3CAB-4EFD-82D1-4CF4B106C058@dwwright.net>
References: <491BE31E.6020605@webchick.net>
	<81C71206-3CAB-4EFD-82D1-4CF4B106C058@dwwright.net>
Message-ID: <491C660E.7080302@gmail.com>

Derek Wright wrote:
> Where's the issue nid for this change?  This seems like a regression to
> me (this means the requirement check for cron not running is now totally
> useless, since cron will always have run once, giving site admins a
> false sense that everything's ok).  However, I'd like to argue about
> this in the appropriate venue. ;)
> 
> Thanks,
> -Derek (dww)
> 
> 

Lacking an issue link, I'll add my cents here...

1.) Yes, it's necessary to inform admins that they need to set up cron.
2.) It's also annoying to formulate this information as an error message. It's a
bit like showing a "This password is incorrect" message on a login form before
you enter anything.

Considering that the "cron has never run" case can /only/ happen just after
installation, perhaps there should be no drupal_set_message() warning at all,
just a step in the site setup process?

"1. Configure your website:
 Once logged in, visit the administration section, where you can customize and
configure all aspects of your website. {You need to set up a cron-job on your
server to perform regular database maintenance.}"

Something like that?



-- 
Arancaytar
----------------------
Nothing beside remains: Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away...
----------------------
PGP:   http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x27CA5C74
XMPP:  arancaytar.ilyaran at gmail.com
AOL:   282026638 / RealArancaytar
URL:   http://ermarian.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/development/attachments/20081113/1c47b7e0/attachment.pgp 

From drupal at dwwright.net  Thu Nov 13 17:50:25 2008
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 13 Nov 2008 09:50:25 -0800
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-3
In-Reply-To: <3861c6770811130937w18d90689ree73309f6fe7cbff@mail.gmail.com>
References: <491BE31E.6020605@webchick.net>
	<81C71206-3CAB-4EFD-82D1-4CF4B106C058@dwwright.net>
	<3861c6770811130937w18d90689ree73309f6fe7cbff@mail.gmail.com>
Message-ID: <EDABF810-6F4A-4E5D-82D7-85F294A36936@dwwright.net>


On Nov 13, 2008, at 9:37 AM, Greg Knaddison - GVS wrote:

> http://drupal.org/node/93509
>
> It seems like your concern is at least somewhat addressed in the  
> discussion and implementation of the issue.

Mostly.  Reading the patch did, however. ;)  They removed the "cron  
never ran" requirement check entirely, and now rely on the "it's been  
a while since cron ran" warnings to remind admins they have a  
problem.  That works.

Sorry for the false alarm...

-Derek (dww)




From amystephen at gmail.com  Fri Nov 14 05:17:39 2008
From: amystephen at gmail.com (Amy Stephen)
Date: Thu, 13 Nov 2008 23:17:39 -0600
Subject: [development] Database creation on Install
Message-ID: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>

I apologize if this is not the appropriate place to ask this question but I
am curious after checking out your fine development work.

Why doesn't the Drupal Installation process try to create the database if it
doesn't exist already? WordPress is the same. Joomla! will use the database
if it exists - and create it, provided the ID has sufficient permissions.
It's just another "make things easier" step (for both the "newbie" crowd,
but also developers testing/working).

I was curious if there were security concerns? Or, if it just never seemed
to be someone's itch?

Again, if I am out of place with this question, please let me know, and
forgive my ignorance.

Kind regards,
Amy :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081113/319f9c5f/attachment-0001.htm 

From dmitrig01 at gmail.com  Fri Nov 14 05:23:56 2008
From: dmitrig01 at gmail.com (Dmitri Gaskin)
Date: Thu, 13 Nov 2008 21:23:56 -0800
Subject: [development] Database creation on Install
In-Reply-To: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
Message-ID: <51408C5F-C9AA-43B1-B8E6-EE75A5126CCE@gmail.com>

This has not yet been attempted (I think) simply because most people  
do not install with a user with sufficient rights to create a  
database, and therefore there is no need for most people

Please correct me if I'm wrong.

Dmitri

On Nov 13, 2008, at 9:17 PM, Amy Stephen wrote:

> I apologize if this is not the appropriate place to ask this  
> question but I am curious after checking out your fine development  
> work.
>
> Why doesn't the Drupal Installation process try to create the  
> database if it doesn't exist already? WordPress is the same. Joomla!  
> will use the database if it exists - and create it, provided the ID  
> has sufficient permissions. It's just another "make things easier"  
> step (for both the "newbie" crowd, but also developers testing/ 
> working).
>
> I was curious if there were security concerns? Or, if it just never  
> seemed to be someone's itch?
>
> Again, if I am out of place with this question, please let me know,  
> and forgive my ignorance.
Nope, this is the right place.
>
>
> Kind regards,
> Amy :)


From dmitry at danilevsky.com  Fri Nov 14 05:24:05 2008
From: dmitry at danilevsky.com (dmitry danilevsky)
Date: Fri, 14 Nov 2008 07:24:05 +0200
Subject: [development] Database creation on Install
In-Reply-To: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
Message-ID: <200811140724.05907.dmitry@danilevsky.com>

On Friday 14 November 2008 07:17:39 Amy Stephen wrote:
> I apologize if this is not the appropriate place to ask this question but I
> am curious after checking out your fine development work.
>
> Why doesn't the Drupal Installation process try to create the database if
> it doesn't exist already? WordPress is the same. Joomla! will use the
> database if it exists - and create it, provided the ID has sufficient
> permissions. It's just another "make things easier" step (for both the
> "newbie" crowd, but also developers testing/working).
>
> I was curious if there were security concerns? Or, if it just never seemed
> to be someone's itch?
>
> Again, if I am out of place with this question, please let me know, and
> forgive my ignorance.
>
> Kind regards,
> Amy :)

becouse many of the hostings do not allow creating db from php-scripts.

From fernandoparedesgarcia at gmail.com  Fri Nov 14 06:29:04 2008
From: fernandoparedesgarcia at gmail.com (=?UTF-8?B?IkZlcm5hbmRvIFAuIEdhcmPDrWEi?=)
Date: Fri, 14 Nov 2008 01:29:04 -0500
Subject: [development] Database creation on Install
In-Reply-To: <200811140724.05907.dmitry@danilevsky.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<200811140724.05907.dmitry@danilevsky.com>
Message-ID: <491D1AB0.4000200@gmail.com>

dmitry danilevsky wrote:
> On Friday 14 November 2008 07:17:39 Amy Stephen wrote:
>   
>> I apologize if this is not the appropriate place to ask this question but I
>> am curious after checking out your fine development work.
>>
>> Why doesn't the Drupal Installation process try to create the database if
>> it doesn't exist already? WordPress is the same. Joomla! will use the
>> database if it exists - and create it, provided the ID has sufficient
>> permissions. It's just another "make things easier" step (for both the
>> "newbie" crowd, but also developers testing/working).
>>
>> I was curious if there were security concerns? Or, if it just never seemed
>> to be someone's itch?
>>
>> Again, if I am out of place with this question, please let me know, and
>> forgive my ignorance.
>>
>> Kind regards,
>> Amy :)
>>     
>
>   
If they already why don't we do?...
> becouse many of the hostings do not allow creating db from php-scripts.
>   
Consider there are lots of people working with a local copy, hostings 
are just an scenario but we can't  just *cut* others without a good reason.

Blessings!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081114/60e21d5b/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fernandoparedesgarcia.vcf
Type: text/x-vcard
Size: 370 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081114/60e21d5b/attachment.vcf 

From recidive at gmail.com  Fri Nov 14 17:00:18 2008
From: recidive at gmail.com (Henrique Recidive)
Date: Fri, 14 Nov 2008 15:00:18 -0200
Subject: [development] Add consistency to node hooks
Message-ID: <841684fe0811140900j32250729vec14d9d6c8feaa95@mail.gmail.com>

Hello,

a while ago I've submitted a patch to bring more consistency to node
hooks, so they are inline with other drupal data hooks such as
hook_user_*(), hook_file_*().

Node hooks are special, i.e. there are two kinds of node hooks: 1)
hooks for modules which implement node types: hook_load(),
hook_save(), etc and 2) hooks for all modules (those which implement
node types and those which don't): hook_nodeapi_load(),
hook_nodeapi_save().

In my opinion type #1 hooks have meaningless names, since they don't
explicit say they are for extending node functionality. And type #2
hooks are very similar to hook_user_*(), hook_file_*() ones, so why
they have 'nodeapi' in their names, not just 'node'?

Basically what the patch does is changing type #1 hooks so they can be
implemented in the following two ways:

Node type specific:

E.g. poll_node_form_poll()

Node type agnostic:

E.g. poll_node_form()

This way modules which implement node types can have either a) one
hook implementation for *each* node type they implement (the first
case above), or one single hook for *all* node types they implement.

The patch also rename type #2 hooks changing 'nodeapi' to 'node', to
make them inline with other APIs. So e.g. hook_nodeapi_load() becomes
hook_node_load().

What do you guys/gals think?

Please comment on the issue:

http://drupal.org/node/322485

Thanks,

Henrique

From pinglaura at gmail.com  Fri Nov 14 17:19:35 2008
From: pinglaura at gmail.com (Laura Scott)
Date: Fri, 14 Nov 2008 10:19:35 -0700
Subject: [development] Database creation on Install
In-Reply-To: <491D1AB0.4000200@gmail.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<200811140724.05907.dmitry@danilevsky.com>
	<491D1AB0.4000200@gmail.com>
Message-ID: <8EDBC25F-C4E8-4695-8936-81D1E252A76E@gmail.com>

There are also security reasons. It's not good for Apache to have such  
powerful permissions. It raises the stakes on security. Ultimately the  
easiest installer is operated outside of the Apache user.

Laura

On Nov 13, 2008, at 11:29 PM, Fernando P. Garc?a wrote:

> dmitry danilevsky wrote:
>>
>> On Friday 14 November 2008 07:17:39 Amy Stephen wrote:
>>
>>> I apologize if this is not the appropriate place to ask this  
>>> question but I
>>> am curious after checking out your fine development work.
>>>
>>> Why doesn't the Drupal Installation process try to create the  
>>> database if
>>> it doesn't exist already? WordPress is the same. Joomla! will use  
>>> the
>>> database if it exists - and create it, provided the ID has  
>>> sufficient
>>> permissions. It's just another "make things easier" step (for both  
>>> the
>>> "newbie" crowd, but also developers testing/working).
>>>
>>> I was curious if there were security concerns? Or, if it just  
>>> never seemed
>>> to be someone's itch?
>>>
>>> Again, if I am out of place with this question, please let me  
>>> know, and
>>> forgive my ignorance.
>>>
>>> Kind regards,
>>> Amy :)
>>>
>>
> If they already why don't we do?...
>> becouse many of the hostings do not allow creating db from php- 
>> scripts.
>>
> Consider there are lots of people working with a local copy,  
> hostings are just an scenario but we can't  just *cut* others  
> without a good reason.
>
> Blessings!
> <fernandoparedesgarcia.vcf>


From darrenoh at sidepotsinternational.com  Fri Nov 14 17:29:24 2008
From: darrenoh at sidepotsinternational.com (Darren Oh)
Date: Fri, 14 Nov 2008 12:29:24 -0500
Subject: [development] Database creation on Install
In-Reply-To: <8EDBC25F-C4E8-4695-8936-81D1E252A76E@gmail.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<200811140724.05907.dmitry@danilevsky.com>
	<491D1AB0.4000200@gmail.com>
	<8EDBC25F-C4E8-4695-8936-81D1E252A76E@gmail.com>
Message-ID: <5AD72510-0DD9-4A9C-81D6-46B0086C8AF4@sidepotsinternational.com>

Drupal installers which automatically create databases are available.  
For an example, see http://packages.debian.org/etch-backports/drupal5.

On Nov 14, 2008, at 12:19 PM, Laura Scott wrote:

> There are also security reasons. It's not good for Apache to have  
> such powerful permissions. It raises the stakes on security.  
> Ultimately the easiest installer is operated outside of the Apache  
> user.
>
> Laura

From pinglaura at gmail.com  Fri Nov 14 18:43:48 2008
From: pinglaura at gmail.com (Laura Scott)
Date: Fri, 14 Nov 2008 11:43:48 -0700
Subject: [development] Database creation on Install
In-Reply-To: <5AD72510-0DD9-4A9C-81D6-46B0086C8AF4@sidepotsinternational.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<200811140724.05907.dmitry@danilevsky.com>
	<491D1AB0.4000200@gmail.com>
	<8EDBC25F-C4E8-4695-8936-81D1E252A76E@gmail.com>
	<5AD72510-0DD9-4A9C-81D6-46B0086C8AF4@sidepotsinternational.com>
Message-ID: <2C8699B4-3BC4-4052-8C8B-F9CB388C3093@gmail.com>

Caveat: They are almost always out of date. After installation, you  
would want to immediately do security updates. http://drupal.org/security

Note also that some installers do not play well with manual  
modification of code/module installs after the fact.

Laura

On Nov 14, 2008, at 10:29 AM, Darren Oh wrote:

> Drupal installers which automatically create databases are  
> available. For an example, see http://packages.debian.org/etch-backports/drupal5 
> .
>
> On Nov 14, 2008, at 12:19 PM, Laura Scott wrote:
>
>> There are also security reasons. It's not good for Apache to have  
>> such powerful permissions. It raises the stakes on security.  
>> Ultimately the easiest installer is operated outside of the Apache  
>> user.
>>
>> Laura


From aldo at caonao.cu  Fri Nov 14 19:58:14 2008
From: aldo at caonao.cu (Aldo Martinez Selleras)
Date: Fri, 14 Nov 2008 14:58:14 -0500
Subject: [development] disable the title link
Message-ID: <200811141458.15028.aldo@caonao.cu>

may i disable the title link in one node where i will execute a php code ???

-- 
----------------------
Aldo Martinez Selleras
Administrador del Nodo
CITMATEL GND Camaguey
Tel: 32-291661
E-mail: aldo at caonao.cu
Linux User #364356

From amystephen at gmail.com  Fri Nov 14 20:20:03 2008
From: amystephen at gmail.com (Amy Stephen)
Date: Fri, 14 Nov 2008 14:20:03 -0600
Subject: [development] Database creation on Install
In-Reply-To: <8EDBC25F-C4E8-4695-8936-81D1E252A76E@gmail.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<200811140724.05907.dmitry@danilevsky.com>
	<491D1AB0.4000200@gmail.com>
	<8EDBC25F-C4E8-4695-8936-81D1E252A76E@gmail.com>
Message-ID: <979e7e490811141220p53d4ed67w6a2056b25c5241cc@mail.gmail.com>

It would have to be a powerful user, like root (w00t!) or a user that has
MySQL create database authority. PHP is simply creating a pipe to MySQL -
through Apache - but it is the MySQL user credentials that would allow or
prohibit this action. It's a nice-ity for local development, although not a
show stopper in any sense. If the local user doesn't have authority, it
would error out in a manner similar to how the install errors now. But, I
could be way off base here.

Thanks for everyone's response. :-)

On Fri, Nov 14, 2008 at 11:19 AM, Laura Scott <pinglaura at gmail.com> wrote:

> There are also security reasons. It's not good for Apache to have such
> powerful permissions. It raises the stakes on security. Ultimately the
> easiest installer is operated outside of the Apache user.
>
> Laura
>
> On Nov 13, 2008, at 11:29 PM, Fernando P. Garc?a wrote:
>
>  dmitry danilevsky wrote:
>>
>>>
>>> On Friday 14 November 2008 07:17:39 Amy Stephen wrote:
>>>
>>>  I apologize if this is not the appropriate place to ask this question
>>>> but I
>>>> am curious after checking out your fine development work.
>>>>
>>>> Why doesn't the Drupal Installation process try to create the database
>>>> if
>>>> it doesn't exist already? WordPress is the same. Joomla! will use the
>>>> database if it exists - and create it, provided the ID has sufficient
>>>> permissions. It's just another "make things easier" step (for both the
>>>> "newbie" crowd, but also developers testing/working).
>>>>
>>>> I was curious if there were security concerns? Or, if it just never
>>>> seemed
>>>> to be someone's itch?
>>>>
>>>> Again, if I am out of place with this question, please let me know, and
>>>> forgive my ignorance.
>>>>
>>>> Kind regards,
>>>> Amy :)
>>>>
>>>>
>>>  If they already why don't we do?...
>>
>>> becouse many of the hostings do not allow creating db from php-scripts.
>>>
>>>  Consider there are lots of people working with a local copy, hostings
>> are just an scenario but we can't  just *cut* others without a good reason.
>>
>> Blessings!
>> <fernandoparedesgarcia.vcf>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081114/70227352/attachment.htm 

From amystephen at gmail.com  Fri Nov 14 20:21:50 2008
From: amystephen at gmail.com (Amy Stephen)
Date: Fri, 14 Nov 2008 14:21:50 -0600
Subject: [development] Database creation on Install
In-Reply-To: <5AD72510-0DD9-4A9C-81D6-46B0086C8AF4@sidepotsinternational.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<200811140724.05907.dmitry@danilevsky.com>
	<491D1AB0.4000200@gmail.com>
	<8EDBC25F-C4E8-4695-8936-81D1E252A76E@gmail.com>
	<5AD72510-0DD9-4A9C-81D6-46B0086C8AF4@sidepotsinternational.com>
Message-ID: <979e7e490811141221v52955e0fg8ee78c209326fdee@mail.gmail.com>

Thanks, Darren, I'll take a look at that, with Laura's advice on currency in
mind.

On Fri, Nov 14, 2008 at 11:29 AM, Darren Oh <
darrenoh at sidepotsinternational.com> wrote:

> Drupal installers which automatically create databases are available. For
> an example, see http://packages.debian.org/etch-backports/drupal5.
>
>
> On Nov 14, 2008, at 12:19 PM, Laura Scott wrote:
>
>  There are also security reasons. It's not good for Apache to have such
>> powerful permissions. It raises the stakes on security. Ultimately the
>> easiest installer is operated outside of the Apache user.
>>
>> Laura
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081114/8f120dad/attachment.htm 

From domas.m at gmail.com  Sat Nov 15 12:20:49 2008
From: domas.m at gmail.com (Domas Monkus)
Date: Sat, 15 Nov 2008 14:20:49 +0200
Subject: [development] Views 2 API hook_views_data and node relationships
Message-ID: <cd6dfc240811150420x6216fb02q675910f56b97e654@mail.gmail.com>

Hi,
my module creates and maintains a table that basically links pairs of nodes
together (it has two columns, both representing nids).

I want to use views to show all nodes related through this table to the node
that is currently being viewed. What should the hook_views_data look like? I
read through the documentation, but didn't manage to figure this out.

Thanks in advance,
Domas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081115/ce3566c7/attachment.htm 

From drupal-devel at webchick.net  Mon Nov 17 07:39:05 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Mon, 17 Nov 2008 02:39:05 -0500
Subject: [development] Re-check "code needs work" patches
Message-ID: <49211F99.3080605@webchick.net>

HEAD was broken today for about 4 hours after the commit of 
http://drupal.org/node/74645#comment-1110500. Because this patch was 
missing a hunk from install.inc, testing bot correctly flagged it as 
"code needs work" with a reason of "Failed to install HEAD." 
Unfortunately, because the patch then got committed to HEAD, that meant 
that *every* patch the testing bot tried thereafter failed for the same 
reason. So over 180 patches got marked "code needs work" as their turns 
came up in the testing queue. :\

The *good* news is that boombatower has some code ready that will test 
vanilla HEAD after each commit and immediately stop processing more 
testing results until this situation remedies itself, should it happen 
again (and it probably will). It will also ping the dev list and the 
core maitainers via email so that they can fix it ASAP.

The *bad* news is that we don't have a real easy way to undo these CNWs 
so this will have to be a manual process. :\ http://pastebin.ca/1258476 
has a list of all of the affected issues. If your patch is on the list, 
please set it back to CNR and click the "Submit for re-testing" link on 
the erroneous failure to get it re-tested.

A good rule of thumb in the future is never set a patch RTBC until it's 
been pinged back from the testing bot, which will ensure:

a) The patch applies
b) The patch doesn't cause Drupal to fail to install
c) The patch doesn't have a PHP syntax error
d) All of the automated tests pass

-Angie

From ywarnier at beeznest.org  Tue Nov 18 14:03:57 2008
From: ywarnier at beeznest.org (Yannick Warnier)
Date: Tue, 18 Nov 2008 09:03:57 -0500
Subject: [development] Database creation on Install
In-Reply-To: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
Message-ID: <1227017037.9998.284.camel@localhost>

Le jeudi 13 novembre 2008 ? 23:17 -0600, Amy Stephen a ?crit :
> I apologize if this is not the appropriate place to ask this question
> but I am curious after checking out your fine development work.
> 
> Why doesn't the Drupal Installation process try to create the database
> if it doesn't exist already? WordPress is the same. Joomla! will use
> the database if it exists - and create it, provided the ID has
> sufficient permissions. It's just another "make things easier" step
> (for both the "newbie" crowd, but also developers testing/working).
> 
> I was curious if there were security concerns? Or, if it just never
> seemed to be someone's itch?

Although the thread is kind of closed, I'd like to back this as a
feature request, considering testing if the database exists and trying
to create it doesn't even have to be visible to the final user, and
would be a nice improvement to the installer's usability.

Something like:
$create = @mysql_query('CREATE DATABASE ...');
if ( $create === false ) {
  // ask 
} else {
  // all good, go to next step
}

Anyway, for what it's worth, I'm just saying I think it's a good idea.

Yannick


From eric.schaefer at eas-consulting.de  Tue Nov 18 19:05:28 2008
From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer)
Date: Tue, 18 Nov 2008 20:05:28 +0100
Subject: [development] Policy for setting issues to 'fixed'
Message-ID: <492311F8.2000800@eas-consulting.de>

Hi List,

for contributed modules, what is the prefered policy for setting issues 
to 'fixed' that have reviewed (!) patches attached:
1. when patch has been committed (providing the commit id)
2. when patch has been committed and is part of new release (providing 
release number)

I have observed both ways, I believe.

Thanks,
Eric

From darrenoh at sidepotsinternational.com  Tue Nov 18 19:15:12 2008
From: darrenoh at sidepotsinternational.com (Darren Oh)
Date: Tue, 18 Nov 2008 14:15:12 -0500
Subject: [development] Policy for setting issues to 'fixed'
In-Reply-To: <492311F8.2000800@eas-consulting.de>
References: <492311F8.2000800@eas-consulting.de>
Message-ID: <440AA258-A430-4C7C-BD3F-AB3BE35F48EC@sidepotsinternational.com>

When the patch has been committed. The issue should be referenced in  
the release notes of the next release.

On Nov 18, 2008, at 2:05 PM, Eric-Alexander Schaefer wrote:

> Hi List,
>
> for contributed modules, what is the prefered policy for setting  
> issues to 'fixed' that have reviewed (!) patches attached:
> 1. when patch has been committed (providing the commit id)
> 2. when patch has been committed and is part of new release  
> (providing release number)
>
> I have observed both ways, I believe.
>
> Thanks,
> Eric


From catch56 at googlemail.com  Tue Nov 18 19:23:41 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Tue, 18 Nov 2008 19:23:41 +0000
Subject: [development] Policy for setting issues to 'fixed'
In-Reply-To: <440AA258-A430-4C7C-BD3F-AB3BE35F48EC@sidepotsinternational.com>
References: <492311F8.2000800@eas-consulting.de>
	<440AA258-A430-4C7C-BD3F-AB3BE35F48EC@sidepotsinternational.com>
Message-ID: <fa5724270811181123x4b7b514byf5ba3d36ed17a5c5@mail.gmail.com>

I agree with Darren on this - by definition, an issue can't be fixed in the
'current' release - because that's frozen, so it will always be fixed in the
next one. And it seems like a lot of unnecessary work to go back marking
issues as fixed when you actually roll a release.

This does bring up an issue I've noticed a lot though - many users re-open
issues which are marked fixed, because the bug is still present in whichever
version of the module they're currently using. Also - if something gets
fixed, and the next version of the module isn't released for some time, then
the 'fixed' issue gets marked closed, drops out of the main issue view, and
results in lots and lots of duplicates being posted because people don't see
it. Would be worth considering ways to make these fixed issues more visible
to those trying to report bugs.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081118/0d7ed51a/attachment-0001.htm 

From arancaytar.ilyaran at gmail.com  Tue Nov 18 19:30:56 2008
From: arancaytar.ilyaran at gmail.com (Arancaytar)
Date: Tue, 18 Nov 2008 20:30:56 +0100
Subject: [development] Policy for setting issues to 'fixed'
In-Reply-To: <fa5724270811181123x4b7b514byf5ba3d36ed17a5c5@mail.gmail.com>
References: <492311F8.2000800@eas-consulting.de>	<440AA258-A430-4C7C-BD3F-AB3BE35F48EC@sidepotsinternational.com>
	<fa5724270811181123x4b7b514byf5ba3d36ed17a5c5@mail.gmail.com>
Message-ID: <492317F0.7040102@gmail.com>

Maybe an extra state around the words of "Fix Released"? "Fixed" would
be renamed to something like "Fix Committed", and only "Fix Released"
would be auto-closed?

I've had no problems as a contrib maintainer convincing users that they
just needed to wait for the release. But I also admit that I release
fixes for non-trivial bugs on a quick schedule of only a few days after
the initial commit if no other problems are reported.

-Aran

On 18.11.2008 20:23, Nathaniel Catchpole wrote:
> I agree with Darren on this - by definition, an issue can't be fixed in
> the 'current' release - because that's frozen, so it will always be
> fixed in the next one. And it seems like a lot of unnecessary work to go
> back marking issues as fixed when you actually roll a release.
> 
> This does bring up an issue I've noticed a lot though - many users
> re-open issues which are marked fixed, because the bug is still present
> in whichever version of the module they're currently using. Also - if
> something gets fixed, and the next version of the module isn't released
> for some time, then the 'fixed' issue gets marked closed, drops out of
> the main issue view, and results in lots and lots of duplicates being
> posted because people don't see it. Would be worth considering ways to
> make these fixed issues more visible to those trying to report bugs.
> 
> Nat

-- 
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare,
The lone and level sands stretch far away.
---------------------------------------------
AOL:  realarancaytar / 282026638
XMPP: arancaytar.ilyaran at gmail.com
PGP:  http://ermarian.net/downloads/0x27CA5C74

From eric.schaefer at eas-consulting.de  Tue Nov 18 23:01:13 2008
From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer)
Date: Wed, 19 Nov 2008 00:01:13 +0100
Subject: [development] Policy for setting issues to 'fixed'
In-Reply-To: <fa5724270811181123x4b7b514byf5ba3d36ed17a5c5@mail.gmail.com>
References: <492311F8.2000800@eas-consulting.de>	<440AA258-A430-4C7C-BD3F-AB3BE35F48EC@sidepotsinternational.com>
	<fa5724270811181123x4b7b514byf5ba3d36ed17a5c5@mail.gmail.com>
Message-ID: <49234939.2050102@eas-consulting.de>

Nathaniel Catchpole schrieb:
> I agree with Darren on this - by definition, an issue can't be fixed in 
> the 'current' release - because that's frozen, so it will always be 
> fixed in the next one. And it seems like a lot of unnecessary work to go 
> back marking issues as fixed when you actually roll a release.

Sounds reasonable.

Thanks,
Eric

From andrewberry at sentex.net  Wed Nov 19 02:36:07 2008
From: andrewberry at sentex.net (Andrew Berry)
Date: Tue, 18 Nov 2008 21:36:07 -0500
Subject: [development] disable the title link
In-Reply-To: <200811141458.15028.aldo@caonao.cu>
References: <200811141458.15028.aldo@caonao.cu>
Message-ID: <2CD46EF1-E19D-47A9-B4BC-3ACC4A627F65@sentex.net>

On 14-Nov-08, at 2:58 PM, Aldo Martinez Selleras wrote:

> may i disable the title link in one node where i will execute a php  
> code ???

You don't say what you're trying to do, but I'm going to guess that  
putting php code in the node is the wrong way to do it.

As far as I'm concerned every node should have a title. If you're  
trying to run code on a specific page, consider putting it in a block,  
or in your theme's template.php, or writing a module.

--Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2672 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081118/f2fb800c/attachment.bin 

From andrewberry at sentex.net  Wed Nov 19 02:37:36 2008
From: andrewberry at sentex.net (Andrew Berry)
Date: Tue, 18 Nov 2008 21:37:36 -0500
Subject: [development] Policy for setting issues to 'fixed'
In-Reply-To: <492311F8.2000800@eas-consulting.de>
References: <492311F8.2000800@eas-consulting.de>
Message-ID: <FF40CF43-4E85-4C89-BB10-FF74F20DCA60@sentex.net>

On 18-Nov-08, at 2:05 PM, Eric-Alexander Schaefer wrote:

> 1. when patch has been committed (providing the commit id)

This is what I do and see most commonly, otherwise the issue queue can  
become way too long.

--Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2672 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081118/164ee1e3/attachment.bin 

From andrewberry at sentex.net  Wed Nov 19 02:40:15 2008
From: andrewberry at sentex.net (Andrew Berry)
Date: Tue, 18 Nov 2008 21:40:15 -0500
Subject: [development] Database creation on Install
In-Reply-To: <51408C5F-C9AA-43B1-B8E6-EE75A5126CCE@gmail.com>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<51408C5F-C9AA-43B1-B8E6-EE75A5126CCE@gmail.com>
Message-ID: <61B8A55E-ECCA-4C99-9EDA-7727CD89B7CF@sentex.net>

On 14-Nov-08, at 12:23 AM, Dmitri Gaskin wrote:

> This has not yet been attempted (I think) simply because most people  
> do not install with a user with sufficient rights to create a  
> database, and therefore there is no need for most people

In most setups I've encountered, if you can CREATE DATABASE you can  
also DROP DATABASE. Not really something I want *any* Drupal install  
to be able to do :).

I would actually suggest the other way around, and that if Drupal  
detects that it can do such things that it sets a warning, just like  
how it does if the permissions on settings.php are too lax.

--Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2672 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081118/970edaeb/attachment.bin 

From fernandoparedesgarcia at gmail.com  Wed Nov 19 05:07:41 2008
From: fernandoparedesgarcia at gmail.com (=?ISO-8859-1?Q?=22Fernando_P=2E_Garc=EDa=22?=)
Date: Wed, 19 Nov 2008 00:07:41 -0500
Subject: [development] Database creation on Install
In-Reply-To: <61B8A55E-ECCA-4C99-9EDA-7727CD89B7CF@sentex.net>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>	<51408C5F-C9AA-43B1-B8E6-EE75A5126CCE@gmail.com>
	<61B8A55E-ECCA-4C99-9EDA-7727CD89B7CF@sentex.net>
Message-ID: <49239F1D.8090101@gmail.com>

Andrew Berry wrote:
> In most setups I've encountered, if you can CREATE DATABASE you can 
> also DROP DATABASE. Not really something I want *any* Drupal install 
> to be able to do :).

The feature requests suggested by Yannick is *just* about CREATE 
DATABASE, nothing about DROP...
Just to annotate.

Blessings!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fernandoparedesgarcia.vcf
Type: text/x-vcard
Size: 359 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081119/4346c2fd/attachment-0001.vcf 

From amystephen at gmail.com  Wed Nov 19 05:18:54 2008
From: amystephen at gmail.com (Amy Stephen)
Date: Tue, 18 Nov 2008 23:18:54 -0600
Subject: [development] Database creation on Install
In-Reply-To: <61B8A55E-ECCA-4C99-9EDA-7727CD89B7CF@sentex.net>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<51408C5F-C9AA-43B1-B8E6-EE75A5126CCE@gmail.com>
	<61B8A55E-ECCA-4C99-9EDA-7727CD89B7CF@sentex.net>
Message-ID: <979e7e490811182118w67375fa6t228e0971a26a56e5@mail.gmail.com>

The J! install works like this:

1 - if the database doesn't exist - it's created.

2 - if the database exists - and there are existing tables -

.... a) the existing tables are backed up (default)

.... b) the existing tables are dropped (you have to choose this option)

The database is never dropped.



On Tue, Nov 18, 2008 at 8:40 PM, Andrew Berry <andrewberry at sentex.net>wrote:

> On 14-Nov-08, at 12:23 AM, Dmitri Gaskin wrote:
>
>  This has not yet been attempted (I think) simply because most people do
>> not install with a user with sufficient rights to create a database, and
>> therefore there is no need for most people
>>
>
> In most setups I've encountered, if you can CREATE DATABASE you can also
> DROP DATABASE. Not really something I want *any* Drupal install to be able
> to do :).
>
> I would actually suggest the other way around, and that if Drupal detects
> that it can do such things that it sets a warning, just like how it does if
> the permissions on settings.php are too lax.
>
> --Andrew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081118/07e7c9e6/attachment.htm 

From ywarnier at beeznest.org  Wed Nov 19 05:25:45 2008
From: ywarnier at beeznest.org (Yannick Warnier)
Date: Wed, 19 Nov 2008 00:25:45 -0500
Subject: [development] Database creation on Install
In-Reply-To: <61B8A55E-ECCA-4C99-9EDA-7727CD89B7CF@sentex.net>
References: <979e7e490811132117r5ea68b8boc583e084ea351faf@mail.gmail.com>
	<51408C5F-C9AA-43B1-B8E6-EE75A5126CCE@gmail.com>
	<61B8A55E-ECCA-4C99-9EDA-7727CD89B7CF@sentex.net>
Message-ID: <1227072345.9998.407.camel@localhost>

Le mardi 18 novembre 2008 ? 21:40 -0500, Andrew Berry a ?crit :
> On 14-Nov-08, at 12:23 AM, Dmitri Gaskin wrote:
> 
> > This has not yet been attempted (I think) simply because most people  
> > do not install with a user with sufficient rights to create a  
> > database, and therefore there is no need for most people
> 
> In most setups I've encountered, if you can CREATE DATABASE you can  
> also DROP DATABASE. Not really something I want *any* Drupal install  
> to be able to do :).

Considering Drupal is open-source and, as such, its database structure
is pretty much public, I can't see much difference in the results
between a "DROP DATABASE x" and several "DELETE FROM TABLE x" ...and I'm
pretty sure Drupal needs a delete permission for most tables.

Yannick


From eric.schaefer at eas-consulting.de  Wed Nov 19 14:58:32 2008
From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer)
Date: Wed, 19 Nov 2008 15:58:32 +0100
Subject: [development] Make Scheduler more generic
Message-ID: <49242998.8040303@eas-consulting.de>

Hi list,

we (a couple of scheduler.module users and I) have been thinking about 
making scheduler more generic because every other week somebody suggest 
another thing that needs to be scheduled. The plan is to make scheduler 
a provider for scheduled triggers. It would hook into the node form and 
let the user select a date and time and the action that is to be 
performed at that time (e.g. trigger "Make post sticky"-action at $date).

I am about to begin coding, but I thought I should share the ideas with 
this list to get some more input before I start.

Here are the ideas so far: http://drupal.org/node/276376

Thanks,
Eric

From barkan at vizteck.com  Wed Nov 19 15:01:03 2008
From: barkan at vizteck.com (Barkan Saeed)
Date: Wed, 19 Nov 2008 20:01:03 +0500
Subject: [development] Make Scheduler more generic
In-Reply-To: <49242998.8040303@eas-consulting.de>
References: <49242998.8040303@eas-consulting.de>
Message-ID: <49242A2F.301@vizteck.com>

Eric, I have drupal developers on team.. if you need any assistance from 
us on this.. we would like to contribute to community

Regards

*Barkan Saeed*


Project Manager/Managing Director
*Vizteck Solutions*

*Ph: +1-480-626-7513 , +92-4413774
barkan at vizteck.com*
*http://www.vizteck.com*



Eric-Alexander Schaefer wrote:
> Hi list,
>
> we (a couple of scheduler.module users and I) have been thinking about 
> making scheduler more generic because every other week somebody 
> suggest another thing that needs to be scheduled. The plan is to make 
> scheduler a provider for scheduled triggers. It would hook into the 
> node form and let the user select a date and time and the action that 
> is to be performed at that time (e.g. trigger "Make post 
> sticky"-action at $date).
>
> I am about to begin coding, but I thought I should share the ideas 
> with this list to get some more input before I start.
>
> Here are the ideas so far: http://drupal.org/node/276376
>
> Thanks,
> Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081119/81ed2715/attachment.htm 

From aldo at caonao.cu  Wed Nov 19 19:40:21 2008
From: aldo at caonao.cu (Aldo Martinez Selleras)
Date: Wed, 19 Nov 2008 14:40:21 -0500
Subject: [development] how to redirect user after login
Message-ID: <200811191440.21974.aldo@caonao.cu>

how may i redirect the user to frontpage, exactly after user login, not when 
the user recieve a 403 error, when the user log in, always send him to 
frontpage!

how can i do this! some module? any modification to user module ?

-- 
----------------------
Aldo Martinez Selleras
Administrador del Nodo
CITMATEL GND Camaguey
Tel: 32-291661
E-mail: aldo at caonao.cu
Linux User #364356

From kb at 2bits.com  Wed Nov 19 19:54:05 2008
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Wed, 19 Nov 2008 14:54:05 -0500
Subject: [development] how to redirect user after login
In-Reply-To: <200811191440.21974.aldo@caonao.cu>
References: <200811191440.21974.aldo@caonao.cu>
Message-ID: <4a9fdc630811191154v16230516qdf28376e83c7b883@mail.gmail.com>

Check this http://drupal.org/project/login_destination

On Wed, Nov 19, 2008 at 2:40 PM, Aldo Martinez Selleras <aldo at caonao.cu>wrote:

> how may i redirect the user to frontpage, exactly after user login, not
> when
> the user recieve a 403 error, when the user log in, always send him to
> frontpage!
>
> how can i do this! some module? any modification to user module ?
>
> --
> ----------------------
> Aldo Martinez Selleras
> Administrador del Nodo
> CITMATEL GND Camaguey
> Tel: 32-291661
> E-mail: aldo at caonao.cu
> Linux User #364356
>



-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081119/4768c75f/attachment.htm 

From michael at favias.org  Wed Nov 19 19:57:58 2008
From: michael at favias.org (Michael Favia)
Date: Wed, 19 Nov 2008 13:57:58 -0600
Subject: [development] how to redirect user after login
In-Reply-To: <200811191440.21974.aldo@caonao.cu>
References: <200811191440.21974.aldo@caonao.cu>
Message-ID: <49246FC6.70003@favias.org>

Aldo Martinez Selleras wrote:
> how can i do this! some module? any modification to user module 
It basically boils down to changing the form action attribute to the 
appropriate value and handling the login credentials for the form 
submission. -mf

From karoly at negyesi.net  Thu Nov 20 06:02:46 2008
From: karoly at negyesi.net (Karoly Negyesi)
Date: Wed, 19 Nov 2008 22:02:46 -0800
Subject: [development] Drupal 7 could be awesome if...
Message-ID: <7e270cea0811192202t7e60fc47s36992b84538281ec@mail.gmail.com>

someone would take Plugin Manager, port to D7 (easy), clean up to code
standards (not hard at all and you will get a lot of help).

http://drupal.org/node/336743

the project has two active and hepful maintainers but as said, I
myself and a number of people on #drupal would be glad to help.

Any takers?

Thanks

NK

From adrian at bryght.com  Thu Nov 20 08:08:35 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Thu, 20 Nov 2008 10:08:35 +0200
Subject: [development] Drupal 7 could be awesome if...
In-Reply-To: <7e270cea0811192202t7e60fc47s36992b84538281ec@mail.gmail.com>
References: <7e270cea0811192202t7e60fc47s36992b84538281ec@mail.gmail.com>
Message-ID: <7E6F5DB1-C7A0-48BE-A56E-7A29F749C736@bryght.com>


On 20 Nov 2008, at 8:02 AM, Karoly Negyesi wrote:

> someone would take Plugin Manager, port to D7 (easy), clean up to code
> standards (not hard at all and you will get a lot of help).

As far as I can tell, it needs to have your server be publicly  
accessible, with an ftp server running,
or with special libraries compiled into PHP, to even work in a basic  
setup.

This means that the module just won't work for the large majority of  
the install base.

It can also not be deployed on a local test environment, as that tends  
to be behind a firewall
with no public IP.

As it stands, I don't believe it's a good candidate for core.
(although I am impressed at how secure they have been able to make it)

This might be able to be worked around if we get more of drush in core  
to be able
to pull the files. But that also requires ssh access (or the ability  
to add a cronjob, maybe).


From darrel.opry at gmail.com  Thu Nov 20 18:02:22 2008
From: darrel.opry at gmail.com (Darrel O'Pry)
Date: Thu, 20 Nov 2008 13:02:22 -0500
Subject: [development] how to redirect user after login
In-Reply-To: <49246FC6.70003@favias.org>
References: <200811191440.21974.aldo@caonao.cu> <49246FC6.70003@favias.org>
Message-ID: <bfcbb6230811201002x1b4f4d18j393a33d435da7ff5@mail.gmail.com>

I would look to drupal_redirect_form for answers...
http://api.drupal.org/api/function/drupal_redirect_form/6
for the lazy.   form_alter in a 'redirect' for user forms in a custom
module...

On Wed, Nov 19, 2008 at 2:57 PM, Michael Favia <michael at favias.org> wrote:

> Aldo Martinez Selleras wrote:
>
>> how can i do this! some module? any modification to user module
>>
> It basically boils down to changing the form action attribute to the
> appropriate value and handling the login credentials for the form
> submission. -mf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081120/fb2e253f/attachment.htm 

From andrewberry at sentex.net  Fri Nov 21 14:57:41 2008
From: andrewberry at sentex.net (Andrew Berry)
Date: Fri, 21 Nov 2008 09:57:41 -0500
Subject: [development] how to redirect user after login
In-Reply-To: <4a9fdc630811191154v16230516qdf28376e83c7b883@mail.gmail.com>
References: <200811191440.21974.aldo@caonao.cu>
	<4a9fdc630811191154v16230516qdf28376e83c7b883@mail.gmail.com>
Message-ID: <01DEF9C2-0FE0-4346-A4A4-006485D1476C@sentex.net>

On 19-Nov-08, at 2:54 PM, Khalid Baheyeldin wrote:

> Check this http://drupal.org/project/login_destination

That module works well, a +1 from me.

> not when
> the user recieve a 403 error

Our users have found the customerror for 403's to be really useful by  
adding the following PHP snippet:

<?php
global $user;
if ($user->uid == 0) {
   print '<p>If your user account has access to this page, <a href="/ 
user?' . drupal_get_destination() . '">log in with your user account</ 
a>.</p>';
}
?>

That way when there's a 403 they get redirected back to the page they  
were trying to access. The above is not really "best practice", it  
should probably call l() or url() so it works when clean URL's are  
disabled.

--Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2672 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20081121/8ac96e54/attachment.bin 

From karoly at negyesi.net  Sat Nov 22 14:18:55 2008
From: karoly at negyesi.net (Karoly Negyesi)
Date: Sat, 22 Nov 2008 15:18:55 +0100 (CET)
Subject: [development] Drupal 7 could be awesome if...
In-Reply-To: <7E6F5DB1-C7A0-48BE-A56E-7A29F749C736@bryght.com>
References: <7e270cea0811192202t7e60fc47s36992b84538281ec@mail.gmail.com>
	<7E6F5DB1-C7A0-48BE-A56E-7A29F749C736@bryght.com>
Message-ID: <E1L3tK3-0006RK-Pa@garm.runbox.com>

> As far as I can tell, it needs to have your server be publicly  
> accessible, with an ftp server running,

TRUE.

> or with special libraries compiled into PHP

TRUE

> to even work in a basic setup.

FALSE: We disagree on the definiton of "basic setup".
 
> This means that the module just won't work for the large majority of  
> the install base.

FALSE: The majority of our install base are on shared hosters which run public accessible FTP servers, thank you.

> It can also not be deployed on a local test environment, 

TRUE (unless you start an ftpd or pecl install ssh2)

> as that tends to be behind a firewall with no public IP.

FALSE. (your browser is behind that too)
 
> As it stands, I don't believe it's a good candidate for core.

FALSE.

> (although I am impressed at how secure they have been able to make it)

TRUE. 

Regards

NL

From swentel at realize.be  Sat Nov 22 17:42:27 2008
From: swentel at realize.be (Kristof De Jaeger)
Date: Sat, 22 Nov 2008 18:42:27 +0100
Subject: [development] Drupal 7 could be awesome if...
In-Reply-To: <E1L3tK3-0006RK-Pa@garm.runbox.com>
References: <7e270cea0811192202t7e60fc47s36992b84538281ec@mail.gmail.com>	<7E6F5DB1-C7A0-48BE-A56E-7A29F749C736@bryght.com>
	<E1L3tK3-0006RK-Pa@garm.runbox.com>
Message-ID: <49284483.2010006@realize.be>

I did a fast port for D7, see http://drupal.org/node/336743
It needs some more love in code and UI, but I think we have enough
people (including me) available to help with this.

K

Karoly Negyesi wrote:
>> As far as I can tell, it needs to have your server be publicly  
>> accessible, with an ftp server running,
> 
> TRUE.
> 
>> or with special libraries compiled into PHP
> 
> TRUE
> 
>> to even work in a basic setup.
> 
> FALSE: We disagree on the definiton of "basic setup".
>  
>> This means that the module just won't work for the large majority of  
>> the install base.
> 
> FALSE: The majority of our install base are on shared hosters which run public accessible FTP servers, thank you.
> 
>> It can also not be deployed on a local test environment, 
> 
> TRUE (unless you start an ftpd or pecl install ssh2)
> 
>> as that tends to be behind a firewall with no public IP.
> 
> FALSE. (your browser is behind that too)
>  
>> As it stands, I don't believe it's a good candidate for core.
> 
> FALSE.
> 
>> (although I am impressed at how secure they have been able to make it)
> 
> TRUE. 
> 
> Regards
> 
> NL
> 

From karoly at negyesi.net  Sun Nov 23 04:13:51 2008
From: karoly at negyesi.net (Karoly Negyesi)
Date: Sun, 23 Nov 2008 05:13:51 +0100 (CET)
Subject: [development] Drupal 7 could be awesome if...
In-Reply-To: <E1L3tK3-0006RK-Pa@garm.runbox.com>
References: <7e270cea0811192202t7e60fc47s36992b84538281ec@mail.gmail.com>
	<7E6F5DB1-C7A0-48BE-A56E-7A29F749C736@bryght.com>
	<E1L3tK3-0006RK-Pa@garm.runbox.com>
Message-ID: <E1L46M3-0005fW-EP@fenris.runbox.com>

> > As far as I can tell, it needs to have your server be publicly  
> > accessible, with an ftp server running,
> TRUE.

> > as that tends to be behind a firewall with no public IP.
> 
> FALSE. (your browser is behind that too)

I made a mistake with those two: the server does not need to be public accessible and the browser does not need matter. What matters is that there is an FTP server which the webserver can access.

From karoly at negyesi.net  Sun Nov 23 04:16:24 2008
From: karoly at negyesi.net (Karoly Negyesi)
Date: Sun, 23 Nov 2008 05:16:24 +0100 (CET)
Subject: [development] Drupal 7 could be awesome if...
In-Reply-To: <49284483.2010006@realize.be>
References: <7e270cea0811192202t7e60fc47s36992b84538281ec@mail.gmail.com>
	<7E6F5DB1-C7A0-48BE-A56E-7A29F749C736@bryght.com>
	<E1L3tK3-0006RK-Pa@garm.runbox.com> <49284483.2010006@realize.be>
Message-ID: <E1L46OW-0004OD-6s@garm.runbox.com>

> I did a fast port for D7, see http://drupal.org/node/336743
> It needs some more love in code and UI, but I think we have enough
> people (including me) available to help with this.

Fantastic!! Thanks.

From yuval at avramzon.net  Mon Nov 24 13:59:38 2008
From: yuval at avramzon.net (Yuval Hager)
Date: Mon, 24 Nov 2008 15:59:38 +0200
Subject: [development] Drupal 7 could be awesome if...
In-Reply-To: <7E6F5DB1-C7A0-48BE-A56E-7A29F749C736@bryght.com>
References: <7e270cea0811192202t7e60fc47s36992b84538281ec@mail.gmail.com>
	<7E6F5DB1-C7A0-48BE-A56E-7A29F749C736@bryght.com>
Message-ID: <200811241559.44636.yuval@avramzon.net>

On Thursday 20 November 2008, Adrian Rossouw wrote:
> (although I am impressed at how secure they have been able to make it)

I'm using a VPS, and for security reasons I do not run an ftp server. For SSH 
to work, I need to enter my SSH password over the clear channel between my 
browser and my server, which beats the whole purpose of SSH being secure.

I'm pretty sure that for most (read: all) users usability counts higher than 
security, but for me it's a blocker to use this module or even call it 
secure.

--yuval
-------------- 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 : http://lists.drupal.org/pipermail/development/attachments/20081124/525b3c0d/attachment-0001.pgp 

From hdeelstra at gmail.com  Tue Nov 25 09:55:33 2008
From: hdeelstra at gmail.com (Heine Deelstra)
Date: Tue, 25 Nov 2008 10:55:33 +0100
Subject: [development] New maintainer sought for Comment Upload, Elements,
	Flatcomments, Taxonomy Defaults and User Badges
Message-ID: <2b508f910811250155w3299f547n4d7fce775873179e@mail.gmail.com>

I seek a new maintainer for the following modules:

http://drupal.org/project/comment_upload
http://drupal.org/project/elements
http://drupal.org/project/flatcomments
http://drupal.org/project/taxonomy_defaults
http://drupal.org/project/user_badges

(others aren't worth continuing imo).

If you are interested, please reply on the issue queue for the
relevant project and I'll assign the projects.

Kind regards,

Heine Deelstra