From amont at 5net.hu  Mon Mar  2 09:25:46 2009
From: amont at 5net.hu (=?ISO-8859-2?Q?=C1mon_Tam=E1s?=)
Date: Mon, 02 Mar 2009 10:25:46 +0100
Subject: [development] Extra fields for file upload
Message-ID: <49ABA61A.4090905@5net.hu>

Hello,

How can I add more attribute to a file upload field?
I am using filefield module, and I like to add some extra attribute,
like language, file-version etc. How can I make it?


?mon Tam?s
Sitefejleszt? ?s programoz?
-- 
5NET Informatikai Kft.
1062 Budapest, Aradi utca 38. A 3/11
telefon: (1) 461-0205  |  fax: (1) 461-0206
e-mail: amont at 5net.hu  |  web: http://www.5net.hu


From mistknight at gmail.com  Mon Mar  2 09:53:40 2009
From: mistknight at gmail.com (Ashraf Amayreh)
Date: Mon, 2 Mar 2009 11:53:40 +0200
Subject: [development] Extra fields for file upload
In-Reply-To: <49ABA61A.4090905@5net.hu>
References: <49ABA61A.4090905@5net.hu>
Message-ID: <a53d1b3b0903020153t2875b7c4w263c92526a60be01@mail.gmail.com>

Please create an issue in the filefield issue queue, this is a development
list that only addresses development topics

http://drupal.org/project/issues/filefield

2009/3/2 ?mon Tam?s <amont at 5net.hu>

> Hello,
>
> How can I add more attribute to a file upload field?
> I am using filefield module, and I like to add some extra attribute,
> like language, file-version etc. How can I make it?
>
>
> ?mon Tam?s
> Sitefejleszt? ?s programoz?
> --
> 5NET Informatikai Kft.
> 1062 Budapest, Aradi utca 38. A 3/11
> telefon: (1) 461-0205  |  fax: (1) 461-0206
> e-mail: amont at 5net.hu  |  web: http://www.5net.hu
>
>


-- 
Ashraf Amayreh
http://aamayreh.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090302/9d0d4b5b/attachment.htm 

From arthur at 24b6.net  Mon Mar  2 14:12:12 2009
From: arthur at 24b6.net (arthur)
Date: Mon, 2 Mar 2009 09:12:12 -0500
Subject: [development] Modules up for grabs to qualified individuals...
In-Reply-To: <bfcbb6230902261315w18d4548eoe5461a1f8b96cf39@mail.gmail.com>
References: <bfcbb6230902261315w18d4548eoe5461a1f8b96cf39@mail.gmail.com>
Message-ID: <0A2B1737-3157-4A5C-888E-4C27562B363C@24b6.net>

If anybody is thinking about taking FFmpeg, I'd love to chat about  
combining FFmpeg Wrapper and FFmpeg- the modules aren't a direct  
duplication of one another, but I think the functionality can be  
merged to provide really solid FFmpeg support.

a.


On Feb 26, 2009, at 4:15 PM, Darrel O'Pry wrote:

> I'll be bowing out of Drupal development for a while. The following  
> modules would like new maintainers.
>
> Daylife, Derivative, Fapilicious, FFMpeg, Filefield, GeoLocation,  
> ImageAPI, Imagecache, Imagefield, MimeDetect, NodeReferrer, and  
> Transformer.
>
> If you're interested in taking over one of the modules send me an  
> email with your plans for the module, why you think you're  
> qualified, and links to your other work.
>
> .darrel.

---------------------------------------------------
arthur at civicactions.com



---------------------------------------------------
arthur at 24b6.net




From nabil at gobrighttree.com  Mon Mar  2 15:24:29 2009
From: nabil at gobrighttree.com (Nabil Alsharif)
Date: Mon, 02 Mar 2009 09:24:29 -0600
Subject: [development] Update.php re-design
Message-ID: <1236007469.3453.24.camel@al-sa3ek.lappy>

There seems to be a couple of projects that are trying to make
update.php command line friendly, non of which seem to be going that
well:
http://drupal.org/node/194107
http://acquia.com/blog/drupal-cli-utils

The issue that I see is that update.php is tightly coupled with the UI.
What I would like to do is pull the functions that preform the updates
out of update.php so that it would be possible to have a different UIs
to modules (Web interface, cli). There are two main reasons I would like
to do this:
1. It would make the projects mentioned above much easier to implement.
2. The projects mentioned above have there own implementation of
update.php that is independent of that way drupal updates the modules.

I hope to endup with something along the lines of update.inc that holds
the function for preforming the updates (i.e get_updates, do_update,
db_add_column.. etc) and update.php that has the current UI for
updates. 

Is there any reason that this hasn't been done before? More importantly
does any one have any good reason to not separate preforming the updates
from the UI? 

-- 
?----------------------------------
Nabil Alsharif
Bright Tree
573-499-1244

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited. Please
consider the environment before printing this email or its
attachment(s).
-------------- 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/20090302/bfcaa1e1/attachment.pgp 

From weitzman at tejasa.com  Mon Mar  2 15:22:03 2009
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Mon, 2 Mar 2009 10:22:03 -0500
Subject: [development] Update.php re-design
In-Reply-To: <1236007469.3453.24.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
Message-ID: <6117a7500903020722k17675255n840c9a4179d8db22@mail.gmail.com>

This makes sense, and I encourage you and others to proceed. There is
no good reason it has not been done so far.

On Mon, Mar 2, 2009 at 10:24 AM, Nabil Alsharif <nabil at gobrighttree.com> wrote:
> There seems to be a couple of projects that are trying to make
> update.php command line friendly, non of which seem to be going that
> well:
> http://drupal.org/node/194107
> http://acquia.com/blog/drupal-cli-utils
>
> The issue that I see is that update.php is tightly coupled with the UI.
> What I would like to do is pull the functions that preform the updates
> out of update.php so that it would be possible to have a different UIs
> to modules (Web interface, cli). There are two main reasons I would like
> to do this:
> 1. It would make the projects mentioned above much easier to implement.
> 2. The projects mentioned above have there own implementation of
> update.php that is independent of that way drupal updates the modules.
>
> I hope to endup with something along the lines of update.inc that holds
> the function for preforming the updates (i.e get_updates, do_update,
> db_add_column.. etc) and update.php that has the current UI for
> updates.
>
> Is there any reason that this hasn't been done before? More importantly
> does any one have any good reason to not separate preforming the updates
> from the UI?
>
> --
> ?----------------------------------
> Nabil Alsharif
> Bright Tree
> 573-499-1244
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete
> the original. Any other use of the email by you is prohibited. Please
> consider the environment before printing this email or its
> attachment(s).
>

From jbrown at openpackage.biz  Mon Mar  2 15:54:13 2009
From: jbrown at openpackage.biz (Jonathan Brown)
Date: Mon, 02 Mar 2009 15:54:13 +0000
Subject: [development] Modules up for grabs to qualified individuals...
In-Reply-To: <0A2B1737-3157-4A5C-888E-4C27562B363C@24b6.net>
References: <bfcbb6230902261315w18d4548eoe5461a1f8b96cf39@mail.gmail.com>
	<0A2B1737-3157-4A5C-888E-4C27562B363C@24b6.net>
Message-ID: <1236009253.4858.10.camel@akalabeth.home>

The ffmpeg implementation in openpackage video is vastly superior with
further improvements to come. I don't know why people started
duplicating it.


On Mon, 2009-03-02 at 09:12 -0500, arthur wrote:
> If anybody is thinking about taking FFmpeg, I'd love to chat about  
> combining FFmpeg Wrapper and FFmpeg- the modules aren't a direct  
> duplication of one another, but I think the functionality can be  
> merged to provide really solid FFmpeg support.
> 
> a.
> 
> 
> On Feb 26, 2009, at 4:15 PM, Darrel O'Pry wrote:
> 
> > I'll be bowing out of Drupal development for a while. The following  
> > modules would like new maintainers.
> >
> > Daylife, Derivative, Fapilicious, FFMpeg, Filefield, GeoLocation,  
> > ImageAPI, Imagecache, Imagefield, MimeDetect, NodeReferrer, and  
> > Transformer.
> >
> > If you're interested in taking over one of the modules send me an  
> > email with your plans for the module, why you think you're  
> > qualified, and links to your other work.
> >
> > .darrel.
> 
> ---------------------------------------------------
> arthur at civicactions.com
> 
> 
> 
> ---------------------------------------------------
> arthur at 24b6.net
> 
> 
> 


From nabil at gobrighttree.com  Mon Mar  2 16:16:10 2009
From: nabil at gobrighttree.com (Nabil Alsharif)
Date: Mon, 02 Mar 2009 10:16:10 -0600
Subject: [development] Update.php re-design
In-Reply-To: <6117a7500903020722k17675255n840c9a4179d8db22@mail.gmail.com>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<6117a7500903020722k17675255n840c9a4179d8db22@mail.gmail.com>
Message-ID: <1236010570.3453.32.camel@al-sa3ek.lappy>

Great. This is going to be my first contribution to drupal and I don't
know what the process for submitting such changes is. Do I open an issue
and attach patches? Or do I have to sign up for a cvs account and commit
via cvs? 

Would it be better to submit (patches or commit) partial but working
changes, or should I wait until it's all done and then submit one big
change?

On Mon, 2009-03-02 at 10:22 -0500, Moshe Weitzman wrote:
> This makes sense, and I encourage you and others to proceed. There is
> no good reason it has not been done so far.
> 
> On Mon, Mar 2, 2009 at 10:24 AM, Nabil Alsharif <nabil at gobrighttree.com> wrote:
> > There seems to be a couple of projects that are trying to make
> > update.php command line friendly, non of which seem to be going that
> > well:
> > http://drupal.org/node/194107
> > http://acquia.com/blog/drupal-cli-utils
> >
> > The issue that I see is that update.php is tightly coupled with the UI.
> > What I would like to do is pull the functions that preform the updates
> > out of update.php so that it would be possible to have a different UIs
> > to modules (Web interface, cli). There are two main reasons I would like
> > to do this:
> > 1. It would make the projects mentioned above much easier to implement.
> > 2. The projects mentioned above have there own implementation of
> > update.php that is independent of that way drupal updates the modules.
> >
> > I hope to endup with something along the lines of update.inc that holds
> > the function for preforming the updates (i.e get_updates, do_update,
> > db_add_column.. etc) and update.php that has the current UI for
> > updates.
> >
> > Is there any reason that this hasn't been done before? More importantly
> > does any one have any good reason to not separate preforming the updates
> > from the UI?
> >
> > --
> > ?----------------------------------
> > Nabil Alsharif
> > Bright Tree
> > 573-499-1244
> >
> > This message is for the designated recipient only and may contain
> > privileged, proprietary, or otherwise private information. If you have
> > received it in error, please notify the sender immediately and delete
> > the original. Any other use of the email by you is prohibited. Please
> > consider the environment before printing this email or its
> > attachment(s).
> >
-------------- 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/20090302/53a46be5/attachment.pgp 

From stewsnooze at gmail.com  Mon Mar  2 16:17:36 2009
From: stewsnooze at gmail.com (Stewart Robinson)
Date: Mon, 2 Mar 2009 16:17:36 +0000
Subject: [development] Update.php re-design
In-Reply-To: <1236010570.3453.32.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<6117a7500903020722k17675255n840c9a4179d8db22@mail.gmail.com>
	<1236010570.3453.32.camel@al-sa3ek.lappy>
Message-ID: <b84e952a0903020817o7577b039m9ac6a2d89fe2ec0d@mail.gmail.com>

update.php uses the batch api I believe.  It would be brilliant if the whole
batch api could be run in CLI mode rather than just update.php.  Good luck.
Stew

2009/3/2 Nabil Alsharif <nabil at gobrighttree.com>

> Great. This is going to be my first contribution to drupal and I don't
> know what the process for submitting such changes is. Do I open an issue
> and attach patches? Or do I have to sign up for a cvs account and commit
> via cvs?
>
> Would it be better to submit (patches or commit) partial but working
> changes, or should I wait until it's all done and then submit one big
> change?
>
> On Mon, 2009-03-02 at 10:22 -0500, Moshe Weitzman wrote:
> > This makes sense, and I encourage you and others to proceed. There is
> > no good reason it has not been done so far.
> >
> > On Mon, Mar 2, 2009 at 10:24 AM, Nabil Alsharif <nabil at gobrighttree.com>
> wrote:
> > > There seems to be a couple of projects that are trying to make
> > > update.php command line friendly, non of which seem to be going that
> > > well:
> > > http://drupal.org/node/194107
> > > http://acquia.com/blog/drupal-cli-utils
> > >
> > > The issue that I see is that update.php is tightly coupled with the UI.
> > > What I would like to do is pull the functions that preform the updates
> > > out of update.php so that it would be possible to have a different UIs
> > > to modules (Web interface, cli). There are two main reasons I would
> like
> > > to do this:
> > > 1. It would make the projects mentioned above much easier to implement.
> > > 2. The projects mentioned above have there own implementation of
> > > update.php that is independent of that way drupal updates the modules.
> > >
> > > I hope to endup with something along the lines of update.inc that holds
> > > the function for preforming the updates (i.e get_updates, do_update,
> > > db_add_column.. etc) and update.php that has the current UI for
> > > updates.
> > >
> > > Is there any reason that this hasn't been done before? More importantly
> > > does any one have any good reason to not separate preforming the
> updates
> > > from the UI?
> > >
> > > --
> > > ?----------------------------------
> > > Nabil Alsharif
> > > Bright Tree
> > > 573-499-1244
> > >
> > > This message is for the designated recipient only and may contain
> > > privileged, proprietary, or otherwise private information. If you have
> > > received it in error, please notify the sender immediately and delete
> > > the original. Any other use of the email by you is prohibited. Please
> > > consider the environment before printing this email or its
> > > attachment(s).
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090302/4a1a5408/attachment-0001.htm 

From winborn at advomatic.com  Mon Mar  2 16:13:22 2009
From: winborn at advomatic.com (Aaron Winborn)
Date: Mon, 2 Mar 2009 11:13:22 -0500 (EST)
Subject: [development] Modules up for grabs to qualified individuals...
In-Reply-To: <22898188.262201236010371911.JavaMail.root@zimbra>
Message-ID: <4222012.262221236010402552.JavaMail.root@zimbra>

If it's so superior, I don't understand why OpenPackage hasn't moved that part of their package as a patch for an API so everyone could benefit.

----- Original Message -----
From: "Jonathan Brown" <jbrown at openpackage.biz>
To: development at drupal.org
Sent: Monday, March 2, 2009 10:54:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [development] Modules up for grabs to qualified individuals...

The ffmpeg implementation in openpackage video is vastly superior with
further improvements to come. I don't know why people started
duplicating it.


On Mon, 2009-03-02 at 09:12 -0500, arthur wrote:
> If anybody is thinking about taking FFmpeg, I'd love to chat about  
> combining FFmpeg Wrapper and FFmpeg- the modules aren't a direct  
> duplication of one another, but I think the functionality can be  
> merged to provide really solid FFmpeg support.
> 
> a.
> 
> 
> On Feb 26, 2009, at 4:15 PM, Darrel O'Pry wrote:
> 
> > I'll be bowing out of Drupal development for a while. The following  
> > modules would like new maintainers.
> >
> > Daylife, Derivative, Fapilicious, FFMpeg, Filefield, GeoLocation,  
> > ImageAPI, Imagecache, Imagefield, MimeDetect, NodeReferrer, and  
> > Transformer.
> >
> > If you're interested in taking over one of the modules send me an  
> > email with your plans for the module, why you think you're  
> > qualified, and links to your other work.
> >
> > .darrel.
> 
> ---------------------------------------------------
> arthur at civicactions.com
> 
> 
> 
> ---------------------------------------------------
> arthur at 24b6.net
> 
> 
> 


From jbrown at openpackage.biz  Mon Mar  2 16:25:12 2009
From: jbrown at openpackage.biz (Jonathan Brown)
Date: Mon, 02 Mar 2009 16:25:12 +0000
Subject: [development] Modules up for grabs to qualified individuals...
In-Reply-To: <4222012.262221236010402552.JavaMail.root@zimbra>
References: <4222012.262221236010402552.JavaMail.root@zimbra>
Message-ID: <1236011112.4858.15.camel@akalabeth.home>

A transcoder module with a plugin API is the destination. We can discuss
this at DC.

Looking forward to it.

On Mon, 2009-03-02 at 11:13 -0500, Aaron Winborn wrote:
> If it's so superior, I don't understand why OpenPackage hasn't moved that part of their package as a patch for an API so everyone could benefit.
> 
> ----- Original Message -----
> From: "Jonathan Brown" <jbrown at openpackage.biz>
> To: development at drupal.org
> Sent: Monday, March 2, 2009 10:54:13 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [development] Modules up for grabs to qualified individuals...
> 
> The ffmpeg implementation in openpackage video is vastly superior with
> further improvements to come. I don't know why people started
> duplicating it.
> 
> 
> On Mon, 2009-03-02 at 09:12 -0500, arthur wrote:
> > If anybody is thinking about taking FFmpeg, I'd love to chat about  
> > combining FFmpeg Wrapper and FFmpeg- the modules aren't a direct  
> > duplication of one another, but I think the functionality can be  
> > merged to provide really solid FFmpeg support.
> > 
> > a.
> > 
> > 
> > On Feb 26, 2009, at 4:15 PM, Darrel O'Pry wrote:
> > 
> > > I'll be bowing out of Drupal development for a while. The following  
> > > modules would like new maintainers.
> > >
> > > Daylife, Derivative, Fapilicious, FFMpeg, Filefield, GeoLocation,  
> > > ImageAPI, Imagecache, Imagefield, MimeDetect, NodeReferrer, and  
> > > Transformer.
> > >
> > > If you're interested in taking over one of the modules send me an  
> > > email with your plans for the module, why you think you're  
> > > qualified, and links to your other work.
> > >
> > > .darrel.
> > 
> > ---------------------------------------------------
> > arthur at civicactions.com
> > 
> > 
> > 
> > ---------------------------------------------------
> > arthur at 24b6.net
> > 
> > 
> > 
> 


From darrenoh at sidepotsinternational.com  Mon Mar  2 16:23:30 2009
From: darrenoh at sidepotsinternational.com (Darren Oh)
Date: Mon, 2 Mar 2009 11:23:30 -0500
Subject: [development] Modules up for grabs to qualified individuals...
In-Reply-To: <4222012.262221236010402552.JavaMail.root@zimbra>
References: <4222012.262221236010402552.JavaMail.root@zimbra>
Message-ID: <D1B77F3F-9436-49DA-B6AC-CAEE27AA1C50@sidepotsinternational.com>

It's at http://drupal.org/project/op_video.

On Mar 2, 2009, at 11:13 AM, Aaron Winborn wrote:

> If it's so superior, I don't understand why OpenPackage hasn't moved  
> that part of their package as a patch for an API so everyone could  
> benefit.

From kyle at codeincarnate.com  Mon Mar  2 16:56:37 2009
From: kyle at codeincarnate.com (Kyle Cunningham)
Date: Mon, 02 Mar 2009 10:56:37 -0600
Subject: [development] Update.php re-design
In-Reply-To: <1236010570.3453.32.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>	<6117a7500903020722k17675255n840c9a4179d8db22@mail.gmail.com>
	<1236010570.3453.32.camel@al-sa3ek.lappy>
Message-ID: <49AC0FC5.6030201@codeincarnate.com>

Nabil Alsharif wrote:
> Great. This is going to be my first contribution to drupal and I don't
> know what the process for submitting such changes is. Do I open an issue
> and attach patches? Or do I have to sign up for a cvs account and commit
> via cvs? 
With this you generally open a new issue (or multiple issues) and with
each issue have a patch at the ready.  It's up to you to decide how fine
grained you want it to be.  But generally smaller patches are better
(they are easier to review).


> Would it be better to submit (patches or commit) partial but working
> changes, or should I wait until it's all done and then submit one big
> change?
If you can I would suggest trying to make the changes incremental and
submitting them over a period of time, with newer patches building on
the older ones.  Open them in separate issues, you can reference the
older issue number in the new issue (e.g. Building on #123456 this
patch...).  It depends on the code in question (sometimes this just
isn't possible), but generally smaller is better.

Best,
Kyle Cunningham

From kb at 2bits.com  Mon Mar  2 17:29:01 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Mon, 2 Mar 2009 12:29:01 -0500
Subject: [development] Update.php re-design
In-Reply-To: <1236010570.3453.32.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<6117a7500903020722k17675255n840c9a4179d8db22@mail.gmail.com>
	<1236010570.3453.32.camel@al-sa3ek.lappy>
Message-ID: <4a9fdc630903020929u65fa7089n519d22ec58814a4e@mail.gmail.com>

If we refactor this properly to be UI independent it will open the door to
things like
using Debian's APT for updates! That would be awesome.

On Mon, Mar 2, 2009 at 11:16 AM, Nabil Alsharif <nabil at gobrighttree.com>wrote:

> Great. This is going to be my first contribution to drupal and I don't
> know what the process for submitting such changes is. Do I open an issue
> and attach patches? Or do I have to sign up for a cvs account and commit
> via cvs?
>

For core, it is always via patches and issues.


>
> Would it be better to submit (patches or commit) partial but working
> changes, or should I wait until it's all done and then submit one big
> change?
>

Depends on if you want to get feedback early or feel you have a solid
approach that is working.

I would say since this is your first attempt at core contributions, submit
partial stuff to get feedback. The process can be slow and may dishearten
the newbies at first. But if you persist, things will get done.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090302/9222f139/attachment.htm 

From domenic at workhabit.com  Mon Mar  2 17:29:54 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Mon, 2 Mar 2009 09:29:54 -0800
Subject: [development] Update.php re-design
In-Reply-To: <1236007469.3453.24.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
Message-ID: <e83e0db0903020929v4cf54871x6e964fd8fbfa8411@mail.gmail.com>

On Mon, Mar 2, 2009 at 7:24 AM, Nabil Alsharif <nabil at gobrighttree.com> wrote:
> Is there any reason that this hasn't been done before? More importantly
> does any one have any good reason to not separate preforming the updates
> from the UI?

The Drush patch in your first link http://drupal.org/node/194107 works
like a charm. If your goal is being able to invoke update.php from the
command line, take a closer looks at it. I've been using it for a
while.

-D

From nabil at gobrighttree.com  Mon Mar  2 18:13:06 2009
From: nabil at gobrighttree.com (Nabil Alsharif)
Date: Mon, 02 Mar 2009 12:13:06 -0600
Subject: [development] Update.php re-design
In-Reply-To: <e83e0db0903020929v4cf54871x6e964fd8fbfa8411@mail.gmail.com>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<e83e0db0903020929v4cf54871x6e964fd8fbfa8411@mail.gmail.com>
Message-ID: <1236017586.3453.46.camel@al-sa3ek.lappy>

I didn't know that that patch worked! When I tried it I got a bunch of
errors but that's beside the point. The issue is that it is still pretty
much a re-write of update.php and as soon as something changes in
update.php the two are out of sync.

I'm glad that it's working though because I was a little worried that a
scriptable update system wouldn't be around in time for my own personal
reasons. 

On Mon, 2009-03-02 at 09:29 -0800, Domenic Santangelo wrote:
> On Mon, Mar 2, 2009 at 7:24 AM, Nabil Alsharif <nabil at gobrighttree.com> wrote:
> > Is there any reason that this hasn't been done before? More importantly
> > does any one have any good reason to not separate preforming the updates
> > from the UI?
> 
> The Drush patch in your first link http://drupal.org/node/194107 works
> like a charm. If your goal is being able to invoke update.php from the
> command line, take a closer looks at it. I've been using it for a
> while.
> 
> -D
-------------- 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/20090302/2874f320/attachment.pgp 

From domenic at workhabit.com  Mon Mar  2 18:11:09 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Mon, 2 Mar 2009 10:11:09 -0800
Subject: [development] Update.php re-design
In-Reply-To: <1236017586.3453.46.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<e83e0db0903020929v4cf54871x6e964fd8fbfa8411@mail.gmail.com>
	<1236017586.3453.46.camel@al-sa3ek.lappy>
Message-ID: <e83e0db0903021011x5f848401ua433390bd5b588c7@mail.gmail.com>

On Mon, Mar 2, 2009 at 10:13 AM, Nabil Alsharif <nabil at gobrighttree.com> wrote:
> I didn't know that that patch worked!

Whoops, I should specify: I can only confirm firsthand that it works in D5!

-D

From nabil at gobrighttree.com  Mon Mar  2 19:10:20 2009
From: nabil at gobrighttree.com (Nabil Alsharif)
Date: Mon, 02 Mar 2009 13:10:20 -0600
Subject: [development] CLI update
In-Reply-To: <e83e0db0903021011x5f848401ua433390bd5b588c7@mail.gmail.com>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<e83e0db0903020929v4cf54871x6e964fd8fbfa8411@mail.gmail.com>
	<1236017586.3453.46.camel@al-sa3ek.lappy>
	<e83e0db0903021011x5f848401ua433390bd5b588c7@mail.gmail.com>
Message-ID: <1236021020.3453.48.camel@al-sa3ek.lappy>

I tried it on a D6 multi-site setup when it didn't work. 

On Mon, 2009-03-02 at 10:11 -0800, Domenic Santangelo wrote:
> On Mon, Mar 2, 2009 at 10:13 AM, Nabil Alsharif <nabil at gobrighttree.com> wrote:
> > I didn't know that that patch worked!
> 
> Whoops, I should specify: I can only confirm firsthand that it works in D5!
> 
> -D
-- 
?----------------------------------
Nabil Alsharif
Bright Tree
573-499-1244

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited. Please
consider the environment before printing this email or its
attachment(s).
-------------- 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/20090302/7f8a4c92/attachment-0001.pgp 

From Matt at NinjitsuWeb.com  Mon Mar  2 19:23:47 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Mon, 02 Mar 2009 14:23:47 -0500
Subject: [development] CLI update
In-Reply-To: <1236021020.3453.48.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>	<e83e0db0903020929v4cf54871x6e964fd8fbfa8411@mail.gmail.com>	<1236017586.3453.46.camel@al-sa3ek.lappy>	<e83e0db0903021011x5f848401ua433390bd5b588c7@mail.gmail.com>
	<1236021020.3453.48.camel@al-sa3ek.lappy>
Message-ID: <49AC3243.9080207@NinjitsuWeb.com>

Nabil Alsharif wrote:
> I tried it on a D6 multi-site setup when it didn't work. 
>   

Here's the script I use for CLI updates on a D6 multi-site installation

http://ninjitsuweb.com/files/drupal-update.sh.txt


I think I got it from an Acquia blog post? Can't remember how much I 
tweaked it, if at all. To update all the sites at once, I call it from 
inside another script that basically looks like this:

for f in `ls drupal-root/sites/`
do
 echo "Updating: $f"
 php -d memory_limit=96M -f drupal-update.sh -- -s $f -r drupal-root/ -m -u &
 wait
done


To do a dry-run to check if updates are needed, replace `-m -u` with `-l 
-d`.


Best,

Matt


From nabil at gobrighttree.com  Mon Mar  2 19:58:20 2009
From: nabil at gobrighttree.com (Nabil Alsharif)
Date: Mon, 02 Mar 2009 13:58:20 -0600
Subject: [development] CLI update
In-Reply-To: <49AC3243.9080207@NinjitsuWeb.com>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<e83e0db0903020929v4cf54871x6e964fd8fbfa8411@mail.gmail.com>
	<1236017586.3453.46.camel@al-sa3ek.lappy>
	<e83e0db0903021011x5f848401ua433390bd5b588c7@mail.gmail.com>
	<1236021020.3453.48.camel@al-sa3ek.lappy>
	<49AC3243.9080207@NinjitsuWeb.com>
Message-ID: <1236023900.3927.0.camel@al-sa3ek.lappy>

w00t w00t! thanks a ton. 
 
On Mon, 2009-03-02 at 14:23 -0500, Matt Chapman wrote:
> Nabil Alsharif wrote:
> > I tried it on a D6 multi-site setup when it didn't work. 
> >   
> 
> Here's the script I use for CLI updates on a D6 multi-site installation
> 
> http://ninjitsuweb.com/files/drupal-update.sh.txt
> 
> 
> I think I got it from an Acquia blog post? Can't remember how much I 
> tweaked it, if at all. To update all the sites at once, I call it from 
> inside another script that basically looks like this:
> 
> for f in `ls drupal-root/sites/`
> do
>  echo "Updating: $f"
>  php -d memory_limit=96M -f drupal-update.sh -- -s $f -r drupal-root/ -m -u &
>  wait
> done
> 
> 
> To do a dry-run to check if updates are needed, replace `-m -u` with `-l 
> -d`.
> 
> 
> Best,
> 
> Matt

-------------- 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/20090302/90fd7401/attachment.pgp 

From gordon at heydon.com.au  Mon Mar  2 23:13:09 2009
From: gordon at heydon.com.au (Gordon Heydon)
Date: Tue, 3 Mar 2009 10:13:09 +1100
Subject: [development] Update.php re-design
In-Reply-To: <1236007469.3453.24.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
Message-ID: <1844B481-8E33-4A5F-B56F-D76C29BD0BAE@heydon.com.au>

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

Hi,

Actually you have also missed the effort that I have been working on  
to create an update.sh which is included directly into core. see http://drupal.org/node/233091 
  which has a working version of update.php but runs from the shell.

I have also have some more changes pending that Dries has suggested.  
but before I can do these I have 2 other patches which are really  
needed for the update.sh to work before I can really push forward.

http://drupal.org/node/375494 which is a patch to change node_load()  
to restrict the size of the static cache and http://drupal.org/node/383196 
  which is tests for update.php so that when I break update.php to  
create a better merged update process to share as much code between  
update.php and update.sh.

On 03/03/2009, at 2:24 AM, Nabil Alsharif wrote:

> There seems to be a couple of projects that are trying to make
> update.php command line friendly, non of which seem to be going that
> well:
> http://drupal.org/node/194107
> http://acquia.com/blog/drupal-cli-utils
>
> The issue that I see is that update.php is tightly coupled with the  
> UI.
> What I would like to do is pull the functions that preform the updates

It is not a coupled as you think. other than the fixes, most of the  
update.php/update.sh is all done in the batchapi. before the batch api  
it was not as clean as it is now.

> out of update.php so that it would be possible to have a different UIs
> to modules (Web interface, cli). There are two main reasons I would  
> like
> to do this:
> 1. It would make the projects mentioned above much easier to  
> implement.
> 2. The projects mentioned above have there own implementation of
> update.php that is independent of that way drupal updates the modules.

I do have to question about how many ways do you need to do updates.  
This is why I have been pushing a shell version as this can be  
interfaced into anything that can run updates.
>
> I hope to endup with something along the lines of update.inc that  
> holds
> the function for preforming the updates (i.e get_updates, do_update,
> db_add_column.. etc) and update.php that has the current UI for
> updates.
>
> Is there any reason that this hasn't been done before? More  
> importantly
> does any one have any good reason to not separate preforming the  
> updates
> from the UI?

I am actually looking at moving most of the update.php stuff to  
update.inc, but other than the fixes which as used to allow the newer  
version to load on the previous versions database, there is not really  
that much that can needs to be  pulled out.

If you want to talk more, just grab me in IRC, or update the update.sh  
issue.

Gordon.

>
> -- 
> ?----------------------------------
> Nabil Alsharif
> Bright Tree
> 573-499-1244
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete
> the original. Any other use of the email by you is prohibited. Please
> consider the environment before printing this email or its
> attachment(s).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkmsaAUACgkQngavurZvkrzS1wCgpHK1JlpgRiYzCffo1K7FaLXA
tPwAoIlcyWzctBia1UpN/x1Txa0BcUYE
=Zq1e
-----END PGP SIGNATURE-----

From sysop at scbbs.com  Tue Mar  3 08:36:13 2009
From: sysop at scbbs.com (Ron Parker)
Date: Tue, 3 Mar 2009 00:36:13 -0800 (PST)
Subject: [development] confirm_form from submit hook
Message-ID: <17596549.3811236069373365.JavaMail.root@zimbra.thefiengroup.com>

I submitted this issue here: http://drupal.org/node/387674, but I really need a response. I think this may be a bug, but I can't be sure right now. Need some advice. 



I have created a form. I want to submit the form values, validate them, then confirm that the user wishes to proceed. I place a drupal_execute('confirmation_form', $form_values) in my submit hook, and in the 'confirmation_form' I execute "confirm_form". But, it doesn't work. I don't get a confirmation form: the code execution cycles through to conformation_form_submit. 




form() 
Input values 




form_validate() 
validate values 




form_submit() 
Now, I want to confirm that the user wants to continue. If I call a form from within this submit hook that executes a confirm_form, the confirm_form() function doesn't work 




form_confirm() 
Execute confirm_form() doesn't work. 




Code example: 



<?php 
function og_user_roles_register_submit ( $form , & $form_state ) { 
global $user ; 

if ( $user -> uid ) { 
$regcode = $form_state [ 'values' ][ 'og_user_roles_regcode' ]; 
$gid = og_user_roles_gid_from_regcode ( $regcode ); 
if ( $gid > 0 ) { 
$node = node_load ( $gid ); 
drupal_execute ( 'og_user_roles_register_confirm' , $form_state , $node , $regcode ); 
} 
} else { 
drupal_access_denied (); 
} 
} 

/** 
* Form builder; Builds the confirmation form for adding user to group using regcode. 
* 
* @ingroup forms 
* @see og_user_roles_register_confirm_submit() 
*/ 
function og_user_roles_register_confirm (& $form_state , $node , $regcode ) { 
$form = array(); 
$form [ '#node' ] = $node ; 
$form [ '#regcode' ] = $regcode ; 
return confirm_form ( $form , t ( 'Are you sure you want to join this group %title?' , array( '%title' => $node -> title )), 'node/' . $node -> nid , t ( 'This action can only be undone by unsubscribing from the group once joined.' ), t ( 'Delete' ), t ( 'Cancel' ), 'og_user_roles_register_confirm' ); 
} 
// Confirmation form does NOT display. Code continues to successfully execute 
// og_user_roles_register_confirm_submit() 
// 
// It's like if a form is called from a successful submit, then it's subsequent submit hook is 
// automatically successful as well. 
?> 



In all the working examples of confirm_form() I've seen in Drupal 6.x, I do not see an example where it is called from a form submit hook. Usually, it is called in some delete function where the key value is passed along in the url. 





I want to enter values, validate those values, then confirm that the user wishes to proceed. How do I do that using confirm_form() (if that's even possible)? 
Thanks for any assistance. 

-ron 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090303/952be0d5/attachment.htm 

From merlin at logrus.com  Tue Mar  3 14:27:06 2009
From: merlin at logrus.com (Earl Miles)
Date: Tue, 03 Mar 2009 06:27:06 -0800
Subject: [development] confirm_form from submit hook
In-Reply-To: <17596549.3811236069373365.JavaMail.root@zimbra.thefiengroup.com>
References: <17596549.3811236069373365.JavaMail.root@zimbra.thefiengroup.com>
Message-ID: <49AD3E3A.1090101@logrus.com>

Ron Parker wrote:
> I submitted this issue here: http://drupal.org/node/387674, but I 
> really need a response.  I think this may be a bug, but I can't be 
> sure right now.  Need some advice.
>
> I have created a form. I want to submit the form values, validate 
> them, then confirm that the user wishes to proceed. I place a 
> drupal_execute('confirmation_form', $form_values) in my submit hook, 
> and in the 'confirmation_form' I execute "confirm_form". But, it 
> doesn't work. I don't get a confirmation form: the code execution 
> cycles through to conformation_form_submit.
>
>
> *form()*
> Input values
>
> *
> *
>
> *form_validate()*
> validate values
>
> *
> *
>
> *form_submit()*
> Now, I want to confirm that the user wants to continue. If I call a 
> form from within this submit hook that executes a confirm_form, the 
> confirm_form() function doesn't work
>
> *
> *
>
> *form_confirm()*
> Execute confirm_form() doesn't work.
>
>
> Code example:
>
>
Yes, drupal_execute() submits a form. it does not render the form. The 
idea there is that it happens completely independently.

To do what you want to do, you are going to need to cache the values 
from your first form somewhere (possibly via values on the confirm form) 
and do your work in the confirm form submit.

In addition, you have the problem that there is no communication between 
FAPI and whatever called drupal_get_form; your submit cannot actually 
render a form (it returns a value to redirect to, not output) so the 
only way you can do this without hacking fapi like I did is to set a 
global variable.

You could also install CTools and use the form wizard tool which this is 
a nice example of, and in fact might make a lovely example of how to do 
a more complex confirm form than the ones that currently exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090303/2d7be1b4/attachment-0001.htm 

From nabil at gobrighttree.com  Tue Mar  3 15:59:25 2009
From: nabil at gobrighttree.com (Nabil Alsharif)
Date: Tue, 03 Mar 2009 09:59:25 -0600
Subject: [development] Update.php re-design
In-Reply-To: <1844B481-8E33-4A5F-B56F-D76C29BD0BAE@heydon.com.au>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<1844B481-8E33-4A5F-B56F-D76C29BD0BAE@heydon.com.au>
Message-ID: <1236095965.28989.29.camel@al-sa3ek.lappy>

On Tue, 2009-03-03 at 10:13 +1100, Gordon Heydon wrote:
> Hi,
> 
> Actually you have also missed the effort that I have been working on  
> to create an update.sh which is included directly into core. see http://drupal.org/node/233091 
>   which has a working version of update.php but runs from the shell.

I saw that issue. I even replied to it. A working version of update.php
that can be run in a script is the reason I started this whole thing.

> On 03/03/2009, at 2:24 AM, Nabil Alsharif wrote:
> 
> > There seems to be a couple of projects that are trying to make
> > update.php command line friendly, non of which seem to be going that
> > well:
> > http://drupal.org/node/194107
> > http://acquia.com/blog/drupal-cli-utils
> >
> > The issue that I see is that update.php is tightly coupled with the  
> > UI.
> > What I would like to do is pull the functions that preform the updates
> 
> It is not a coupled as you think. other than the fixes, most of the  
> update.php/update.sh is all done in the batchapi. before the batch api  
> it was not as clean as it is now.

That is true, but people still have to manage the fixes, which means
they (you?) have to update the script every time update.php adds a new
fix. 

> I do have to question about how many ways do you need to do updates.  
> This is why I have been pushing a shell version as this can be  
> interfaced into anything that can run updates.

It's not about how many ways I want to do updates it about the fact that
you might want to do updates a different way then I do.

For example I am going to have to maintain a large number of drupal
sites. I have an upgrade process for these sites in place that includes
some non-standard (in a drupal context) processes. It would be awesome
if I could manage drupals database updates from there too, and the
easies way I see to do that is via a sane update API.
-------------- 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/20090303/0235a13b/attachment.pgp 

From sysop at scbbs.com  Tue Mar  3 19:55:01 2009
From: sysop at scbbs.com (Ron Parker)
Date: Tue, 3 Mar 2009 11:55:01 -0800 (PST)
Subject: [development] confirm_form from submit hook
Message-ID: <17991040.4121236110101842.JavaMail.root@zimbra.thefiengroup.com>

Thank you. This helped. What I did was to create my confirm_form function as a menu callback: 

<?php 
$items['og/regcode/confirm/%'] = array( 
'title' => 'Confirm registration code', 
'page callback' => 'drupal_get_form', 
'page arguments' => array('og_user_roles_register_confirm'), 
'access callback' => 'user_access', 
'access arguments' => array('use registration codes'), 
'weight' => 10, 
'type' => MENU_LOCAL_TASK, 
); 
?> 

So, in my submit hook, I do a "drupal_goto" (as opposed to drupal_execute or drupal_get_form) and put the key variable in the argument as part of the url. This works. But, seems to me that it would be much easier to be able to call another form and pass form variables from a submit hook (as I was attempting to do). 

-ron 

Earl Miles wrote: 


Yes, drupal_execute() submits a form. it does not render the form. The 
idea there is that it happens completely independently. 

To do what you want to do, you are going to need to cache the values 
from your first form somewhere (possibly via values on the confirm form) 
and do your work in the confirm form submit. 

In addition, you have the problem that there is no communication between 
FAPI and whatever called drupal_get_form; your submit cannot actually 
render a form (it returns a value to redirect to, not output) so the 
only way you can do this without hacking fapi like I did is to set a 
global variable. 

You could also install CTools and use the form wizard tool which this is 
a nice example of, and in fact might make a lovely example of how to do 
a more complex confirm form than the ones that currently exist. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090303/8f19aa88/attachment.htm 

From gordon at heydon.com.au  Tue Mar  3 23:47:16 2009
From: gordon at heydon.com.au (Gordon Heydon)
Date: Wed, 4 Mar 2009 10:47:16 +1100
Subject: [development] Update.php re-design
In-Reply-To: <1236095965.28989.29.camel@al-sa3ek.lappy>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<1844B481-8E33-4A5F-B56F-D76C29BD0BAE@heydon.com.au>
	<1236095965.28989.29.camel@al-sa3ek.lappy>
Message-ID: <6C327031-A4A1-4281-96A6-C020563EA1F1@heydon.com.au>

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

Hi,

On 04/03/2009, at 2:59 AM, Nabil Alsharif wrote:

> On Tue, 2009-03-03 at 10:13 +1100, Gordon Heydon wrote:
>> Hi,
>>
>> Actually you have also missed the effort that I have been working on
>> to create an update.sh which is included directly into core. see http://drupal.org/node/233091
>>  which has a working version of update.php but runs from the shell.
>
> I saw that issue. I even replied to it. A working version of  
> update.php
> that can be run in a script is the reason I started this whole thing.

And since I created that issue I have had working code for Drupal 5  
and above.
>
>> On 03/03/2009, at 2:24 AM, Nabil Alsharif wrote:
>>
>>> There seems to be a couple of projects that are trying to make
>>> update.php command line friendly, non of which seem to be going that
>>> well:
>>> http://drupal.org/node/194107
>>> http://acquia.com/blog/drupal-cli-utils
>>>
>>> The issue that I see is that update.php is tightly coupled with the
>>> UI.
>>> What I would like to do is pull the functions that preform the  
>>> updates
>>
>> It is not a coupled as you think. other than the fixes, most of the
>> update.php/update.sh is all done in the batchapi. before the batch  
>> api
>> it was not as clean as it is now.
>
> That is true, but people still have to manage the fixes, which means
> they (you?) have to update the script every time update.php adds a new
> fix.

The only time the update.php script is changed in during the major  
Drupal updates. ie from Drupal 5 to drupal 6. All the other changes  
are in the install files.
>
>> I do have to question about how many ways do you need to do updates.
>> This is why I have been pushing a shell version as this can be
>> interfaced into anything that can run updates.
>
> It's not about how many ways I want to do updates it about the fact  
> that
> you might want to do updates a different way then I do.
>
> For example I am going to have to maintain a large number of drupal
> sites. I have an upgrade process for these sites in place that  
> includes
> some non-standard (in a drupal context) processes. It would be awesome
> if I could manage drupals database updates from there too, and the
> easies way I see to do that is via a sane update API.

All the these systems that I have seen have the ability to execute  
shell scripts. So when doing the update the management process just  
needs to execute the shell script to do the update.

I management all my clients with git, and basically I just have a post- 
update script will does the following.

./scripts/update.sh -l
if [ $? -ne 0 ]; then
   ./scripts/update.sh -u
fi

With Debian packages you can do the same thing from the post  
installation script and the update will run.

Drupal already have an update api, which is a part of the install  
files attached to every module. My goal with the issue I raised is to  
create a minimize the common code between the 2 and allow the updates  
to be done from either method.

Gordon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkmtwYQACgkQngavurZvkrz2WwCfVfJTvPSY6JcAWLE8gnIfjUqZ
NVkAn1ovcpmsRxDeGxu7GicDNLyAWixH
=E6cG
-----END PGP SIGNATURE-----

From mike at mikeyp.net  Wed Mar  4 00:21:45 2009
From: mike at mikeyp.net (Michael Prasuhn)
Date: Tue, 3 Mar 2009 16:21:45 -0800
Subject: [development] confirm_form from submit hook
In-Reply-To: <17991040.4121236110101842.JavaMail.root@zimbra.thefiengroup.com>
References: <17991040.4121236110101842.JavaMail.root@zimbra.thefiengroup.com>
Message-ID: <F097612E-E68C-471E-921C-312DB818B9B2@mikeyp.net>

On Mar 3, 2009, at 11:55 AM, Ron Parker wrote:
> Thank you. This helped.  What I did was to create my confirm_form  
> function as a menu callback:

> So, in my submit hook, I do a "drupal_goto" (as opposed to  
> drupal_execute or drupal_get_form) and put the key variable in the  
> argument as part of the url.  This works.  But, seems to me that it  
> would be much easier to be able to call another form and pass form  
> variables from a submit hook (as I was attempting to do).


It's also quite possible that you could open a cross site request  
forgery that way. What you are really asking about is multi-step form.  
'Confir'm is not a hook that is automatically recognized in FAPI in  
the way the _submit and _validate are. There is an example of what you  
are trying to do in core, in the node module for the page at admin/ 
content/node, and the batch operations for that page, which provides a  
confirm form without redirecting the user at all.

To see a better example (node is a little long and slightly confusing)  
you could look at this module file in CVS: http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/mikeyp/system_table_cleaner/system_table_cleaner.module?revision=1.3&view=markup

This is a short module I wrote that implements functionality similar  
to what you seem to want. Most importantly, look at the  
system_table_cleaner() function and it's switching and return of a  
different form. This was modeled after the core method used in node  
module.

-Mike

__________________
Michael Prasuhn
503.488.5433 office
714.356.0168 cell
503.661.7574 home
mike at mikeyp.net
http://mikeyp.net






From nabil at gobrighttree.com  Wed Mar  4 15:35:24 2009
From: nabil at gobrighttree.com (Nabil Alsharif)
Date: Wed, 04 Mar 2009 09:35:24 -0600
Subject: [development] Update.php re-design
In-Reply-To: <6C327031-A4A1-4281-96A6-C020563EA1F1@heydon.com.au>
References: <1236007469.3453.24.camel@al-sa3ek.lappy>
	<1844B481-8E33-4A5F-B56F-D76C29BD0BAE@heydon.com.au>
	<1236095965.28989.29.camel@al-sa3ek.lappy>
	<6C327031-A4A1-4281-96A6-C020563EA1F1@heydon.com.au>
Message-ID: <1236180924.3479.20.camel@al-sa3ek.lappy>

On Wed, 2009-03-04 at 10:47 +1100, Gordon Heydon wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> And since I created that issue I have had working code for Drupal 5  
> and above.
umm... ok? It's cool that you got working for all three. Soon enough
there are going to be 4.

> The only time the update.php script is changed in during the major  
> Drupal updates. ie from Drupal 5 to drupal 6. All the other changes  
> are in the install files.
Just because a problem happens only once in a while doesn't mean that it
isn't a problem
 
> Drupal already have an update api, which is a part of the install  
> files attached to every module. My goal with the issue I raised is to  
> create a minimize the common code between the 2 and allow the updates  
> to be done from either method.
> 
Yes I agree with you that the goal and I hope that we can maybe work
together on this. The current problems that I see are three:
1. Major upgrades, i.e from drupal 5 to 6 to 7 (to 8?).
2. Even though your script works, a lot of energy is required to
re-create or change it. 
3. Duplicate code between the two update scripts (web and cli) but an
update.inc could resolve this.
> Gordon.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> 
> iEYEARECAAYFAkmtwYQACgkQngavurZvkrz2WwCfVfJTvPSY6JcAWLE8gnIfjUqZ
> NVkAn1ovcpmsRxDeGxu7GicDNLyAWixH
> =E6cG
> -----END PGP SIGNATURE-----
-------------- 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/20090304/2aa4eb05/attachment.pgp 

From winborn at advomatic.com  Wed Mar  4 16:29:17 2009
From: winborn at advomatic.com (Aaron Winborn)
Date: Wed, 4 Mar 2009 11:29:17 -0500 (EST)
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <28217689.265551236183914132.JavaMail.root@zimbra>
Message-ID: <1491315.265571236184157568.JavaMail.root@zimbra>

I'm concerned about the sentiment in Dries' declaration of Drupal 7 will be released when it's ready. I know this has been hashed out before, for instance back in September with Disparity of Versions: Towards Creating a Sustainable Solution to the Disparity between Drupal Core and Contributed Modules (http://drupal.org/node/311893) (which was itself an eloquent continuation of a long-standing discussion).

I still strongly believe that we're shooting ourselves in the foot when we continue to use "0 critical patches" as the sole metric of a core release. Core MUST BE informed by contrib. To do otherwise is to create a divide of development that means six to nine months of the vast majority of sites waiting on critical module updates.

In the referenced thread, chx asked, "Creating a "golden" contrib has been discussed for very long. It's not clear what we would achieve and who would work on achieving that." Acquia has answered that quite well.

Acquia has stepped up to fill in this need with their official "Acquia Drupal", with its list of 21 supported contributed modules. I applaud their efforts. To quote them, they address this need: "From the thousands of Drupal modules, Acquia has selected some of the most commonly used and essential community modules for building modern, social publishing websites without programming."

Chx continued with "Also, the whole issue is IMO Drupal 6 specific. As Drupal 5 is such a fantastic release, people felt it's good enough to serve longer and redesigned the architecture of their modules. This is not something that will be repeated soon IMO. As the Drupal 7 cycle is made longer, the issue will smoothen itself out during the next half year."

I believe that lengthening the core development cycle is an answer, but still not THE answer. The unstable releases have certainly been a boon, and it's exciting to see a few modules beginning to create unstable releases; this is core informing contrib, and webchick has really stepped up to the plate to make that happen.

However, no matter the fanfare with which Drupal 7 will be released, few sites in the wild will upgrade until their required contrib modules have been upgraded to that version. Yes, Drupal 6 was exceptional in the time required before major adoption. In a nod to contrib, fields and views are going into core, which is a direct way of contrib informing core. But there will always be a new Views or CCK that takes off like wildfire, and there will often be times when adoption of a new release of core will be held up by waiting development on a new and complex contributed module. Maybe not Drupal 7, but if we don't address this concern in a systematic and thoughtful way, it will possibly happen by Drupal 8, and certainly by Drupal 9 or X.

Another show-stopping factor in creating a new metric is agreement on what metric to adopt. The team that penned Disparity of Versions were intentionally agnostic to metric in their discussions. However, no matter how these golden modules would be selected, and regardless of how that could be gamed, the reality is there will always be important contributed modules that the community depends upon.

We can look to Acquia and other companies to identify these modules for us. That's a good thing, and irrelevant to the discussion. In fact, if the community would step up and take responsibility for these issues, it would validate their efforts.

I propose that we take the tool that was not yet available at the time of the original post. We now have a publicly available metric of modules at use in the wild. Let's just take the top 10, top 5, or even top 3 modules and call those our "golden modules". Create a new "Supported modules" that dynamically consist of these modules; that can be tweaked once we have some experience with it.

Then don't release Drupal 7 until there are 0 critical issues in its queue, AND each of the Supported modules has an official release. The community already works with the modules they need to help with that effort; this gives them more incentive and validation. If a Supported module is not making sufficient progress in an acceptable amount of time, that's likely a sign that perhaps it should be removed from that tier and back into the wild of contrib, so that things are not held up unnecessarily.

I strongly believe that these simple steps will make the release of Drupal 7, and each subsequent release, the best release ever.

Thanks,
Aaron Winborn
 

From Greg at GrowingVentureSolutions.com  Wed Mar  4 17:28:22 2009
From: Greg at GrowingVentureSolutions.com (Greg Knaddison)
Date: Wed, 4 Mar 2009 12:28:22 -0500
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <1491315.265571236184157568.JavaMail.root@zimbra>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<1491315.265571236184157568.JavaMail.root@zimbra>
Message-ID: <3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>

On Wed, Mar 4, 2009 at 11:29 AM, Aaron Winborn <winborn at advomatic.com> wrote:
<great stuff>

My sense (hope?) is that Drupal7 will only be released when "0
critical bugs AND drupal.org is upgraded."  I think this should solve
most of the problem you cite because drupal.org now and increasingly
relies on many of the major modules.

It may lead to some uncomfortable feelings (if we are 4 months after
code freeze and no d.o upgrade in site, for example) but those
uncomfortable feelings will fuel desire to work on the modules needed
for d.o.  That will also give time for developers of other modules.

Regards,
Greg

-- 
Greg Knaddison
http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com

From starbow at citris-uc.org  Wed Mar  4 18:12:30 2009
From: starbow at citris-uc.org (Tao Starbow)
Date: Wed, 04 Mar 2009 10:12:30 -0800
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<1491315.265571236184157568.JavaMail.root@zimbra>
	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>
Message-ID: <49AEC48E.50509@citris-uc.org>

How about, no release until "0 critical bugs, drupal.org is upgraded, 
and 5 of the top 10 modules on http://drupal.org/project/usage are 
upgraded"?

Of course, what you really want is for that metric to be met earlier in 
the cycle, so that some of the experience gained by upgrading drupal.org 
and the module can actually inform core.

cheers,
-tao

Greg Knaddison wrote:
> On Wed, Mar 4, 2009 at 11:29 AM, Aaron Winborn <winborn at advomatic.com> wrote:
> <great stuff>
>
> My sense (hope?) is that Drupal7 will only be released when "0
> critical bugs AND drupal.org is upgraded."  I think this should solve
> most of the problem you cite because drupal.org now and increasingly
> relies on many of the major modules.
>
> It may lead to some uncomfortable feelings (if we are 4 months after
> code freeze and no d.o upgrade in site, for example) but those
> uncomfortable feelings will fuel desire to work on the modules needed
> for d.o.  That will also give time for developers of other modules.
>
> Regards,
> Greg
>
>   

From Matt at NinjitsuWeb.com  Wed Mar  4 19:31:40 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Wed, 04 Mar 2009 14:31:40 -0500
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <49AEC48E.50509@citris-uc.org>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<1491315.265571236184157568.JavaMail.root@zimbra>	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>
	<49AEC48E.50509@citris-uc.org>
Message-ID: <49AED71C.9060704@NinjitsuWeb.com>

I agree entirely that the expanding gap between core & contrib is a 
major problem, and one that seems to be underestimated by some core 
developers.

However, I'm slightly concerned that establishing a set of golden 
modules in this way will stifle the evolution by natural selection that 
has served Drupal so well. To make the point, imagine if it had been 
decided that Drupal 5 was not ready for release until Flexinode was 
updated....

It's not so important to users that module X be available, but that 
feature Y be provided by some module; preferably with an upgrade path 
from module X, but that is secondary from a development perspective.

Rather than golden modules, what we need are golden 'use cases.' Perhaps 
this takes the form of supported Profiles or Patterns. (I'll use the 
term 'profile' to mean any means of collecting modules and 
configurations for implementing a specific end-user functionality. I 
think installation profiles as currently supported by Drupal are 
severely lacking, having abandoned one in favor of database dumps for 
the time being.)

It has been my experience that the lack of a D6 version for needed 
modules caused me to look for and find other, better solutions. Or it 
forced me to more closely analyze the strengths and weaknesses of the 
various solutions, to determine which is most worth my effort to upgrade 
myself.

Also, I strongly suspect that it is often the case that the modules with 
a better underlying architecture are easiest to upgrade. A lag in 
upgrading a particular module may be a sign that it could be replaced by 
a  better solution.

Finally, supporting profiles instead of modules makes the system less 
susceptible to single points of failure. It takes less technical 
expertise to maintain a profile than it does to maintain a module. If I 
maintain the Community Events Management profile, and there's no e-mail 
reminder functionality available for Drupal 7, I can petition 3 or 4 
different module developers to upgrade their module, or I can try to 
organize some developers to create a new, better one, to leverage the 
new DX features of Drupal 7.

You may say, 'What about modules that are so generic that they are used 
in most any site?' I'd suggest that those are exactly the sorts of 
modules that should be included in Core. We're seeing this happen with 
CCK, and Views seems poised to follow shortly. We could even make the 
criteria for core eligibility more explicit: If a module is used in 
EVERY supported profile, then it should be moved to core in some form. 
(And the converse: if a module is not used by any supported profile, it 
should probably be removed from core.)

One thing that would really help this is more street cred for profile 
maintainers. However about some front-page case studies for a couple 
profiles?

Hey, Acquia, could you throw some money at a few profile maintainers to 
get them to really polish their profiles, or convert them into patterns 
& add the patterns module into your distro?

All the Best,

Matt
http://www.NinjitsuWeb.com



From michael at favias.org  Wed Mar  4 21:40:01 2009
From: michael at favias.org (Michael Favia)
Date: Wed, 04 Mar 2009 15:40:01 -0600
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <49AED71C.9060704@NinjitsuWeb.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<1491315.265571236184157568.JavaMail.root@zimbra>	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>	<49AEC48E.50509@citris-uc.org>
	<49AED71C.9060704@NinjitsuWeb.com>
Message-ID: <49AEF531.5000703@favias.org>

Matt Chapman wrote:
> I agree entirely that the expanding gap between core & contrib is a 
> major problem, and one that seems to be underestimated by some core 
> developers.
>
> However, I'm slightly concerned that establishing a set of golden 
> modules in this way will stifle the evolution by natural selection 
> that has served Drupal so well. To make the point, imagine if it had 
> been decided that Drupal 5 was not ready for release until Flexinode 
> was updated....
Thank you for echoing my concerns exactly. This is a key tenet of the 
success of opensource. Unfortunately, i think that any attempt to define 
specific modules or even specific use cases (profiles) will fail in a 
similar fashion because the same argument applies to the use cases as 
each new version changes the capabilities of our platform and makes it 
more apt to various tasks and less apt to others.

I agree that the lag of module upgrade between 5 and 6 was undesirable 
but i don't think that it can be prevented with the increasing number of 
dependencies that are developing around important modules these days. 
Any attempt to do so would unwisely slow the pace of development in core 
and put us at a competitive disadvantage against other CMSs.

Identifying the successful modules with many dependencies and 
incorporating them into core in an efficient matter seems to be key in 
preventing another lag similar to the last. With cck on its way in and 
views shortly behind i think that the worts may be behind us. Paradigm 
shifts arent easy. :)
--
Michael Favia

From Matt at NinjitsuWeb.com  Wed Mar  4 22:06:21 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Wed, 04 Mar 2009 17:06:21 -0500
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <49AEF531.5000703@favias.org>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<1491315.265571236184157568.JavaMail.root@zimbra>	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>	<49AEC48E.50509@citris-uc.org>	<49AED71C.9060704@NinjitsuWeb.com>
	<49AEF531.5000703@favias.org>
Message-ID: <49AEFB5D.4070108@NinjitsuWeb.com>

Michael Favia wrote:
> Thank you for echoing my concerns exactly. This is a key tenet of the 
> success of opensource. Unfortunately, i think that any attempt to 
> define specific modules or even specific use cases (profiles) will 
> fail in a similar fashion because the same argument applies to the use 
> cases as each new version changes the capabilities of our platform and 
> makes it more apt to various tasks and less apt to others.
Not if the selected profiles are based on popularity, and fluctuate 
accordingly. I.e., when the first alpha of a new Core appears, we check 
and see what the most used profiles are, and then the maintainers of 
those profiles are called upon to see to it that the functionality 
provided by their profiles is available at release time, or to bring on 
co-maintainers who can do so.

This way, Drupal's version changes are kept in line with they ways in 
which Drupal is actually being used. If a change prevents a major use 
case, I'd say we've got a serious problem. If a change breaks a major 
module, that's worth consideration, but in the end, it's just the nature 
of the moving drop.

Matt
NinjitsuWeb.com



From rubinstein.james at gmail.com  Wed Mar  4 22:08:38 2009
From: rubinstein.james at gmail.com (james rubinstein)
Date: Wed, 4 Mar 2009 17:08:38 -0500
Subject: [development] Need help to build module to create content and user
	at the same time
Message-ID: <8144532c0903041408h49ae848fqff3ffef20f708533@mail.gmail.com>

Hello all,
I'm a bit new to this whole development thing, so please forgive me if
I screw this up :)

What I'd like to do is create a module that would allow the creation
of content and a user at the same time.
Basically, the reason for this module is for an operator to take a
classified ad listing over the phone.
The operator would then enter the User's email address.
The System would look up the email and if the email exists, then the
authorship would be assigned to the User with that email address.
If there is not already a user with that email address, the User will
be created, and  the login instructions will be emailed to him.

I hope that is clear. I created a support request that has a bit more
detail here:

http://drupal.org/node/391188

I was really hoping that something like this already existed, but I
have not found anything that does this yet.
If there is something already available, please let me know.

Otherwise, would anyone be interested in partnering with me to form
this module.

I have 0 Drupal module coding experience; I am a usability guy by
training. So if I can contribute in that way....

Thank you very much.
Please let me know if you are interested in helping.

James

From cxjohnson at gmail.com  Wed Mar  4 22:10:46 2009
From: cxjohnson at gmail.com (Chris Johnson)
Date: Wed, 4 Mar 2009 17:10:46 -0500
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <49AEF531.5000703@favias.org>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<1491315.265571236184157568.JavaMail.root@zimbra>
	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>
	<49AEC48E.50509@citris-uc.org> <49AED71C.9060704@NinjitsuWeb.com>
	<49AEF531.5000703@favias.org>
Message-ID: <9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>

Rather than venture any opinion at this point on what to do about
selecting the date when Drupal 7 is "ready" I want to inject this, I
think, factual[1] data point:

The time it will take to update modules from Drupal 6 to Drupal 7 will
be on average _longer_ than it took to update modules from Drupal 5 to
Drupal 6.

Because of some major rewrites of important modules like Views for
Drupal 6, those modules may well updated sooner.  But the API changes
are vast in Drupal 7.  Be aware and forewarned so as to consider the
release date question with the proper perspective.

--
..chris

[1] No, I do not have hard metrics to prove this assertion.  I do feel
very confident in my statement, having been involved in a project
which updated or helped update roughly a hundred modules to D6.  If
there is any disagreement on the point, I hope we can discuss it in
another thread so as to not sidetrack this one.

From paolomainardi at gmail.com  Wed Mar  4 22:21:08 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Wed, 4 Mar 2009 23:21:08 +0100
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<1491315.265571236184157568.JavaMail.root@zimbra>
	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>
	<49AEC48E.50509@citris-uc.org> <49AED71C.9060704@NinjitsuWeb.com>
	<49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
Message-ID: <c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>

On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson at gmail.com> wrote:

>  But the API changes
> are vast in Drupal 7.  Be aware and forewarned so as to consider the
> release date question with the proper perspective.
>

I agree, but we must think to a soft of "compatibility API", i think that is
impossible to rewrite the world to every new Drupal release.

We need a public stable API + Compatibility layer + new API Method,
otherwise we've to reinvent the wheel every time.

It's impossible a solution like this ?

Cheers

-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090304/463da28b/attachment-0001.htm 

From gerhard at killesreiter.de  Wed Mar  4 22:47:26 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Wed, 04 Mar 2009 23:47:26 +0100
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<1491315.265571236184157568.JavaMail.root@zimbra>	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>	<49AEC48E.50509@citris-uc.org>
	<49AED71C.9060704@NinjitsuWeb.com>	<49AEF531.5000703@favias.org>	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
Message-ID: <49AF04FE.5000609@killesreiter.de>

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

Paolo Mainardi schrieb:
> On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson at gmail.com> wrote:
> 
>>  But the API changes
>> are vast in Drupal 7.  Be aware and forewarned so as to consider the
>> release date question with the proper perspective.
>>
> 
> I agree, but we must think to a soft of "compatibility API", i think that is
> impossible to rewrite the world to every new Drupal release.

I take it you are new to Drupal development?

We get this suggestion every time a similar discussion comes up.
Luckily, every time the anser is: No.

> We need a public stable API + Compatibility layer + new API Method,
> otherwise we've to reinvent the wheel every time.
> 
> It's impossible a solution like this ?

Pretty much, yes. A full compatibility layer would like affect
performance big time and a less intrusive version is probably not worth
anybody's time to write.

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

iEYEARECAAYFAkmvBP0ACgkQfg6TFvELooTFDQCdG6sFnWtZOCzivVjTn/2sGyDc
Ew4AmgMiq3vwA68uOitvlEyoP8v7KpNX
=WUlK
-----END PGP SIGNATURE-----

From weitzman at tejasa.com  Wed Mar  4 22:50:52 2009
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Wed, 4 Mar 2009 17:50:52 -0500
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <1491315.265571236184157568.JavaMail.root@zimbra>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<1491315.265571236184157568.JavaMail.root@zimbra>
Message-ID: <6117a7500903041450n2d3f08cbjd1647f3c6b5ff526@mail.gmail.com>

On Wed, Mar 4, 2009 at 11:29 AM, Aaron Winborn <winborn at advomatic.com> wrote:
> I'm concerned about the sentiment in Dries' declaration of Drupal 7 will be released when it's ready. I know this has been hashed out before, for instance back in September with Disparity of Versions: Towards Creating a Sustainable Solution to the Disparity between Drupal Core and Contributed Modules (http://drupal.org/node/311893) (which was itself an eloquent continuation of a long-standing discussion).

Dries did not say anything about D7 that should cause concern. He just
said "when it is ready" and we can all discuss what that means. You
are assuming it excludes Contrib. But even more productive IMO would
be to discuss what we can do to help modules upgrade quickly. Lets not
even get into the reasons why D6 Contrib adoption was slow. What
documentation is needed beyond the upgrade page (screencasts,
coder/deadwood, .webinars, ...). Can we provide testing infrastructure
for contrib modules? Could we focus the issue queue so issues about
upgrading are more easily handled?

From paolomainardi at gmail.com  Wed Mar  4 23:03:41 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Thu, 5 Mar 2009 00:03:41 +0100
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <49AF04FE.5000609@killesreiter.de>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<1491315.265571236184157568.JavaMail.root@zimbra>
	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>
	<49AEC48E.50509@citris-uc.org> <49AED71C.9060704@NinjitsuWeb.com>
	<49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
Message-ID: <c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>

On Wed, Mar 4, 2009 at 11:47 PM, Gerhard Killesreiter <
gerhard at killesreiter.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Paolo Mainardi schrieb:
> > On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson at gmail.com>
> wrote:
> >
> >>  But the API changes
> >> are vast in Drupal 7.  Be aware and forewarned so as to consider the
> >> release date question with the proper perspective.
> >>
> >
> > I agree, but we must think to a soft of "compatibility API", i think that
> is
> > impossible to rewrite the world to every new Drupal release.
>
> I take it you are new to Drupal development?
>

Yes, i don't have contribute never to Drupal core, but i work on drupal
development from a lot of time, and i've released some contribution, but
this is not the point.


> We get this suggestion every time a similar discussion comes up.
> Luckily, every time the anser is: No.


Sorry but i don't understand, why "luckily" the answer every time is no ?


Pretty much, yes. A full compatibility layer would like affect
> performance big time and a less intrusive version is probably not worth
> anybody's time to write.


But D7 not will be a less intrusive version, this is the point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090305/01d8eafe/attachment.htm 

From gerhard at killesreiter.de  Wed Mar  4 23:23:30 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Thu, 05 Mar 2009 00:23:30 +0100
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<1491315.265571236184157568.JavaMail.root@zimbra>	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>	<49AEC48E.50509@citris-uc.org>
	<49AED71C.9060704@NinjitsuWeb.com>	<49AEF531.5000703@favias.org>	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
Message-ID: <49AF0D72.8020207@killesreiter.de>

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

Paolo Mainardi schrieb:
> On Wed, Mar 4, 2009 at 11:47 PM, Gerhard Killesreiter <
> gerhard at killesreiter.de> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Paolo Mainardi schrieb:
>>> On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson at gmail.com>
>> wrote:
>>>>  But the API changes
>>>> are vast in Drupal 7.  Be aware and forewarned so as to consider the
>>>> release date question with the proper perspective.
>>>>
>>> I agree, but we must think to a soft of "compatibility API", i think that
>> is
>>> impossible to rewrite the world to every new Drupal release.
>> I take it you are new to Drupal development?
>>
> 
> Yes, i don't have contribute never to Drupal core, but i work on drupal
> development from a lot of time, and i've released some contribution, but
> this is not the point.


Maybe not.


>> We get this suggestion every time a similar discussion comes up.
>> Luckily, every time the anser is: No.
> 
> 
> Sorry but i don't understand, why "luckily" the answer every time is no ?

Because the bright people that develop Drupal have recignized that it is
futile.

>> Pretty much, yes. A full compatibility layer would like affect
>> performance big time and a less intrusive version is probably not worth
>> anybody's time to write.
> 
> 
> But D7 not will be a less intrusive version, this is the point.
> 

"less intrusive version" was referring to the compatibility layer, not
Drupal.

Basically, we've had similar discussions for Drupal 4.7, 5, and 6 and
all were hailed as the end of Drupal as we know it because nobody would
be able to update their modules in time, etc yadayada. We probably have
had this discussions for even earlier versions but luckily I've managed
to forget them.

Executive summary: Compatibility layer == bad.

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

iEYEARECAAYFAkmvDXIACgkQfg6TFvELooRM4QCfW/f1CnAPGSRgF0/5OdGulqU3
bE8An19o7spFpg5ohbwD1AHsfI2QNytO
=CpLf
-----END PGP SIGNATURE-----

From paolomainardi at gmail.com  Wed Mar  4 23:29:32 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Thu, 5 Mar 2009 00:29:32 +0100
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <49AF0D72.8020207@killesreiter.de>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>
	<49AEC48E.50509@citris-uc.org> <49AED71C.9060704@NinjitsuWeb.com>
	<49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
Message-ID: <c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>

On Thu, Mar 5, 2009 at 12:23 AM, Gerhard Killesreiter <
gerhard at killesreiter.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Paolo Mainardi schrieb:
> > On Wed, Mar 4, 2009 at 11:47 PM, Gerhard Killesreiter <
> > gerhard at killesreiter.de> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Paolo Mainardi schrieb:
> >>> On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson at gmail.com>
> >> wrote:
> >>>>  But the API changes
> >>>> are vast in Drupal 7.  Be aware and forewarned so as to consider the
> >>>> release date question with the proper perspective.
> >>>>
> >>> I agree, but we must think to a soft of "compatibility API", i think
> that
> >> is
> >>> impossible to rewrite the world to every new Drupal release.
> >> I take it you are new to Drupal development?
> >>
> >
> > Yes, i don't have contribute never to Drupal core, but i work on drupal
> > development from a lot of time, and i've released some contribution, but
> > this is not the point.
>
>
> Maybe not.
>
>
> >> We get this suggestion every time a similar discussion comes up.
> >> Luckily, every time the anser is: No.
> >
> >
> > Sorry but i don't understand, why "luckily" the answer every time is no ?
>
> Because the bright people that develop Drupal have recignized that it is
> futile.





>
>
> >> Pretty much, yes. A full compatibility layer would like affect
> >> performance big time and a less intrusive version is probably not worth
> >> anybody's time to write.
> >
> >
> > But D7 not will be a less intrusive version, this is the point.
> >
>
> "less intrusive version" was referring to the compatibility layer, not
> Drupal.
>
> Basically, we've had similar discussions for Drupal 4.7, 5, and 6 and
> all were hailed as the end of Drupal as we know it because nobody would
> be able to update their modules in time, etc yadayada. We probably have
> had this discussions for even earlier versions but luckily I've managed
> to forget them.
>
> Executive summary: Compatibility layer == bad.
>

I agree, but it's bat too rewrite from scratch every time a lot of code,
like Views or CCK or Panels.

Could be nicer have at least a stable API or a *drupalX-compat" plugin with
older API, but bright people surely know this things better of me :)

P.


-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090305/f4a2b344/attachment.htm 

From winborn at advomatic.com  Thu Mar  5 00:57:45 2009
From: winborn at advomatic.com (Aaron Winborn)
Date: Wed, 4 Mar 2009 19:57:45 -0500 (EST)
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <10416367.266431236214575804.JavaMail.root@zimbra>
Message-ID: <21512667.266451236214665970.JavaMail.root@zimbra>

On Wed, Mar 4, 2009 at 5:50 PM, "Moshe Weitzman" <weitzman at tejasa.com> wrote:
>Dries did not say anything about D7 that should cause concern. He just
said "when it is ready" and we can all discuss what that means. You
are assuming it excludes Contrib. But even more productive IMO would

Dries actually followed up "when it is ready" by stating it'll be ready when there are "0 critical patches". But I'll certainly give him the benefit of the doubt, and not read any more into that statement, nor from any omissions from that statement. The last thing I want to do is put words in his mouth.

>be to discuss what we can do to help modules upgrade quickly. Lets not
even get into the reasons why D6 Contrib adoption was slow. What
documentation is needed beyond the upgrade page (screencasts,
coder/deadwood, .webinars, ...). Can we provide testing infrastructure
for contrib modules? Could we focus the issue queue so issues about
upgrading are more easily handled?

Yes, yes, yes, and yes! A "Supported Tier" of modules by itself would do nothing to solve the issue. We need all of what you've suggested regardless of the outcome this proposal. That means we all need to work towards making this happen, regardless of the metric (or metrics) Dries chooses to use for the release of Drupal X.

From kb at 2bits.com  Thu Mar  5 01:06:14 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Wed, 4 Mar 2009 20:06:14 -0500
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AEC48E.50509@citris-uc.org> <49AED71C.9060704@NinjitsuWeb.com>
	<49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
Message-ID: <4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>

> >> Pretty much, yes. A full compatibility layer would like affect
>> >> performance big time and a less intrusive version is probably not worth
>> >> anybody's time to write.
>> >
>> >
>> > But D7 not will be a less intrusive version, this is the point.
>> >
>>
>> "less intrusive version" was referring to the compatibility layer, not
>> Drupal.
>>
>> Basically, we've had similar discussions for Drupal 4.7, 5, and 6 and
>> all were hailed as the end of Drupal as we know it because nobody would
>> be able to update their modules in time, etc yadayada. We probably have
>> had this discussions for even earlier versions but luckily I've managed
>> to forget them.
>>
>> Executive summary: Compatibility layer == bad.
>>
>
> I agree, but it's bat too rewrite from scratch every time a lot of code,
> like Views or CCK or Panels.
>

> Could be nicer have at least a stable API or a *drupalX-compat" plugin with
> older API, but bright people surely know this things better of me :)
>


So far, it has proven to be an acceptable price to pay for innovation. Yes,
it causes some pain, but if we fix the APIs between major releases, this
will be the start of the end for Drupal, since it will either get bloated by
a compatibility layer (more resources, slow, complexity, ...etc.), or Drupal
will stagnate and no longer become a leading content management
platform/application.

Having said that, there is nothing stopping YOU (or others) from building a
compatibility layers. Some people tried that from Drupal 4.6 to 4.7 after
Form API was in core. We just don't want that to be in core.

Better focus on tools that would make migrating your modules easier/quicker
(core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)


> P.
>
>
> --
> Paolo Mainardi
>
> Vice Presidente Assoc.ILDN (http://www.ildn.net)
> Blog: http://www.paolomainardi.com
>



-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090304/1ab8f97e/attachment.htm 

From mathews.kyle at gmail.com  Thu Mar  5 01:40:25 2009
From: mathews.kyle at gmail.com (Kyle Mathews)
Date: Wed, 4 Mar 2009 18:40:25 -0700
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AED71C.9060704@NinjitsuWeb.com> <49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
Message-ID: <efeed12d0903041740lcc5c323gfa1bb95be39d6603@mail.gmail.com>

Come on people -- has anyone who's complaining about upgrading a
module ever actually upgraded a module from one version to another?
It's really not that hard -- especially with coder / deadwood. I
upgraded a couple modules from Drupal 5 to 6 in only a couple of hours
including testing. Deadwood automates most of the process.

And to kill yet again the myth that keeps coming up again and again
zombie-like -- the reason so many modules had trouble upgrading from 5
to 6 is because they were dependent on Views which took so long to
upgrade not because of API changes but because it was completely
rewritten over the transition.

Kyle

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



On Wed, Mar 4, 2009 at 6:06 PM, Khalid Baheyeldin <kb at 2bits.com> wrote:
>
>>> >> Pretty much, yes. A full compatibility layer would like affect
>>> >> performance big time and a less intrusive version is probably not
>>> >> worth
>>> >> anybody's time to write.
>>> >
>>> >
>>> > But D7 not will be a less intrusive version, this is the point.
>>> >
>>>
>>> "less intrusive version" was referring to the compatibility layer, not
>>> Drupal.
>>>
>>> Basically, we've had similar discussions for Drupal 4.7, 5, and 6 and
>>> all were hailed as the end of Drupal as we know it because nobody would
>>> be able to update their modules in time, etc yadayada. We probably have
>>> had this discussions for even earlier versions but luckily I've managed
>>> to forget them.
>>>
>>> Executive summary: Compatibility layer == bad.
>>
>> I agree, but it's bat too rewrite from scratch every time a lot of code,
>> like Views or CCK or Panels.
>>
>> Could be nicer have at least a stable API or a *drupalX-compat" plugin
>> with older API, but bright people surely know this things better of me :)
>
>
> So far, it has proven to be an acceptable price to pay for innovation. Yes,
> it causes some pain, but if we fix the APIs between major releases, this
> will be the start of the end for Drupal, since it will either get bloated by
> a compatibility layer (more resources, slow, complexity, ...etc.), or Drupal
> will stagnate and no longer become a leading content management
> platform/application.
>
> Having said that, there is nothing stopping YOU (or others) from building a
> compatibility layers. Some people tried that from Drupal 4.6 to 4.7 after
> Form API was in core. We just don't want that to be in core.
>
> Better focus on tools that would make migrating your modules easier/quicker
> (core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)
>
>>
>> P.
>>
>>
>> --
>> Paolo Mainardi
>>
>> Vice Presidente Assoc.ILDN (http://www.ildn.net)
>> Blog: http://www.paolomainardi.com
>
>
>
> --
> Khalid M. Baheyeldin
> 2bits.com, Inc.
> http://2bits.com
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. -- ?Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. -- ? Leonardo da Vinci
>

From mail at webthatworks.it  Thu Mar  5 09:08:51 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Thu, 5 Mar 2009 10:08:51 +0100
Subject: [development] How to port modules? was: Drupal 7 "When it's Ready"
In-Reply-To: <4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AEC48E.50509@citris-uc.org> <49AED71C.9060704@NinjitsuWeb.com>
	<49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
Message-ID: <20090305100851.6e6ef58b@dawn.webthatworks.it>

On Wed, 4 Mar 2009 20:06:14 -0500
Khalid Baheyeldin <kb at 2bits.com> wrote:

> So far, it has proven to be an acceptable price to pay for
> innovation. Yes, it causes some pain, but if we fix the APIs

I think some more attention should be put on "so far".

I never read a book on software development that suggest that
writing from scratch is a good strategy but I admit having felt the
pain of refactoring quite frequently I've read more books on how to
fix the problems rather than how to get involved in a completely new
set of problems ;)

It could be that this is going to be part of drupal nature... since
it is a tool for a still very dynamic environment where the set of
problems change quite radically... but still... I wouldn't take it
for granted that drupal development life-cycle and nature is going
to be the same as it has been in the past.
For the same reason I consider the argument of "let's stabilise the
API" a legit argument as well... and it is just a matter of balance
and context.
I think the evolution of how fast API are going to change will
follow the evolution of how much core is an application vs. a
framework.
I think one of the secret for success of drupal has been being
halfway between a self sufficient application and a framework.
This is a ideal spot for small to medium projects where you can add
value with some tuning and the cost of rewriting is lower than the
cost of missing a large improvement made to core.
But the space for small shops is shrinking and the complexity of the
overall drupal project is increasing.
I wouldn't take for granted that the sweet spot is always where it
used to be and factor in as much elements as I could to make a
forecast.
Maybe core devs belongs to "subset" of drupal community that has
"its own itches", but the efforts of core to "scratch their own
itches" may not be the best compromise to scratch the "collective
itches" of the community that is *evolving*.
I'm not saying that core devs are blind or insensible to community
needs, I'm just saying that it's better to take nothing for granted
and somehow this kind of discussions aren't pointless just because
they are repeated.

Panta rei.

Orchestrating for this is one of the most valuable targets of
software development especially in Open Source projects.

> Better focus on tools that would make migrating your modules
> easier/quicker (core, deadwood, documentation for converting from
> 6.x to 7.x, ...etc.)

Awesome.
I've found http://drupal.org/project/deadwood
That was easy.
What were you referring to with "core"?

Do you have any other pointers to tools, docs, secret
recipe, everything that will help to port modules?

I was just planning to write my own tool at least to spot changes in
signatures.

Are there any coding standards that could make porting easier?
Core dev strategies that could make any change easier to digest?

Maybe Kyle Mathews is right and we just need to try and all the
tools, docs and efforts from the core team to make transitions as
smooth as possible are already there... but is there some further
knowledge, tool, strategy that could be deployed?
Or just a linden tisane?

thanks

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


From matt at mattfarina.com  Thu Mar  5 12:16:48 2009
From: matt at mattfarina.com (Matt Farina)
Date: Thu, 5 Mar 2009 07:16:48 -0500
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <20090305100851.6e6ef58b@dawn.webthatworks.it>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AEC48E.50509@citris-uc.org> <49AED71C.9060704@NinjitsuWeb.com>
	<49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
Message-ID: <EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>

On the documentation side of updating there is http://drupal.org/ 
update. If you are talking about modules see http://drupal.org/update/modules 
.

Also note that, a number of module maintainers (for widely used  
projects) have openly said they would like to release versions of  
their modules when drupal 7 is released.

Dries, also, said that releasing drupal 6 without drupal.org being  
updated to it was a mistake he doesn't want to see happen again.

I would be careful about trying to legislate anything. Let's see how  
the community responds. It might be good to get a movement of  
maintainers to update their modules for drupal 7 when a good time  
comes for that (like after the code freeze). I think that would be  
better received and more likely to make a difference.

On Mar 5, 2009, at 4:08 AM, Ivan Sergio Borgonovo wrote:

> On Wed, 4 Mar 2009 20:06:14 -0500
> Khalid Baheyeldin <kb at 2bits.com> wrote:
>
>> So far, it has proven to be an acceptable price to pay for
>> innovation. Yes, it causes some pain, but if we fix the APIs
>
> I think some more attention should be put on "so far".
>
> I never read a book on software development that suggest that
> writing from scratch is a good strategy but I admit having felt the
> pain of refactoring quite frequently I've read more books on how to
> fix the problems rather than how to get involved in a completely new
> set of problems ;)
>
> It could be that this is going to be part of drupal nature... since
> it is a tool for a still very dynamic environment where the set of
> problems change quite radically... but still... I wouldn't take it
> for granted that drupal development life-cycle and nature is going
> to be the same as it has been in the past.
> For the same reason I consider the argument of "let's stabilise the
> API" a legit argument as well... and it is just a matter of balance
> and context.
> I think the evolution of how fast API are going to change will
> follow the evolution of how much core is an application vs. a
> framework.
> I think one of the secret for success of drupal has been being
> halfway between a self sufficient application and a framework.
> This is a ideal spot for small to medium projects where you can add
> value with some tuning and the cost of rewriting is lower than the
> cost of missing a large improvement made to core.
> But the space for small shops is shrinking and the complexity of the
> overall drupal project is increasing.
> I wouldn't take for granted that the sweet spot is always where it
> used to be and factor in as much elements as I could to make a
> forecast.
> Maybe core devs belongs to "subset" of drupal community that has
> "its own itches", but the efforts of core to "scratch their own
> itches" may not be the best compromise to scratch the "collective
> itches" of the community that is *evolving*.
> I'm not saying that core devs are blind or insensible to community
> needs, I'm just saying that it's better to take nothing for granted
> and somehow this kind of discussions aren't pointless just because
> they are repeated.
>
> Panta rei.
>
> Orchestrating for this is one of the most valuable targets of
> software development especially in Open Source projects.
>
>> Better focus on tools that would make migrating your modules
>> easier/quicker (core, deadwood, documentation for converting from
>> 6.x to 7.x, ...etc.)
>
> Awesome.
> I've found http://drupal.org/project/deadwood
> That was easy.
> What were you referring to with "core"?
>
> Do you have any other pointers to tools, docs, secret
> recipe, everything that will help to port modules?
>
> I was just planning to write my own tool at least to spot changes in
> signatures.
>
> Are there any coding standards that could make porting easier?
> Core dev strategies that could make any change easier to digest?
>
> Maybe Kyle Mathews is right and we just need to try and all the
> tools, docs and efforts from the core team to make transitions as
> smooth as possible are already there... but is there some further
> knowledge, tool, strategy that could be deployed?
> Or just a linden tisane?
>
> thanks
>
> -- 
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
>


From kb at 2bits.com  Thu Mar  5 12:20:11 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Thu, 5 Mar 2009 07:20:11 -0500
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <20090305100851.6e6ef58b@dawn.webthatworks.it>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
Message-ID: <4a9fdc630903050420q57ca256cv222b3b80f3f9a8d4@mail.gmail.com>

On Thu, Mar 5, 2009 at 4:08 AM, Ivan Sergio Borgonovo
<mail at webthatworks.it>wrote:

> On Wed, 4 Mar 2009 20:06:14 -0500
> Khalid Baheyeldin <kb at 2bits.com> wrote:
>
> > So far, it has proven to be an acceptable price to pay for
> > innovation. Yes, it causes some pain, but if we fix the APIs
>
> I think some more attention should be put on "so far".
>
> I never read a book on software development that suggest that
> writing from scratch is a good strategy but I admit having felt the
> pain of refactoring quite frequently I've read more books on how to
> fix the problems rather than how to get involved in a completely new
> set of problems ;)
>

Most of the books are geared to corporate/commercial environment where
there is a central authority directing everything, a limited pool of people
resources with known skill levels to do the work, and a budget set by the
business.

This is open source where all the rules are broken: we have a larger pool
of talent with varying skill levels, they do the work on their own as they
have the time to do it, for fun or profit or both, and anyone can jump in
and
create patches for any project and ask for reviews.

It does not have to perfect from day 1: it just has to be good enough and
released
early so others can refine it. I maintain/co-maintain 37+ modules (since I
last checked)
and it would be insane if I would have to upgrade them all. Instead, for a
couple
of core releases, people upgrade them as they need them and submit patches.

It works wonderfully. Organized chaos!

It could be that this is going to be part of drupal nature... since
> it is a tool for a still very dynamic environment where the set of
> problems change quite radically... but still... I wouldn't take it
> for granted that drupal development life-cycle and nature is going
> to be the same as it has been in the past.
> For the same reason I consider the argument of "let's stabilise the
> API" a legit argument as well... and it is just a matter of balance
> and context.
> I think the evolution of how fast API are going to change will
> follow the evolution of how much core is an application vs. a
> framework.
> I think one of the secret for success of drupal has been being
> halfway between a self sufficient application and a framework.
> This is a ideal spot for small to medium projects where you can add
> value with some tuning and the cost of rewriting is lower than the
> cost of missing a large improvement made to core.
> But the space for small shops is shrinking and the complexity of the
> overall drupal project is increasing.
> I wouldn't take for granted that the sweet spot is always where it
> used to be and factor in as much elements as I could to make a
> forecast.
> Maybe core devs belongs to "subset" of drupal community that has
> "its own itches", but the efforts of core to "scratch their own
> itches" may not be the best compromise to scratch the "collective
> itches" of the community that is *evolving*.
> I'm not saying that core devs are blind or insensible to community
> needs, I'm just saying that it's better to take nothing for granted
> and somehow this kind of discussions aren't pointless just because
> they are repeated.
>

>From what I explained, the "so far" is still valid, so need to change it for
D7.

We always adapt and if we feel like D8 needs to change that, then we
cross that bridge when we get to it.


> Panta rei.
>
> Orchestrating for this is one of the most valuable targets of
> software development especially in Open Source projects.
>
> > Better focus on tools that would make migrating your modules
> > easier/quicker (core, deadwood, documentation for converting from
> > 6.x to 7.x, ...etc.)
>
> Awesome.
> I've found http://drupal.org/project/deadwood
> That was easy.
> What were you referring to with "core"?
>

Typo. Should read coder: http://drupal.org/project/coder

Again the best asset of Drupal is not modules, or code. It is the volunteer
base. They will jump in and upgrade stuff for you as they need it.


>
> Do you have any other pointers to tools, docs, secret
> recipe, everything that will help to port modules?
>

Help the modules you care about by submitting patches, testing patches,
improving the README and other documenation.


>
> I was just planning to write my own tool at least to spot changes in
> signatures.
>

See coder above. Help improve it if you like it.

>
> Are there any coding standards that could make porting easier?
> Core dev strategies that could make any change easier to digest?
>

Again, coder checks a lot of that.

>
> Maybe Kyle Mathews is right and we just need to try and all the
> tools, docs and efforts from the core team to make transitions as
> smooth as possible are already there... but is there some further
> knowledge, tool, strategy that could be deployed?
> Or just a linden tisane?
>

Perhaps a guide in the hand book will help: "a quick guide to upgrading
modules from a previous version to a current version" with all of the above
info and much more.

Any volunteers?

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


-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090305/abdb6347/attachment-0001.htm 

From s.nerz at orestes-sol.com  Thu Mar  5 12:28:29 2009
From: s.nerz at orestes-sol.com (Sebastian Nerz)
Date: Thu, 05 Mar 2009 13:28:29 +0100
Subject: [development] Core vs profile [was: Drupal 7 "When it's Ready"]
In-Reply-To: <49AED71C.9060704@NinjitsuWeb.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<1491315.265571236184157568.JavaMail.root@zimbra>	<3861c6770903040928q19736566j1333fbab8494fe3d@mail.gmail.com>	<49AEC48E.50509@citris-uc.org>
	<49AED71C.9060704@NinjitsuWeb.com>
Message-ID: <49AFC56D.1010704@orestes-sol.com>

Hi,

I apologize right in front - I'm new to Drupal development (so neither 
to programming nor to php/webprogramming), nevertheless I want to voice 
some of my concerns regarding "core" vs "profiles", as the problem was 
mentioned in the discussion /Drupal 7 "When it's Ready"/.

Matt Chapman schrieb:
> You may say, 'What about modules that are so generic that they are
> used in most any site?' I'd suggest that those are exactly the sorts
> of modules that should be included in Core. We're seeing this happen
> with CCK, and Views seems poised to follow shortly. We could even make
> the criteria for core eligibility more explicit: If a module is used
> in EVERY supported profile, then it should be moved to core in some
> form.
> (And the converse: if a module is not used by any supported profile,
> it should probably be removed from core.)
>
> One thing that would really help this is more street cred for profile
> maintainers. However about some front-page case studies for a couple
> profiles?

I am a big fan of modular development - and in my eyes modular
development means: Keep core as minimal as possible and provide modules
and module-packs.
For Drupal this would mean: A minimal core (might include minimal CCK
and Views (API), but e.g. not Blog or Forum) that is required, abd not a
single optional module. Then provide some "standard profiles/usecases".
Most users would download the standard profile (thus including e.g.
Blog, Forum and Views UI). Replace the standard download link with a
link to the standard profile.

What is the difference? Core is more critical then optional modules.
Thus every module-update has to be part of a core-update - while
updating single non-core modules is far easier for both, the developer
and the user. A minimal core thus provides the highest flexibility.
You can e.g. see that in Drupal - core modules tend to develop much
slower then contrib ones. This is ok, but does Drupal really need a
large Core?

For the average user (and even the average developer) a minimal core
with a standard profile wouldn't change anything.

This would change the scope of profiles, but I think it would be for the
best.

> It's not so important to users that module X be available, but that 
> feature Y be provided by some module; preferably with an upgrade path 
> from module X, but that is secondary from a development perspective.

I agree - and believe that this again is an argument in favor of
"minimal core, maximal profile".

> Rather than golden modules, what we need are golden 'use cases.' Perhaps 
> this takes the form of supported Profiles or Patterns. (I'll use the 
> term 'profile' to mean any means of collecting modules and 
> configurations for implementing a specific end-user functionality. I 
> think installation profiles as currently supported by Drupal are 
> severely lacking, having abandoned one in favor of database dumps for 
> the time being.)

I agree.
Profiles would need to be changed into something more generic. In fact,
an automatic download tool in combination with use-cases would solve
even more problems: Use-cases (or profiles) could be
downloaded/selected, and the needed modules are automatically downloaded
and installed. I agree, that quite a couple of professional webmasters
wouldn't use automatic downloaders out of the box - but they should be
able to download needed modules by themselves, provided the use-case
lists the needed modules.
A use-case could e.g. be a module with requirements, but without content
(define what modules you need for the given use-case, possible link them
together, but provide no functionality for yourself). If a use-case
needs functionality that is not defined in any module - add a
corresponding module. If the functionality is only needed in the given
use-case, add it to the use-case module.
This would allow a much more flexible combination of use-cases/profiles,
it would allow for extending use-cases (e.g. Blogpage, Reviewblog
extends Blogpage, etc)

> Finally, supporting profiles instead of modules makes the system less 
> susceptible to single points of failure. It takes less technical 
> expertise to maintain a profile than it does to maintain a module. If I 
> maintain the Community Events Management profile, and there's no e-mail 
> reminder functionality available for Drupal 7, I can petition 3 or 4 
> different module developers to upgrade their module, or I can try to 
> organize some developers to create a new, better one, to leverage the 
> new DX features of Drupal 7.

Again: I believe that this is an argument pro "profiles" and against
"core" as it would be easier to maintain a set of use-cases/profiles
with a minimal core, provided use-cases could include other use-cases.

-- 
Mit freundlichen Gr??en / Best regards / Saludos cordiales

*Sebastian Nerz*

___________________________________________
*Orestes*
Eduard-Spranger-Str. 56
D-72076 Tuebingen - Deutschland
Of.  : +49-7071-56519-30 - Fax : +49-7071-56519-31
www.orestes-sol.com <http://www.orestes-sol.com/>
s.nerz at orestes-sol.com <mailto:s.nerz at orestes-sol.com>
___________________________________________


From anselm_list at netuxo.co.uk  Thu Mar  5 12:32:47 2009
From: anselm_list at netuxo.co.uk (Anselm)
Date: Thu, 5 Mar 2009 12:32:47 +0000
Subject: [development] Drupal 7 "When it's Ready"
In-Reply-To: <1491315.265571236184157568.JavaMail.root@zimbra>
References: <1491315.265571236184157568.JavaMail.root@zimbra>
Message-ID: <200903051232.47138.anselm_list@netuxo.co.uk>


There's a few contributors who are really into the Drupal project, but I would 
guess most contributors don't upgrade their modules until they have to. Until 
there's a D7 release, there will be no need for people to upgrade their 
modules, and so they won't.

I know because that's what I do. I need a functionality that doesn't exist, I 
write the module for it, and then I contribute it back for other people who 
might want it. I will apply patches sent to me (and give other people CVS 
access), but beyond that I won't develop the module further as long as it 
does what I want. That means I won't port it to D7 until I need it on a D7 
site ; and that won't happen until D7 is out.

This is not an uncommon thing in the floss world ; KDE 4.0 comes to mind as a 
good example.

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

From paolomainardi at gmail.com  Thu Mar  5 12:41:43 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Thu, 5 Mar 2009 13:41:43 +0100
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
Message-ID: <c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>

On Thu, Mar 5, 2009 at 1:16 PM, Matt Farina <matt at mattfarina.com> wrote:

> On the documentation side of updating there is http://drupal.org/update.
> If you are talking about modules see http://drupal.org/update/modules.
>
> Also note that, a number of module maintainers (for widely used projects)
> have openly said they would like to release versions of their modules when
> drupal 7 is released.


Indeed, the contrary, I believe that it is stable API that can make a
valuable in enterprise environments. (SDL, DirectX, Carbon, Cocoa etc ...).

We should begin to put these arguments on the table, backward and 'a subject
that will' sooner or later be addressed.


> Dries, also, said that releasing drupal 6 without drupal.org being updated
> to it was a mistake he doesn't want to see happen again.


Why it's happen ? Because big missing, "Views, OG, Panels etc...etc...",
because backward compatibility API doesn't exists.

Could be possible have a more abstract API on top of new features,
decoupling the implementation from the interface.

P.

-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090305/0953bdf6/attachment.htm 

From gabor at hojtsy.hu  Thu Mar  5 12:57:50 2009
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Thu, 5 Mar 2009 13:57:50 +0100
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <20090305100851.6e6ef58b@dawn.webthatworks.it>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AEF531.5000703@favias.org>
	<9ea8d6030903041410t48469dfdn52891998cf03d754@mail.gmail.com>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
Message-ID: <86ca3ccb0903050457r507f3c65wa7722bed9bdf5339@mail.gmail.com>

On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo
<mail at webthatworks.it> wrote:
> I was just planning to write my own tool at least to spot changes in
> signatures.

Already done. In terms of docs, it is implemented on api.drupal.org,
in terms of module upgrade mistake checking, it is implemented in
coder.module.

G?bor

From catch56 at googlemail.com  Thu Mar  5 13:04:13 2009
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 5 Mar 2009 08:04:13 -0500
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<c538f9410903041421v49b54081q5b38fbba22ada1ea@mail.gmail.com>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>
Message-ID: <fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>

>
>> Dries, also, said that releasing drupal 6 without drupal.org being
>> updated to it was a mistake he doesn't want to see happen again.
>
>
> Why it's happen ? Because big missing, "Views, OG, Panels etc...etc...",
> because backward compatibility API doesn't exists.
>

Views 2 (in Drupal 6) isn't compatable with Views 1 (in 5.x). A 'backwards
compatability API' would have had zero effect, possibly a negative effect on
the Views upgrade process.

Organic Groups AND Panels both rely on Views - so could only be updated
fully once Views was at release candidate stage.

I really wish people would familarise themselves with the issues at hand
before mouthing off on this list about "we need to do this [useless thing
which would have zero effect]". Even a tiny bit of research would show what
the issues are, and it's not API changes in core - it's manpower helping out
the commonly used modules to get upgraded.

If you want to see contrib modules ready when Drupal 7 is, you can start now
by providing and/or testing patches for your favourite modules to get them
upgraded. There are also modules with development versions or even beta
releases for Drupal 7 listed here -
http://drupal.org/project/modules?filters=drupal_core:103&solrsort=title_sort%20asc-
again I'm sure their maintainers wouldn't turn down patches when
there's
API changes in HEAD.

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

From winborn at advomatic.com  Thu Mar  5 13:06:07 2009
From: winborn at advomatic.com (Aaron Winborn)
Date: Thu, 5 Mar 2009 08:06:07 -0500 (EST)
Subject: [development] How to port modules? was: Drupal 7 "When it's
 Ready"
In-Reply-To: <86ca3ccb0903050457r507f3c65wa7722bed9bdf5339@mail.gmail.com>
Message-ID: <29649259.266501236258367007.JavaMail.root@zimbra>

api-contrib.drupal.org would be nice... :D

----- Original Message -----
From: "G?bor Hojtsy" <gabor at hojtsy.hu>
To: development at drupal.org
Sent: Thursday, March 5, 2009 7:57:50 AM GMT -05:00 US/Canada Eastern
Subject: Re: [development] How to port modules? was: Drupal 7 "When it's Ready"

On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo
<mail at webthatworks.it> wrote:
> I was just planning to write my own tool at least to spot changes in
> signatures.

Already done. In terms of docs, it is implemented on api.drupal.org,
in terms of module upgrade mistake checking, it is implemented in
coder.module.

G?bor

From gabor at hojtsy.hu  Thu Mar  5 13:12:14 2009
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Thu, 5 Mar 2009 14:12:14 +0100
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <29649259.266501236258367007.JavaMail.root@zimbra>
References: <86ca3ccb0903050457r507f3c65wa7722bed9bdf5339@mail.gmail.com>
	<29649259.266501236258367007.JavaMail.root@zimbra>
Message-ID: <86ca3ccb0903050512w396e1bb4k1c5d414050e0c895@mail.gmail.com>

Niel has this on his TODO list :)

G?bor

On Thu, Mar 5, 2009 at 2:06 PM, Aaron Winborn <winborn at advomatic.com> wrote:
> api-contrib.drupal.org would be nice... :D
>
> ----- Original Message -----
> From: "G?bor Hojtsy" <gabor at hojtsy.hu>
> To: development at drupal.org
> Sent: Thursday, March 5, 2009 7:57:50 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [development] How to port modules? was: Drupal 7 "When it's Ready"
>
> On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo
> <mail at webthatworks.it> wrote:
>> I was just planning to write my own tool at least to spot changes in
>> signatures.
>
> Already done. In terms of docs, it is implemented on api.drupal.org,
> in terms of module upgrade mistake checking, it is implemented in
> coder.module.
>
> G?bor
>

From paolomainardi at gmail.com  Thu Mar  5 13:30:53 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Thu, 5 Mar 2009 14:30:53 +0100
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AF04FE.5000609@killesreiter.de>
	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>
	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>
Message-ID: <c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>

On Thu, Mar 5, 2009 at 2:04 PM, Nathaniel Catchpole
<catch56 at googlemail.com>wrote:

>
>
>>> Dries, also, said that releasing drupal 6 without drupal.org being
>>> updated to it was a mistake he doesn't want to see happen again.
>>
>>
>> Why it's happen ? Because big missing, "Views, OG, Panels etc...etc...",
>> because backward compatibility API doesn't exists.
>>
>
> Views 2 (in Drupal 6) isn't compatable with Views 1 (in 5.x). A 'backwards
> compatability API' would have had zero effect, possibly a negative effect on
> the Views upgrade process.


My point is different, a backward compatibility API could run Views 1.x on D
> 5, this was the point.


>
> I really wish people would familarise themselves with the issues at hand
> before mouthing off on this list about "we need to do this [useless thing
> which would have zero effect]". Even a tiny bit of research would show what
> the issues are, and it's not API changes in core - it's manpower helping out
> the commonly used modules to get upgraded.


Yes, it's not only "mouthing off", i'm developing with Drupal all days, i'm
trying to be propositional with full respect for your work.


>
>
> If you want to see contrib modules ready when Drupal 7 is, you can start
> now by providing and/or testing patches for your favourite modules to get
> them upgraded. There are also modules with development versions or even beta
> releases for Drupal 7 listed here -
> http://drupal.org/project/modules?filters=drupal_core:103&solrsort=title_sort%20asc- again I'm sure their maintainers wouldn't turn down patches when there's
> API changes in HEAD.
>
> Nat
>

You confirm my theory, no pathces because API changes, i don't like at all,
but it's the Druapl development cycle and if it's the the price to pay for a
such great project. ;)

-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090305/babbedf6/attachment.htm 

From dipench at gmail.com  Thu Mar  5 13:33:09 2009
From: dipench at gmail.com (Dipen)
Date: Thu, 5 Mar 2009 19:03:09 +0530
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <29649259.266501236258367007.JavaMail.root@zimbra>
References: <86ca3ccb0903050457r507f3c65wa7722bed9bdf5339@mail.gmail.com>
	<29649259.266501236258367007.JavaMail.root@zimbra>
Message-ID: <1fcccc8a0903050533v6f538e37kf6a495f1e729d8d4@mail.gmail.com>

+100 for api-contrib.drupal.org
go Niel !!!




On Thu, Mar 5, 2009 at 6:36 PM, Aaron Winborn <winborn at advomatic.com> wrote:

> api-contrib.drupal.org would be nice... :D
>
> ----- Original Message -----
> From: "G?bor Hojtsy" <gabor at hojtsy.hu>
> To: development at drupal.org
> Sent: Thursday, March 5, 2009 7:57:50 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [development] How to port modules? was: Drupal 7 "When it's
> Ready"
>
> On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo
> <mail at webthatworks.it> wrote:
> > I was just planning to write my own tool at least to spot changes in
> > signatures.
>
> Already done. In terms of docs, it is implemented on api.drupal.org,
> in terms of module upgrade mistake checking, it is implemented in
> coder.module.
>
> G?bor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090305/713dd8a6/attachment.htm 

From Matt at NinjitsuWeb.com  Thu Mar  5 21:39:20 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Thu, 05 Mar 2009 16:39:20 -0500
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <29649259.266501236258367007.JavaMail.root@zimbra>
References: <29649259.266501236258367007.JavaMail.root@zimbra>
Message-ID: <49B04688.9070009@NinjitsuWeb.com>

Aaron Winborn wrote:
> api-contrib.drupal.org would be nice... :D
>   
Sorry if this has already been pointed out. I've had a hard time keeping 
up with the pace of conversation today:

http://api.freestylesystems.co.uk/






From drumm at delocalizedham.com  Thu Mar  5 23:30:42 2009
From: drumm at delocalizedham.com (Neil Drumm)
Date: Thu, 5 Mar 2009 18:30:42 -0500
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <29649259.266501236258367007.JavaMail.root@zimbra>
References: <86ca3ccb0903050457r507f3c65wa7722bed9bdf5339@mail.gmail.com>
	<29649259.266501236258367007.JavaMail.root@zimbra>
Message-ID: <c96281260903051530u2c2c4134pa232171ba51f1dd5@mail.gmail.com>

I would like to see Drupal shops start setting up API sites for their
modules and start filing issues to solve what comes up when you have
lots of code mixed in one site.

We need:
* Another column to add a concept of project
* Integrate with update status to get the right system for each module
* Add navigation so users know where they are in the site
* How should searching be handled?
* Report documentation coverage to the module page on Drupal.org.

I'll be working on API module at the DC code sprint as one of my many
projects. Find me if you want to help.

-Neil

On Thu, Mar 5, 2009 at 8:06 AM, Aaron Winborn <winborn at advomatic.com> wrote:
> api-contrib.drupal.org would be nice... :D
>
> ----- Original Message -----
> From: "G?bor Hojtsy" <gabor at hojtsy.hu>
> To: development at drupal.org
> Sent: Thursday, March 5, 2009 7:57:50 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [development] How to port modules? was: Drupal 7 "When it's Ready"
>
> On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo
> <mail at webthatworks.it> wrote:
>> I was just planning to write my own tool at least to spot changes in
>> signatures.
>
> Already done. In terms of docs, it is implemented on api.drupal.org,
> in terms of module upgrade mistake checking, it is implemented in
> coder.module.
>
> G?bor
>



-- 
Neil Drumm
http://delocalizedham.com

From merlin at logrus.com  Fri Mar  6 04:23:09 2009
From: merlin at logrus.com (Earl Miles)
Date: Thu, 05 Mar 2009 20:23:09 -0800
Subject: [development] How to port modules? was: Drupal 7 "When
	it's	Ready"
In-Reply-To: <c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<49AF04FE.5000609@killesreiter.de>	<c538f9410903041503y62541a29if63ff674c8749a68@mail.gmail.com>	<49AF0D72.8020207@killesreiter.de>	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>	<20090305100851.6e6ef58b@dawn.webthatworks.it>	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>
	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>
Message-ID: <49B0A52D.6080207@logrus.com>

Paolo Mainardi wrote:
>
>
> On Thu, Mar 5, 2009 at 2:04 PM, Nathaniel Catchpole 
> <catch56 at googlemail.com <mailto:catch56 at googlemail.com>> wrote:
>
>
>
>             Dries, also, said that releasing drupal 6 without
>             drupal.org <http://drupal.org> being updated to it was a
>             mistake he doesn't want to see happen again.
>
>
>         Why it's happen ? Because big missing, "Views, OG, Panels
>         etc...etc...", because backward compatibility API doesn't exists.
>
>
>     Views 2 (in Drupal 6) isn't compatable with Views 1 (in 5.x). A
>     'backwards compatability API' would have had zero effect, possibly
>     a negative effect on the Views upgrade process.
>
>
> My point is different, a backward compatibility API could run Views 
> 1.x on D > 5, this was the point.
>  
No, it can't.

Drupal changed entire sub systems. Not just how the functions are called 
but how the data is stored and what the data signatures are. A 
'backwards compatibility API' would have required KEEPING data around 
that would cause the system to run slowly. The performance would be a 
nightmare. When going from version to version, one of the advantages is 
that we can throw away paradigms that are unsuccessful. A backwards 
compatibility API requires us to keep those paradigms.

Remember, an API is not just a bunch of function signatures. It is much, 
much deeper than that, and they would completely change the wya things 
have to be implemented. They would be a major burden, possibly MORE 
major than the effort of simply upgrading the modules to new APIs.

From paolomainardi at gmail.com  Fri Mar  6 08:58:49 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Fri, 6 Mar 2009 09:58:49 +0100
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <49B0A52D.6080207@logrus.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>
	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>
	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>
	<49B0A52D.6080207@logrus.com>
Message-ID: <c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>

On Fri, Mar 6, 2009 at 5:23 AM, Earl Miles <merlin at logrus.com> wrote:

> Paolo Mainardi wrote:
>
>>
>>
>> On Thu, Mar 5, 2009 at 2:04 PM, Nathaniel Catchpole <
>> catch56 at googlemail.com <mailto:catch56 at googlemail.com>> wrote:
>>
>>
>>
>>            Dries, also, said that releasing drupal 6 without
>>            drupal.org <http://drupal.org> being updated to it was a
>>            mistake he doesn't want to see happen again.
>>
>>
>>        Why it's happen ? Because big missing, "Views, OG, Panels
>>        etc...etc...", because backward compatibility API doesn't exists.
>>
>>
>>    Views 2 (in Drupal 6) isn't compatable with Views 1 (in 5.x). A
>>    'backwards compatability API' would have had zero effect, possibly
>>    a negative effect on the Views upgrade process.
>>
>>
>> My point is different, a backward compatibility API could run Views 1.x on
>> D > 5, this was the point.
>>
>>
> No, it can't.
>
> Drupal changed entire sub systems. Not just how the functions are called
> but how the data is stored and what the data signatures are. A 'backwards
> compatibility API' would have required KEEPING data around that would cause
> the system to run slowly. The performance would be a nightmare. When going
> from version to version, one of the advantages is that we can throw away
> paradigms that are unsuccessful. A backwards compatibility API requires us
> to keep those paradigms.
>
> Remember, an API is not just a bunch of function signatures. It is much,
> much deeper than that, and they would completely change the wya things have
> to be implemented.


A good API could change the implementation without changing the signatures,
they not are strictly related, it's not the only practices to do the things.

How is related from the data storage and API ? At API level, we don't do any
assumption on how data is stored or how is the internal implementation,
these are things to a lower (not API) level.

I think could be possible to write a sort of more abstract general API on
top of existent for expose a bunch of general "services" with Drupal
versions compatilibity in mind. Could be a plugin.

P.


-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090306/3e1bee81/attachment-0001.htm 

From gerhard at killesreiter.de  Fri Mar  6 09:05:25 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Fri, 06 Mar 2009 10:05:25 +0100
Subject: [development] How to port modules? was: Drupal 7 "When
	it's	Ready"
In-Reply-To: <c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<49AF0D72.8020207@killesreiter.de>	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>	<20090305100851.6e6ef58b@dawn.webthatworks.it>	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>	<49B0A52D.6080207@logrus.com>
	<c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
Message-ID: <49B0E755.3080500@killesreiter.de>

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

Paolo Mainardi schrieb:
> On Fri, Mar 6, 2009 at 5:23 AM, Earl Miles <merlin at logrus.com> wrote:
> 
>> Remember, an API is not just a bunch of function signatures. It is
>> much, much deeper than that, and they would completely change the
>> wya things have to be implemented.
> 
> A good API could change the implementation without changing the
> signatures, they not are strictly related, it's not the only
> practices to do the things.
> 
> How is related from the data storage and API ? At API level, we
> don't do any assumption on how data is stored or how is the internal
> implementation, these are things to a lower (not API) level.
> 
> I think could be possible to write a sort of more abstract general
> API on top of existent for expose a bunch of general "services" with
> Drupal versions compatilibity in mind. Could be a plugin.

Yeah, but apparently nobody of the usual suspects is interested in
doing your bidding.

[x] Go away and come back when you've got code to show.

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

iEYEARECAAYFAkmw51UACgkQfg6TFvELooR4fwCeIcKs371dGktL5wA3LWPs5v1u
6m0AoKtQaxGEyzLkBRNsDQSqrGHWt7T5
=MItU
-----END PGP SIGNATURE-----

From paolomainardi at gmail.com  Fri Mar  6 09:08:12 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Fri, 6 Mar 2009 10:08:12 +0100
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <49B0E755.3080500@killesreiter.de>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>
	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>
	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>
	<49B0A52D.6080207@logrus.com>
	<c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
	<49B0E755.3080500@killesreiter.de>
Message-ID: <c538f9410903060108h94cdb60v37fbdb1c5e2773f7@mail.gmail.com>

On Fri, Mar 6, 2009 at 10:05 AM, Gerhard Killesreiter <
gerhard at killesreiter.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [x] Go away and come back when you've got code to show.
>

Yeah, really nice, please relax Gerard.

-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090306/90fb5cc3/attachment.htm 

From michael at favias.org  Fri Mar  6 16:42:02 2009
From: michael at favias.org (Michael Favia)
Date: Fri, 06 Mar 2009 10:42:02 -0600
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <c538f9410903060108h94cdb60v37fbdb1c5e2773f7@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>	<20090305100851.6e6ef58b@dawn.webthatworks.it>	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>	<49B0A52D.6080207@logrus.com>	<c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>	<49B0E755.3080500@killesreiter.de>
	<c538f9410903060108h94cdb60v37fbdb1c5e2773f7@mail.gmail.com>
Message-ID: <49B1525A.5060702@favias.org>

Paolo Mainardi wrote:
> Yeah, really nice, please relax Gerard.
Sorry for the curtness, but this isn't exactly the first time this 
argument has come up in the last 5 years and some people get tired of 
beating it to death. We have maintained a steady position that our 
willingness to break API on major version releases allows for more 
innovative work and less complex development of new features. It 
constitutes is one of our competitive advantages over other CMS 
solutions and allows us to focus our development efforts forward not 
backward. We fully understand the costs of following such a model and 
understand if it isnt something youre interested in, but nobody pulled 
the rug out from under you here. This is how its been and how it will 
be. It is a big reason that a lot of us are on this project instead of 
others whether we know it or not. We understand that this may scare off 
some enterprise customers seeking stability. We dont have stability yet 
and might not for along time. Your efforts and the efforts of everyone 
postulating the best way to release D7 would be best applied like they 
usually are in assistance upgrading the modules you care about :). Good 
luck. -mf

From news at unleashedmind.com  Fri Mar  6 17:02:04 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Fri, 6 Mar 2009 18:02:04 +0100
Subject: [development] How to port modules? was: Drupal 7 "When
	it'sReady"
In-Reply-To: <49B1525A.5060702@favias.org>
Message-ID: <022501c99e7d$46bd1ff0$0200a8c0@structworks.com>

...and it is stated and reasoned in Drupal's mission and principles:
http://drupal.org/node/65922

sun 


From matze999 at gmx.net  Fri Mar  6 19:07:38 2009
From: matze999 at gmx.net (Matt Funk)
Date: Fri, 6 Mar 2009 12:07:38 -0700
Subject: [development] a (probably) simple question w.r.t. drupal_execute
Message-ID: <200903061207.39047.matze999@gmx.net>

Hi,

i am pretty new at developing stuff in Drupal. So this question is probably an 
easy one to answer, but i am still new enough that i don't even really know 
where to look to start the debugging process. And i am hoping this is the 
correct list to post to.

Anyway, here's the question:

I am simply trying to programmatically create an attribute for ubercart 
(ver2). As far as i can tell drupal_execute seems the easiest (and intended?) 
way to do this.

So i create my $form_state array etc...
Then $form_id = 'uc_attribute_form';

When i put that into the module and the menu callback is executed i get:

...
warning: call_user_func_array() [function.call-user-func-array]: First 
argument is expected to be a valid callback, 'uc_attribute_form' was given 
in /home/content/x/p/d/xpdtek/html/drupal-6.10/includes/form.inc on line 366.
...

So apparently i am not quite getting something here. My first guess is that 
the form_id is wrong. But uc_attributes is enabled and from what i can tell 
the form that lets me manually create an attribute is called 
uc_attribute_form (located in uc_attribute/uc_attribute.admin.inc).


Can anyone shed some light on this for me ...


thanks
matt

From matze999 at gmx.net  Fri Mar  6 23:59:05 2009
From: matze999 at gmx.net (Matt Funk)
Date: Fri, 6 Mar 2009 16:59:05 -0700
Subject: [development] a (probably) simple question w.r.t. drupal_execute
In-Reply-To: <200903061207.39047.matze999@gmx.net>
References: <200903061207.39047.matze999@gmx.net>
Message-ID: <200903061659.06099.matze999@gmx.net>

mmhh,

well, to answer my own question, i guess i had to do a 
include_once(drupal_get_path('module', 'uc_attribute'). '/uc_attribute.admin.inc');

in the module file in order to have access to that form. It looks like it 
works now.


Anyway, 
is it better to post stuff on drupal.org than on this list?

thanks
matt

On Friday 06 March 2009, Matt Funk wrote:
> Hi,
>
> i am pretty new at developing stuff in Drupal. So this question is probably
> an easy one to answer, but i am still new enough that i don't even really
> know where to look to start the debugging process. And i am hoping this is
> the correct list to post to.
>
> Anyway, here's the question:
>
> I am simply trying to programmatically create an attribute for ubercart
> (ver2). As far as i can tell drupal_execute seems the easiest (and
> intended?) way to do this.
>
> So i create my $form_state array etc...
> Then $form_id = 'uc_attribute_form';
>
> When i put that into the module and the menu callback is executed i get:
>
> ...
> warning: call_user_func_array() [function.call-user-func-array]: First
> argument is expected to be a valid callback, 'uc_attribute_form' was given
> in /home/content/x/p/d/xpdtek/html/drupal-6.10/includes/form.inc on line
> 366. ...
>
> So apparently i am not quite getting something here. My first guess is that
> the form_id is wrong. But uc_attributes is enabled and from what i can tell
> the form that lets me manually create an attribute is called
> uc_attribute_form (located in uc_attribute/uc_attribute.admin.inc).
>
>
> Can anyone shed some light on this for me ...
>
>
> thanks
> matt



From fgrunta at gmail.com  Sat Mar  7 00:01:12 2009
From: fgrunta at gmail.com (Frederik Grunta)
Date: Sat, 7 Mar 2009 00:01:12 +0000
Subject: [development] a (probably) simple question w.r.t. drupal_execute
In-Reply-To: <200903061659.06099.matze999@gmx.net>
References: <200903061207.39047.matze999@gmx.net>
	<200903061659.06099.matze999@gmx.net>
Message-ID: <401b53480903061601i9732e21rb2c5874a54f01208@mail.gmail.com>

Hey Matt,

This list is for Drupal core development, so you're better off posting on
the support forums on drupal.org, or heading to the irc chanel
#drupal-support on freenode.net.

Cheers,

Frederik

2009/3/6 Matt Funk <matze999 at gmx.net>

> mmhh,
>
> well, to answer my own question, i guess i had to do a
> include_once(drupal_get_path('module', 'uc_attribute').
> '/uc_attribute.admin.inc');
>
> in the module file in order to have access to that form. It looks like it
> works now.
>
>
> Anyway,
> is it better to post stuff on drupal.org than on this list?
>
> thanks
> matt
>
> On Friday 06 March 2009, Matt Funk wrote:
> > Hi,
> >
> > i am pretty new at developing stuff in Drupal. So this question is
> probably
> > an easy one to answer, but i am still new enough that i don't even really
> > know where to look to start the debugging process. And i am hoping this
> is
> > the correct list to post to.
> >
> > Anyway, here's the question:
> >
> > I am simply trying to programmatically create an attribute for ubercart
> > (ver2). As far as i can tell drupal_execute seems the easiest (and
> > intended?) way to do this.
> >
> > So i create my $form_state array etc...
> > Then $form_id = 'uc_attribute_form';
> >
> > When i put that into the module and the menu callback is executed i get:
> >
> > ...
> > warning: call_user_func_array() [function.call-user-func-array]: First
> > argument is expected to be a valid callback, 'uc_attribute_form' was
> given
> > in /home/content/x/p/d/xpdtek/html/drupal-6.10/includes/form.inc on line
> > 366. ...
> >
> > So apparently i am not quite getting something here. My first guess is
> that
> > the form_id is wrong. But uc_attributes is enabled and from what i can
> tell
> > the form that lets me manually create an attribute is called
> > uc_attribute_form (located in uc_attribute/uc_attribute.admin.inc).
> >
> >
> > Can anyone shed some light on this for me ...
> >
> >
> > thanks
> > matt
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090307/8822f15b/attachment.htm 

From matze999 at gmx.net  Sat Mar  7 00:12:34 2009
From: matze999 at gmx.net (Matt Funk)
Date: Fri, 6 Mar 2009 17:12:34 -0700
Subject: [development] a (probably) simple question w.r.t. drupal_execute
In-Reply-To: <401b53480903061601i9732e21rb2c5874a54f01208@mail.gmail.com>
References: <200903061207.39047.matze999@gmx.net>
	<200903061659.06099.matze999@gmx.net>
	<401b53480903061601i9732e21rb2c5874a54f01208@mail.gmail.com>
Message-ID: <200903061712.34271.matze999@gmx.net>

sorry for getting on the wrong list ...

won't happen again,
matt

On Friday 06 March 2009, Frederik Grunta wrote:
> Hey Matt,
>
> This list is for Drupal core development, so you're better off posting on
> the support forums on drupal.org, or heading to the irc chanel
> #drupal-support on freenode.net.
>
> Cheers,
>
> Frederik
>
> 2009/3/6 Matt Funk <matze999 at gmx.net>
>
> > mmhh,
> >
> > well, to answer my own question, i guess i had to do a
> > include_once(drupal_get_path('module', 'uc_attribute').
> > '/uc_attribute.admin.inc');
> >
> > in the module file in order to have access to that form. It looks like it
> > works now.
> >
> >
> > Anyway,
> > is it better to post stuff on drupal.org than on this list?
> >
> > thanks
> > matt
> >
> > On Friday 06 March 2009, Matt Funk wrote:
> > > Hi,
> > >
> > > i am pretty new at developing stuff in Drupal. So this question is
> >
> > probably
> >
> > > an easy one to answer, but i am still new enough that i don't even
> > > really know where to look to start the debugging process. And i am
> > > hoping this
> >
> > is
> >
> > > the correct list to post to.
> > >
> > > Anyway, here's the question:
> > >
> > > I am simply trying to programmatically create an attribute for ubercart
> > > (ver2). As far as i can tell drupal_execute seems the easiest (and
> > > intended?) way to do this.
> > >
> > > So i create my $form_state array etc...
> > > Then $form_id = 'uc_attribute_form';
> > >
> > > When i put that into the module and the menu callback is executed i
> > > get:
> > >
> > > ...
> > > warning: call_user_func_array() [function.call-user-func-array]: First
> > > argument is expected to be a valid callback, 'uc_attribute_form' was
> >
> > given
> >
> > > in /home/content/x/p/d/xpdtek/html/drupal-6.10/includes/form.inc on
> > > line 366. ...
> > >
> > > So apparently i am not quite getting something here. My first guess is
> >
> > that
> >
> > > the form_id is wrong. But uc_attributes is enabled and from what i can
> >
> > tell
> >
> > > the form that lets me manually create an attribute is called
> > > uc_attribute_form (located in uc_attribute/uc_attribute.admin.inc).
> > >
> > >
> > > Can anyone shed some light on this for me ...
> > >
> > >
> > > thanks
> > > matt



From news at unleashedmind.com  Sat Mar  7 00:18:57 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Sat, 7 Mar 2009 01:18:57 +0100
Subject: [development] a (probably) simple question w.r.t. drupal_execute
In-Reply-To: <401b53480903061601i9732e21rb2c5874a54f01208@mail.gmail.com>
Message-ID: <026001c99eba$4edcd210$0200a8c0@structworks.com>

> This list is for Drupal core development...
> 
> Frederik

Wow.  False assumption.  This list is about Drupal development, not limited
to Drupal core.

sun


From merlin at logrus.com  Sat Mar  7 03:10:01 2009
From: merlin at logrus.com (Earl Miles)
Date: Fri, 06 Mar 2009 19:10:01 -0800
Subject: [development] How to port modules? was: Drupal 7 "When
	it's	Ready"
In-Reply-To: <c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<49AF0D72.8020207@killesreiter.de>	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>	<20090305100851.6e6ef58b@dawn.webthatworks.it>	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>	<49B0A52D.6080207@logrus.com>
	<c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
Message-ID: <49B1E589.1030708@logrus.com>

Paolo Mainardi wrote:
>
>
> On Fri, Mar 6, 2009 at 5:23 AM, Earl Miles <merlin at logrus.com 
> <mailto:merlin at logrus.com>> wrote:
> nd
>
> A good API could change the implementation without changing the 
> signatures, they not are strictly related, it's not the only practices 
> to do the things.
>
> How is related from the data storage and API ? At API level, we don't 
> do any assumption on how data is stored or how is the internal 
> implementation, these are things to a lower (not API) level.
>
> I think could be possible to write a sort of more abstract general API 
> on top of existent for expose a bunch of general "services" with 
> Drupal versions compatilibity in mind. Could be a plugin.
I'm sorry, you just told me that I'm wrong.

Which is it:

a) You believe I don't know what I'm talking about.
b) You believe I am lying.

Seriously. This is NOT just about function signatures. Drupal's API is 
not just a set of functions. It's about events, timing, and it is about 
data storage. You can *say* until you're blue in the face that these 
things are not true, but that will not make you right.

I frankly find it distressing that people who say how easy it would be 
to have a backward compatibility API are people who clearly don't 
actually understand the codebase.

From cxjohnson at gmail.com  Sat Mar  7 04:07:29 2009
From: cxjohnson at gmail.com (Chris Johnson)
Date: Fri, 6 Mar 2009 23:07:29 -0500
Subject: [development] a (probably) simple question w.r.t. drupal_execute
In-Reply-To: <026001c99eba$4edcd210$0200a8c0@structworks.com>
References: <401b53480903061601i9732e21rb2c5874a54f01208@mail.gmail.com>
	<026001c99eba$4edcd210$0200a8c0@structworks.com>
Message-ID: <9ea8d6030903062007r3ca332b0m2c7f0f22d8e1f475@mail.gmail.com>

Matt,

This list was the right place for your question.  It is not limited to
core-only development discussion.

..chris

On Fri, Mar 6, 2009 at 7:18 PM, Daniel F. Kudwien
<news at unleashedmind.com> wrote:
>> This list is for Drupal core development...
>>
>> Frederik

From karoly at negyesi.net  Sat Mar  7 05:07:25 2009
From: karoly at negyesi.net (Karoly Negyesi)
Date: Sat, 07 Mar 2009 06:07:25 +0100 (CET)
Subject: [development] How to port modules? was: Drupal 7 "When it's
 Ready"
In-Reply-To: <49B1E589.1030708@logrus.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>
	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>
	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>
	<49B0A52D.6080207@logrus.com>
	<c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
	<49B1E589.1030708@logrus.com>
Message-ID: <E1Lfokv-0006yp-TS@fenris.runbox.com>

There are UNSTABLE tags for HEAD. Angie announces them here regularly so if you are using this list then you know about them. Check one out, port a module. No need to chase HEAD. By the time the code freeze comes, we can port drupal.org to D7 if this happens, write the missing tests and release in two months. We just need people not to waste their and others time on this list but crack open the editor and get coding. There are countless advantages to this even if you need to do a bit of work to port from UNSTABLE-5 to the next version, if you need arguments, just read the original issue. http://drupal.org/node/190901

Best

Karoly 'chx' Negyesi

From dmitrig01 at gmail.com  Sat Mar  7 05:37:33 2009
From: dmitrig01 at gmail.com (Dmitri Gaskin)
Date: Sat, 7 Mar 2009 00:37:33 -0500
Subject: [development] Drupalcon tag for issues
Message-ID: <AEF8AB1D-2596-40D2-804B-73194A59879D@gmail.com>

Let's tag all code sprint issues "dc2009 code sprint"

Thanks

Dmitri

From Matt at NinjitsuWeb.com  Sat Mar  7 05:39:11 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Sat, 07 Mar 2009 00:39:11 -0500
Subject: [development] How to port modules? was: Drupal 7
	"When	it's	Ready"
In-Reply-To: <49B1E589.1030708@logrus.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>	<49AF0D72.8020207@killesreiter.de>	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>	<20090305100851.6e6ef58b@dawn.webthatworks.it>	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>	<49B0A52D.6080207@logrus.com>	<c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
	<49B1E589.1030708@logrus.com>
Message-ID: <49B2087F.5000702@NinjitsuWeb.com>

Paolo Mainardi wrote:
>
> I think could be possible to write a sort of more abstract general API 
> on top of existent for expose a bunch of general "services" with 
> Drupal versions compatilibity in mind. Could be a plugin. 

Earl Miles wrote:
>
> I frankly find it distressing that people who say how easy it would be 
> to have a backward compatibility API are people who clearly don't 
> actually understand the codebase.

Ah, the idealism of youth, and the bitter wisdom of experience. :-)

I remember making the same arguments as Paolo with people who are much 
smarter than me. Then I actually started writing and upgrading modules. 
I now know it's much easier the just upgrade the modules I actually use 
in the real world than to dream about a theoretical compatability layer 
for the benefit of the 3,950 modules I'll never need. (But it's easier 
still to complain and avoid real work altogether, believe me, I know.)

Could Core Developer do more to make module upgrades easier for the rest 
of us? In theory, yes, but I'd rather they spent their time using their 
superior brain power to make Drupal more awesome. The rest of us can 
easily enough follow their excellent instructions for upgrading our 
modules, which are practically paint-by-numbers easy. We also get a 
leaner code base. It's a win-win.

Drupal is moving in a direction or more and more abstraction (DB:TNG), 
so I predict that it will get easier and easier to upgrade modules over 
time. It's not like Earl and Karoly and the gang want it to be hard. 
Even now, I've 'upgraded' a couple modules from 5 to 6 with only one or 
two lines of code changed. How much more can you ask for?

That said, Paolo, if you see a particular function change which could 
done in an equally effective way, while preserving compatibility, I'm 
sure a patch would be considered. The issue queue is open to everyone.

Best,

Matt





From mail at webthatworks.it  Sat Mar  7 09:49:47 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Sat, 7 Mar 2009 10:49:47 +0100
Subject: [development] feeds for docs? and "developers" group?
Message-ID: <20090307104947.56a5557d@dawn.webthatworks.it>

Reading the "When it's Ready" thread I've just learned 2 important
things:
- there is an automatic tool to help porting modules (deadwood)
- now there are good docs about SimpleTest

Sometimes I look into discussions or docs or "groups" to see how to
best deal with cvs when you use another tool internally, how to
setup multisite, if there is anything new about DB API I could
exploit etc...
Sometimes the docs get stale, outdated or it just don't solve my
problem.

a) it would be nice if dev could be kept updated on changes to
specific sections of docs.
b) is there a place to discuss about how to become better drupal
developers? techniques, tools etc...

Every time I learn something from a ml that could be useful to
others or I may "forget" I've the habit to take notes on my (oh!)
drupal website.
If there was a place where to discuss how to become better drupal
developers (and maybe there is such a place) I think the
documentation would be even larger and maybe some recurring topics
would be less frequent.


The dev list most frequent use seems to be:
- core announcements and strategies
- how do I program this?

but not: how do I become a better drupal dev?

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


From fgrunta at gmail.com  Sat Mar  7 10:23:32 2009
From: fgrunta at gmail.com (Frederik Grunta)
Date: Sat, 7 Mar 2009 10:23:32 +0000
Subject: [development] a (probably) simple question w.r.t. drupal_execute
In-Reply-To: <026001c99eba$4edcd210$0200a8c0@structworks.com>
References: <401b53480903061601i9732e21rb2c5874a54f01208@mail.gmail.com>
	<026001c99eba$4edcd210$0200a8c0@structworks.com>
Message-ID: <401b53480903070223r504cbb63lfd635d7dded5000d@mail.gmail.com>

Whoops. Sorry Matt.

2009/3/7 Daniel F. Kudwien <news at unleashedmind.com>

> > This list is for Drupal core development...
> >
> > Frederik
>
> Wow.  False assumption.  This list is about Drupal development, not limited
> to Drupal core.
>
> sun
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090307/9ec4559b/attachment.htm 

From sivaji2009 at gmail.com  Sat Mar  7 11:44:57 2009
From: sivaji2009 at gmail.com (sivaji j.g)
Date: Sat, 7 Mar 2009 17:14:57 +0530
Subject: [development] How to clear database after a regular interval
Message-ID: <fce946780903070344l3d0b52a4v23e416c1ba061ec4@mail.gmail.com>

Hello geeks,

Most of the drupal modules has test site programmed to clear database after
a regular interval, i would like to know how it works. I want to do the same
for drupal quiz module demo site, The demo site has been hosted at bluehost
which has cpanel where i have options to write my own cron and run it, but i
have no idea on how to use it for this purpose.  Any suggestions and
criticisms regarding this will be appreciated.

-- 
Thanks a lot
-----------------------------------------
http://ubuntuslave.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090307/7dd51ebf/attachment-0001.htm 

From robrechtj+drupal at gmail.com  Sat Mar  7 11:52:59 2009
From: robrechtj+drupal at gmail.com (Robrecht Jacques)
Date: Sat, 7 Mar 2009 12:52:59 +0100
Subject: [development] How to clear database after a regular interval
In-Reply-To: <fce946780903070344l3d0b52a4v23e416c1ba061ec4@mail.gmail.com>
References: <fce946780903070344l3d0b52a4v23e416c1ba061ec4@mail.gmail.com>
Message-ID: <b31486840903070352o46b23099w313b459c267c5289@mail.gmail.com>

Write a module that implements hook_cron().

2009/3/7 sivaji j.g <sivaji2009 at gmail.com>

> Hello geeks,
>
> Most of the drupal modules has test site programmed to clear database after
> a regular interval, i would like to know how it works. I want to do the same
> for drupal quiz module demo site, The demo site has been hosted at bluehost
> which has cpanel where i have options to write my own cron and run it, but i
> have no idea on how to use it for this purpose.  Any suggestions and
> criticisms regarding this will be appreciated.
>
> --
> Thanks a lot
> -----------------------------------------
> http://ubuntuslave.blogspot.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090307/35ce3843/attachment.htm 

From winborn at advomatic.com  Sat Mar  7 13:44:05 2009
From: winborn at advomatic.com (Aaron Winborn)
Date: Sat, 7 Mar 2009 08:44:05 -0500 (EST)
Subject: [development] a (probably) simple question w.r.t. drupal_execute
In-Reply-To: <14865610.271031236433402770.JavaMail.root@zimbra>
Message-ID: <21292755.271051236433445851.JavaMail.root@zimbra>

Matt,

You could also use module_load_include('inc', 'uc_attribute', 'uc_attribute.admin');

Aaron

----- Original Message -----
From: "Matt Funk" <matze999 at gmx.net>
To: development at drupal.org
Sent: Friday, March 6, 2009 6:59:05 PM GMT -05:00 US/Canada Eastern
Subject: Re: [development] a (probably) simple question w.r.t. drupal_execute

mmhh,

well, to answer my own question, i guess i had to do a 
include_once(drupal_get_path('module', 'uc_attribute'). '/uc_attribute.admin.inc');

in the module file in order to have access to that form. It looks like it 
works now.


Anyway, 
is it better to post stuff on drupal.org than on this list?

thanks
matt

On Friday 06 March 2009, Matt Funk wrote:
> Hi,
>
> i am pretty new at developing stuff in Drupal. So this question is probably
> an easy one to answer, but i am still new enough that i don't even really
> know where to look to start the debugging process. And i am hoping this is
> the correct list to post to.
>
> Anyway, here's the question:
>
> I am simply trying to programmatically create an attribute for ubercart
> (ver2). As far as i can tell drupal_execute seems the easiest (and
> intended?) way to do this.
>
> So i create my $form_state array etc...
> Then $form_id = 'uc_attribute_form';
>
> When i put that into the module and the menu callback is executed i get:
>
> ...
> warning: call_user_func_array() [function.call-user-func-array]: First
> argument is expected to be a valid callback, 'uc_attribute_form' was given
> in /home/content/x/p/d/xpdtek/html/drupal-6.10/includes/form.inc on line
> 366. ...
>
> So apparently i am not quite getting something here. My first guess is that
> the form_id is wrong. But uc_attributes is enabled and from what i can tell
> the form that lets me manually create an attribute is called
> uc_attribute_form (located in uc_attribute/uc_attribute.admin.inc).
>
>
> Can anyone shed some light on this for me ...
>
>
> thanks
> matt



From hovercrafter at earthlink.net  Sat Mar  7 14:18:04 2009
From: hovercrafter at earthlink.net (Jamie Holly)
Date: Sat, 07 Mar 2009 09:18:04 -0500
Subject: [development] How to clear database after a regular interval
In-Reply-To: <fce946780903070344l3d0b52a4v23e416c1ba061ec4@mail.gmail.com>
References: <fce946780903070344l3d0b52a4v23e416c1ba061ec4@mail.gmail.com>
Message-ID: <49B2821C.4060507@earthlink.net>

Use the demo module:

http://drupal.org/project/demo

Jamie Holly
http://www.intoxination.net 
http://www.hollyit.net



sivaji j.g wrote:
> Hello geeks,
>
> Most of the drupal modules has test site programmed to clear database 
> after a regular interval, i would like to know how it works. I want to 
> do the same for drupal quiz module demo site, The demo site has been 
> hosted at bluehost which has cpanel where i have options to write my 
> own cron and run it, but i have no idea on how to use it for this 
> purpose.  Any suggestions and criticisms regarding this will be 
> appreciated.
>
> -- 
> Thanks a lot
> -----------------------------------------
> http://ubuntuslave.blogspot.com/
>

From dmitrig01 at gmail.com  Sat Mar  7 15:19:26 2009
From: dmitrig01 at gmail.com (Dmitri Gaskin)
Date: Sat, 7 Mar 2009 10:19:26 -0500
Subject: [development] feeds for docs? and "developers" group?
In-Reply-To: <20090307104947.56a5557d@dawn.webthatworks.it>
References: <20090307104947.56a5557d@dawn.webthatworks.it>
Message-ID: <9694E918-4CE2-4401-AC59-B394B3834A40@gmail.com>

Use the documentation mailing list.

Dmitri

On Mar 7, 2009, at 4:49 AM, Ivan Sergio Borgonovo wrote:

> Reading the "When it's Ready" thread I've just learned 2 important
> things:
> - there is an automatic tool to help porting modules (deadwood)
> - now there are good docs about SimpleTest
>
> Sometimes I look into discussions or docs or "groups" to see how to
> best deal with cvs when you use another tool internally, how to
> setup multisite, if there is anything new about DB API I could
> exploit etc...
> Sometimes the docs get stale, outdated or it just don't solve my
> problem.
>
> a) it would be nice if dev could be kept updated on changes to
> specific sections of docs.
> b) is there a place to discuss about how to become better drupal
> developers? techniques, tools etc...
>
> Every time I learn something from a ml that could be useful to
> others or I may "forget" I've the habit to take notes on my (oh!)
> drupal website.
> If there was a place where to discuss how to become better drupal
> developers (and maybe there is such a place) I think the
> documentation would be even larger and maybe some recurring topics
> would be less frequent.
>
>
> The dev list most frequent use seems to be:
> - core announcements and strategies
> - how do I program this?
>
> but not: how do I become a better drupal dev?
>
> -- 
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
>


From cxjohnson at gmail.com  Sat Mar  7 17:01:40 2009
From: cxjohnson at gmail.com (Chris Johnson)
Date: Sat, 7 Mar 2009 12:01:40 -0500
Subject: [development] How to port modules? was: Drupal 7 "When it's
	Ready"
In-Reply-To: <49B2087F.5000702@NinjitsuWeb.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>
	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>
	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>
	<49B0A52D.6080207@logrus.com>
	<c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
	<49B1E589.1030708@logrus.com> <49B2087F.5000702@NinjitsuWeb.com>
Message-ID: <9ea8d6030903070901q5f8fa372i8c166750059b184d@mail.gmail.com>

Not to criticize or insult anyone, but more to address a perhaps
common fallacy:  core developers are not necessarily "smarter" than
the rest.  There are some really smart people out there, both core and
non-core developers, and even just non-developers.

What makes core developers who they are is a combination of things.
Having "superior brain power" doesn't hurt.  But it includes
dedication, ability to spend more time on the project, desire,
demonstrated contribution, sometimes history, some luck, and no doubt
more than a few other things.

Thomas Edison said:  "Genius is one percent inspiration and
ninety-nine percent perspiration."  I think that applies here.

Just to reiterate -- I respect the "brain power" of all core
developers -- in fact, of all contributors.  Don't be intimidated into
not contributing.

..chris

On Sat, Mar 7, 2009 at 12:39 AM, Matt Chapman

> Could Core Developer do more to make module upgrades easier for the rest of
> us? In theory, yes, but I'd rather they spent their time using their
> superior brain power to make Drupal more awesome. The rest of us can easily
> enough follow their excellent instructions for upgrading our modules, which
> are practically paint-by-numbers easy. We also get a leaner code base. It's
> a win-win.

From mail at webthatworks.it  Sat Mar  7 18:31:41 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Sat, 7 Mar 2009 19:31:41 +0100
Subject: [development] feeds for docs? and "developers" group?
In-Reply-To: <9694E918-4CE2-4401-AC59-B394B3834A40@gmail.com>
References: <20090307104947.56a5557d@dawn.webthatworks.it>
	<9694E918-4CE2-4401-AC59-B394B3834A40@gmail.com>
Message-ID: <20090307193141.06b6ca3f@dawn.webthatworks.it>

On Sat, 7 Mar 2009 10:19:26 -0500
Dmitri Gaskin <dmitrig01 at gmail.com> wrote:

> Use the documentation mailing list.

I just gave a look to the archives and it looks like a place for
contributors to doc rather than users of the docs.

What about a place where developers could discuss about techniques,
programming environment, management of drupal?

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


From arancaytar.ilyaran at gmail.com  Sat Mar  7 18:55:02 2009
From: arancaytar.ilyaran at gmail.com (Arancaytar Ilyaran)
Date: Sat, 07 Mar 2009 19:55:02 +0100
Subject: [development] How to clear database after a regular interval
In-Reply-To: <b31486840903070352o46b23099w313b459c267c5289@mail.gmail.com>
References: <fce946780903070344l3d0b52a4v23e416c1ba061ec4@mail.gmail.com>
	<b31486840903070352o46b23099w313b459c267c5289@mail.gmail.com>
Message-ID: <49B2C306.6030409@gmail.com>

Depends on what exactly you want to clear. If you just need to empty the
user/node tables or reset the site theme, it's fairly straight-forward - just
put a few "DELETE" statements in the hook_cron implementation.

Re-installing the entire site would be tricky to do via a module inside the site
itself ("cutting off the branch you're sitting on"). In that case, you would be
better served by a batch script started by a separate cron-job outside the
Drupal site.

Robrecht Jacques wrote:
> Write a module that implements hook_cron().
> 
> 2009/3/7 sivaji j.g <sivaji2009 at gmail.com <mailto:sivaji2009 at gmail.com>>
> 
>     Hello geeks,
> 
>     Most of the drupal modules has test site programmed to clear
>     database after a regular interval, i would like to know how it
>     works. I want to do the same for drupal quiz module demo site, The
>     demo site has been hosted at bluehost which has cpanel where i have
>     options to write my own cron and run it, but i have no idea on how
>     to use it for this purpose.  Any suggestions and criticisms
>     regarding this will be appreciated.
> 
>     -- 
>     Thanks a lot
>     -----------------------------------------
>     http://ubuntuslave.blogspot.com/
> 
> 


-- 
eternity lies ahead of us, and behind.
have you drunk your fill?
         * * *
PGP:   http://ermarian.net/downloads/0x27CA5C74
XMPP:  arancaytar.ilyaran at gmail.com
AOL:   282026638 @icq / RealArancaytar @aim
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/20090307/47805143/attachment.pgp 

From kb at 2bits.com  Sat Mar  7 19:01:50 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Sat, 7 Mar 2009 14:01:50 -0500
Subject: [development] How to clear database after a regular interval
In-Reply-To: <49B2C306.6030409@gmail.com>
References: <fce946780903070344l3d0b52a4v23e416c1ba061ec4@mail.gmail.com>
	<b31486840903070352o46b23099w313b459c267c5289@mail.gmail.com>
	<49B2C306.6030409@gmail.com>
Message-ID: <4a9fdc630903071101l70723373y85e03ef8e5d326d0@mail.gmail.com>

On Sat, Mar 7, 2009 at 1:55 PM, Arancaytar Ilyaran <
arancaytar.ilyaran at gmail.com> wrote:

> Depends on what exactly you want to clear. If you just need to empty the
> user/node tables or reset the site theme, it's fairly straight-forward -
> just
> put a few "DELETE" statements in the hook_cron implementation.
>

If you take this approach, and you use MySQL like most Drupal sites do, then
use TRUNCATE on the tables. It is much faster and less resource intensive.
Would not matter if you only have a small amount of data, but will matter
for larger amounts.


>
> Re-installing the entire site would be tricky to do via a module inside the
> site
> itself ("cutting off the branch you're sitting on"). In that case, you
> would be
> better served by a batch script started by a separate cron-job outside the
> Drupal site.
>
> Robrecht Jacques wrote:
> > Write a module that implements hook_cron().
> >
> > 2009/3/7 sivaji j.g <sivaji2009 at gmail.com <mailto:sivaji2009 at gmail.com>>
> >
> >     Hello geeks,
> >
> >     Most of the drupal modules has test site programmed to clear
> >     database after a regular interval, i would like to know how it
> >     works. I want to do the same for drupal quiz module demo site, The
> >     demo site has been hosted at bluehost which has cpanel where i have
> >     options to write my own cron and run it, but i have no idea on how
> >     to use it for this purpose.  Any suggestions and criticisms
> >     regarding this will be appreciated.
> >
> >     --
> >     Thanks a lot
> >     -----------------------------------------
> >     http://ubuntuslave.blogspot.com/
> >
> >
>
>
> --
> eternity lies ahead of us, and behind.
> have you drunk your fill?
>         * * *
> PGP:   http://ermarian.net/downloads/0x27CA5C74
> XMPP:  arancaytar.ilyaran at gmail.com
> AOL:   282026638 @icq / RealArancaytar @aim
> URL:   http://ermarian.net
>
>


-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090307/331401e2/attachment-0001.htm 

From news at unleashedmind.com  Sat Mar  7 19:40:10 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Sat, 7 Mar 2009 20:40:10 +0100
Subject: [development] How to clear database after a regular interval
In-Reply-To: <49B2C306.6030409@gmail.com>
Message-ID: <030701c99f5c$86fb17e0$0200a8c0@structworks.com>

> Re-installing the entire site would be tricky to do via a 
> module inside the site itself ("cutting off the branch you're 
> sitting on"). In that case, you would be better served by a 
> batch script started by a separate cron-job outside the Drupal site.

This is exactly what Demo module (http://drupal.org/project/demo) does.

1) Install the module.

2) Create a snapshot of your clean demo site.

3) Configure the reset interval and setup cron (see http://drupal.org/cron).

   - and/or -

   Enable the "Reset site" block, which allows users to reset the site manually.

4) Profit.


Demo module is also a great way to

- take arbitrary snapshots during site building and development (for testing potential modules to install, re-configuration, automated processes, data imports, safety backups before running update.php, etc) or

- test module update paths (from 6.x-1.x to 6.x-2.x) or

- even test entire upgrade paths (5.x to 6.x).


Rob Loach even went ahead and created a Demo installation profile (http://drupal.org/project/demo_profile), which may be an alternative to regular installation profiles in certain use-cases.

sun


From mpartap at gmx.net  Sun Mar  8 02:03:09 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Sun, 08 Mar 2009 03:03:09 +0100
Subject: [development] D7 contrib module development
Message-ID: <49B3275D.8020109@gmx.net>

Hi fellow drupal devs,
wanted to bring up a few points about module development for some time 
and i guess now that module development happens to be the hot topic of 
the day would be a good time..
While D6 is proving to be a great success and through contrib modules 
can be flexibly expanded to almost unlimited use case customizations, 
working with a whole bunch of modules on our site my experience is 
that quantity is not necessarily a good compensation for quality. 
Several problems just keep coming up:
- modules spamming the watchdog table with E_ALL warnings
- modules ignoring the style/documentation guide lines
- applied insane programming(TM) techniques
- undescriptive module names
but by far the most serious one is
- duplication (partial feature overlap with existing modules).
There might be different perspectives on this but IMHO specifically 
for D7 this is not a good way to go. An example for this mess is the 
huge number of competing notification/subscription modules for D6 - 
each with a destinct feature set and of course incompatible to all 
others. While competition is a good thing, certainly having multiple 
similar D5 modules live on and slowly creep up the version ladder 
while fighting for the same 'market share' is hindering real progress 
(=feature innovation, code sanity and API excellence) more than it is 
promoting it.

If we want D7 to become *THE* perfect open source CMS, maybe a change 
in the module development process can help guaranteeing a higher level 
of code quality. One possible option could be to go some steps towards 
the linux model, in which all patches have to be signed off by a small 
team of core developers. Drupal would not have to choose an official 
team of reviewers though - patches could be confirmed by a simple 
voting system, in combination with the already working automatic 
testing. The issue tracking system could be optimized for 
reviewing/auto testing/auto committing patches (more code centric).

However the specific details: the point of that change would be to 
shift responsibility (=power) from individual module creators to the 
coding swarm of contributors. This would significantly lower the odds 
of b(rainde)ad code getting in and hopefully drastically cut down on 
duplication.

Especially because of the to-be-expected great API changes in D7 and 
the resulting amount of code rewriting that has to be done, wouldn't 
it be a great point in time to get our act together and come up with a 
single bind-them-all notification framework? _One_ cleverly designed 
poll/decision extension? Merging/standardizing the various e-payment 
modules? Imho taking this direction in the long run will result in 
more coherent code and enable easier adaption to core API changes, 
also cutting down on user confusion - furthermore increasing overall 
D7 r0xorn3ss!
What's your view on this?

regards,
marcel.


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mathews.kyle at gmail.com  Sun Mar  8 02:29:07 2009
From: mathews.kyle at gmail.com (Kyle Mathews)
Date: Sat, 7 Mar 2009 21:29:07 -0500
Subject: [development] D7 contrib module development
In-Reply-To: <49B3275D.8020109@gmx.net>
References: <49B3275D.8020109@gmx.net>
Message-ID: <efeed12d0903071829n13b940bbt61769fd313fadab7@mail.gmail.com>

RE following the linux model -- we already are. Linux has one "kernel" and
how ever many applications built on top it that there are individuals
interested enough to write one. We follow the exact same model -- Drupal's
kernel (the core) has two committers and a core group of individuals who
either maintain subsections of our "kernel" or know enough about core
development to "sign off" on patches before they're added to core.

But in the Linux application space it's a wild wild west as far as quality
standards go. There are many Linux applications of very high quality
maintained by companies or dedicated individuals but again there's scads of
poorly coded, poorly maintained duplicating applications available for
Linux.

As Drupal matures, so will the contributed modules space. Already more
important modules like Views see significant commercial support and have
code quality standards as high as core.

I think forcing all contrib code to go through a central space is a really
bad idea because a) it doesn't scale -- who wants to spend time reviewing
someone's weekend hacking project? and b) it'd unfairly kill ugly baby
modules which might mature into something significant. Innovation isn't
"perfect" at the start.

Kyle

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


On Sat, Mar 7, 2009 at 9:03 PM, Marcel Partap <mpartap at gmx.net> wrote:

> Hi fellow drupal devs,
> wanted to bring up a few points about module development for some time and
> i guess now that module development happens to be the hot topic of the day
> would be a good time..
> While D6 is proving to be a great success and through contrib modules can
> be flexibly expanded to almost unlimited use case customizations, working
> with a whole bunch of modules on our site my experience is that quantity is
> not necessarily a good compensation for quality. Several problems just keep
> coming up:
> - modules spamming the watchdog table with E_ALL warnings
> - modules ignoring the style/documentation guide lines
> - applied insane programming(TM) techniques
> - undescriptive module names
> but by far the most serious one is
> - duplication (partial feature overlap with existing modules).
> There might be different perspectives on this but IMHO specifically for D7
> this is not a good way to go. An example for this mess is the huge number of
> competing notification/subscription modules for D6 - each with a destinct
> feature set and of course incompatible to all others. While competition is a
> good thing, certainly having multiple similar D5 modules live on and slowly
> creep up the version ladder while fighting for the same 'market share' is
> hindering real progress (=feature innovation, code sanity and API
> excellence) more than it is promoting it.
>
> If we want D7 to become *THE* perfect open source CMS, maybe a change in
> the module development process can help guaranteeing a higher level of code
> quality. One possible option could be to go some steps towards the linux
> model, in which all patches have to be signed off by a small team of core
> developers. Drupal would not have to choose an official team of reviewers
> though - patches could be confirmed by a simple voting system, in
> combination with the already working automatic testing. The issue tracking
> system could be optimized for reviewing/auto testing/auto committing patches
> (more code centric).
>
> However the specific details: the point of that change would be to shift
> responsibility (=power) from individual module creators to the coding swarm
> of contributors. This would significantly lower the odds of b(rainde)ad code
> getting in and hopefully drastically cut down on duplication.
>
> Especially because of the to-be-expected great API changes in D7 and the
> resulting amount of code rewriting that has to be done, wouldn't it be a
> great point in time to get our act together and come up with a single
> bind-them-all notification framework? _One_ cleverly designed poll/decision
> extension? Merging/standardizing the various e-payment modules? Imho taking
> this direction in the long run will result in more coherent code and enable
> easier adaption to core API changes, also cutting down on user confusion -
> furthermore increasing overall D7 r0xorn3ss!
> What's your view on this?
>
> regards,
> marcel.
>
>
> --
>  "Obstacles are those frightful things you see when you take
>  your eyes off your goal."         -- Henry Ford (1863-1947)
>
>  Change the world! Vote: http://hfopi.org/vote-future
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090307/30042a82/attachment.htm 

From news at unleashedmind.com  Sun Mar  8 02:57:30 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Sun, 8 Mar 2009 03:57:30 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <49B3275D.8020109@gmx.net>
Message-ID: <033c01c99f99$9f44f900$0200a8c0@structworks.com>

> Several problems just keep coming up:
> - modules spamming the watchdog table with E_ALL warnings
> - modules ignoring the style/documentation guide lines
> - applied insane programming(TM) techniques

Go ahead and create patches for those modules.  That's the only way to fix
'em.

> but by far the most serious one is
> - duplication (partial feature overlap with existing modules).

Bad habit of module authors.  Slap them, but create a patch to remove what
has been duplicated afterwards.

> There might be different perspectives on this but IMHO 
> specifically for D7 this is not a good way to go. An example 
> for this mess is the huge number of competing 
> notification/subscription modules for D6 - each with a 
> destinct feature set and of course incompatible to all 
> others.

The reason for that is that someone thought he/she could write something
better, wrote it, and ended up with something that already exists.  From
then on, happy developers continued to improve the pre-existing thingy,
while some others installed the duplicated thingy and advanced on that.  The
end result is: two parties that think either approach is wrong and a massive
croud of users that thinks "And this is why Drupal sucks.(tm)"

Removing the duplication requires that those module maintainers (finally)
come to that conclusion.

> One possible 
> option could be to go some steps towards the linux model, in 
> which all patches have to be signed off by a small team of 
> core developers.

Core developers are already buried with core development.  Take a look at
issue queues of "sub-core" modules like Views and you'll understand that
each project needs its own code-guards.

> Drupal would not have to choose an official 
> team of reviewers though - patches could be confirmed by a 
> simple voting system, in combination with the already working 
> automatic testing. The issue tracking system could be 
> optimized for reviewing/auto testing/auto committing patches 
> (more code centric).

Machines can not (yet) replace the complex thoughts and decisions of a
human.  If a patch passes some (human-created) tests, that only means a) it
passed an expected behavior (which still can be wrong or outdated) and b) it
passed coding-style tests (if there were some) - but there still has to be a
gate-keeper who tells you about logic errors and the future of Drupal.

> However the specific details: the point of that change would 
> be to shift responsibility (=power) from individual module 
> creators to the coding swarm of contributors. This would 
> significantly lower the odds of b(rainde)ad code getting in 
> and hopefully drastically cut down on duplication.

False assumption: Duplication is caused by braindead code.  Also by
developers who a) are unable to search or b) really want to get another
project on their list to raise their ego.  Cooperation and collaboration
with maintainers of existing projects is the key (which still requires that
you are competent enough to search).

> Especially because of the to-be-expected great API changes in 
> D7 and the resulting amount of code rewriting that has to be 
> done, wouldn't it be a great point in time to get our act 
> together and come up with a single bind-them-all notification 
> framework? _One_ cleverly designed poll/decision extension? 
> Merging/standardizing the various e-payment modules? Imho 
> taking this direction in the long run will result in more 
> coherent code and enable easier adaption to core API changes, 
> also cutting down on user confusion - furthermore increasing overall
> D7 r0xorn3ss!

This mostly depends on the maintainers of those modules.  Because if you
would want to remove the duplication you would have to create yet another
duplicated project.

> What's your view on this?

Somebody circle stomp those developers.

sun


From mpartap at gmx.net  Sun Mar  8 02:58:55 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Sun, 08 Mar 2009 03:58:55 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <efeed12d0903071829n13b940bbt61769fd313fadab7@mail.gmail.com>
References: <49B3275D.8020109@gmx.net>
	<efeed12d0903071829n13b940bbt61769fd313fadab7@mail.gmail.com>
Message-ID: <49B3346F.40008@gmx.net>

On 08/03/09 03:29, Kyle Mathews wrote:
> RE following the linux model -- we already are. Linux has one
> "kernel" and how ever many applications built on top it that there
>  are individuals interested enough to write one. [...] But in the
> Linux application space it's a wild wild west as far as quality
> standards go.
Seems a bit to me like you intentionally misunderstood my analogy ;D
The comparison i was (not even) trying to make is linux core kernel
and optional modules versus Drupal core and contrib.

> As Drupal matures, so will the contributed modules space.
Even though you are trying hard, i am not talking names (of modules
which contain code that just scares me).

> Already more important modules like Views see significant
> commercial support and have code quality standards as high as
> core.
Well so these modules are not the problem. But what about that
notification modules mess?

> I think forcing all contrib code to go through a central space is a
> really bad idea because a) it doesn't scale
May i guess that you never been subscribed to the wine-patches mailing
list? Granted the project's scope is very different, but a huge amount
of code diffs is flowing through that channel everyday - and with
designated nested folders in my thunderbird i find it highly
manageable to skim through code i'm interested in.. speaking of which
maybe a drupal-patches mailing list synchronized with an automatic
patch tracker wouldn't be a bad way to handle this..

> who wants to spend time reviewing someone's weekend hacking
> project?
That's the point. Someone's weekend hacking project just doesn't
belong in the d.o repository if the quality is not sufficient, period
(imho *g).


> and b) it'd unfairly kill ugly baby modules which might mature into
> something significant.
Well those ugly baby modules then simply need to be rewritten for D7
to push the code to a higher level of quality. This is not about
social fairness. This is about software that has to reliably work for
millions of people. _And_ be fast at it.
> Innovation isn't "perfect" at the start.
'Course not - but we had D1-6 for that ain't it?

rgds
marcel.


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From news at unleashedmind.com  Sun Mar  8 03:04:15 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Sun, 8 Mar 2009 04:04:15 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <49B3346F.40008@gmx.net>
Message-ID: <033d01c99f9a$9120b6b0$0200a8c0@structworks.com>

> > Innovation isn't "perfect" at the start.
> 
> 'Course not - but we had D1-6 for that ain't it?

Don't expect too much from D7:
http://buytaert.net/drupal-7-code-freeze-september-1st

My 2 cents.

sun


From mpartap at gmx.net  Sun Mar  8 03:26:19 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Sun, 08 Mar 2009 04:26:19 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <033c01c99f99$9f44f900$0200a8c0@structworks.com>
References: <033c01c99f99$9f44f900$0200a8c0@structworks.com>
Message-ID: <49B33ADB.1020507@gmx.net>

On 08/03/09 03:57, Daniel F. Kudwien wrote:
>>  Several problems just keep coming up:
>>  - modules spamming the watchdog table with E_ALL warnings
>>  - modules ignoring the style/documentation guide lines
>>  - applied insane programming(TM) techniques
> Go ahead and create patches for those modules.  That's the only way to fix
> 'em.
Dude i've been wasting my whole summer on that. Cleaning up afterwards 
is a hell lot of more unrewarding work than preventing the shit from 
hitting the fan.

>>  but by far the most serious one is
>>  - duplication (partial feature overlap with existing modules).
> Bad habit of module authors.  Slap them, but create a patch to remove what
> has been duplicated afterwards.
Yeah like i even have multiple days each day - sorry i simply can not 
fix stuff beyond the needs of my NGO site.
If the development process allows module authors to have bad habits - 
well maybe its not tightly regulated enough.

>>  There might be different perspectives on this but IMHO
>>  specifically for D7 this is not a good way to go. An example
>>  for this mess is the huge number of competing
>>  notification/subscription modules for D6 - each with a
>>  destinct feature set and of course incompatible to all
>>  others.
>
> The reason for that is that someone thought he/she could write something
> better, wrote it, and ended up with something that already exists.  From
> then on, happy developers continued to improve the pre-existing thingy,
> while some others installed the duplicated thingy and advanced on that.  The
> end result is: two parties that think either approach is wrong and a massive
> croud of users that thinks "And this is why Drupal sucks.(tm)"
>
> Removing the duplication requires that those module maintainers (finally)
> come to that conclusion.
That seems far less realistic than setting up a strict regulatory 
bottleneck for every line of official core/contrib D7 code. Take a 
look at how extremely discerning the benevolent dictator of the Wine 
project - Alexandre Julliard - handles the many code submissions from 
wine-patches - and at the resulting quality. There's a reason he skips 
committing 30% of patches.

>>  One possible
>>  option could be to go some steps towards the linux model, in
>>  which all patches have to be signed off by a small team of
>>  core developers.
>
> Core developers are already buried with core development.  Take a look at
> issue queues of "sub-core" modules like Views and you'll understand that
> each project needs its own code-guards.
That very well i know. Maybe we can all improve the process and 
optimize the obligatory set of tools?


>>  Drupal would not have to choose an official
>>  team of reviewers though - patches could be confirmed by a
>>  simple voting system, in combination with the already working
>>  automatic testing. The issue tracking system could be
>>  optimized for reviewing/auto testing/auto committing patches
>>  (more code centric).
> Machines can not (yet) replace the complex thoughts and decisions of a
> human.  If a patch passes some (human-created) tests, that only means a) it
> passed an expected behavior (which still can be wrong or outdated) and b) it
> passed coding-style tests (if there were some) - but there still has to be a
> gate-keeper who tells you about logic errors and the future of Drupal.
Of course not - but if the automated tests pass, AND 10 registered 
Drupal developers okay the patch by voting RTBC - for sure a commit 
bot can take the decision to just do it?
My guess: swarm intelligence + sophisticated tools outperform stressed 
individual core developers.

>>  However the specific details: the point of that change would
>>  be to shift responsibility (=power) from individual module
>>  creators to the coding swarm of contributors. This would
>>  significantly lower the odds of b(rainde)ad code getting in
>>  and hopefully drastically cut down on duplication.
> False assumption: Duplication is caused by braindead code.  Also by
> developers who a) are unable to search or b) really want to get another
> project on their list to raise their ego.  Cooperation and collaboration
> with maintainers of existing projects is the key (which still requires that
> you are competent enough to search).
Well of course it is the key, and the docs have been endorsing it 
since years. In reality.. well uhem http://drupal.org/node/197093 
cough cough..
Ok fine maybe it is more practical to set up an development algorithm 
*for D7* (not D6, everyone can still go bonkers there) that leaves 
less freedom for 'stuff' (communication, decisions) to 'go wrong'.

>>  Especially because of the to-be-expected great API changes in
>>  D7 and the resulting amount of code rewriting that has to be
>>  done, wouldn't it be a great point in time to get our act
>>  together and come up with a single bind-them-all notification
>>  framework? _One_ cleverly designed poll/decision extension?
>>  Merging/standardizing the various e-payment modules? Imho
>>  taking this direction in the long run will result in more
>>  coherent code and enable easier adaption to core API changes,
>>  also cutting down on user confusion - furthermore increasing overall
>>  D7 r0xorn3ss!
> This mostly depends on the maintainers of those modules.  Because if you
> would want to remove the duplication you would have to create yet another
> duplicated project.
You can call it duplication - i'd prefer talking about rewriting and 
merging. Key focus should be on clean design, flexibility and code 
efficiency - just the values that are relevant to D7 core development.

>>  What's your view on this?
> Somebody circle stomp those developers.
Will that make the problem vanish? Or maybe it'll just annihilate 
precious programming talent.. X)


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mike at michaelfbooth.com  Sun Mar  8 04:27:16 2009
From: mike at michaelfbooth.com (Michael F Booth)
Date: Sat, 07 Mar 2009 23:27:16 -0500
Subject: [development] D7 contrib module development
In-Reply-To: <49B3275D.8020109@gmx.net>
References: <49B3275D.8020109@gmx.net>
Message-ID: <1236486436.21565.1304211201@webmail.messagingengine.com>

On Sun, 08 Mar 2009 03:03 +0100, "Marcel Partap" <mpartap at gmx.net>
wrote:

> One possible option could be to go some steps towards 
> the linux model, in which all patches have to be signed off by a small 
> team of core developers. 

Linux is an operating system -- specifically, an eighteen-year-old
elaboration of a thirty-seven-year-old operating system. Wine is
end-user software developed by C programmers (using clean-room
techniques and black-box testing) to match a spec that's defined by a
fourteen-year-old commercial product. And Drupal is a modular software
toolkit for the web, designed to be customized by several different
audiences to suit a multitude of use cases, many of which hadn't been
invented five years ago and some of which are being invented *now*.

Drupal is open source. That's about all it has in common with these
projects.

In my earlier career, I worked in semiconductor factories where we
weren't allowed to change the settings on a single knob without formal
change orders, extensive experimental data, and an official review.
Perhaps Drupal would be better if we used Intel's development model. Or
maybe, just maybe, developing Drupal is a completely different problem
from developing a microprocessor.

  -- mechfish
-- 
  Michael F Booth
  mike at michaelfbooth.com


From news at unleashedmind.com  Sun Mar  8 04:29:10 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Sun, 8 Mar 2009 05:29:10 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <49B33ADB.1020507@gmx.net>
Message-ID: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>

> Dude i've been wasting my whole summer on that. Cleaning up 
> afterwards 
> is a hell lot of more unrewarding work than preventing the shit from 
> hitting the fan.

100% of all other contributors are "wasting" their time (not only the past
summer) to improve Drupal core and contributed modules.

Change requires to take some action.

> > Bad habit of module authors.  Slap them, but create a patch 
> to remove what
> > has been duplicated afterwards.
> Yeah like i even have multiple days each day - sorry i simply can not 
> fix stuff beyond the needs of my NGO site.
> If the development process allows module authors to have bad habits - 
> well maybe its not tightly regulated enough.

We have several handbook pages that outline coding standards and best
practices.  You can simply put it this way: Developers who do not adhere to
them do not want that anyone contributes to their modules.

To be realistic, we can't regulate more than regulating that any code in CVS
is licensed under GPL.

> > Removing the duplication requires that those module 
> maintainers (finally)
> > come to that conclusion.
> That seems far less realistic than setting up a strict regulatory 
> bottleneck for every line of official core/contrib D7 code. Take a 
> look at how extremely discerning the benevolent dictator of the Wine 
> project - Alexandre Julliard - handles the many code submissions from 
> wine-patches - and at the resulting quality. There's a reason 
> he skips 
> committing 30% of patches.

...which prevents innovation.  At least one of my modules would not exist
today if it would not have gone through 1 year of quality assurance and
testing, becoming one of the most popular Drupal modules in the end.

> > Core developers are already buried with core development.  
> Take a look at
> > issue queues of "sub-core" modules like Views and you'll 
> understand that
> > each project needs its own code-guards.
> That very well i know. Maybe we can all improve the process and 
> optimize the obligatory set of tools?

The issue is not the tools, but the brains and time of contributors.  Each
and every module needs people who "love" a module and can spare a fair
amount of dedicated time to think about and work on a project.

Improvement and innovation requires in-depth knowledge about something.

> > Machines can not (yet) replace the complex thoughts and 
> decisions of a
> > human.  If a patch passes some (human-created) tests, that 
> only means a) it
> > passed an expected behavior (which still can be wrong or 
> outdated) and b) it
> > passed coding-style tests (if there were some) - but there 
> still has to be a
> > gate-keeper who tells you about logic errors and the future 
> of Drupal.
> Of course not - but if the automated tests pass, AND 10 registered 
> Drupal developers okay the patch by voting RTBC - for sure a commit 
> bot can take the decision to just do it?
> My guess: swarm intelligence + sophisticated tools outperform 
> stressed individual core developers.

We have this system already.  It is called "co-maintainers".

sun


From cog.rusty at gmail.com  Sun Mar  8 05:25:52 2009
From: cog.rusty at gmail.com (Cog Rusty)
Date: Sun, 8 Mar 2009 07:25:52 +0200
Subject: [development] D7 contrib module development
In-Reply-To: <033c01c99f99$9f44f900$0200a8c0@structworks.com>
References: <49B3275D.8020109@gmx.net>
	<033c01c99f99$9f44f900$0200a8c0@structworks.com>
Message-ID: <a08ea0280903072125r2b5a40d1tc8fba4522804ea8e@mail.gmail.com>

On Sun, Mar 8, 2009 at 4:57 AM, Daniel F. Kudwien
<news at unleashedmind.com> wrote:
...snip...
>> An example
>> for this mess is the huge number of competing
>> notification/subscription modules for D6 - each with a
>> destinct feature set and of course incompatible to all
>> others.
>
> The reason for that is that someone thought he/she could write something
> better, wrote it, and ended up with something that already exists. ?From
> then on, happy developers continued to improve the pre-existing thingy,
> while some others installed the duplicated thingy and advanced on that. ?The
> end result is: two parties that think either approach is wrong and a massive
> croud of users that thinks "And this is why Drupal sucks.(tm)"
>
> Removing the duplication requires that those module maintainers (finally)
> come to that conclusion.

I remember watching the relevant discussions. I think the issue of the
different subscription/notification modules is good evidence that the
problem is often organic and not just a result of incompetence,
negligence, or lack of information.

On one side, we have some fine developers who can allocate only so
much time and energy on a particular module, and will refuse big
patches which could make them lose control or delay or break the
module if they don't do much more work than they intended to do. On
the other side, we may have also good developers with some particular
need at the time, who offer a huge chunk of code. This is always a
tough call for a responsible module maintainer, who can't even predict
if the newcomer developer can/will continue to work on the project or
will move on to something else.

In the case of the subscription/notification modules, so far both
project seem to be doing fine. Eventually one may win the users, or
they may take different directions. Much more often, the newcomer
developer moves on, and the maintainer says "I told you so".

What about the argument for banning duplicate modules? A reason that
this is not possible is the antithesis between the responsibility of
the maintainer who wants to have a working module within the
constraints of real life vs the apparent needs of the newcomer
developer. Introducing a third party who will decide the fate of a
project unaffected by these realities isn't such a good thing, since
that third party can't force anyone to work.

I think all we can do is ask for documentation of the differences and
put some pressure on the people involved to make them "think aloud"
about the particular situation and make sure that they have considered
the consequences and the options.
...snip...

From dmitrig01 at gmail.com  Sun Mar  8 05:29:56 2009
From: dmitrig01 at gmail.com (Dmitri Gaskin)
Date: Sun, 8 Mar 2009 00:29:56 -0500
Subject: [development] "Accepted" status for issues
Message-ID: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>

Hey Development,

What about adding a "Accepted" status for issues, kind of in between  
"active" and "has a patch" - we recognize it's a bug, we're working to  
fix it, or we like this feature, we're going to implement it.

What are your thoughts?

Dmitri

From gabor at hojtsy.hu  Sun Mar  8 05:36:00 2009
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Sun, 8 Mar 2009 06:36:00 +0100
Subject: [development] "Accepted" status for issues
In-Reply-To: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
References: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
Message-ID: <86ca3ccb0903072136y1159e31ex3f8704b545e0d7a5@mail.gmail.com>

On Sun, Mar 8, 2009 at 6:29 AM, Dmitri Gaskin <dmitrig01 at gmail.com> wrote:
> What about adding a "Accepted" status for issues, kind of in between
> "active" and "has a patch" - we recognize it's a bug, we're working to fix
> it, or we like this feature, we're going to implement it.

I felt the need for this before, but then realized that "accepted" ==
"active" and "assigned to someone". Sure, this combined approach does
not allow you to filter for such issues as easy as just to look for a
certain state.

G?bor

From kathleen at ceardach.com  Sun Mar  8 06:50:14 2009
From: kathleen at ceardach.com (Kathleen Murtagh)
Date: Sun, 8 Mar 2009 01:50:14 -0500
Subject: [development] "Accepted" status for issues
In-Reply-To: <86ca3ccb0903072136y1159e31ex3f8704b545e0d7a5@mail.gmail.com>
References: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
	<86ca3ccb0903072136y1159e31ex3f8704b545e0d7a5@mail.gmail.com>
Message-ID: <78789e870903072250o42cf4bcarbbdcf01ef0595d16@mail.gmail.com>

Using a "New" status for newly created tickets is a common way to say
that a ticket has not yet been reviewed for validity.  I find it
useful and use it in my ticket tracking systems.

--
Kathleen Murtagh



On Sun, Mar 8, 2009 at 12:36 AM, G?bor Hojtsy <gabor at hojtsy.hu> wrote:
> On Sun, Mar 8, 2009 at 6:29 AM, Dmitri Gaskin <dmitrig01 at gmail.com> wrote:
>> What about adding a "Accepted" status for issues, kind of in between
>> "active" and "has a patch" - we recognize it's a bug, we're working to fix
>> it, or we like this feature, we're going to implement it.
>
> I felt the need for this before, but then realized that "accepted" ==
> "active" and "assigned to someone". Sure, this combined approach does
> not allow you to filter for such issues as easy as just to look for a
> certain state.
>
> G?bor
>

From earnie at users.sourceforge.net  Sun Mar  8 13:31:31 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Sun, 08 Mar 2009 09:31:31 -0400
Subject: [development] "Accepted" status for issues
In-Reply-To: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
References: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
Message-ID: <20090308093131.oi37d7htrn4sg8c8@mail.progw.org>

Quoting Dmitri Gaskin <dmitrig01 at gmail.com>:

> Hey Development,
>
> What about adding a "Accepted" status for issues, kind of in between  
> "active" and "has a patch" - we recognize it's a bug, we're working 
> to  fix it, or we like this feature, we're going to implement it.
>
> What are your thoughts?
>

It belongs in an issue queue for the web maintainers.  I would like for 
each project to be able to add or remove statuses to their liking but I 
don't have time to work a patch and it isn't as important as other 
items on the list.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From earnie at users.sourceforge.net  Sun Mar  8 13:46:54 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Sun, 08 Mar 2009 09:46:54 -0400
Subject: [development] D7 contrib module development
In-Reply-To: <49B3275D.8020109@gmx.net>
References: <49B3275D.8020109@gmx.net>
Message-ID: <20090308094654.a75mdfe9pfk004og@mail.progw.org>

Quoting Marcel Partap <mpartap at gmx.net>:

> Hi fellow drupal devs,
> wanted to bring up a few points about module development for some 
> time and i guess now that module development happens to be the hot 
> topic of the day would be a good time..
> While D6 is proving to be a great success and through contrib modules 
> can be flexibly expanded to almost unlimited use case customizations, 
> working with a whole bunch of modules on our site my experience is 
> that quantity is not necessarily a good compensation for quality. 
> Several problems just keep coming up:
> - modules spamming the watchdog table with E_ALL warnings
> - modules ignoring the style/documentation guide lines
> - applied insane programming(TM) techniques
> - undescriptive module names
> but by far the most serious one is
> - duplication (partial feature overlap with existing modules).

I like duplication overlap.  In particular when that overlap provides 
better features than another module of like manner.  There is code and 
then there is better code as you've noted in your first four points.  
The modules of importance will be upgraded by those who care.  Others 
can pay for the upgrade of a module if they wish or take over the 
maintenance of that module themselves.  IMO, the most serious is your 
second point of modules ignoring the style/documentation guide lines.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From gerhard at killesreiter.de  Sun Mar  8 13:59:29 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Sun, 08 Mar 2009 14:59:29 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <49B3346F.40008@gmx.net>
References: <49B3275D.8020109@gmx.net>	<efeed12d0903071829n13b940bbt61769fd313fadab7@mail.gmail.com>
	<49B3346F.40008@gmx.net>
Message-ID: <49B3CF41.40906@killesreiter.de>

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

Marcel Partap schrieb:
> On 08/03/09 03:29, Kyle Mathews wrote:
>> RE following the linux model -- we already are. Linux has one
>> "kernel" and how ever many applications built on top it that there
>>  are individuals interested enough to write one. [...] But in the
>> Linux application space it's a wild wild west as far as quality
>> standards go.
> Seems a bit to me like you intentionally misunderstood my analogy ;D
> The comparison i was (not even) trying to make is linux core kernel
> and optional modules versus Drupal core and contrib.
> 
>> As Drupal matures, so will the contributed modules space.
> Even though you are trying hard, i am not talking names (of modules
> which contain code that just scares me).

Why not?

Reporting hard to understand or otherwise scary code is a good thing
for the module maintainer.

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

iEYEARECAAYFAkmzz0EACgkQfg6TFvELooRfZQCcCwk73pRSZ8sfWupmOUpFDkXS
/NIAniLizJ8hEf72O/y2LF/KyeZjQNee
=g7sX
-----END PGP SIGNATURE-----

From stella at stellapower.net  Sun Mar  8 14:01:45 2009
From: stella at stellapower.net (Stella Power)
Date: Sun, 8 Mar 2009 10:01:45 -0400
Subject: [development] "Accepted" status for issues
In-Reply-To: <20090308093131.oi37d7htrn4sg8c8@mail.progw.org>
References: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
	<20090308093131.oi37d7htrn4sg8c8@mail.progw.org>
Message-ID: <cdcea3940903080701gb12b3f0wf14e118658a96afa@mail.gmail.com>

There's already an issue open on d.o about re-organising the issue status
settings - http://drupal.org/node/171350

Cheers,
Stella

On Sun, Mar 8, 2009 at 9:31 AM, Earnie Boyd <earnie at users.sourceforge.net>wrote:

> Quoting Dmitri Gaskin <dmitrig01 at gmail.com>:
>
>  Hey Development,
>>
>> What about adding a "Accepted" status for issues, kind of in between
>>  "active" and "has a patch" - we recognize it's a bug, we're working to  fix
>> it, or we like this feature, we're going to implement it.
>>
>> What are your thoughts?
>>
>>
> It belongs in an issue queue for the web maintainers.  I would like for
> each project to be able to add or remove statuses to their liking but I
> don't have time to work a patch and it isn't as important as other items on
> the list.
>
> --
> Earnie  http://r-feed.com
>  Make a Drupal difference and review core patches.
>
> -- http://for-my-kids.com/  -- http://www.4offer.biz/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090308/9581fd16/attachment.htm 

From mpartap at gmx.net  Sun Mar  8 15:30:29 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Sun, 08 Mar 2009 16:30:29 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
Message-ID: <49B3E495.7000805@gmx.net>

> Change requires to take some action.
That's what me taking the initiative was all about ;)


>>> Bad habit of module authors.  Slap them, but create a patch to
>>> remove what has been duplicated afterwards.
>> Yeah like i even have multiple days each day - sorry i simply can
>> not fix stuff beyond the needs of my NGO site. If the development
>> process allows module authors to have bad habits - well maybe its
>> not tightly regulated enough.
> We have several handbook pages that outline coding standards and
> best practices.  You can simply put it this way: Developers who do
>  not adhere to them do not want that anyone contributes to their
> modules. To be realistic, we can't regulate more than regulating
> that any code in CVS is licensed under GPL.
Yes we can. We can set up a clearly defined landing path for code
submissions.

>>> Removing the duplication requires that those module maintainers
>>> (finally) come to that conclusion.
>> That seems far less realistic than setting up a strict
>> regulatory bottleneck for every line of official core/contrib D7
>> code. Take a look at how extremely discerning the benevolent
>> dictator of the Wine project - Alexandre Julliard - handles the
>> many code submissions from wine-patches - and at the resulting
>> quality. There's a reason he skips committing 30% of patches.
> ...which prevents innovation.  At least one of my modules would not
> exist today if it would not have gone through 1 year of quality
> assurance and testing, becoming one of the most popular Drupal
> modules in the end.
Does not. A lot of stuff has been tried already for D6 - for D7
everyone and his dog should have made the experiences from which we
can benefit, especially about which design decisions cause maintenance
problems later one.
So in my opinion the concern you voice is valid even for D6, it would
have stiffled innovation to regulate code committs. But for D7, i
believe the goal should shift from having a huge quantity of modules
to expandable frameworks for areas like notifications, polls/web
forms/questionaires, payment that provide coherent and flexible APIs
to obliterate fuplicate attempts of providing the same functionality.
If it takes a lot of time to migrate certain modules from D6 to D7,
and just as much time to implement a totally new module for D7 which
merges functionality, code and vision of several modules, i (as a
student of engineering, specializing in construction and development)
*very very very* strongly would support the later choice. It might be
difficult and require changes, but in the long run it will be worth it.

>>> Core developers are already buried with core development. Take
>>> a look at issue queues of "sub-core" modules like Views and
>>> you'll understand that each project needs its own code-guards.
>> That very well i know. Maybe we can all improve the process and
>> optimize the obligatory set of tools?
> The issue is not the tools, but the brains and time of
> contributors.  Each and every module needs people who "love" a
> module and can spare a fair amount of dedicated time to think about
> and work on a project.
Yes and no. Each piece of code needs to be written by someone who
needs the functionality AND is passionate about it, ACK. But that
should not inherently make him the person to solely be responsible for
the code. Instead, every code contribution should be subject of a
community process in which everyone caring about it reviews and
contributes, without defining single individuals as maintainer of a
module (though recording the credits for each individual submission).

> Improvement and innovation requires in-depth knowledge about
> something.
True. How does a more swarm-like approach to code committal hinder
that? That'd just channel the flow more tightly.

>>> Machines can not (yet) replace the complex thoughts and
>>> decisions of a human.  If a patch passes some (human-created)
>>> tests, that only means a) it passed an expected behavior (which
>>> still can be wrong or outdated) and b) it passed coding-style
>>> tests (if there were some) - but there still has to be a
>>> gate-keeper who tells you about logic errors and the future
>> of Drupal. Of course not - but if the automated tests pass, AND
>> 10 registered Drupal developers okay the patch by voting RTBC -
>> for sure a commit bot can take the decision to just do it? My
>> guess: swarm intelligence + sophisticated tools outperform
>> stressed individual core developers.
> We have this system already.  It is called "co-maintainers".
Well it doesn't systemicly solve the problem, as it really just 
expands the number of stressed individual developers who have 
responsibility instead of tackling the root cause that makes all this 
even possible: no enforcement of coding standards, no wider review of 
changes before committal, no opportunity for improvements to be made 
before committal, single individuals responsible for decisions.

To clarify here's how it could work:
- erection of drupal-patches mailing list for all code to pass through
- coupling that mailing list with a revised patch tracking system
   - patch submissions to the ML create a patch issue
   - comments to the posting get also attached to the issue
   - in turn, patch issues file through the web interface are echoed
     on the ML, just as comments to it
   (similar how to what the mailman/mailhandler modules.. i hereby
    step up for a clean reimplementation of this functionality)
- inserting a voting system into the patch issue tracker
   - two choices: 'ready to be committed' or 'veto'
   - core developers' votes get higher weight, can clear 1/2 veto votes
- having the patch issue tracker DISPLAY the code by default
   additionally to providing it as attachment
- setting up rules and regulation (proposal)
   - developers get awarded D7 svn rights by either landing more
     than 1K of code or 10 commits in core, or by being promoted
   - all code *has* to be either committed by these developers or
     has to get 10 RTBC votes with no vetoes
   - all code going in has to at least break no tests AND
   - all code is automatically tested for adherence to coding standard
   - patches can -and should- be improved by all who care until 10 RTBC
   - code contributors are recorded in each modules changelog / AUTHORS
- several frameworks have to be put in place for D7:
   - messaging / change notification
   - polls / web forms / questionaires / quiz
   - translation (l10n server integration, finally!)
   - caching
   - media integration
   - probably e-commerce/payment
   => brainstorming in the corresponding groups needs to start

Of course implementing this would require messing with the ways of 
some drupal developers, and it will definitly slow down the rate of 
contrib code increase. However, in the end, you get what you pay for!

To explicitly say it again: all this is only viable because of the 
experience gained from D6 unregulated contrib development creativity. 
But looking at how *quality* is at the top of the D7 agenda, it might 
be a wise idea to apply more pruning and gardening tactics in general 
also to the modules to _not_ end up in an impenetrable jungle thicket 
like the D6 contrib area. And swarm intelligence is just the right 
buzzword to do it..

Webchick, Dries, core devs: pleace voice opinion NOW ;)
rgds marcel.


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From stella at stellapower.net  Sun Mar  8 16:46:41 2009
From: stella at stellapower.net (Stella Power)
Date: Sun, 8 Mar 2009 12:46:41 -0400
Subject: [development] D7 contrib module development
In-Reply-To: <49B3E495.7000805@gmx.net>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
Message-ID: <cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>

>   However, in the end, you get what you pay for!
>

Well, Drupal is free and you don't pay for it. :)

To be honest, I think this is an absolutely terrible idea.  It's just not
scalable.  We've got thousands of contributed modules and themes, which
makes for millions of lines of code.  To ask that we can have a core team of
developers managing contrib patches, means that they need to get familiar
with all those projects and how they work, the various potentially complex
code and features in each.  It's just not realistic.  It's also not
realistic to expect those same developers to review _all_ of the patches
that need to get committed.  Don't forget this doesn't just include patches
that get submitted via the issue queues but all of the changes that the
maintainers themselves commit as they're working on new features, etc.  Most
Drupal contributors provide their time and effort for free - again it's not
realistic, this proposal sounds like a full time job.

I also really dislike this proposal because, as you pointed out, the rate of
changes to contrib will decrease.  This includes both features and bug
fixes.  It goes against the whole "the drop is always moving" and in doing
so, removes one of the great things about Drupal.

If you really want to help improve contrib, then help by writing more
"comparisons of duplicated modules" (http://drupal.org/node/266179 - though
the handbook is a bit messed up since the upgrade).  Help by working with
contrib project maintainers and convince them to merge their duplicate
modules.  Help by reviewing contrib modules and providing patches.

So a big -1 for this proposal.

Cheers,
Stella
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090308/f04dbbd7/attachment-0001.htm 

From sivaji2009 at gmail.com  Sun Mar  8 18:01:09 2009
From: sivaji2009 at gmail.com (sivaji j.g)
Date: Sun, 8 Mar 2009 23:31:09 +0530
Subject: [development] How to clear database after a regular interval
In-Reply-To: <030701c99f5c$86fb17e0$0200a8c0@structworks.com>
References: <49B2C306.6030409@gmail.com>
	<030701c99f5c$86fb17e0$0200a8c0@structworks.com>
Message-ID: <fce946780903081101i67db803q5dab9af1df3cf72@mail.gmail.com>

On Sun, Mar 8, 2009 at 1:10 AM, Daniel F. Kudwien <news at unleashedmind.com>wrote:

>
> This is exactly what Demo module (http://drupal.org/project/demo) does.
>
>
thanks to all, let me try this module .



-- 
Thanks a lot
-----------------------------------------
http://ubuntuslave.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090308/8873a5ab/attachment.htm 

From mpartap at gmx.net  Sun Mar  8 18:03:51 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Sun, 08 Mar 2009 19:03:51 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
Message-ID: <49B40887.5010504@gmx.net>

...
> However, in the end, you get what you pay for! Well, Drupal is free
> and you don't pay for it. :)
What i meant was of course the effort to install a code bottlenecking
process, not the cost of drupal but guess you understand that ;)

> To be honest, I think this is an absolutely terrible idea.  It's
> just not scalable.  We've got thousands of contributed modules and
> themes, which makes for millions of lines of code. To ask that we
> can have a core team of developers managing contrib patches,
Quite frankly that's not what i'm proposing, out of the reasons you
just stated.
BTW although according to
wget -qO - http://ftp.drupal.org/files/projects/|html2text -width 130 
-nobs|'grep' "\-6.x\-"|sed 's/\[\[   \]\]//;s/-6.*//'|sort -u|wc -l
there currently are 2227 D6 contrib projects (compared to 2827 for D5) 
- do you really think all of those provide a useful benefit to the 
community? how many of those are deprecated, unmaintained or plain 
useless? Even then we can prevent that from happening on D7 *without* 
destroying what's already there. D6 will live on for perhaps up to a 
decade anyways... There are still D4 sites out there!

> means that they need to get familiar with all those projects and
> how they work, the various potentially complex code and features in
> each.  It's just not realistic.  It's also not realistic to expect
> those same developers to review _all_ of the patches that need to
> get committed.

What i am proposing is that all code *not* coming from the most active
(in-know) drupal developers (which includes core just aswell as f.e.
cck, views and coder devs) passes through a ML/refined patch tracker,
is reviewed by the drupal-patches subscribers - and only enters the
repository after *either* one of the high-profile devs voted RTBC (1 *
weight 10) *or* ten 'normal' reviewers voted RTBC, at which point the
code is also automatically committed (if it still passes the
conformance tests and noone vetoes).
To explain again, the new process would not be interfering with the 
working mode of the most active drupal developers, but make reviewing 
patches from casual contributors obligatory.

Just speaking for me but i'd definitly see merit and take part in such
a process.

> Don't forget this doesn't just include patches that get submitted
> via the issue queues but all of the changes that the maintainers
> themselves commit as they're working on new features, etc.
Sure it does, and if anyone wants to submit a valid fix or 
enhancement, easily will the community okay the changes at which point 
they automatically get committed. Working on new features however is a 
different story: why should half-baked testing code get committed to 
the central repository at all? Nevertheless the process i'm proposing 
can be applied to experimental code changes just fine - they'd just 
not be committed until the work on that issue has resulted in 
something sane. Most patches going into core pretty much went through 
the exact same process: someone posting an initial patch which gets 
refined to a piece of sufficient quality in mutual exchange of code 
and opinions.

> Most Drupal contributors provide their time and effort for free - again
> it's not realistic, this proposal sounds like a full time job.
For whom? The additional work load of more thoroughly reviewing and 
careful sanitizing code submissions is not to be forced upon 
individual people. It's about making that a swarm thing!

> I also really dislike this proposal because, as you pointed out,
> the rate of changes to contrib will decrease.
If quantity goes down, quality goes up: is it bad or good? Which 
numbers count heavier, SLOC or #bugs?

> This includes both features and bug fixes.
How do bugs get introduced in the first place? Committing experimental 
stuff too quickly and without review.
How do modules end up in the situation where ugly hacks become 
necessary and new features become hard to implement? Bad design 
decisions because of the lack of a careful conceptualization phase.

> It goes against the whole "the drop is
> always moving" and in doing so, removes one of the great things
> about Drupal.
Does not. The drop will still be moving, even faster through uber meta 
channeling :D

> If you really want to help improve contrib, then help by writing
> more "comparisons of duplicated modules"
> (http://drupal.org/node/266179 - though the handbook is a bit
> messed up since the upgrade).
Waste of time better spent on reimplementing functionality in the best 
possible manner.

> Help by working with contrib project
> maintainers and convince them to merge their duplicate modules.
Hahahahaahahaha.. .. sorry the part about convincing was too funny. 
Make module 'owners' give up their precious 'property'? What about 
establishing the art of hand-knitting in London's most popular night 
clubs?

> Help by reviewing contrib modules and providing patches.
Been there done that. Let me repeat: once the shit *has* hit the fan, 
cleaning up is a messy unrewarding work.

> So a big -1 for this proposal.
Hope that's not set in stone ;)

Another point to make: D6 is good. Together with the vast variety of 
contrib modules, in some way or the other it does provide the 
functionality to easily implement web projects with almost any use 
case covered. So there's no need to rush out, neither D7 core nor 
contrib modules. Why not take the time to do things right from the 
beginning? If D6 module code has to be heavily modified anyways, why 
not consider the benefits of reimplementing it from scratch?

rgds marcel.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From domenic at workhabit.com  Sun Mar  8 18:09:38 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Sun, 8 Mar 2009 10:09:38 -0800
Subject: [development] D7 contrib module development
In-Reply-To: <cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
Message-ID: <e83e0db0903081109ya785b51v5bac8a195bffb88c@mail.gmail.com>

On Sun, Mar 8, 2009 at 8:46 AM, Stella Power <stella at stellapower.net> wrote:
>
>> ? However, in the end, you get what you pay for!
>
> Well, Drupal is free and you don't pay for it. :)

One of the things that surprised me when I started working with Drupal
is the breadth of functionality that's left out of core. No automatic
path aliasing? No subscribing to a post? Wait, I can't add more fields
to my content types??? For a "Content Management System", Drupal core
is _severely_ lacking in features.

The logical end is that modules now have inflated importance to
Drupal, because you (basically) can't do jack without at least some of
them. This creates an odd disparity: the concept of "modules" refers
to both one-off, unimportant, unfinished modules, AND to
cck/views/pathauto, three modules you basically can't build a site
without.

-D

From news at unleashedmind.com  Sun Mar  8 18:10:15 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Sun, 8 Mar 2009 19:10:15 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <49B3E495.7000805@gmx.net>
Message-ID: <03a001c9a019$21fc01c0$0200a8c0@structworks.com>

> So in my opinion the concern you voice is valid even for D6, 
> it would have stiffled innovation to regulate code committs. 
> But for D7, i believe the goal should shift from having a 
> huge quantity of modules to expandable frameworks for areas 
> like notifications, polls/web forms/questionaires, payment 
> that provide coherent and flexible APIs to obliterate 
> fuplicate attempts of providing the same functionality.
> If it takes a lot of time to migrate certain modules from D6 
> to D7, and just as much time to implement a totally new 
> module for D7 which merges functionality, code and vision of 
> several modules, i (as a student of engineering, specializing 
> in construction and development) *very very very* strongly 
> would support the later choice. It might be difficult and 
> require changes, but in the long run it will be worth it.

That's a nice vision you have there.  But it sounds like you only want to
talk about it.  Merging and rewriting most of those duplicated modules from
scratch (e.g. Notifications/Subscriptions, eCommerce/Ubercart, etc) requires
a lot of development time - much more than simply porting them to yet
another Drupal core version.  To have any effect in the end, it also
requires that all module maintainers agree on the "roadmap", which means
that they will let their own, duplicated modules die in favor of the new,
centralized module.

This has been done before.  Two examples:

- Content profile module is the successor of Bio, Node profile, and Usernode
modules, created after months of discussions between all maintainers,
developers, and contributors of the previous modules.  Given that Fields
(CCK) are in D7 core now, this decision and joined effort for 6.x will
ensure that there is a unique upgrade path to 7.x all developers can work
on.

- Wysiwyg API module is the successor of all client-side editor integration
modules, because someone analyzed the anatomy of all previously existing
modules and thought about a better, generic way to do it with Drupal.
Almost none of the other maintainers and developers ever contributed to this
vision, which is the reason for why the few developers of this project are
completely buried with work, and Drupal users are (even more) confused about
which module to choose/install.  Because of that, we won't have better
Wysiwyg support in Drupal 7 core.


> Yes and no. Each piece of code needs to be written by someone 
> who needs the functionality AND is passionate about it, ACK. 
> But that should not inherently make him the person to solely 
> be responsible for the code. Instead, every code contribution 
> should be subject of a community process in which everyone 
> caring about it reviews and contributes, without defining 
> single individuals as maintainer of a module (though 
> recording the credits for each individual submission).
...
> > Improvement and innovation requires in-depth knowledge about 
> > something.
> True. How does a more swarm-like approach to code committal 
> hinder that? That'd just channel the flow more tightly.

People most often forget that maintaining a project is primarily about
responsibility, once it is in the wild.  Yet another example: If there was
some bad, not carefully reviewed code committed to Views module, then 72,799
sites could go down.

I have seen issues where 10 or more contributors reviewed and gave their
thumbs up, but luckily there was this responsible maintainer who told them
that the entire approach is wrong, followed by the proper way to do it.
That is the primary job of maintainers (gate-keepers) and the reason for why
it is both excellent and required to have separate, specialized knowledge
and vision per project.


> > We have this system already.  It is called "co-maintainers".
> 
> Well it doesn't systemicly solve the problem, as it really 
> just expands the number of stressed individual developers who 
> have responsibility instead of tackling the root cause that 
> makes all this even possible: no enforcement of coding 
> standards, no wider review of changes before committal, no 
> opportunity for improvements to be made before committal, 
> single individuals responsible for decisions.

If a project or maintainer does not adhere to Drupal's coding standards and
best practices, there are most likely no co-maintainers.  The reason is
simple: Without adhering to them, other developers and contributors have
very hard times to fix, improve, and advance on what's there.

Your proposal really boils down to the question whether a project maintainer
is open to improvements by the Drupal community and thereby takes the
required, additional steps to ensure that the community is able to
contribute.  It's about following a certain paradigm - or not.  No automated
process or AI will be able to change the paradigms of humans who do not want
to follow a certain paradigm.


> But looking at how *quality* is at the top of the D7 agenda, 
> it might be a wise idea to apply more pruning and gardening 
> tactics in general also to the modules to _not_ end up in an 
> impenetrable jungle thicket like the D6 contrib area. And 
> swarm intelligence is just the right buzzword to do it..

We can measure quality in contrib (and there are plans to do so), but
putting regulations onto contrib hinders innovation, evolution,
contributions, and lastly freedom.

That said, I was wrong in that our CVS licensing policy is the only
constraint.  Fresh Drupal developers who want to create a new project on
drupal.org must pass an initial code review quality assurance.

Because 99.9999% of all Drupalers are not really aware of that, I want to
take the chance to publicly say THANK YOU to Andy Kirkham (AjK), who does an
awesome job on carefully reviewing a bloat of CVS applications - mostly
alone.  We get several new CVS applications *each day*.  Although there are
a few other community members who are eligible to process CVS applications,
he is the one who takes this on with the required responsibility,
discipline, and motivation.

That's an ungrateful job, because many applicants complain about the slow
review process and in parallel, his hard and time-consuming work is not
recognized throughout the community. :(

Thank you, Andy!  You are one of the most important people for Drupal.
Without you, Drupal contrib would certainly be a pain.

sun


From karoly at negyesi.net  Sun Mar  8 18:28:23 2009
From: karoly at negyesi.net (Karoly Negyesi)
Date: Sun, 08 Mar 2009 19:28:23 +0100 (CET)
Subject: [development] How to port modules? was: Drupal 7 "When	it's
 Ready"
In-Reply-To: <49B2087F.5000702@NinjitsuWeb.com>
References: <28217689.265551236183914132.JavaMail.root@zimbra>
	<49AF0D72.8020207@killesreiter.de>
	<c538f9410903041529o10a34e02xe2abed190e2dee0@mail.gmail.com>
	<4a9fdc630903041706i66984b00nf6de0e9a24e030e8@mail.gmail.com>
	<20090305100851.6e6ef58b@dawn.webthatworks.it>
	<EA5E6408-2BF3-43AE-B2E7-B8574A36B60C@mattfarina.com>
	<c538f9410903050441q1edbf61cs322fdbf178b90b1f@mail.gmail.com>
	<fa5724270903050504m4f9ec3fdncc62f6c4dd4a99fa@mail.gmail.com>
	<c538f9410903050530p237b42a8rae2a554dc123ac4e@mail.gmail.com>
	<49B0A52D.6080207@logrus.com>
	<c538f9410903060058u6f50294aj38ffc1b1f360f379@mail.gmail.com>
	<49B1E589.1030708@logrus.com> <49B2087F.5000702@NinjitsuWeb.com>
Message-ID: <E1LgNjb-0005zU-JL@garm.runbox.com>

> It's not like ... Karoly ... gang want it to be hard. 

Why are you so sure of that :p 

From mpartap at gmx.net  Sun Mar  8 19:47:58 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Sun, 08 Mar 2009 20:47:58 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <03a001c9a019$21fc01c0$0200a8c0@structworks.com>
References: <03a001c9a019$21fc01c0$0200a8c0@structworks.com>
Message-ID: <49B420EE.5050004@gmx.net>

...
> Because 99.9999% of all Drupalers are not really aware of that, I
> want to take the chance to publicly say THANK YOU to Andy Kirkham
> (AjK), who does an awesome job on carefully reviewing a bloat of
> CVS applications - mostly alone. We get several new CVS
> applications *each day*. Although there are a few other community
> members who are eligible to process CVS applications, he is the
> one who takes this on with the required responsibility, discipline,
> and motivation.
You're right, haven't noticed him although he probably also processed
my application.. KUDOS Andy for bearing with the community ;)

> That's an ungrateful job, because many applicants complain about
> the slow review process and in parallel, his hard and
> time-consuming work is not recognized throughout the community. :(
Yeah being in the jury just never pay off.

> Thank you, Andy!  You are one of the most important people for
> Drupal. Without you, Drupal contrib would certainly be a pain.
Wow i didn't realize it could be far worse..
Now on to the more profane stuff.

>> It might be difficult and require changes, but in the long run it
>> will be worth it.
> That's a nice vision you have there.  But it sounds like you only
> want to talk about it.
Well admittedly starting the discussion is only a first small part.
For much of the work i can not be of help simply because i have other
obligations, but i volunteered for reimplementing a mailman/drupal
integration module and would contribute as much as possible.

> Merging and rewriting most of those duplicated modules from scratch
> (e.g. Notifications/Subscriptions, eCommerce/Ubercart, etc)
> requires a lot of development time - much more than simply porting
> them to yet another Drupal core version.
Well of course it does, but a) the structural sanity benefit might be
worth it and b) the license doesn't prohibit code reuse ;)

> To have any effect in the end, it also requires that all module
> maintainers agree on the "roadmap", which means that they will let
>  their own, duplicated modules die in favor of the new, centralized
>  module.
No. It does require the community at large to do the work of
discussing, drafting and finalizing the structural design of these new
frameworks - module maintainers are not required, but of course their
experience would be of tremendous use.

> This has been done before.
Fine. So uhm let's do.

> - Wysiwyg API module is the successor of all client-side editor
> integration modules, because someone analyzed the anatomy of all
> previously existing modules and thought about a better, generic way
> to do it with Drupal. Almost none of the other maintainers and
> developers ever contributed to this vision, which is the reason for
> why the few developers of this project are completely buried with
> work, and Drupal users are (even more) confused about which module
> to choose/install.  Because of that, we won't have better Wysiwyg
> support in Drupal 7 core.
Shame on those module maintainers! But still, all is not lost. Let us
try making it suceed and mirroring the process, without leaving
current module maintainers out of the equation.
By the way, a policy change like described would put more pressure on
those maintainers - if they want to have at least some of their code
run on D7 - they better be cooperative!

>> True. How does a more swarm-like approach to code committal
>> hinder that? That'd just channel the flow more tightly.
> People most often forget that maintaining a project is primarily
> about responsibility, once it is in the wild.
Ok now that's a valid point. Maybe it can be possible for people to
take responsibility without having exclusive access rights to a module?

> Yet another example: If there was some bad, not carefully reviewed
>  code committed to Views module, then 72,799 sites could go down.
So as that has not yet happened it seems responsible developers exist
in the drupal community.. hurray! ;)

> I have seen issues where 10 or more contributors reviewed and gave
>  their thumbs up, but luckily there was this responsible maintainer
>  who told them that the entire approach is wrong, followed by the
> proper way to do it.
That's the scenario where the veto vote i proposed comes into play ;)

> That is the primary job of maintainers (gate-keepers) and the
> reason for why it is both excellent and required to have separate,
>  specialized knowledge and vision per project.
Well if it work better, that'd be great. However not all individuals
live up to these standards, which is why i think maybe the drupal dev
collective at large can better fulfill this role!

> Your proposal really boils down to the question whether a project
> maintainer is open to improvements by the Drupal community and
> thereby takes the required, additional steps to ensure that the
> community is able to contribute.
My proposal was to shift the responsibility from individual persons to
a community process, to minimize possible negative influence of those.
The process should promote and support taking responsibility by
anyone, and hinder the opposite.


> It's about following a certain paradigm - or not.  No automated
> process or AI will be able to change the paradigms of humans who do
> not want to follow a certain paradigm.
True, _but_ individuals who do not want to follow the common shared
values may be excluded from using the community to publish their code.
That will teach them ;)

> We can measure quality in contrib (and there are plans to do so),
> but putting regulations onto contrib hinders innovation,
> evolution, contributions, and lastly freedom.
Yes and no. It restricts freedom, true. But why does experimental code
need to be committed to the central repository, and how does enforcing
an open development process hinder evolution?


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mathews.kyle at gmail.com  Sun Mar  8 20:49:52 2009
From: mathews.kyle at gmail.com (Kyle Mathews)
Date: Sun, 8 Mar 2009 16:49:52 -0400
Subject: [development] D7 contrib module development
In-Reply-To: <49B420EE.5050004@gmx.net>
References: <03a001c9a019$21fc01c0$0200a8c0@structworks.com>
	<49B420EE.5050004@gmx.net>
Message-ID: <efeed12d0903081349s726509ftb78d802ce67d466@mail.gmail.com>

It seems we're falling into one of two sides of the old argument over design
philosophies. One side says "do the right thing", the other believes "worse
is better." One side builds monolithic jewels, the other side builds simple
modular tools that while messy are simple to use and understand.

More here:
http://www.jwz.org/doc/worse-is-better.html

There are also parallels here to a comparison of publishing on the internet
and traditional publishing in print. Publishing a magazine or newspaper is
expensive, very expensive. So nothing is printed until it passes through an
army of editors, fact checkers, graphic designers etc. that mold the content
into something special. Publishing on the internet is, on the other hand,
extraordinarily cheap. Head over to wordpress.com and 5 minutes later, you
have an international publishing platform -- for free. And millions of
people have done that which is why the internet is now full of junk and
useless or so critics will say.

But it's still very easy to find very high-quality useful information on the
internet. Why? Because there's tools which help filter out the good content
by mining the collective intelligence of human of human interaction on the
web. Google works its search magic by discovering which pages have the most
"votes" from incoming links. Collaborative news sites such as digg, hacker
news, reddit, and others work by voting. The best news bubbles up to the
top. Memetrackers analyze new content and discover which topics are being
discussed the most and push those conversational clusters to the top of the
news page. And so on.

Both systems of publishing content are filters -- the traditional system
says -- "publishing is expensive, so we'll filter content
*before*publishing." The second system says "we can't stop people from
publishing --
so let's devise better filters to help the best content still come out on
top."

Many people will argue against the second system complaining about
information overload -- "there's too much stuff on the internet, we need
professional editors to help us know what to read." Clay Shirky talked about
this awhile ago and said "there's no such thing as information overload,
just filter failure." He expanded on the
argument<http://www.cjr.org/overload/interview_with_clay_shirky_par.php?page=all>
:

So, the real question is, how do we design filters that let us find our way
through this particular abundance of information? And, you know, my answer
to that question has been: the only group that can catalog everything is
everybody. One of the reasons you see this enormous move towards social
filters, as with Digg, as with del.icio.us, as with Google Reader, in a way,
is simply that the scale of the problem has exceeded what professional
catalogers can do. But, you know, you never hear twenty-year-olds talking
about information overload because they understand the filters they?re
given. You only hear, you know, forty- and fifty-year-olds taking about it,
sixty-year-olds talking about because we grew up in the world of card
catalogs and *TV Guide*. And now, all the filters we?re used to are broken
and we?d like to blame it on the environment instead of admitting that we?re
just, you know, we just don?t understand what?s going on.

Now I hope I'm not distorting Marcel's argument here (and if I'm wrong I'm
sure he'll correct me :) when I say he's arguing that there's too many
modules, too many "bad" developers, writing too much "bad" code and we'd be
all better off if the module landscape was less messy and more prestine.
Perhaps this is too neat but it seems his argument falls along the same
lines as those who say we need professional editors to filter content before
publishing. I think his idea is a bad one (for our situation -- it works
great for manufacturing, magazines, skyscrapers, etc.) for many of the same
reasons as others have argued. But we do need better filters to help us find
the best and right modules to use (and I'm sure some duplicate modules are
written simply because the author didn't *know* there was an existing
solution). And I think the drupal community is already working very hard to
do just that -- provide better filters to point site builders to the current
"best-of-breed" modules for a given situation. Much of the drupal.org design
was directed at that problem and the (still coming) Drupal distro revolution
will also greatly help at standardizing the module selection and focusing
developer effort.

Kyle

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


On Sun, Mar 8, 2009 at 3:47 PM, Marcel Partap <mpartap at gmx.net> wrote:

> ...
>
>> Because 99.9999% of all Drupalers are not really aware of that, I
>> want to take the chance to publicly say THANK YOU to Andy Kirkham
>> (AjK), who does an awesome job on carefully reviewing a bloat of
>> CVS applications - mostly alone. We get several new CVS
>> applications *each day*. Although there are a few other community
>> members who are eligible to process CVS applications, he is the
>> one who takes this on with the required responsibility, discipline,
>> and motivation.
>>
> You're right, haven't noticed him although he probably also processed
> my application.. KUDOS Andy for bearing with the community ;)
>
>  That's an ungrateful job, because many applicants complain about
>> the slow review process and in parallel, his hard and
>> time-consuming work is not recognized throughout the community. :(
>>
> Yeah being in the jury just never pay off.
>
>  Thank you, Andy!  You are one of the most important people for
>> Drupal. Without you, Drupal contrib would certainly be a pain.
>>
> Wow i didn't realize it could be far worse..
> Now on to the more profane stuff.
>
>  It might be difficult and require changes, but in the long run it
>>> will be worth it.
>>>
>> That's a nice vision you have there.  But it sounds like you only
>> want to talk about it.
>>
> Well admittedly starting the discussion is only a first small part.
> For much of the work i can not be of help simply because i have other
> obligations, but i volunteered for reimplementing a mailman/drupal
> integration module and would contribute as much as possible.
>
>  Merging and rewriting most of those duplicated modules from scratch
>> (e.g. Notifications/Subscriptions, eCommerce/Ubercart, etc)
>> requires a lot of development time - much more than simply porting
>> them to yet another Drupal core version.
>>
> Well of course it does, but a) the structural sanity benefit might be
> worth it and b) the license doesn't prohibit code reuse ;)
>
>  To have any effect in the end, it also requires that all module
>> maintainers agree on the "roadmap", which means that they will let
>>  their own, duplicated modules die in favor of the new, centralized
>>  module.
>>
> No. It does require the community at large to do the work of
> discussing, drafting and finalizing the structural design of these new
> frameworks - module maintainers are not required, but of course their
> experience would be of tremendous use.
>
>  This has been done before.
>>
> Fine. So uhm let's do.
>
>  - Wysiwyg API module is the successor of all client-side editor
>> integration modules, because someone analyzed the anatomy of all
>> previously existing modules and thought about a better, generic way
>> to do it with Drupal. Almost none of the other maintainers and
>> developers ever contributed to this vision, which is the reason for
>> why the few developers of this project are completely buried with
>> work, and Drupal users are (even more) confused about which module
>> to choose/install.  Because of that, we won't have better Wysiwyg
>> support in Drupal 7 core.
>>
> Shame on those module maintainers! But still, all is not lost. Let us
> try making it suceed and mirroring the process, without leaving
> current module maintainers out of the equation.
> By the way, a policy change like described would put more pressure on
> those maintainers - if they want to have at least some of their code
> run on D7 - they better be cooperative!
>
>  True. How does a more swarm-like approach to code committal
>>> hinder that? That'd just channel the flow more tightly.
>>>
>> People most often forget that maintaining a project is primarily
>> about responsibility, once it is in the wild.
>>
> Ok now that's a valid point. Maybe it can be possible for people to
> take responsibility without having exclusive access rights to a module?
>
>  Yet another example: If there was some bad, not carefully reviewed
>>  code committed to Views module, then 72,799 sites could go down.
>>
> So as that has not yet happened it seems responsible developers exist
> in the drupal community.. hurray! ;)
>
>  I have seen issues where 10 or more contributors reviewed and gave
>>  their thumbs up, but luckily there was this responsible maintainer
>>  who told them that the entire approach is wrong, followed by the
>> proper way to do it.
>>
> That's the scenario where the veto vote i proposed comes into play ;)
>
>  That is the primary job of maintainers (gate-keepers) and the
>> reason for why it is both excellent and required to have separate,
>>  specialized knowledge and vision per project.
>>
> Well if it work better, that'd be great. However not all individuals
> live up to these standards, which is why i think maybe the drupal dev
> collective at large can better fulfill this role!
>
>  Your proposal really boils down to the question whether a project
>> maintainer is open to improvements by the Drupal community and
>> thereby takes the required, additional steps to ensure that the
>> community is able to contribute.
>>
> My proposal was to shift the responsibility from individual persons to
> a community process, to minimize possible negative influence of those.
> The process should promote and support taking responsibility by
> anyone, and hinder the opposite.
>
>
>  It's about following a certain paradigm - or not.  No automated
>> process or AI will be able to change the paradigms of humans who do
>> not want to follow a certain paradigm.
>>
> True, _but_ individuals who do not want to follow the common shared
> values may be excluded from using the community to publish their code.
> That will teach them ;)
>
>  We can measure quality in contrib (and there are plans to do so),
>> but putting regulations onto contrib hinders innovation,
>> evolution, contributions, and lastly freedom.
>>
> Yes and no. It restricts freedom, true. But why does experimental code
> need to be committed to the central repository, and how does enforcing
> an open development process hinder evolution?
>
>
>
> --
>  "Obstacles are those frightful things you see when you take
>  your eyes off your goal."         -- Henry Ford (1863-1947)
>
>  Change the world! Vote: http://hfopi.org/vote-future
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090308/446f3a75/attachment.htm 

From mpartap at gmx.net  Sun Mar  8 21:54:17 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Sun, 08 Mar 2009 22:54:17 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <efeed12d0903081349s726509ftb78d802ce67d466@mail.gmail.com>
References: <03a001c9a019$21fc01c0$0200a8c0@structworks.com>	<49B420EE.5050004@gmx.net>
	<efeed12d0903081349s726509ftb78d802ce67d466@mail.gmail.com>
Message-ID: <49B43E89.7020203@gmx.net>

Well overall it seems my proposal does not find much support here, but
anyways *g

> There are also parallels here to a comparison of publishing on the
> internet and traditional publishing in print.
Parallels, yes. But software is very different from news articles.

> And millions of people have done that which is why the internet is
> now full of junk
Well it is, and means not only wasting the time of those producing
poor content, but especially of those who don't know how to properly
use the filters.

> Google works its search magic by discovering which pages have the
> most "votes" from incoming links. Collaborative news sites such as
> digg, hacker news, reddit, and others work by voting. The best news
> bubbles up to the top.
Is not. The most popular news does. Quantity before quality - which is
why many people have difficulties penetrating that thick layer of crap
and spam to reach the real quality regions of the internet.

> Both systems of publishing content are filters -- the traditional
> system says -- "publishing is expensive, so we'll filter content
> /before/ publishing." The second system says "we can't stop people
> from publishing -- so let's devise better filters to help the best
> content still come out on top."
But what i am proposing is more like publishing it internally and not
release until a sufficient number of people agree with the quality. Ah
well the metaphor just doesn't hold. :)

> Now I hope I'm not distorting Marcel's argument here (and if I'm
> wrong I'm sure he'll correct me :)
Here i am fullfilling your prediction *g

> when I say he's arguing that there's too many modules, too many
> "bad" developers, writing too much "bad" code and we'd be all
> better off if the module landscape was less messy and more
> prestine.
Well i wouldn't have phrased it so negatively but basically, imho the
current process just leaves to much room for people to fail and
'ungood' stuff to happen.

> Perhaps this is too neat but it seems his argument falls along the
> same lines as those who say we need professional editors to filter
> content before publishing.
But this is a very different matter. The point is not so much to make
'professionals' decide about what goes in and what not, but rather
about a process that, although promoting creativity and innovative
work, in the end guarantees that stuff that goes in is worth being there.

> And I think the drupal community is already working very hard to
> do just that -- provide better filters to point site builders to
> the current "best-of-breed" modules for a given situation.
But why create bad code to filter out in the first place? Setting up a
tighter process for contrib code makes sure that developers do *have*
to make sure they are in line with the Drupal standards. Maybe
filtering out by popularity was enough of a solution for D6. Maybe it
even is for D7 - but changing the process may prove to be even a
better one.

rgds, marcel.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From Matt at NinjitsuWeb.com  Sun Mar  8 22:20:07 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Sun, 08 Mar 2009 18:20:07 -0400
Subject: [development] D7 contrib module development
In-Reply-To: <49B40887.5010504@gmx.net>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>	<49B3E495.7000805@gmx.net>	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
	<49B40887.5010504@gmx.net>
Message-ID: <49B44497.8050201@NinjitsuWeb.com>

Marcel Partap wrote:
>> If you really want to help improve contrib, then help by writing
>> more "comparisons of duplicated modules"
>> (http://drupal.org/node/266179 - though the handbook is a bit
>> messed up since the upgrade).
> Waste of time better spent on reimplementing functionality in the best 
> possible manner.

There lies the fallacy. I don't believe there is any 'one best solution' 
for most given problems, especially in Drupal.

Which is better: a simple solution that gives a few features out of the 
box, or a highly configurable, extensible solution that requires 
multiple configurations before it can be used? It depends on the site 
being built and on the site builder. In the realm of email subscription 
modules, for example, the needs of an internal documentation site versus 
a public news publishing site are very different.

Likewise, Site builders who are coders are going to be drawn to the 
module that describes itself this way:

"This is a complete Subscriptions/Notifications Framework aiming at 
extendability and escalability. It allows any number of plug-ins 
defining new event types or subscription types or a different user 
interface."

Site builders who are afraid of PHP will drawn to:

"This module allows users to subscribe to periodic emails which include 
all new or revised content and/or comments much like the daily news 
letters sent by some websites"

or, if they already know the drupal lingo and need more power, maybe:

"This module enables users to subscribe to be notified of changes to 
nodes or taxonomies, such as new comments in specific forums, or 
additions to some category of blog."

Duplicated modules aren't necessarily competing modules. I think it's 
good to have different modules focused on meeting the needs of different 
audiences. One size does not fit all.

It was suggested that some duplicated modules exist solely to feed 
developer ego. That's not the most flattering way to put it, but I have 
noticed that being the maintainer of a module does lead to business 
inquiries; I'm not keen to give up the publicity. One possible solution 
to this would be to have project pages list all the committers for a 
project, and not just the one owner. This would increase the value of 
collaboration and decrease the hesitation for developers to let a module 
die in favor or a new, truly better solution.

Best,

Matt

From mpartap at gmx.net  Sun Mar  8 23:43:13 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 00:43:13 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <49B44497.8050201@NinjitsuWeb.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>	<49B3E495.7000805@gmx.net>	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>	<49B40887.5010504@gmx.net>
	<49B44497.8050201@NinjitsuWeb.com>
Message-ID: <49B45811.1000103@gmx.net>

> There lies the fallacy. I don't believe there is any 'one best
> solution' for most given problems, especially in Drupal.
No, but what is possible is to come up with an algorithm that leads to
a statistically significant improvement on the sustainability and
correctness of decisions.

> Which is better: a simple solution that gives a few features out
> of the box, or a highly configurable, extensible solution that
> requires multiple configurations before it can be used?
Well you asked for it: better is an extensible framework which does
what 80% of the users want in the minimum/default configuration, and
can be expanded to all other use cases by activating extra modules 
(just like cck, i18n, views, xmlsitemap..).
To have different code for simple and complex use cases is what i
consider to be the worst case.

> It depends on the site being built and on the site builder. In the
> realm of email subscription modules, for example, the needs of an
> internal documentation site versus a public news publishing site
> are very different.
So a notification framework clearly needs a lot of clever thinking to
come up with a structural design that scales from small and simple to
huge and complex. That's why brainstorming on it has to start soon ;)

> Likewise, Site builders who are coders are going to be drawn to the
> module that describes itself this way:
>
> "This is a complete Subscriptions/Notifications Framework aiming at
> extendability and escalability. It allows any number of plug-ins
> defining new event types or subscription types or a different user
> interface."
>
> Site builders who are afraid of PHP will drawn to:
>
> "This module allows users to subscribe to periodic emails which
> include all new or revised content and/or comments much like the
> daily news letters sent by some websites"
>
> or, if they already know the drupal lingo and need more power,
> maybe:
>
> "This module enables users to subscribe to be notified of changes
> to nodes or taxonomies, such as new comments in specific forums, or
> additions to some category of blog."
So the solution would be two frameworks:
"Hi, i am the messaging framework and responsible for handling all
communication. You can enable different sub modules for mail, sms,
jabber, twitter, smoke signaling according to your needs." and
"This module is for handling change notifications of nodes, fields and
comments. By itself it does not expose any UI."
plus the correspondent modules building on that:
"regular notifications UI - user interface to enable intervalled
updates for all types of subscriptions"
"change notifications UI - notify users when an Drupal object changes"
"advanced subscription settings UI - provide UI for more precise
control of content subscriptions"
(something along these lines, i'm sure many people more experienced
with this stuff than me can do better)

> Duplicated modules aren't necessarily competing modules.
Disagree.
> I think it's good to have different modules focused on meeting the
> needs of different audiences.
Yes, but the clever way is to make them share code. Just like all the
.DLL and .so files on your computer, which are frameworks that
provide a broad variety of special functions for applications to use
a selected lot of them.

> One size does not fit all.
No, but reimplementing basic functionality multiple times in
incompatible ways is not exactly the clever approach either.

> It was suggested that some duplicated modules exist solely to feed
>  developer ego. That's not the most flattering way to put it, but
> I have noticed that being the maintainer of a module does lead to
> business inquiries; I'm not keen to give up the publicity.
Well the mission of drupal should definitly not to feed module
maintainers, but to strive continuously to be the best open source CMS
in existence. So this really shouldn't be influencing the decision.
Furthermore, my proposal did state that each module collects the
credits of its contributor, and i am sure we can find ways to give
hard working coders some publicity. Ever read the KDE commit digests?
They have some nice statistics at the top (people with most
commits/bug fixes/buzz)...


> One possible solution to this would be to have project pages list
> all the committers for a project, and not just the one owner. This
> would increase the value of collaboration and decrease the
> hesitation for developers to let a module die in favor or a new,
> truly better solution.
Not invasive enough. In my opinion, bold steps will result in better
results here. Trying to _promote_ a certain way of doing things or
specific values does not seem to work well enough.

Still voting for 'let the swarm maintain the modules', 'improve
code-centric tools and communication' and 'tightly enforce quality
standards for the official D7 contrib repository' here.
rgds marcel.


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From Matt at NinjitsuWeb.com  Mon Mar  9 00:09:20 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Sun, 08 Mar 2009 20:09:20 -0400
Subject: [development] D7 contrib module development
In-Reply-To: <49B45811.1000103@gmx.net>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>	<49B3E495.7000805@gmx.net>	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>	<49B40887.5010504@gmx.net>	<49B44497.8050201@NinjitsuWeb.com>
	<49B45811.1000103@gmx.net>
Message-ID: <49B45E30.1080401@NinjitsuWeb.com>



Marcel Partap wrote:
> So the solution would be two frameworks:
> "Hi, i am the messaging framework and responsible for handling all
> communication. You can enable different sub modules for mail, sms,
> jabber, twitter, smoke signaling according to your needs." and
> "This module is for handling change notifications of nodes, fields and
> comments. By itself it does not expose any UI."
> plus the correspondent modules building on that:
> "regular notifications UI - user interface to enable intervalled
> updates for all types of subscriptions"
> "change notifications UI - notify users when an Drupal object changes"
> "advanced subscription settings UI - provide UI for more precise
> control of content subscriptions"
> (something along these lines, i'm sure many people more experienced
> with this stuff than me can do better)

So now the first time site builder who just wants his friends to be able 
to decide if they want to receive email notice of new content needs to 
download and enable the right combination of at least 3 modules. Or he 
can just download and enable notify module.

As a developer, sometimes it much easier for me to write my own solution 
to my own simple problem than to take the time to learn someone else's 
framework for a generic class of similar problems. Sometimes, 
duplicating basic code is the more efficient  process, especially in a 
system as complex as you describe.

Also, the cost of change is factor in the real world. Even though notify 
module is an inferior module on several levels, it was easier to upgrade 
it to D6 than to switch to one of the newer frameworks. Probably the 
only reason notify module still exists is because it's the oldest of the 
solutions. If someone wants to write a migration tool for the 
notifications or subscriptions framework, and a UI module that 
duplicates notify's simplicity, once these are included in the framework 
download package, I will gladly shutdown notify.


Best,

Matt

From kb at 2bits.com  Mon Mar  9 00:51:00 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Sun, 8 Mar 2009 19:51:00 -0500
Subject: [development] D7 contrib module development
In-Reply-To: <e83e0db0903081109ya785b51v5bac8a195bffb88c@mail.gmail.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
	<e83e0db0903081109ya785b51v5bac8a195bffb88c@mail.gmail.com>
Message-ID: <4a9fdc630903081751j1d2b585du6eb3143d605532f3@mail.gmail.com>

On Sun, Mar 8, 2009 at 1:09 PM, Domenic Santangelo <domenic at workhabit.com>wrote:

> On Sun, Mar 8, 2009 at 8:46 AM, Stella Power <stella at stellapower.net>
> wrote:
> >
> >>   However, in the end, you get what you pay for!
> >
> > Well, Drupal is free and you don't pay for it. :)
>
> One of the things that surprised me when I started working with Drupal
> is the breadth of functionality that's left out of core. No automatic
> path aliasing? No subscribing to a post? Wait, I can't add more fields
> to my content types??? For a "Content Management System", Drupal core
> is _severely_ lacking in features.
>
> The logical end is that modules now have inflated importance to
> Drupal, because you (basically) can't do jack without at least some of
> them. This creates an odd disparity: the concept of "modules" refers
> to both one-off, unimportant, unfinished modules, AND to
> cck/views/pathauto, three modules you basically can't build a site
> without.
>

That is actually one of the strengths of Drupal. Core providing
extensibility, and
not trying to be everything for everyone, and farming out functionality to
contrib.

Contrib is where innovation happens faster than in core, because the "think
it,
code it, commit it, release it, download it, try it, improve it" cycle is
faster in
contrib. It is not dependent on a few core committers with limited times and

hundreds of tasks to get it in. People who want to try something can do it
faster
and people download and test and improve it faster as well.

The second thing is that there are many arguments of task X be done in a
certain
way, and not another. If core did something just one way, then all the
others will
be precluded without being tried in the field. By providing an extensible
framework
where people extend it in different ways, and "let the market decide" which
one is
better, or even if all of them exist at the same time, everyone wins.

Over time, we continually re-evaluate and move stuff in and out of core as
appropriate.
We pick what has been proven and get it in core, like we are doing with
fields now.
And we send other parts to contrib.

This is the open source way: It does not have to be perfect, just good
enough, and then
released to the community to tear apart, use, extend, remix, borrow,
copy/paste, ...etc.

Think of Linux: it is just a kernel and people take it and extend it, bundle
it, port it
so it runs on everything from cell phones to IBM mainframes to supercompters
and
many things in between. If Linus insisted on doing a distro early on, it may
not have
been as successful as it is now.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090308/c07de29d/attachment.htm 

From news at unleashedmind.com  Mon Mar  9 00:59:29 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Mon, 9 Mar 2009 01:59:29 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <49B45E30.1080401@NinjitsuWeb.com>
Message-ID: <03c901c9a052$4d3a2b30$0200a8c0@structworks.com>

> So now the first time site builder who just wants his friends 
> to be able to decide if they want to receive email notice of 
> new content needs to download and enable the right 
> combination of at least 3 modules. Or he can just download 
> and enable notify module.

Now your users start crying for a feature that Notify module does not
provide.  You create a patch for it, it gets committed, and Notify module is
one more step closer to be a full duplicate of other notification modules.


> As a developer, sometimes it much easier for me to write my 
> own solution to my own simple problem than to take the time 
> to learn someone else's framework for a generic class of 
> similar problems. Sometimes, duplicating basic code is the 
> more efficient  process, especially in a system as complex as 
> you describe.

The real issue starts with module integration.  User-facing modules like
Buddylist, Guestbook, Organic Groups, Privatemsg, and a lot others integrate
either with one or the other notification module.  So you end up with
Privatemsg, which integrates with Subscriptions, and Guestbook, which
integrates with Notifications.

Now, module maintainers are either forced to integrate with more than one
notification module, or none at all - requiring the notification modules to
take over the integration.  Drupal users (not developers) most often cannot
do anything about it at all.  All they could do is to install more than one
notification module, but that would obviously be a pain for their site's
users and performance.

That's why duplication hurts the entire Drupal project and community.


> Also, the cost of change is factor in the real world. Even 
> though notify module is an inferior module on several levels, 
> it was easier to upgrade it to D6 than to switch to one of 
> the newer frameworks. Probably the only reason notify module 
> still exists is because it's the oldest of the solutions. If 
> someone wants to write a migration tool for the notifications 
> or subscriptions framework, and a UI module that duplicates 
> notify's simplicity, once these are included in the framework 
> download package, I will gladly shutdown notify.

As long as there is this duplication, this won't happen anytime soon.  Both
modules, Subscriptions and Notifications, suffer from their own duplication
- code-wise, feature-wise, as well as usability-wise.  The same applies to
other duplicated modules.

sun


From kb at 2bits.com  Mon Mar  9 01:07:25 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Sun, 8 Mar 2009 20:07:25 -0500
Subject: [development] D7 contrib module development
In-Reply-To: <49B40887.5010504@gmx.net>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
	<49B40887.5010504@gmx.net>
Message-ID: <4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>

> To be honest, I think this is an absolutely terrible idea.  It's
>> just not scalable.  We've got thousands of contributed modules and
>> themes, which makes for millions of lines of code. To ask that we
>> can have a core team of developers managing contrib patches,
>>
> Quite frankly that's not what i'm proposing, out of the reasons you
> just stated.
> BTW although according to
> wget -qO - http://ftp.drupal.org/files/projects/|html2text<http://ftp.drupal.org/files/projects/%7Chtml2text>-width 130 -nobs|'grep' "\-6.x\-"|sed 's/\[\[   \]\]//;s/-6.*//'|sort -u|wc
> -l
> there currently are 2227 D6 contrib projects (compared to 2827 for D5) - do
> you really think all of those provide a useful benefit to the community? how
> many of those are deprecated, unmaintained or plain useless? Even then we
> can prevent that from happening on D7 *without* destroying what's already
> there. D6 will live on for perhaps up to a decade anyways... There are still
> D4 sites out there!
>

Yes, your observation is correct, but  ... so what?

We've always had stuff that falls off the face of earth. So what? The
caravan continues on ...

The very first module I contributed (feedback) illustrates a point: It was
started in 2002 by someone called "barry". I had it working I took it over
in 2004 with totally new code for Drupal 4.5. Then "fago" overhauled it a
lot in 2006. Over time, the contact module in core came along, and I stopped
using feedback. Then in 2008 "sun" took it over and repurposed it with new
code.

The "too many modules in contrib syndrome" can be taken as confusing,
excessive, ...etc. but can also be taken as a sign of a healthy and vibrant
community. So what if we have a few extra gigabytes of code? So what if they
become unmaintained?

If we raise the barrier or block new entries we will be shutting ourselves
off from being the platform for the new chx or the new merlinofchaos.

It does not matter ... if it is the wild wild west, then let it be. It is a
small price to pay for innovation and the power of the masses.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090308/ed0fe729/attachment.htm 

From gerhard at killesreiter.de  Mon Mar  9 01:27:18 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Mon, 09 Mar 2009 02:27:18 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <03c901c9a052$4d3a2b30$0200a8c0@structworks.com>
References: <03c901c9a052$4d3a2b30$0200a8c0@structworks.com>
Message-ID: <49B47076.5000807@killesreiter.de>

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

Daniel F. Kudwien schrieb:
>> So now the first time site builder who just wants his friends 
>> to be able to decide if they want to receive email notice of 
>> new content needs to download and enable the right 
>> combination of at least 3 modules. Or he can just download 
>> and enable notify module.
> 
> Now your users start crying for a feature that Notify module does
> not provide.  You create a patch for it, it gets committed, and
> Notify module is one more step closer to be a full duplicate of
> other notification modules.

If the cries of your users get too loud it's time to either close the
door or crank up the sound level...



Or you could create a migration script to one of the more advanced
notification modules.


>> As a developer, sometimes it much easier for me to write my own
>> solution to my own simple problem than to take the time to learn
>> someone else's framework for a generic class of similar
>> problems. Sometimes, duplicating basic code is the more efficient
>> process, especially in a system as complex as you describe.
> 
> The real issue starts with module integration.  User-facing modules
> like Buddylist, Guestbook, Organic Groups, Privatemsg, and a lot
> others integrate either with one or the other notification module.
> So you end up with Privatemsg, which integrates with Subscriptions,
> and Guestbook, which integrates with Notifications.
> 
> Now, module maintainers are either forced to integrate with more
> than one notification module, or none at all - requiring the
> notification modules to take over the integration.


I believe the latter way is the way to go. Drupal core should make
this process easy by providing hooks etc.

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

iEYEARECAAYFAkm0cHUACgkQfg6TFvELooSvCQCgqN6Wj6CBHch5vPtrhhdb8p01
rmIAnjJXiNdJPNlYpoNO6vM8iv5We7Xu
=n4Lk
-----END PGP SIGNATURE-----

From Matt at NinjitsuWeb.com  Mon Mar  9 02:08:05 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Sun, 08 Mar 2009 22:08:05 -0400
Subject: [development] D7 contrib module development
In-Reply-To: <03c901c9a052$4d3a2b30$0200a8c0@structworks.com>
References: <03c901c9a052$4d3a2b30$0200a8c0@structworks.com>
Message-ID: <49B47A05.6090901@NinjitsuWeb.com>

Daniel F. Kudwien wrote:
> Now your users start crying for a feature that Notify module does not
> provide.  You create a patch for it, it gets committed, and Notify module is
> one more step closer to be a full duplicate of other notification modules.
>   

If you had read the project page or the issue queue for notify, you 
would not have said this. I have a number of issue threads that end in 
'I found this other combination of modules to do what I wanted' and I'm 
thrilled, because, as I said, I don't believe that duplicate modules are 
necessarily competitors.

The solution is not always to eliminate modules that duplicate 
functionality; the key is to educate maintainers about the other 
modules, so that they can effectively recommend the best solutions to 
crying users.

Much like the discussions of backward compatibility, if people would get 
out of the academic theory and actually read/write/port/use the code, 
we'd avoid a lot of needless FUD and abstract arguments that produce 
nothing.

(I'm not referring specifically to Daniel's comments here; he & I are 
largely in agreement on the issue, I think.)

Best,

Matt

From drupal at dwwright.net  Mon Mar  9 07:55:25 2009
From: drupal at dwwright.net (Derek Wright)
Date: Mon, 9 Mar 2009 00:55:25 -0700
Subject: [development] "Accepted" status for issues
In-Reply-To: <20090308093131.oi37d7htrn4sg8c8@mail.progw.org>
References: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
	<20090308093131.oi37d7htrn4sg8c8@mail.progw.org>
Message-ID: <2104F763-5C34-4AC4-BEAB-5FA8BA28E264@dwwright.net>


On Mar 8, 2009, at 6:31 AM, Earnie Boyd wrote:

> I would like for each project to be able to add or remove statuses  
> to their liking but I don't have time to work a patch and it isn't  
> as important as other items on the list.

That'd be a pain for various reasons.  For one thing, it'd be  
impossible to filter by status across projects if the set of possible  
values was different on each project.  Basically, status would become  
just like component in the current issue queues, and I think that's a  
step in the wrong direction.


On Mar 8, 2009, at 7:01 AM, Stella Power wrote:

> There's already an issue open on d.o about re-organising the issue  
> status settings - http://drupal.org/node/171350

I hoped to have time on the flight home to look at this closely, but  
was dealing with other things.  My initial impression of that proposal  
(and what Earnie is saying above) is that we need *less* distinct  
status values, not more.  For all the subtle, fine-grained stuff  
people keep wanting, that we should use issue tagging (or a separate  
"Status reason" vocabulary) instead.  But, I'll reply with a more  
coherent counter-proposal at #171350 when I can.

Cheers,
-Derek (dww)




From earnie at users.sourceforge.net  Mon Mar  9 11:40:28 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 09 Mar 2009 07:40:28 -0400
Subject: [development] "Accepted" status for issues
In-Reply-To: <2104F763-5C34-4AC4-BEAB-5FA8BA28E264@dwwright.net>
References: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
	<20090308093131.oi37d7htrn4sg8c8@mail.progw.org>
	<2104F763-5C34-4AC4-BEAB-5FA8BA28E264@dwwright.net>
Message-ID: <20090309074028.tokdd1wellzzkskg@mail.progw.org>

Quoting Derek Wright <drupal at dwwright.net>:

>
> On Mar 8, 2009, at 6:31 AM, Earnie Boyd wrote:
>
>> I would like for each project to be able to add or remove statuses  
>> to their liking but I don't have time to work a patch and it isn't  
>> as important as other items on the list.
>
> That'd be a pain for various reasons.  For one thing, it'd be  
> impossible to filter by status across projects if the set of possible 
>  values was different on each project.  Basically, status would 
> become  just like component in the current issue queues, and I think 
> that's a  step in the wrong direction.
>

Thanks for the explanation Derek.

>
> On Mar 8, 2009, at 7:01 AM, Stella Power wrote:
>
>> There's already an issue open on d.o about re-organising the issue  
>> status settings - http://drupal.org/node/171350
>
> I hoped to have time on the flight home to look at this closely, but  
> was dealing with other things.  My initial impression of that 
> proposal  (and what Earnie is saying above) is that we need *less* 
> distinct  status values, not more.  For all the subtle, fine-grained 
> stuff  people keep wanting, that we should use issue tagging (or a 
> separate  "Status reason" vocabulary) instead.  But, I'll reply with 
> a more  coherent counter-proposal at #171350 when I can.
>

I really appreciate the work you do to keep project improving.  It is 
one of the things that sets Drupal apart from some other projects.  I 
just wish I had more time to help you.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From mpartap at gmx.net  Mon Mar  9 15:28:22 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 16:28:22 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>	<49B3E495.7000805@gmx.net>	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>	<49B40887.5010504@gmx.net>
	<4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>
Message-ID: <49B53596.7040106@gmx.net>

> We've always had stuff that falls off the face of earth. So what? The
> caravan continues on ...
Sorry but i don't consider that a logically valid argument.

> The very first module I contributed (feedback) illustrates a point: It
> was started in 2002 by someone called "barry". I had it working I took
> it over in 2004 with totally new code for Drupal 4.5. Then "fago"
> overhauled it a lot in 2006. Over time, the contact module in core came
> along, and I stopped using feedback. Then in 2008 "sun" took it over and
> repurposed it with new code.
Well good that process worked out than, btw i am actually using the 
module ;)
But from the experiences gained, how would you design such a module 
from scratch? How could it be integrated with other modules, what 
could be factored out into 'frameworks' (/library modules) ?
That is the stuff each of the drupal code contributors needs to think 
about as early as possible in the D7 cycle, which would be right 
about.. _now_!


> The "too many modules in contrib syndrome" can be taken as confusing,
> excessive, ...etc. but can also be taken as a sign of a healthy and
> vibrant community.
Sure. But what is the prior goal of the Drupal project? To create a 
healthy vibrant community? Or to create the best open source CMS CODE 
out there (best accomplished through a healthy vibrant community)?

> So what if we have a few extra gigabytes of code? So
> what if they become unmaintained?
Uhhm sorry i don't share that so-what mentality. I want to have *all* 
the functionality spread over slightly different modules with the same 
purpose, combined into one flexible solution. And i am quite sure i am 
not the only one.

> If we raise the barrier or block new entries we will be shutting
> ourselves off from being the platform for the new chx or the new
> merlinofchaos.
Woow stop for a minute please.. so you're saying people like chx or 
merlinofchaos are not capable of adapting to coding standards and 
qualified to contribute code which can be worked on to raise over the 
ready-and-useful barrier to be included in the official Drupal repository?

> It does not matter ... if it is the wild wild west, then let it be. It
> is a small price to pay for innovation and the power of the masses.
But the thing is, sometimes innovation needs channeling. Granted, in 
the early phases of the industrial revolution it would have been 
counterproductive to regulate machines and processes in any manner, 
simply because not enough practical experience had been gained. But 
once a certain level of sophistication is reached, there is no way you 
want to live without agreed standard interfaces and common norms. 
Imagine todays industries without all the ISO standards for screws, 
bearings, gears, quality management.. What do you think which kind of 
a car would you drive if none of them would exist?
In my opinion with D7 we have reached that level of wild life 
experience to benefit from a more ordered development process. To say 
again, why trade in quality for quantity/speed? Most people will be 
quite happy with D6 for years to come.

rgds marcel.



-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From kb at 2bits.com  Mon Mar  9 16:00:48 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Mon, 9 Mar 2009 12:00:48 -0400
Subject: [development] D7 contrib module development
In-Reply-To: <49B53596.7040106@gmx.net>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
	<49B40887.5010504@gmx.net>
	<4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>
	<49B53596.7040106@gmx.net>
Message-ID: <4a9fdc630903090900v5088ea71v58bdd6c22ec5d05f@mail.gmail.com>

On Mon, Mar 9, 2009 at 11:28 AM, Marcel Partap <mpartap at gmx.net> wrote:

> We've always had stuff that falls off the face of earth. So what? The
>> caravan continues on ...
>>
> Sorry but i don't consider that a logically valid argument.
>

What I meant is modules come and disappear all the time. This
experimentation has proven to be healthy, and the project is healthy despite
that.

It is not a negative to have unmaintained modules and such, given that
others are thriving.


>
>  The very first module I contributed (feedback) illustrates a point: It
>> was started in 2002 by someone called "barry". I had it working I took
>> it over in 2004 with totally new code for Drupal 4.5. Then "fago"
>> overhauled it a lot in 2006. Over time, the contact module in core came
>> along, and I stopped using feedback. Then in 2008 "sun" took it over and
>> repurposed it with new code.
>>
> Well good that process worked out than, btw i am actually using the module
> ;)
> But from the experiences gained, how would you design such a module from
> scratch?


In the four instances, the code was rewritten from scratch, preserving the
name and often obsoleting the prior functionality.

How could it be integrated with other modules, what could be factored out
> into 'frameworks' (/library modules) ?


It happens naturally. For example userpoints started as an application, then
people wrote more applications for it, it was all in a single project. Later
we took out the community contributions and split them into the
userpoints_contrib project. Then we split off ANY and ALL applications (what
used to be userpoints_basic, now userpoints_nc) leaving only the API in the
project.

Views started the same way with splitting off the bonus pack ...etc.

What I am saying it happens naturally as people realize that they are
evolving their pet project into an API/Framework over time.


> That is the stuff each of the drupal code contributors needs to think about
> as early as possible in the D7 cycle, which would be right about.. _now_!
>
>
>  The "too many modules in contrib syndrome" can be taken as confusing,
>> excessive, ...etc. but can also be taken as a sign of a healthy and
>> vibrant community.
>>
> Sure. But what is the prior goal of the Drupal project? To create a healthy
> vibrant community? Or to create the best open source CMS CODE out there
> (best accomplished through a healthy vibrant community)?
>

The vibrant community leads to the best open source CMS code.

Creating the best CMS code does not mean that the default download be
bloated with hundreds of modules that not everyone will use.

As I said: kernel -> distros. One for education, one commerically supported,
another for high traffic sites, another for whatever.

It is working out ...


>
>
>  So what if we have a few extra gigabytes of code? So
>> what if they become unmaintained?
>>
> Uhhm sorry i don't share that so-what mentality.


You miss the fact that this is an ecosystem, and you have all kind of
relationships: symbiosis, parasitism, commensalism, ..etc.

You can't dictate what happens in contrib without stifling the innovation
that this ecosystem has.
We can nudge people to work together but we can't force them to.


> I want to have *all* the functionality spread over slightly different
> modules with the same purpose, combined into one flexible solution. And i am
> quite sure i am not the only one.
>

You are advocating the "one true way". But without letting people
experiment, that one true way could be the one with less features, with a
non-committed maintainer, could be buggy, ...etc. You don't know until you
put it out there and let the ecosystem decide. Who will decide the one true
way? Committee? Hierarchy? Nope, sorry. Don't want that in a community led
project. Might as well go to commercial CMSs then.

What we can do is let things evolve for a while and then naturally a winner
or two will emerge from the fray. As disconcerting this is to some, it is a
sure way to have a proven solution for the problem space.


>
>  If we raise the barrier or block new entries we will be shutting
>> ourselves off from being the platform for the new chx or the new
>> merlinofchaos.
>>
> Woow stop for a minute please.. so you're saying people like chx or
> merlinofchaos are not capable of adapting to coding standards and qualified
> to contribute code which can be worked on to raise over the ready-and-useful
> barrier to be included in the official Drupal repository?
>

No. I am saying is that without seeing people contribute for some time you
don't know before hand if they will turn to be a drive-by contributor of a
so-so project, or the author of the next big hit.

And it is not only about technical prowess, it is about how you work with
the community, are you committed to the community and Drupal, do you
encourage others who use/contribute to your project, and much more. All that
cannot be seen just from the first contribution adherence to coding
standards.


>
>
>  It does not matter ... if it is the wild wild west, then let it be. It
>> is a small price to pay for innovation and the power of the masses.
>>
> But the thing is, sometimes innovation needs channeling. Granted, in the
> early phases of the industrial revolution it would have been
> counterproductive to regulate machines and processes in any manner, simply
> because not enough practical experience had been gained. But once a certain
> level of sophistication is reached, there is no way you want to live without
> agreed standard interfaces and common norms. Imagine todays industries
> without all the ISO standards for screws, bearings, gears, quality
> management.. What do you think which kind of a car would you drive if none
> of them would exist?


Fair point, standards will arise across CMS's too, such as the new proposed
CMIS that makes them interoperate. There are differences in an information
world than an industrial one too (capital required, barrier to entry, ...)

But the argument is : are we at that point yet? Is it now? I don't think so
myself.

But within Drupal, I don't see we are the point where we have a central body
.

Later maybe? Perhaps. But not now. When you see a majority of the community
cry for that, then it is time to re-evaluate.


> In my opinion with D7 we have reached that level of wild life experience to
> benefit from a more ordered development process. To say again, why trade in
> quality for quantity/speed? Most people will be quite happy with D6 for
> years to come.
>

Again, you see "now is the time", I see "not now".

As for D6, it will not get security support forever. So those who use it are
on their own after D9 comes out, whenever that is.


>
>
> rgds marcel.
>
>
>
> --
>  "Obstacles are those frightful things you see when you take
>  your eyes off your goal."         -- Henry Ford (1863-1947)
>
>  Change the world! Vote: http://hfopi.org/vote-future
>



-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/72459333/attachment.htm 

From catch56 at googlemail.com  Mon Mar  9 16:09:38 2009
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Mon, 9 Mar 2009 12:09:38 -0400
Subject: [development] D7 contrib module development
In-Reply-To: <49B53596.7040106@gmx.net>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
	<49B40887.5010504@gmx.net>
	<4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>
	<49B53596.7040106@gmx.net>
Message-ID: <fa5724270903090909h76217440haf2b03b212d5b186@mail.gmail.com>

> Sure. But what is the prior goal of the Drupal project? To create a healthy
> vibrant community? Or to create the best open source CMS CODE out there
> (best accomplished through a healthy vibrant community)?



If we lost all the code tomorrow, we'd have 400,000 to put it back together
(even if 1% of that are active coders that's still 4,000 people to actually
write it). If the community gets collectively pissed off, everything falls
apart.


>
>
>  So what if we have a few extra gigabytes of code? So
>> what if they become unmaintained?
>>
> Uhhm sorry i don't share that so-what mentality. I want to have *all* the
> functionality spread over slightly different modules with the same purpose,
> combined into one flexible solution. And i am quite sure i am not the only
> one.


This is already happening - every release, Views and CCK make another 1-200
modules obsolete. That some modules get ported anyway makes them more
obsolescent than obsolete - but unless all the maintainers provide
rock-solid migration paths (much harder than a port), there's not much to do
about that.



 If we raise the barrier or block new entries we will be shutting
> ourselves off from being the platform for the new chx or the new
> merlinofchaos.
>
Woow stop for a minute please.. so you're saying people like chx or
> merlinofchaos are not capable of adapting to coding standards and qualified
> to contribute code which can be worked on to raise over the ready-and-useful
> barrier to be included in the official Drupal repository?


Most of our major contributors didn't start off in the Drupal community
fully formed and descended from heaven, even chx and merlinofchaos. In terms
of core contributors - I''m credited with a lot of patches against Drupal 7,
I pretty much learned PHP reviewing and writing patches against Drupal 6. If
my interest was in contrib rather than core, your new rules would've been a
major barrier to getting involved. Fortunately anyone can upload any patch
they like to the core issue queue, getting beyond that is where it takes a
lot of effort.

And we already have a filter for people applying for a CVS account which
tries to weed out the worst quality code or obvious duplication.


 It does not matter ... if it is the wild wild west, then let it be. It
> is a small price to pay for innovation and the power of the masses.
>
But the thing is, sometimes innovation needs channeling. Granted, in the
> early phases of the industrial revolution it would have been
> counterproductive to regulate machines and processes in any manner, simply
> because not enough practical experience had been gained. But once a certain
> level of sophistication is reached, there is no way you want to live without
> agreed standard interfaces and common norms.


Standards are emergent. Look at USB, high definition DVDs, RDF, SPARQL etc.
The car industry is a terrible example to give, given most modern cars are
really inefficient, and the whole thing is collapsing at the moment.


>
> In my opinion with D7 we have reached that level of wild life experience to
> benefit from a more ordered development process. To say again, why trade in
> quality for quantity/speed? Most people will be quite happy with D6 for
> years to come.


Have you looked at Drupal 7 yet? How familiar are you with the core
development process? While I'd love to see some consolidation in contrib, I
don't see any realistic proposals for handling this, rather than mythical
hordes of people who'll magically appear to review patches for contrib as
well as core.

I'd love to see code quality metrics (both coder and test coverage) for
modules, and that combined with usage and other metrics. With that, the
unmaintained modules will naturally get filtered out to the bottom.

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

From mpartap at gmx.net  Mon Mar  9 16:52:02 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 17:52:02 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <4a9fdc630903090900v5088ea71v58bdd6c22ec5d05f@mail.gmail.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>	<49B3E495.7000805@gmx.net>	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>	<49B40887.5010504@gmx.net>	<4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>	<49B53596.7040106@gmx.net>
	<4a9fdc630903090900v5088ea71v58bdd6c22ec5d05f@mail.gmail.com>
Message-ID: <49B54932.8020103@gmx.net>

> It is not a negative to have unmaintained modules and such, given that
> others are thriving.
Well what if unmaintained/bad modules are sucking the time of users 
and developers and annoying them for no good reason? Not negative?

>     How could it be integrated with other modules, what could be
>     factored out into 'frameworks' (/library modules) ?
> It happens naturally.
Very well. But there's a reason bioengineering is the latest hype: it 
is a lot FASTER and more DIRECTED than the evolutionary process.

> What I am saying it happens naturally as people realize that they are
> evolving their pet project into an API/Framework over time.
At our university we are taught: the more brainwork you invest early 
on in the development process, the less headache you'll have to cope with.



>> Sure. But what is the prior goal of the Drupal project? To create a
>> healthy vibrant community? Or to create the best open source CMS
>> CODE out there (best accomplished through a healthy vibrant community)?
> The vibrant community leads to the best open source CMS code.
No, not by itself. It needs some structural algorithm to have things 
develop into that direction.

> You miss the fact that this is an ecosystem, and you have all kind of
> relationships: symbiosis, parasitism, commensalism, ..etc.
If they interfere with the creation of top-most quality code - they 
should be prevented from doing that. If people can make money offering 
drupal services to customers: fine. Should the development process of 
an open source project try to facilitate that? I don't think so.

> You can't dictate what happens in contrib without stifling the
> innovation that this ecosystem has.
Who's talking about dictating.. Everyone can code freely. But for code 
to enter the official repository, quality checks should apply. That 
doesn't stop innovation, does it? Look at the few commits to the 
cck/views branches for example. Why is that kind of responsible code 
committing not scalable to all other modules as well?

> We can nudge people to work together but we can't force them to.
Well not many people who score goals by hand have made successfull 
career in football. How comes? Might it be that whoever doesn't 
respect the rules will not be allowed to play?


>> I want to have *all* the functionality spread over slightly
>> different modules with the same purpose, combined into one flexible
>> solution. And i am quite sure i am not the only one.
> You are advocating the "one true way".
Am not. What i am advocating is a process that makes problems that 
occured in the past less likely to happen.



> But without letting people
> experiment
Why is not letting experimental code into the repository stopping 
people from trying stuff out? Please explain that to me, i simply 
don't get that.

> that one true way could be the one with less features, with
> a non-committed maintainer, could be buggy, ...etc. You don't know until
> you put it out there and let the ecosystem decide.

> Who will decide the one true way? Committee? Hierarchy?
No - the swarm, that is us. We all work together on finding the best 
way to lay the foundation for the respective functionality. Aren't we 
already doing that with core? Is it impossible to apply to non-core 
modules?

> What we can do is let things evolve for a while and then naturally a
> winner or two will emerge from the fray.
So please tell me, what is the winning change notification framework? 
Notifications, Subscriptions, Comment Notify, Notify, ...?
Which is the best module to create sophisticated web questionnaires? 
Is it webforms? Advanced Poll? Decisions?
Do you really want to have the same situation with D7? Not terribly 
user-friendly, is it?


> As disconcerting this is to
> some, it is a sure way to have a proven solution for the problem space.
Is not. It might be sufficient, but it surely isn't the optimum.

> No. I am saying is that without seeing people contribute for some time
> you don't know before hand if they will turn to be a drive-by
> contributor of a so-so project, or the author of the next big hit.
Why is applying quality checks before applying code to the official 
repository making it harder for people to code, experiment, innovate? 
How does having each submission routinely reviewed by the community 
stop anyone to contribute?

> All that cannot be seen just from the first contribution adherence to
> coding standards.
Whos talking about judging people by their first code? But what is a 
good reason for the first contribution of someone starting to learn 
drupal to be included in the official repository? Wouldn't it be much 
more helpful to receive comments and tips in the discussion thread for 
their patch?

> Fair point, standards will arise across CMS's too
Didn't even touch _that_ topic.

> But within Drupal, I don't see we are the point where we have a central
> body .
Well i didn't propose a central committee, but for the whole community 
to pick up quality checking and maintain the modules as a huge diverse 
team. Sounds implausible? Well who's stopping us from trying.


> Later maybe? Perhaps. But not now. When you see a majority of the
> community cry for that, then it is time to re-evaluate.
At the time people are crying it usually is a bit late.

>     rgds marcel.


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From starbow at citris-uc.org  Mon Mar  9 16:52:13 2009
From: starbow at citris-uc.org (Tao Starbow)
Date: Mon, 09 Mar 2009 09:52:13 -0700
Subject: [development] "Accepted" status for issues
In-Reply-To: <2104F763-5C34-4AC4-BEAB-5FA8BA28E264@dwwright.net>
References: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
	<20090308093131.oi37d7htrn4sg8c8@mail.progw.org>
	<2104F763-5C34-4AC4-BEAB-5FA8BA28E264@dwwright.net>
Message-ID: <49B5493D.1000803@citris-uc.org>

I like the idea of managing my list with issue tags.  We'd just need to 
be able to see them in the table at http://drupal.org/project/user, and 
filter by them.
Is there an open issue for this?

-tao

Derek Wright wrote:
>
> On Mar 8, 2009, at 6:31 AM, Earnie Boyd wrote:
>
>> I would like for each project to be able to add or remove statuses to 
>> their liking but I don't have time to work a patch and it isn't as 
>> important as other items on the list.
>
> That'd be a pain for various reasons.  For one thing, it'd be 
> impossible to filter by status across projects if the set of possible 
> values was different on each project.  Basically, status would become 
> just like component in the current issue queues, and I think that's a 
> step in the wrong direction.
>
>
> On Mar 8, 2009, at 7:01 AM, Stella Power wrote:
>
>> There's already an issue open on d.o about re-organising the issue 
>> status settings - http://drupal.org/node/171350
>
> I hoped to have time on the flight home to look at this closely, but 
> was dealing with other things.  My initial impression of that proposal 
> (and what Earnie is saying above) is that we need *less* distinct 
> status values, not more.  For all the subtle, fine-grained stuff 
> people keep wanting, that we should use issue tagging (or a separate 
> "Status reason" vocabulary) instead.  But, I'll reply with a more 
> coherent counter-proposal at #171350 when I can.
>
> Cheers,
> -Derek (dww)
>
>
>

From michael at favias.org  Mon Mar  9 16:53:32 2009
From: michael at favias.org (Michael Favia)
Date: Mon, 09 Mar 2009 11:53:32 -0500
Subject: [development] Wasting time and effort
Message-ID: <49B5498C.6000208@favias.org>

I've noticed an increasing number of "meta discussions" and I'd like to 
try to refocus our collective efforts if possible. All of these 
discussions about regulating contribution module development or only 
releasing core when the top X modules are upgraded, are more distracting 
then they are productive in my opinion. It is a dearth of labor not a 
lack of ideas that is the bottleneck of this project and almost every 
one of the issues raised could be fixed by more work in place of 
increased regulation.

The ordinary folks who review and create patches on issues are our 
lifeblood and engine. While it might not be as glorifying as 
re-imagining the contribution module ecosystem or as easy as writing an 
email, we notice and value your effort for the real contribution that it 
is. We dont need more regulation, we need more contribution. So lets 
pick up our shovels instead of our pens and get to work (myself 
included). If you don't know how and want to learn how just ask in 
channel and I'll be happy to help you personally. -mf

From nan_wich at bellsouth.net  Mon Mar  9 16:55:14 2009
From: nan_wich at bellsouth.net (Nancy Wichmann)
Date: Mon, 9 Mar 2009 12:55:14 -0400
Subject: [development] An alternative to common thinking in 5->6 migration
In-Reply-To: <fa5724270903090909h76217440haf2b03b212d5b186@mail.gmail.com>
Message-ID: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>

In moving modules from 5.x to 6.x it is commonly suggested to move our
?drupal_add_css? (and _js) into hook_init.  Ceratinly I did this in nearly
all my modules because it was the common suggestion. However, now that I?m
making a big change in one and having problems with the CSS, it dawned on me
that this suggestion adds the CSS files to *every* page, not just the ones
we were targeting. It finally dawned on me that I have hook_help that only
fires on the pages I need to CSS on, so I moved the ?drupal_add_css? into
hook_help, which to me makes a lot more sense because now my CSS is only
applied to those pages for which it is intended.  What do others think of
this? Are there pitfalls I may not have covered?

Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/8b5fc8ac/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: multipart/alternative
Size: 0 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20090309/8b5fc8ac/attachment.bin 
-------------- next part --------------

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.11.9/1990 - Release Date: 3/8/2009 5:17 PM

From sirkitree at gmail.com  Mon Mar  9 16:58:26 2009
From: sirkitree at gmail.com (Jerad Bitner)
Date: Mon, 9 Mar 2009 09:58:26 -0700
Subject: [development] Wasting time and effort
In-Reply-To: <49B5498C.6000208@favias.org>
References: <49B5498C.6000208@favias.org>
Message-ID: <215a89c90903090958l2d5515e5y476fb6b1c88d4a3b@mail.gmail.com>

here here!

On Mon, Mar 9, 2009 at 9:53 AM, Michael Favia <michael at favias.org> wrote:

> I've noticed an increasing number of "meta discussions" and I'd like to try
> to refocus our collective efforts if possible. All of these discussions
> about regulating contribution module development or only releasing core when
> the top X modules are upgraded, are more distracting then they are
> productive in my opinion. It is a dearth of labor not a lack of ideas that
> is the bottleneck of this project and almost every one of the issues raised
> could be fixed by more work in place of increased regulation.
>
> The ordinary folks who review and create patches on issues are our
> lifeblood and engine. While it might not be as glorifying as re-imagining
> the contribution module ecosystem or as easy as writing an email, we notice
> and value your effort for the real contribution that it is. We dont need
> more regulation, we need more contribution. So lets pick up our shovels
> instead of our pens and get to work (myself included). If you don't know how
> and want to learn how just ask in channel and I'll be happy to help you
> personally. -mf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/de08920e/attachment-0001.htm 

From kb at 2bits.com  Mon Mar  9 17:00:27 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Mon, 9 Mar 2009 13:00:27 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <49B5498C.6000208@favias.org>
References: <49B5498C.6000208@favias.org>
Message-ID: <4a9fdc630903091000v63a23d90yf2768911550d9d09@mail.gmail.com>

On Mon, Mar 9, 2009 at 12:53 PM, Michael Favia <michael at favias.org> wrote:

> I've noticed an increasing number of "meta discussions" and I'd like to try
> to refocus our collective efforts if possible. All of these discussions
> about regulating contribution module development or only releasing core when
> the top X modules are upgraded, are more distracting then they are
> productive in my opinion. It is a dearth of labor not a lack of ideas that
> is the bottleneck of this project and almost every one of the issues raised
> could be fixed by more work in place of increased regulation.
>
> The ordinary folks who review and create patches on issues are our
> lifeblood and engine. While it might not be as glorifying as re-imagining
> the contribution module ecosystem or as easy as writing an email, we notice
> and value your effort for the real contribution that it is. We dont need
> more regulation, we need more contribution.


Amen to that!

Well said ...
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/ec8bb165/attachment.htm 

From ezra at growingventuresolutions.com  Mon Mar  9 17:01:36 2009
From: ezra at growingventuresolutions.com (Ezra B. Gildesgame)
Date: Mon, 9 Mar 2009 13:01:36 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <4a9fdc630903091000v63a23d90yf2768911550d9d09@mail.gmail.com>
References: <49B5498C.6000208@favias.org>
	<4a9fdc630903091000v63a23d90yf2768911550d9d09@mail.gmail.com>
Message-ID: <ccbb750f0903091001p76b2a3e5ge9a8437f4aa74dcb@mail.gmail.com>

Thanks for this!


On Mon, Mar 9, 2009 at 1:00 PM, Khalid Baheyeldin <kb at 2bits.com> wrote:
> On Mon, Mar 9, 2009 at 12:53 PM, Michael Favia <michael at favias.org> wrote:
>>
>> I've noticed an increasing number of "meta discussions" and I'd like to
>> try to refocus our collective efforts if possible. All of these discussions
>> about regulating contribution module development or only releasing core when
>> the top X modules are upgraded, are more distracting then they are
>> productive in my opinion. It is a dearth of labor not a lack of ideas that
>> is the bottleneck of this project and almost every one of the issues raised
>> could be fixed by more work in place of increased regulation.
>>
>> The ordinary folks who review and create patches on issues are our
>> lifeblood and engine. While it might not be as glorifying as re-imagining
>> the contribution module ecosystem or as easy as writing an email, we notice
>> and value your effort for the real contribution that it is. We dont need
>> more regulation, we need more contribution.
>
> Amen to that!
>
> Well said ...
> --
> Khalid M. Baheyeldin
> 2bits.com, Inc.
> http://2bits.com
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. -- ?Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. -- ? Leonardo da Vinci
>



-- 
Ezra Barnett Gildesgame
http://growingventuresolutions.com
http://ezra-g.com

From sirkitree at gmail.com  Mon Mar  9 16:58:26 2009
From: sirkitree at gmail.com (Jerad Bitner)
Date: Mon, 9 Mar 2009 09:58:26 -0700
Subject: [development] Wasting time and effort
In-Reply-To: <49B5498C.6000208@favias.org>
References: <49B5498C.6000208@favias.org>
Message-ID: <215a89c90903090958l2d5515e5y476fb6b1c88d4a3b@mail.gmail.com>

here here!

On Mon, Mar 9, 2009 at 9:53 AM, Michael Favia <michael at favias.org> wrote:

> I've noticed an increasing number of "meta discussions" and I'd like to try
> to refocus our collective efforts if possible. All of these discussions
> about regulating contribution module development or only releasing core when
> the top X modules are upgraded, are more distracting then they are
> productive in my opinion. It is a dearth of labor not a lack of ideas that
> is the bottleneck of this project and almost every one of the issues raised
> could be fixed by more work in place of increased regulation.
>
> The ordinary folks who review and create patches on issues are our
> lifeblood and engine. While it might not be as glorifying as re-imagining
> the contribution module ecosystem or as easy as writing an email, we notice
> and value your effort for the real contribution that it is. We dont need
> more regulation, we need more contribution. So lets pick up our shovels
> instead of our pens and get to work (myself included). If you don't know how
> and want to learn how just ask in channel and I'll be happy to help you
> personally. -mf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/de08920e/attachment-0002.htm 

From mpartap at gmx.net  Mon Mar  9 17:11:52 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 18:11:52 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <fa5724270903090909h76217440haf2b03b212d5b186@mail.gmail.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>	<49B3E495.7000805@gmx.net>	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>	<49B40887.5010504@gmx.net>	<4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>	<49B53596.7040106@gmx.net>
	<fa5724270903090909h76217440haf2b03b212d5b186@mail.gmail.com>
Message-ID: <49B54DD8.2000904@gmx.net>


> If the community gets collectively pissed off, everything falls apart.
If we as community take the decision to change the process, why would 
that piss us off?

> That some modules get ported anyway makes them
> more obsolescent than obsolete - but unless all the maintainers provide
> rock-solid migration paths (much harder than a port), there's not much
> to do about that.
Well how is that impossible to achieve after having settled on new 
framework designs? It's just a simple matter of converting DB fields 
isn't it.

> Most of our major contributors didn't start off in the Drupal community
> fully formed and descended from heaven, even chx and merlinofchaos. In
> terms of core contributors - I''m credited with a lot of patches against
> Drupal 7, I pretty much learned PHP reviewing and writing patches
> against Drupal 6. If my interest was in contrib rather than core, your
> new rules would've been a major barrier to getting involved.
How does preventing bad code from landing in the repository make it 
harder for you to get involved? Why is it not possible to erect a 
support system that facilitates easier reviewing and testing of code 
not in the repo.

> Fortunately anyone can upload any patch they like to the core issue queue, getting
> beyond that is where it takes a lot of effort.
To make the same apply for non-core modules is what i am proposing. It 
seemingly didn't stop you from becoming a drupal developer, did it? 
Would you rather have seen any code submission from you have been 
committed without those checks? Then why should that be the case for 
non-core modules?

> Have you looked at Drupal 7 yet?
Very sporadically. I've installed it, from time to time looked at 
diffs and the changelog.
> How familiar are you with the core
> development process?
Well i know it sometimes takes years to get stuff in *g

> While I'd love to see some consolidation in
> contrib, I don't see any realistic proposals for handling this, rather
> than mythical hordes of people who'll magically appear to review patches
> for contrib as well as core.
It all stands or falls with accessible support interfaces and good 
operational algorithms (i've made a detailed proposal but noone picked 
it up).

> I'd love to see code quality metrics (both coder and test coverage) for
> modules, and that combined with usage and other metrics. With that, the
> unmaintained modules will naturally get filtered out to the bottom.
The unmaintained modules are not really much of a problem. What my 
proposal is targeting is mainly the situation where duplicate modules 
are seeing continues development with diverting trend, instead of 
merging. That's the hardest issue to solve, and now is the time to 
try. Why now? Because the D7 non-core development cycle just started. 
Anything is possible now. When all modules have migrated from D6 to D7 
we will basically have perpetuated the situation to continue through 
the whole D7 cycle.

Please have a look at the attached graphic which is an excerpt from 
this lecture 'Quality Management - Quality and Economics':
http://www.wzl.rwth-aachen.de/en/ebecb2e7d199a686c125736f00454c10/04_l_eng_quality_and_economics.pdf

..marcel.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future
-------------- next part --------------
A non-text attachment was scrubbed...
Name: failure-cost.png
Type: image/png
Size: 48864 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20090309/f25a36d6/attachment-0001.png 

From starbow at citris-uc.org  Mon Mar  9 17:16:20 2009
From: starbow at citris-uc.org (Tao Starbow)
Date: Mon, 09 Mar 2009 10:16:20 -0700
Subject: [development] D7 contrib module development
In-Reply-To: <4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
	<49B40887.5010504@gmx.net>
	<4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>
Message-ID: <49B54EE4.3060504@citris-uc.org>

I think Khalid is exactly right here.  The low barrier to entry is one 
of the non-obvious secrets to Drupal's success.  It helps sucks new 
people in, gets them connected to the community, and we all benefit as 
their skills and contributions grow.

Clay Shirky's book, "Here comes everybody" is all about the fundamental 
change that the internet is sparking: the change from 
create-filter-publish, to create-publish-filter.  It can seem like a 
small change, but it is unleashing a huge wave of energy and creativity 
into the world.  And Drupal is benefiting from that wave, every bit as 
much more obvious projects, like Wikipedia or Flickr.

Of course, drupal.org has been a little weak in terms of tools for 
harnessing the power of the group mind in filtering after publishing, 
and it can be frustrating trying to separating the wheat from the chaff 
on your own.  Currently drupalmodules.com is the best place for viewing 
and contributing to the collective wisdom about existing modules, but 
http://drupal.org/project/usage is also a big step forward, and the 
drupal.org redesign will move the ball forward even more.

I would say that anyone that feel passionately about this subject should 
get involved with the drupal.org redesign, and start contributing there, 
either with time and expertise, or with funding.

cheers,
-tao
>
> Yes, your observation is correct, but  ... so what?
>
> We've always had stuff that falls off the face of earth. So what? The 
> caravan continues on ...
>
> The very first module I contributed (feedback) illustrates a point: It 
> was started in 2002 by someone called "barry". I had it working I took 
> it over in 2004 with totally new code for Drupal 4.5. Then "fago" 
> overhauled it a lot in 2006. Over time, the contact module in core 
> came along, and I stopped using feedback. Then in 2008 "sun" took it 
> over and repurposed it with new code.
>
> The "too many modules in contrib syndrome" can be taken as confusing, 
> excessive, ...etc. but can also be taken as a sign of a healthy and 
> vibrant community. So what if we have a few extra gigabytes of code? 
> So what if they become unmaintained?
>
> If we raise the barrier or block new entries we will be shutting 
> ourselves off from being the platform for the new chx or the new 
> merlinofchaos.
>
> It does not matter ... if it is the wild wild west, then let it be. It 
> is a small price to pay for innovation and the power of the masses.
> -- 
> Khalid M. Baheyeldin
> 2bits.com <http://2bits.com>, Inc.
> http://2bits.com
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. --   Leonardo da Vinci

From mpartap at gmx.net  Mon Mar  9 17:18:15 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 18:18:15 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <49B5498C.6000208@favias.org>
References: <49B5498C.6000208@favias.org>
Message-ID: <49B54F57.6050508@gmx.net>

First, of course i agree discussing doesn't create good code, coding 
creates good code. However if we are not taking decisions to more 
tightly channel module development, i bet we will see the porting of 
_all_ notifications and _all_ advanced questionnaire modules without 
any reconsolidation, which would be a great opportunity wasted. But if 
I am the only one who thinks we will benefit from changing the process 
a bit, very well, i'll just continue contributing however i can and 
watch the shit to hit the fan.
regards marcel.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From michael at favias.org  Mon Mar  9 17:19:13 2009
From: michael at favias.org (Michael Favia)
Date: Mon, 09 Mar 2009 12:19:13 -0500
Subject: [development] An alternative to common thinking in 5->6
	migration
In-Reply-To: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
Message-ID: <49B54F91.2060108@favias.org>

Nancy Wichmann wrote:
>
> In moving modules from 5.x to 6.x it is commonly suggested to move our 
> ?drupal_add_css? (and _js/) /into hook_init. Ceratinly I did this in 
> nearly all my modules because it was the common suggestion. However, 
> now that I?m making a big change in one and having problems with the 
> CSS, it dawned on me that this suggestion adds the CSS files to 
> **every** page, not just the ones we were targeting. It finally dawned 
> on me that I have hook_help that only fires on the pages I need to CSS 
> on, so I moved the ?drupal_add_css? into hook_help, which to me makes 
> a lot more sense because now my CSS is only applied to those pages for 
> which it is intended. What do others think of this? Are there pitfalls 
> I may not have covered?
>
You clicked "reply" on an email deep inside another thread to make your 
most recent post to the list. Most of us view our email in a threaded 
mail reader to follow discussions and this puts your new question WAY at 
the bottom of this existing (and seemingly interminable) discussion 
where it wont get the attention it deserves. Please dont reply to an 
email to compose a new message to the list. Instead just "compose one" 
from scratch so we can all see it :).

To answer your question, with "css munging" drupal_add_css doesn't 
result in an additional page hit for the new css file (because they are 
combined into 1) and I normally suggest including it because the small 
bandwidth penalty on page load #1 is normally outweighed by the latency 
+ bandwidth on the following page loads where it has t be dynamically 
loaded. if you dont use css munging then you approach has some validity 
i suppose but id be hesitant to put it in the help section and instead 
makes sure it is added when and where needed by your actual theme code 
so that it isnt a maintenance issue.

-mf

From starbow at citris-uc.org  Mon Mar  9 17:27:34 2009
From: starbow at citris-uc.org (Tao Starbow)
Date: Mon, 09 Mar 2009 10:27:34 -0700
Subject: [development] Wasting time and effort
In-Reply-To: <49B5498C.6000208@favias.org>
References: <49B5498C.6000208@favias.org>
Message-ID: <49B55186.9090609@citris-uc.org>

I don't agree.  It can be frustrating that the same meta subjects come 
up every six months or so, but the fact that they always stir up such a 
firestorm of interest means there are lots of people that care and 
haven't yet found a better way to channel there energy.  Maybe it would 
be better for them to search through the list archives, but I don't 
think so. Drupal changes fast.  Some things that were central orthodoxy 
a year ago have changed, while some seem to be eternal. And Drupal lives 
because people are passionate about it.

Of course, it does seem to be an eternal Drupal tradition that after 
every outbreak of passionate meta discussion, someone has to say 
"Everyone stop talking and get back to work". And who am I to argue with 
tradition :)

cheers,
-tao

Michael Favia wrote:
> I've noticed an increasing number of "meta discussions" and I'd like 
> to try to refocus our collective efforts if possible. All of these 
> discussions about regulating contribution module development or only 
> releasing core when the top X modules are upgraded, are more 
> distracting then they are productive in my opinion. It is a dearth of 
> labor not a lack of ideas that is the bottleneck of this project and 
> almost every one of the issues raised could be fixed by more work in 
> place of increased regulation.
>
> The ordinary folks who review and create patches on issues are our 
> lifeblood and engine. While it might not be as glorifying as 
> re-imagining the contribution module ecosystem or as easy as writing 
> an email, we notice and value your effort for the real contribution 
> that it is. We dont need more regulation, we need more contribution. 
> So lets pick up our shovels instead of our pens and get to work 
> (myself included). If you don't know how and want to learn how just 
> ask in channel and I'll be happy to help you personally. -mf

From news at unleashedmind.com  Mon Mar  9 17:31:25 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Mon, 9 Mar 2009 18:31:25 +0100
Subject: [development] An alternative to common thinking in 5->6migration
In-Reply-To: <49B54F91.2060108@favias.org>
Message-ID: <048401c9a0dc$df426710$0200a8c0@structworks.com>

If it makes sense for your use-case, drupal_add_css/_js() should always be
invoked in the builder or rendering function of a "thing".

I.e., if the CSS applies to a form, invoke drupal_add_css() from the form
builder function.  That way, the form (or other "thing") can be rendered
with the proper stylesheet in other places.

However, if your CSS applies specifically to your module's help text, then
yeah, hook_help() is the proper location for invoking drupal_add_css() - so
the help text would be the "thing" here.

sun

> Nancy Wichmann wrote:
> >
> > In moving modules from 5.x to 6.x it is commonly suggested 
> to move our 
> > ?drupal_add_css? (and _js/) /into hook_init. Ceratinly I 
> did this in 
> > nearly all my modules because it was the common suggestion. 
> However, 
> > now that I?m making a big change in one and having problems 
> with the 
> > CSS, it dawned on me that this suggestion adds the CSS files to
> > **every** page, not just the ones we were targeting. It 
> finally dawned 
> > on me that I have hook_help that only fires on the pages I 
> need to CSS 
> > on, so I moved the ?drupal_add_css? into hook_help, which 
> to me makes 
> > a lot more sense because now my CSS is only applied to 
> those pages for 
> > which it is intended. What do others think of this? Are 
> there pitfalls 
> > I may not have covered?
> >
> To answer your question, with "css munging" drupal_add_css 
> doesn't result in an additional page hit for the new css file 
> (because they are combined into 1) and I normally suggest 
> including it because the small bandwidth penalty on page load 
> #1 is normally outweighed by the latency 
> + bandwidth on the following page loads where it has t be dynamically
> loaded. if you dont use css munging then you approach has 
> some validity i suppose but id be hesitant to put it in the 
> help section and instead makes sure it is added when and 
> where needed by your actual theme code so that it isnt a 
> maintenance issue.
> 
> -mf


From mpartap at gmx.net  Mon Mar  9 17:33:59 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 18:33:59 +0100
Subject: [development] An alternative to common thinking in
	5->6	migration
In-Reply-To: <49B54F91.2060108@favias.org>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<49B54F91.2060108@favias.org>
Message-ID: <49B55307.3000702@gmx.net>


> this existing (and seemingly interminable) discussion
> where it wont get the attention it deserves.
I highly value your appreciation for my attempt to evaluate solutions 
to one of drupal's biggest problems. Thank you so much.


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From kb at 2bits.com  Mon Mar  9 17:41:51 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Mon, 9 Mar 2009 13:41:51 -0400
Subject: [development] An alternative to common thinking in 5->6
	migration
In-Reply-To: <49B55307.3000702@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<49B54F91.2060108@favias.org> <49B55307.3000702@gmx.net>
Message-ID: <4a9fdc630903091041k54fd8617rc0725eae3f47046d@mail.gmail.com>

Marcel

This is not personal. Please understand why many see this the way they see
it.

Every six months, we get the same arguments and we have long running threads
to something that was hashed out before many times.

So, don't be offended. This list is normally low traffic and these discusses
just get to some.

My advice: jump in and contribute, review patches, get immersed. And most
importantly: Persevere.

Then revisit this issue in a year, and see if you changed your mind about
how the community and open source works.

On Mon, Mar 9, 2009 at 1:33 PM, Marcel Partap <mpartap at gmx.net> wrote:

>
>  this existing (and seemingly interminable) discussion
>> where it wont get the attention it deserves.
>>
> I highly value your appreciation for my attempt to evaluate solutions to
> one of drupal's biggest problems. Thank you so much.
>
>
> --
>  "Obstacles are those frightful things you see when you take
>  your eyes off your goal."         -- Henry Ford (1863-1947)
>
>  Change the world! Vote: http://hfopi.org/vote-future
>



-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/c5b70b67/attachment-0001.htm 

From catch56 at googlemail.com  Mon Mar  9 17:42:18 2009
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Mon, 9 Mar 2009 17:42:18 +0000
Subject: [development] D7 contrib module development
In-Reply-To: <49B54932.8020103@gmx.net>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
	<49B40887.5010504@gmx.net>
	<4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>
	<49B53596.7040106@gmx.net>
	<4a9fdc630903090900v5088ea71v58bdd6c22ec5d05f@mail.gmail.com>
	<49B54932.8020103@gmx.net>
Message-ID: <fa5724270903091042x38b260feu29a4d89adc05d4cc@mail.gmail.com>

>>  Who's talking about dictating.. Everyone can code freely. But for code
to enter the official repository, quality >>checks should apply. That
doesn't stop innovation, does it? Look at the few commits to the cck/views
branches >>for example. Why is that kind of responsible code committing not
scalable to all other modules as well?

We already have a way for code to get reviewed before it gets committed to
the repository, it's called patches.

The gatekeepers for core aren't just the two committers - there's also a
whole layer of people who regularly review patches before they get
committed, not enough of them, but  that's how the code for core gets
filtered.

There are 92 pages of patches which need review against core or contrib. If
we could fine people to review all of those patches intelligently - not to
mention dealing with new bug reports and support requests for the top 200
most used modules, that'd help to consolidate efforts a lot. Anything else
is putting the cart very, very far before the horse.

http://drupal.org/project/issues/search?text=&projects=&assigned=&submitted=&participant=&status[]=8

That doesn't include all code marked for commit or needs work which nearly
doubles that number.

Or to put it another way, count the number people who reply to support
requests, let alone post and review patches for the Views issue queue. It's
a small number of overworked people. The people working on core and the 'top
40' (or 100, or 300) contrib modules are buried in issues, don't get nearly
enough help with their projects - but then you want these people to review
every commit as well?

>>No - the swarm, that is us. We all work together on finding the best way
to lay the foundation for the respective >>functionality. Aren't we already
doing that with core? Is it impossible to apply to non-core modules?

Yes it's impossible unless we massively increase the people dealing with
support requests, bug reports and patch reviews for the major modules which
have already 'won'. Let alone co-ordinating efforts to merge
smaller/duplicated/abandoned modules as time goes on.

>>Why is not letting experimental code into the repository stopping people
from trying stuff out? Please explain that >>to me, i simply don't get that.

A lot of sandbox projects on Drupal.org have turned into great modules or
core patches - often resurrected by people other than the original author.
Having all this code centralised is a good thing and isn't going to change.
What will hopefully change is filtering those projects from the most widely
used and supported ones for new users - again, there's efforts to do this
both with the redesign and numerous feature requests to project*.

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

From michael at favias.org  Mon Mar  9 17:42:44 2009
From: michael at favias.org (Michael Favia)
Date: Mon, 09 Mar 2009 12:42:44 -0500
Subject: [development] Wasting time and effort
In-Reply-To: <49B54F57.6050508@gmx.net>
References: <49B5498C.6000208@favias.org> <49B54F57.6050508@gmx.net>
Message-ID: <49B55514.4020306@favias.org>

Marcel Partap wrote:
> First, of course i agree discussing doesn't create good code, coding 
> creates good code. However if we are not taking decisions to more 
> tightly channel module development, i bet we will see the porting of 
> _all_ notifications and _all_ advanced questionnaire modules without 
> any reconsolidation, which would be a great opportunity wasted. 
It is only an opportunity if the authors and users of the module agree 
it is one. This is something you wont discover on this list. Open an 
issue, or create a patch and you'll get a much better response from the 
authors and the community using the module in question. I agree with 
reducing duplication of effort where possible and I know for a fact that 
most module developers share our point of view if you're willing to lend 
a hand.

Additionally, while it does require extra effort, competition is not a 
bad thing or a waste. It encourages innovation and offers alternative 
ways to approach the same problem. As common approaches to similar 
problems develop, projects frequently begin to share a common code base 
or break out the shared functionality into an API module to reduce 
duplication of effort. Our attitude towards healthy competition has 
gotten us this far in open source I'd hate to abandon it now and try to 
dictate a solution instead.
> But if I am the only one who thinks we will benefit from changing the 
> process a bit, very well, i'll just continue contributing however i 
> can and watch the shit to hit the fan.
Every patch and review is appreciated by me at least. Thank you. -mf

From gerhard at killesreiter.de  Mon Mar  9 17:52:38 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Mon, 09 Mar 2009 18:52:38 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <49B54F57.6050508@gmx.net>
References: <49B5498C.6000208@favias.org> <49B54F57.6050508@gmx.net>
Message-ID: <49B55766.5080600@killesreiter.de>

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

Marcel Partap schrieb:
> First, of course i agree discussing doesn't create good code, coding
> creates good code. However if we are not taking decisions to more
> tightly channel module development, i bet we will see the porting of
> _all_ notifications and _all_ advanced questionnaire modules without any
> reconsolidation, which would be a great opportunity wasted. But if I am
> the only one who thinks we will benefit from changing the process a bit,
> very well, i'll just continue contributing however i can and watch the
> shit to hit the fan.

Your attitude does not match your contribution level to the Drupal project.

Maybe consider gracing another project with your presence.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm1V2YACgkQfg6TFvELooRYQwCfRfq4O991Sse9QkKqTjTrlVl3
exkAoLxdO/HUJtZfswEIEIDvVo5lklfW
=BOYm
-----END PGP SIGNATURE-----

From kb at 2bits.com  Mon Mar  9 18:01:40 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Mon, 9 Mar 2009 14:01:40 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <49B55766.5080600@killesreiter.de>
References: <49B5498C.6000208@favias.org> <49B54F57.6050508@gmx.net>
	<49B55766.5080600@killesreiter.de>
Message-ID: <4a9fdc630903091101m3654751bo4aa0b9a603adac43@mail.gmail.com>

On Mon, Mar 9, 2009 at 1:52 PM, Gerhard Killesreiter <
gerhard at killesreiter.de> wrote:

>
> Marcel Partap schrieb:
> > First, of course i agree discussing doesn't create good code, coding
> > creates good code. However if we are not taking decisions to more
> > tightly channel module development, i bet we will see the porting of
> > _all_ notifications and _all_ advanced questionnaire modules without any
> > reconsolidation, which would be a great opportunity wasted. But if I am
> > the only one who thinks we will benefit from changing the process a bit,
> > very well, i'll just continue contributing however i can and watch the
> > shit to hit the fan.
>
> Your attitude does not match your contribution level to the Drupal project.
>
> Maybe consider gracing another project with your presence.
>

gerhard

Please stop eating noobz. You will get indigestion.

marcel, the translation is : "this is a doocracy, and people will listen
more to your
argument as you get involved more and have contributions to show".
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/2200f7f4/attachment.htm 

From earnie at users.sourceforge.net  Mon Mar  9 18:02:31 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 09 Mar 2009 14:02:31 -0400
Subject: [development] An alternative to common thinking in
	5->6	migration
In-Reply-To: <49B55307.3000702@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<49B54F91.2060108@favias.org> <49B55307.3000702@gmx.net>
Message-ID: <20090309140231.lv597666j1pcc0wk@mail.progw.org>

Quoting Marcel Partap <mpartap at gmx.net>:

>
>> this existing (and seemingly interminable) discussion
>> where it wont get the attention it deserves.
> I highly value your appreciation for my attempt to evaluate solutions 
> to one of drupal's biggest problems. Thank you so much.
>

The problem here is that the issue you try to elaborate in discussion 
has already been discussed and the outcome of that discussion is what 
we already have in place.  You perceive it as a problem while many more 
perceive it as the way it is and would be a bad thing to change.  You 
then have the choices of continue wasting time in discussion on a dead 
(won't fix) issue or get busy and provide patches to make your favorite 
module better.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From news at unleashedmind.com  Mon Mar  9 18:15:59 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Mon, 9 Mar 2009 19:15:59 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <49B55186.9090609@citris-uc.org>
Message-ID: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>

One point of his proposal is valid though: We could do better in preventing
duplicated modules and efforts.

We have

- CVS sandboxes for experimental code. (I'd argue that almost no one knows
about sandboxes and how to use them)

- Official projects on drupal.org. (With complete release, issue, and
versioning systems)

- No "moderation" for new project nodes. (Anyone with a CVS account is able
to create anything)


Question:

Would it really hurt the process of evolution and innovation in Drupal when
a new project ("request") would go into a "new projects queue" first, where
all community members could do a quick review and optionally point to a
possible existing project that could benefit from additional man-power,
features, and stuff?

Would such a process not even do the opposite - speeding up evolution (by
not duplicating efforts)?


I mean, as a developer, I can review a module's code to find out which
module is sane to use.  Regular Drupal users cannot - they have to blindly
choose one of the modules.  Whether developer or user, finding out which
module to choose is a pain, a "waste of time and effort".

Implementing that process would be fairly easy.  So I can only guess that
the majority of developers a) either does not know about CVS sandboxes, or
b) likes to have duplicate efforts, or that c) I'm on crack.

sun


From mpartap at gmx.net  Mon Mar  9 18:31:35 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 19:31:35 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <49B55766.5080600@killesreiter.de>
References: <49B5498C.6000208@favias.org> <49B54F57.6050508@gmx.net>
	<49B55766.5080600@killesreiter.de>
Message-ID: <49B56087.4050608@gmx.net>

> Your attitude does not match your contribution level to the Drupal project.
How can you tell. Because i only committed something two times with my 
CVS account? Not going to waste my time defending myself but a) i'm 
not a no0b and b) i spent a lot more time fixing issues and creating 
patches (and learning to code) than you think.
rgds marcel.


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mpartap at gmx.net  Mon Mar  9 18:38:24 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 19:38:24 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
References: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
Message-ID: <49B56220.3090503@gmx.net>

> the majority of developers a) either does not know about CVS sandboxes, or
> b) likes to have duplicate efforts, or that c) I'm on crack.
It's c). We're on crack. Clearly it's those who want everything to 
stay as is who have clear vision.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mail at webthatworks.it  Mon Mar  9 18:56:35 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Mon, 9 Mar 2009 19:56:35 +0100
Subject: [development] D7 contrib module development
In-Reply-To: <49B54932.8020103@gmx.net>
References: <034401c99fa6$6dbc6320$0200a8c0@structworks.com>
	<49B3E495.7000805@gmx.net>
	<cdcea3940903080946x14ad14b0m73cc1c579d16e4e1@mail.gmail.com>
	<49B40887.5010504@gmx.net>
	<4a9fdc630903081807x43558921o4ba63d5d84907fce@mail.gmail.com>
	<49B53596.7040106@gmx.net>
	<4a9fdc630903090900v5088ea71v58bdd6c22ec5d05f@mail.gmail.com>
	<49B54932.8020103@gmx.net>
Message-ID: <20090309195635.0bf8738f@dawn.webthatworks.it>

On Mon, 09 Mar 2009 17:52:02 +0100
Marcel Partap <mpartap at gmx.net> wrote:

> >     How could it be integrated with other modules, what could be
> >     factored out into 'frameworks' (/library modules) ?
> > It happens naturally.
> Very well. But there's a reason bioengineering is the latest hype:
> it is a lot FASTER and more DIRECTED than the evolutionary process.

Faster and more directed doesn't mean right.
I think that evolution isn't rational... but at least it generally
provide a lot of testing ;)
We can try to be rational and let evolution do the "testing".

> > What I am saying it happens naturally as people realize that
> > they are evolving their pet project into an API/Framework over
> > time.
> At our university we are taught: the more brainwork you invest
> early on in the development process, the less headache you'll have
> to cope with.

If you invest it right and you're freeze in time.
I'm not a strong fan of XP but still in its less X incarnation has
its merits.

The problem of low quality modules and duplication could be reduced
to further info on module pages: activity, releases, downloads,
related modules...
These aren't perfect metrics but they can help without anyone
playing God or just get into the way of developers making
requirements.



> > You can't dictate what happens in contrib without stifling the
> > innovation that this ecosystem has.
> Who's talking about dictating.. Everyone can code freely. But for
> code to enter the official repository, quality checks should
> apply. That doesn't stop innovation, does it? Look at the few
> commits to the cck/views branches for example. Why is that kind of
> responsible code committing not scalable to all other modules as
> well?
> 
> > We can nudge people to work together but we can't force them to.
> Well not many people who score goals by hand have made successfull 
> career in football. How comes? Might it be that whoever doesn't 
> respect the rules will not be allowed to play?
> 
> 
> >> I want to have *all* the functionality spread over slightly
> >> different modules with the same purpose, combined into one
> >> flexible solution. And i am quite sure i am not the only one.
> > You are advocating the "one true way".
> Am not. What i am advocating is a process that makes problems that 
> occured in the past less likely to happen.
> 
> 
> 
> > But without letting people
> > experiment
> Why is not letting experimental code into the repository stopping 
> people from trying stuff out? Please explain that to me, i simply 
> don't get that.
> 
> > that one true way could be the one with less features, with
> > a non-committed maintainer, could be buggy, ...etc. You don't
> > know until you put it out there and let the ecosystem decide.
> 
> > Who will decide the one true way? Committee? Hierarchy?
> No - the swarm, that is us. We all work together on finding the
> best way to lay the foundation for the respective functionality.
> Aren't we already doing that with core? Is it impossible to apply
> to non-core modules?
> 
> > What we can do is let things evolve for a while and then
> > naturally a winner or two will emerge from the fray.
> So please tell me, what is the winning change notification
> framework? Notifications, Subscriptions, Comment Notify,
> Notify, ...? Which is the best module to create sophisticated web
> questionnaires? Is it webforms? Advanced Poll? Decisions?
> Do you really want to have the same situation with D7? Not
> terribly user-friendly, is it?
> 
> 
> > As disconcerting this is to
> > some, it is a sure way to have a proven solution for the problem
> > space.
> Is not. It might be sufficient, but it surely isn't the optimum.
> 
> > No. I am saying is that without seeing people contribute for
> > some time you don't know before hand if they will turn to be a
> > drive-by contributor of a so-so project, or the author of the
> > next big hit.
> Why is applying quality checks before applying code to the
> official repository making it harder for people to code,
> experiment, innovate? How does having each submission routinely
> reviewed by the community stop anyone to contribute?
> 
> > All that cannot be seen just from the first contribution
> > adherence to coding standards.
> Whos talking about judging people by their first code? But what is
> a good reason for the first contribution of someone starting to
> learn drupal to be included in the official repository? Wouldn't
> it be much more helpful to receive comments and tips in the
> discussion thread for their patch?
> 
> > Fair point, standards will arise across CMS's too
> Didn't even touch _that_ topic.
> 
> > But within Drupal, I don't see we are the point where we have a
> > central body .
> Well i didn't propose a central committee, but for the whole
> community to pick up quality checking and maintain the modules as
> a huge diverse team. Sounds implausible? Well who's stopping us
> from trying.
> 
> 
> > Later maybe? Perhaps. But not now. When you see a majority of the
> > community cry for that, then it is time to re-evaluate.
> At the time people are crying it usually is a bit late.
> 
> >     rgds marcel.
> 
> 


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


From mail at webthatworks.it  Mon Mar  9 19:55:26 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Mon, 9 Mar 2009 20:55:26 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <49B5498C.6000208@favias.org>
References: <49B5498C.6000208@favias.org>
Message-ID: <20090309205526.712655aa@dawn.webthatworks.it>

On Mon, 09 Mar 2009 11:53:32 -0500
Michael Favia <michael at favias.org> wrote:

> and get to work (myself included). If you don't know how and want
> to learn how just ask in channel and I'll be happy to help you
> personally. -mf

I'd like to know how.
I've tons of questions that will make my work better, faster and
more drupal friendly.

I'm coding and I would like to be able to just concentrate on coding.
But I'm not coding in the hyperuranium, we are coding for a project
in a community.

Is really IRC the best place where to share this knowledge?

I just guess there are thousands way to get more productive in the
"drupal environment".

I'm still catching up while I'm making my mammoth module ready for
public consumption. It finally saw the light 3-4 weeks ago (in
production on 2 websites) but for a long series of reasons it's not
ready for public consumption and I'm scared there are so many things
to clean up to make it of "general" use that I won't be able to catch
up with the community changes once put it in public consumption.

One thing is writing your own stuff for your own itch, one thing is
being productive inside a community project.

I've been lucky enough I ran in very few problems in drupal code.
I'm on the old stable and I reported the few glitches I came across
sometimes with snippet of code.

Other than IRC is there a place where to learn how to set up a
development and testing environment?
How do you guys:
- check out HEAD, install it, test a patch or write one
  systematically?
- how to work with [dvcs] and drupal csv?
- how to monitor commit to core?
- how to maintain dev, staging and production?
- etc...

There are docs on this kind of topic but I think people are running
much more functional infrastructure for their development.

I'd say this kind of topics should be discussed on a ml and then
find their way in the docs.
The advantage over IRC is you can keep up, there is an archive on
which you can distil the documentation to push to drupal.org and
while no one find the time to distil docs you can still make the
discussion searchable through google.

Michael your offer was very appreciated. I'll try at least to lurk
on IRC more.

[BTW] sorry for the previous badly trimmed post. I was supposed to
'save to draft' and re-edit later... but my finger slip.
I wasn't even sure it was meant to be sent.

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


From drupal-devel at webchick.net  Mon Mar  9 20:34:40 2009
From: drupal-devel at webchick.net (Angela Byron)
Date: Mon, 9 Mar 2009 16:34:40 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <20090309205526.712655aa@dawn.webthatworks.it>
References: <49B5498C.6000208@favias.org>
	<20090309205526.712655aa@dawn.webthatworks.it>
Message-ID: <C785A314-8735-448D-9B25-CB481F781785@webchick.net>


On 9-Mar-09, at 3:55 PM, Ivan Sergio Borgonovo wrote:

> On Mon, 09 Mar 2009 11:53:32 -0500
> Michael Favia <michael at favias.org> wrote:
>
>> and get to work (myself included). If you don't know how and want
>> to learn how just ask in channel and I'll be happy to help you
>> personally. -mf
>
> I'd like to know how.
> I've tons of questions that will make my work better, faster and
> more drupal friendly.
>
> I'm coding and I would like to be able to just concentrate on coding.
> But I'm not coding in the hyperuranium, we are coding for a project
> in a community.
>
> Is really IRC the best place where to share this knowledge?
>
> I just guess there are thousands way to get more productive in the
> "drupal environment".
>
> I'm still catching up while I'm making my mammoth module ready for
> public consumption. It finally saw the light 3-4 weeks ago (in
> production on 2 websites) but for a long series of reasons it's not
> ready for public consumption and I'm scared there are so many things
> to clean up to make it of "general" use that I won't be able to catch
> up with the community changes once put it in public consumption.
>
> One thing is writing your own stuff for your own itch, one thing is
> being productive inside a community project.
>
> I've been lucky enough I ran in very few problems in drupal code.
> I'm on the old stable and I reported the few glitches I came across
> sometimes with snippet of code.
>
> Other than IRC is there a place where to learn how to set up a
> development and testing environment?

The http://drupal.org/getting-involved section of the handbook has  
most of the information centralized. I would suggest reading through  
the "Contribute code" subsection (http://drupal.org/node/10259) and  
either editing pages directly or creating issues in the Documentation  
queue for places where things are unclear.

-Angie


From ezra at growingventuresolutions.com  Mon Mar  9 21:15:31 2009
From: ezra at growingventuresolutions.com (Ezra B. Gildesgame)
Date: Mon, 9 Mar 2009 17:15:31 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <49B5498C.6000208@favias.org>
References: <49B5498C.6000208@favias.org>
Message-ID: <ccbb750f0903091415t24846c0ele94475deb3756ec0@mail.gmail.com>

Tao Starbow wrote:>Drupal changes fast.  Some things that were central
orthodoxy a year ago have changed, while some seem to be eternal. And
Drupal lives because people are  passionate about it.

Michael Favia wrote: > It is a dearth of labor not a lack of ideas
that is the bottleneck of this
> project

This snippet from Michael eloquently communicated the intellectual
vibrancy (and resulting bottleneck) of our community: We have more
(often great) ideas than we can there are person-hours spent
implementing them.  I found this generally motivational rather than a
reason to mute any discussion about improving the methods and tools
that we use to collaborate with one another.

Regards,

Ezra



-- 
Ezra Barnett Gildesgame
http://growingventuresolutions.com
http://ezra-g.com

From anton.list at gmail.com  Mon Mar  9 21:30:13 2009
From: anton.list at gmail.com (Anton)
Date: Tue, 10 Mar 2009 10:30:13 +1300
Subject: [development] An alternative to common thinking in 5->6
	migration
In-Reply-To: <49B55307.3000702@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<49B54F91.2060108@favias.org> <49B55307.3000702@gmx.net>
Message-ID: <45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>

2009/3/10 Marcel Partap <mpartap at gmx.net>:
>
>> this existing (and seemingly interminable) discussion
>> where it wont get the attention it deserves.
>
> I highly value your appreciation for my attempt to evaluate solutions to one
> of drupal's biggest problems. Thank you so much.

Marcel, I don't know if you've noticed but you haven't managed to
visibly convince anyone your solution is a good one. Especially not
anyone who will bother to try and implement it.

On the contrary, you have a whole host of people saying it isn't a
good idea and giving reasons why. These people (not me mind you) are
the dedicated volunteers that do actually work hard to implement
solutions to Drupals problems, and are each in their own way
personally responsible for the current success of Drupal today. They
do understand the background and developer culture of the community,
and the reasons behind Drupals success.

Don't take this personally, but your idea and justifications for it
have an air of either ivory tower academia or heavyweight process
driven enterprise thinking about them. Neither of which have a very
good track record of actually getting things done in a volunteer
driven open source community where inspiration and enthusiasm is the
biggest driver behind doing anything.

I started using Drupal when it was a practically unknown project and
have seen it grow to be probably the 2nd most popular open source CMS
out there and possibly the biggest in terms of developer community.
The rate of progress in both Drupal and the supporting infrastructure
over that time has been staggering. It's a tall order claiming that
the environment or culture that achieved that success is broken -
especially since people have come along and announced that plenty of
times in the past. Why should that claim be correct now, when it has
been shown to be false in the past?

Your proposal to have every D7 contrib commit vetted by some sort of
vote would just drive away the very enthusiasm and inspiration that
drew in all the newbie contrib developers that grew up into veteran
developers and core contributers (and that would be the single best
way to kill Drupal). I certainly wouldn't bother releasing any Drupal
7 modules if that were the case. And for a lot of modules (eg my own),
they simply don't have a user base capable of evaluating the quality
of the commit - they will just vote for it anyway so they can get
their hands on the bug fix or new feature they desperately need. In
nearly all cases, the people doing the voting will know far less about
coding or the internals of the module than the author. It won't change
much in terms of code quality - it will just add frustration to
everyones experience.

-- 
Cheers
Anton

From andrewberry at sentex.net  Mon Mar  9 21:38:17 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Mon, 9 Mar 2009 17:38:17 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
References: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
Message-ID: <325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>

On 9-Mar-09, at 2:15 PM, Daniel F. Kudwien wrote:

> Would it really hurt the process of evolution and innovation in  
> Drupal when
> a new project ("request") would go into a "new projects queue"  
> first, where
> all community members could do a quick review and optionally point  
> to a
> possible existing project that could benefit from additional man- 
> power,
> features, and stuff?

I think this is a good idea. I was having this conversation with some  
at DC; we all noted that for our very first contribution, we did a  
great deal of thinking, planning, and so on, but for subsequent  
modules they tend to go in without as much attention. I'm sure I'm not  
the only one who's written code only to discover after that someone  
else did it under a different name. No one I think really likes  
duplication without reason.

Long term, I think the solution is for search on d.o to continue to  
improve so that it is easy to tell within a few searches if another  
module exists. Until then, a "does this exist" queue or mailing list  
could serve quite nicely.

--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/20090309/9b58a57c/attachment-0001.bin 

From gerhard at killesreiter.de  Mon Mar  9 21:55:34 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Mon, 09 Mar 2009 22:55:34 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>
References: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>
Message-ID: <49B59056.7050403@killesreiter.de>

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

Andrew Berry schrieb:
> On 9-Mar-09, at 2:15 PM, Daniel F. Kudwien wrote:
> 
>> Would it really hurt the process of evolution and innovation in Drupal
>> when
>> a new project ("request") would go into a "new projects queue" first,
>> where
>> all community members could do a quick review and optionally point to a
>> possible existing project that could benefit from additional man-power,
>> features, and stuff?
> 
> I think this is a good idea. I was having this conversation with
> some at DC; we all noted that for our very first contribution, we
> did a great deal of thinking, planning, and so on, but for
> subsequent modules they tend to go in without as much attention. I'm
> sure I'm not the only one who's written code only to discover after
> that someone else did it under a different name. No one I think
> really likes duplication without reason.

There is already a RSS feed of new projects. Everybody who wants to
help new authors (and I guess many would appreciate that. Or should,
at least.).

> Long term, I think the solution is for search on d.o to continue to
> improve so that it is easy to tell within a few searches if another
> module exists. Until then, a "does this exist" queue or mailing list
> could serve quite nicely.

We are trying to improve "findability" as part of the
redesign. Everybody who wants to help with this is welcome and should
study the drafts from Marc Boulton.

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

iEYEARECAAYFAkm1kFYACgkQfg6TFvELooSxwACgkt7yxy8OLe8HlvQJHg4FXLl9
LNQAoL68gj2hTfkubnHSfOHVCQFeaOr6
=5ryQ
-----END PGP SIGNATURE-----

From greg at t2media.com  Mon Mar  9 21:49:01 2009
From: greg at t2media.com (Greg Holsclaw)
Date: Mon, 9 Mar 2009 14:49:01 -0700
Subject: [development] Wasting time and effort
In-Reply-To: <325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>
References: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>
Message-ID: <006401c9a100$dc4d86b0$94e89410$@com>


-----Original Message-----
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of Andrew Berry
Sent: Monday, March 09, 2009 2:38 PM
To: development at drupal.org
Subject: Re: [development] Wasting time and effort

On 9-Mar-09, at 2:15 PM, Daniel F. Kudwien wrote:

> Would it really hurt the process of evolution and innovation in  
> Drupal when
> a new project ("request") would go into a "new projects queue"  
> first, where
> all community members could do a quick review and optionally point  
> to a
> possible existing project that could benefit from additional man- 
> power,
> features, and stuff?

I think this is a good idea. I was having this conversation with some  
at DC; we all noted that for our very first contribution, we did a  
great deal of thinking, planning, and so on, but for subsequent  
modules they tend to go in without as much attention. I'm sure I'm not  
the only one who's written code only to discover after that someone  
else did it under a different name. No one I think really likes  
duplication without reason.

Long term, I think the solution is for search on d.o to continue to  
improve so that it is easy to tell within a few searches if another  
module exists. Until then, a "does this exist" queue or mailing list  
could serve quite nicely.

--Andrew

There are new modules listed at http://drupalmodules.com/new-modules/feed.
Also, many times before people have used this list to announce new modules,
or inquire if someone is already working on something which leads exactly to
the feedback that was suggested.

But I am against the 'request' verbiage that was used in this idea. Gives
the impression that an idea or module has to be approved before being worked
on, and that is not an open source ideal at all. In Drupal and other open
source projects, the hurdle to success or failure should be as low as
possible, and even parallel modules more adequately search the solution
space of a problem. All are good things. And yes, the module list has grown
from hundreds at 4.7, to thousands now, but that problem will persist as
long as Drupal is leading the pack.

Greg


From mpartap at gmx.net  Mon Mar  9 22:22:02 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Mon, 09 Mar 2009 23:22:02 +0100
Subject: [development] An alternative to common thinking in
	5->6	migration
In-Reply-To: <45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>	<49B54F91.2060108@favias.org>
	<49B55307.3000702@gmx.net>
	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>
Message-ID: <49B5968A.4020008@gmx.net>

> Marcel, I don't know if you've noticed but you haven't managed to
> visibly convince anyone your solution is a good one.
Well yes i do have noticed. Apart from 'don't like it' and 'messes
with our ways' i have not heard any sound counter arguments though,
but that might well be enough of an argument by itself in such a
community project.

> Especially not anyone who will bother to try and implement it.
Well if we all wanted to, we could make it. Easily: it's just a matter
of breaking habits, and not even that drastically. Btw it works for
other projects (linux, wine).

> On the contrary, you have a whole host of people saying it isn't a
> good idea and giving reasons why.
Like 'nah dont like'. (Almost) noone even picked my arguments in favor
of such a process, or tried to think up how it could be made to work, 
or even propose something entirely different.

> These people (not me mind you) are the dedicated volunteers that do
> actually work hard to implement solutions to Drupals problems, and
> are each in their own way personally responsible for the current
> success of Drupal today.
Well of course but i really missed some voices from those high-profile
developers. BTW nothing would change for them, especially no increase 
in work-load.

> They do understand the background and developer culture of the
> community, and the reasons behind Drupals success.
So that implies i don't do that, which is wrong. But to truly achieve
excellence, sometimes you have to trade in a bad habit (casual
developers committing code to the central repository) for a bitter
pill (having all code not from already proven drupal master minds
undergo a transparent quality screening) for long term profit (cure
the contrib). It's simply people not liking bitter pills until they
suffer severely from their sickness.. totally human.

> Don't take this personally
Course not, but i would have hoped for some support. Without any
community backing surely my idea does sound silly.

> but your idea and justifications for it have an air of either ivory
> tower academia or heavyweight process driven enterprise thinking
> about them.
Well it's not that my proposal is totally unrealistic. Only because no
one is supporting it does it become so. Would Dries or Angela have
proposed it, everybody and his dog would be up in flames of enthusiasm
and surely consider it the right way to go.

> Neither of which have a very good track record of actually getting
> things done in a volunteer driven open source community where
> inspiration and enthusiasm is the biggest driver behind doing
> anything.
Who is trying to stop that. By preventing bull sh1t code from being
committed to the official contrib? C'mon! We could easily set up a
testing repository, set up a drupal-patches mailing list and nice up
the issue tracker to facilitate more code centric work on stuff.

> The rate of progress in both Drupal and the supporting
> infrastructure over that time has been staggering.
Yes, true. So with all that gained, how are we possibly going to loose
it through tighter quality management?

> It's a tall order claiming that the environment or culture that
> achieved that success is broken - especially since people have come
> along and announced that plenty of times in the past.
I didn't say it's broken, it just allows unlucky stuff to happen.
Modifying it a bit could solve the problem for good. Not that this
step is _required_, but maybe we as a *software* project would 
_profit_ from it.

> Why should that claim be correct now, when it has been shown to be
> false in the past?
A major core redesign is the best time to make these modifications.
Why i proposed these changes i hope i have explained sufficiently.

> Your proposal to have every D7 contrib commit vetted by some sort
> of vote would just drive away the very enthusiasm and inspiration
> that drew in all the newbie contrib developers that grew up into
> veteran developers and core contributers (and that would be the
> single best way to kill Drupal).
Ahem, no. Why would anyone insist on committing every mind fart to the
official drupal repository? Heck as stated above, how hard is it to
have a staging branch?
The main motivation to even waste my time in this discussion was to
find a solution to the problems mentioned in the original posting:
> - modules spamming the watchdog table with E_ALL warnings
> - modules ignoring the style/documentation guide lines
> - applied insane programming(TM) techniques
> - undescriptive module names
> - duplication (partial feature overlap with existing modules).
If anyone has a more viable solution at hand, i'm more than willing to 
surrender my effort to their proposal. Right now all i've heard is 
votes for natural selection. Surely that is one approach to it, but at 
least not my favorite.
Also, almost every possible use case is covered by one or the other D6 
module, making that 'no more innovation' argument really not that 
convincing. What is the point of producing D7 at all? Restructuring! 
How is that case invalid for non-core modules, simply don't see it.
Furthermore, simply don't like the fact that individuals hold the keys 
to modules. The linux kernel f.e. handles this very differently: 
contributors get mentioned in the file header.
Really, the linux approach of development is what i think drupal 
should hand pick some points from.

 > I certainly wouldn't bother releasing any Drupal
> 7 modules if that were the case.
You must be kidding.
 > And for a lot of modules (eg my
> own), they simply don't have a user base capable of evaluating the
> quality of the commit
Code voting for developers only of course - sure all this needs 
implementing. Where's a will, there's a way.

> In nearly all cases, the people doing the voting will know
> far less about coding or the internals of the module than the
> author. It won't change much in terms of code quality - it will
> just add frustration to everyones experience.
Noone wants that, not even crazy me. But my belief still is: if we 
really want to find a way to improve the process, we can do it. If i 
stand alone, this is not a fight i'll waste my blood on.

BTW, i really wished i had the time to code all the stuff i'd like to, 
but obligations (you know.. school, work and stuff *g) shrink my 
visions to small compact pressed clumps that lay around. It would 
simply need some outside support to inflate them again, but convincing 
people to support something unknown nowadays doesn't seem to be too 
easy. Ah well.. back to work, the profane.
regards


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From andrewberry at sentex.net  Mon Mar  9 23:01:39 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Mon, 9 Mar 2009 19:01:39 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <49B59056.7050403@killesreiter.de>
References: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>
	<49B59056.7050403@killesreiter.de>
Message-ID: <5A4C9BFB-C293-4C50-819C-CB50BC49C4D7@sentex.net>

On 9-Mar-09, at 5:55 PM, Gerhard Killesreiter wrote:

> There is already a RSS feed of new projects. Everybody who wants to
> help new authors (and I guess many would appreciate that. Or should,
> at least.).

Thanks - I didn't know that "modules" was in the taxonomy system. The  
only way I could get a link to it though was through Google. What  
would it take to have a link to http://drupal.org/taxonomy/term/14/0  
placed under Contributor Links, and as a note under node/add/project?

--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/20090309/641c0c46/attachment.bin 

From harry at devbee.com  Mon Mar  9 21:12:32 2009
From: harry at devbee.com (Harry Slaughter)
Date: Mon, 09 Mar 2009 14:12:32 -0700
Subject: [development] wit's end: altering options for an
 optionwidgets_select element - OR - life without #DANGEROUS_SKIP_CHECK
Message-ID: <49B58640.6000102@devbee.com>

I want to alter the options for a cck optionwidgets_select element based on data
in the node itself.

I can't use a function in the cck widget configuration page because that's
called before the node is loaded, so I don't know what the options should be yet.

I can't do it in hook_form_alter() because optionwidgets_select elements have
not yet been fully rendered (the actual options for the select have not been set
yet).

I can make the alteration using #pre_render, but then form validation has run
already so I've corrupted the form and I fail _form_validate() and get the
'illegal choice...' error. And I cannot use the
drupal_process_form()/drupal_rebuild_form() trick (as seen in AHAH) because the
#pre_render callback does not have access to $form_state.

I can't use #DANGEROUS_SKIP_CHECK because it has been removed.

Maybe I could use AHAH, but that would be very hacky as I do not need any input
from the user in order to generate my options, just data from the node itself.

The upgrade doc says to look here for alternatives to #DANGEROUS_SKIP_CHECK:
http://drupal.org/node/182310 - yet that issue supplies no examples of a workaround.

I understand the reason for removal of #DANGEROUS_SKIP_CHECK, but this use case
is the type that the option was truly created for (I think :)

I'm posting this question to the list after several days of trying every
solution I could think of.

If there is a solution, surely it will help others as well.

-- 
Harry Slaughter
Web Developer
Devbee - Effective Drupal
http://devbee.com/
619-249-8780

From gerhard at killesreiter.de  Mon Mar  9 23:21:44 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Tue, 10 Mar 2009 00:21:44 +0100
Subject: [development] wit's end: altering options for an
 optionwidgets_select element - OR - life without #DANGEROUS_SKIP_CHECK
In-Reply-To: <49B58640.6000102@devbee.com>
References: <49B58640.6000102@devbee.com>
Message-ID: <49B5A488.2080000@killesreiter.de>

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

Harry Slaughter schrieb:
> I want to alter the options for a cck optionwidgets_select element based on data
> in the node itself.
> 
> I can't use a function in the cck widget configuration page because that's
> called before the node is loaded, so I don't know what the options should be yet.
> 
> I can't do it in hook_form_alter() because optionwidgets_select elements have
> not yet been fully rendered (the actual options for the select have not been set
> yet).
> 
> I can make the alteration using #pre_render, but then form validation has run
> already so I've corrupted the form and I fail _form_validate() and get the
> 'illegal choice...' error. And I cannot use the
> drupal_process_form()/drupal_rebuild_form() trick (as seen in AHAH) because the
> #pre_render callback does not have access to $form_state.
> 
> I can't use #DANGEROUS_SKIP_CHECK because it has been removed.


Have you considere to add a #process function that runs after the
optionwidget one? Look at the flexifield  module how to add one.

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

iEYEARECAAYFAkm1pIcACgkQfg6TFvELooSflQCfR3l1d13rdfaqvM43M5Y4PXZW
jd4AoIYuo3Dgzp+eVBLECh8Hc5Y8AASl
=7cT/
-----END PGP SIGNATURE-----

From cxjohnson at gmail.com  Mon Mar  9 23:44:03 2009
From: cxjohnson at gmail.com (Chris Johnson)
Date: Mon, 9 Mar 2009 18:44:03 -0500
Subject: [development] Wasting time and effort
In-Reply-To: <49B5498C.6000208@favias.org>
References: <49B5498C.6000208@favias.org>
Message-ID: <9ea8d6030903091644p7631ea5cnb00111da54aa1cca@mail.gmail.com>

I respectfully disagree completely.  Software development is not all
about solving the latest coding problem.  In fact, the so-called "meta
discussions" are really the largest and most important part, in a
sense.

Signal to noise on this list is probably the biggest problem in my
view, where noise is defined (by me) as any reply that doesn't add new
information or stake a out a different position (hence, most +1 and
similar remarks are pretty much noise -- on rare occasion where the
temperature of the community needs to be gauged they can be useful).

Attempts to squelch opposing views is generally counter-productive, as
well.  If one is not interested in the topic, delete it.  It will save
you tons of time and consternation.

..chris

On Mon, Mar 9, 2009 at 11:53 AM, Michael Favia <michael at favias.org> wrote:
> I've noticed an increasing number of "meta discussions" and I'd like to try
> to refocus our collective efforts if possible. All of these discussions
> about regulating contribution module development or only releasing core when
> the top X modules are upgraded, are more distracting then they are
> productive in my opinion.

From gerhard at killesreiter.de  Mon Mar  9 23:48:59 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Tue, 10 Mar 2009 00:48:59 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <5A4C9BFB-C293-4C50-819C-CB50BC49C4D7@sentex.net>
References: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>	<325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>	<49B59056.7050403@killesreiter.de>
	<5A4C9BFB-C293-4C50-819C-CB50BC49C4D7@sentex.net>
Message-ID: <49B5AAEB.1070804@killesreiter.de>

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

Andrew Berry schrieb:
> On 9-Mar-09, at 5:55 PM, Gerhard Killesreiter wrote:
> 
>> There is already a RSS feed of new projects. Everybody who wants to
>> help new authors (and I guess many would appreciate that. Or should,
>> at least.).
> 
> Thanks - I didn't know that "modules" was in the taxonomy system. The
> only way I could get a link to it though was through Google. What would
> it take to have a link to http://drupal.org/taxonomy/term/14/0 placed
> under Contributor Links, and as a note under node/add/project?

I guess something like this is already part of the redesign and we'll
wait a few weeks longer untill that is finished. If it isn't part of it,
please add an issue for it and tag it with "drupal.org redesign".

Cheers,	
	Gerhard


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

iEYEARECAAYFAkm1quoACgkQfg6TFvELooTj7QCeKRUtdz4BP+SuKkVPYkxWOHTg
oIUAoLrXbSo5sVSOSl+hEeRXsl92gYPx
=7P9L
-----END PGP SIGNATURE-----

From harry at devbee.com  Mon Mar  9 23:49:40 2009
From: harry at devbee.com (Harry Slaughter)
Date: Mon, 09 Mar 2009 16:49:40 -0700
Subject: [development] wit's end: altering options for an
 optionwidgets_select element - OR - life without #DANGEROUS_SKIP_CHECK
In-Reply-To: <49B5A488.2080000@killesreiter.de>
References: <49B58640.6000102@devbee.com> <49B5A488.2080000@killesreiter.de>
Message-ID: <49B5AB14.60603@devbee.com>

Gerhard Killesreiter wrote:
> Harry Slaughter schrieb:
>> I want to alter the options for a cck optionwidgets_select element based on data
>> in the node itself.
> 
>> I can't use a function in the cck widget configuration page because that's
>> called before the node is loaded, so I don't know what the options should be yet.
> 
>> I can't do it in hook_form_alter() because optionwidgets_select elements have
>> not yet been fully rendered (the actual options for the select have not been set
>> yet).
> 
>> I can make the alteration using #pre_render, but then form validation has run
>> already so I've corrupted the form and I fail _form_validate() and get the
>> 'illegal choice...' error. And I cannot use the
>> drupal_process_form()/drupal_rebuild_form() trick (as seen in AHAH) because the
>> #pre_render callback does not have access to $form_state.
> 
>> I can't use #DANGEROUS_SKIP_CHECK because it has been removed.
> 
> 
> Have you considere to add a #process function that runs after the
> optionwidget one? Look at the flexifield  module how to add one.
> 
> Cheers,
> 	Gerhard

Thanks for the response. I did look into #process but was unable to quickly
figure out what the heck it does :) I was quite frustrated.

Shortly after sending out this message, I figured out that the options for an
optionwidgets_select element are accessible from hook_form_alter(), but not in
the place one would expect ($form['my_cck_select_field'][#options]) but instead
are stored as a string in
$form['#field_info']['my_cck_select_field']['allowed_values']. I can set a
string value of options there and it will show up in the rendered form. Not at
all pretty, but it works.



-- 
Harry Slaughter
Web Developer
Devbee - Effective Drupal
http://devbee.com/
619-249-8780

From andrewberry at sentex.net  Tue Mar 10 01:22:29 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Mon, 9 Mar 2009 21:22:29 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <49B5AAEB.1070804@killesreiter.de>
References: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>	<325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>	<49B59056.7050403@killesreiter.de>
	<5A4C9BFB-C293-4C50-819C-CB50BC49C4D7@sentex.net>
	<49B5AAEB.1070804@killesreiter.de>
Message-ID: <4CF50B28-3DB0-4EF5-85D1-2069201F635E@sentex.net>

On 9-Mar-09, at 7:48 PM, Gerhard Killesreiter wrote:

> I guess something like this is already part of the redesign and we'll
> wait a few weeks longer untill that is finished. If it isn't part of  
> it,
> please add an issue for it and tag it with "drupal.org redesign".

For anyone interested: http://drupal.org/node/396760

--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/20090309/c8ae5dff/attachment.bin 

From drewish at katherinehouse.com  Tue Mar 10 01:29:37 2009
From: drewish at katherinehouse.com (andrew morton)
Date: Mon, 9 Mar 2009 21:29:37 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
References: <49B55186.9090609@citris-uc.org>
	<049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
Message-ID: <fab053ce0903091829g3c1baf70x412bbe16886edf51@mail.gmail.com>

Daniel's proposal to moderate the creation of project nodes is really
the only suggestion that I've found compelling in this thread. Having
a checkpoint that requires a maintainer to list other similar modules
and explain how their module is different from other existing ones
would be very helpful.

andrew

On Mon, Mar 9, 2009 at 2:15 PM, Daniel F. Kudwien
<news at unleashedmind.com> wrote:
> One point of his proposal is valid though: We could do better in preventing
> duplicated modules and efforts.
>
> We have
>
> - CVS sandboxes for experimental code. (I'd argue that almost no one knows
> about sandboxes and how to use them)
>
> - Official projects on drupal.org. (With complete release, issue, and
> versioning systems)
>
> - No "moderation" for new project nodes. (Anyone with a CVS account is able
> to create anything)
>
>
> Question:
>
> Would it really hurt the process of evolution and innovation in Drupal when
> a new project ("request") would go into a "new projects queue" first, where
> all community members could do a quick review and optionally point to a
> possible existing project that could benefit from additional man-power,
> features, and stuff?
>
> Would such a process not even do the opposite - speeding up evolution (by
> not duplicating efforts)?
>
>
> I mean, as a developer, I can review a module's code to find out which
> module is sane to use. ?Regular Drupal users cannot - they have to blindly
> choose one of the modules. ?Whether developer or user, finding out which
> module to choose is a pain, a "waste of time and effort".
>
> Implementing that process would be fairly easy. ?So I can only guess that
> the majority of developers a) either does not know about CVS sandboxes, or
> b) likes to have duplicate efforts, or that c) I'm on crack.
>
> sun
>
>

From greg at t2media.com  Tue Mar 10 01:39:31 2009
From: greg at t2media.com (Greg Holsclaw)
Date: Mon, 9 Mar 2009 18:39:31 -0700
Subject: [development] Wasting time and effort
In-Reply-To: <fab053ce0903091829g3c1baf70x412bbe16886edf51@mail.gmail.com>
References: <49B55186.9090609@citris-uc.org>
	<049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<fab053ce0903091829g3c1baf70x412bbe16886edf51@mail.gmail.com>
Message-ID: <00a401c9a121$0f7490e0$2e5db2a0$@com>

In some good Web2.0 books like Here Comes Everybody: The Power of Organizing
Without Organizations (by Clay Shirky, with some open source books also to
his name) and others, the concept of Publish then Filter is a main tenant of
Open Source and general Internet publishing in general. The old days of
print media where 'the professionals' had to filter because all the day's
info just couldn't fit into the printed pages of a newspaper are gone.

The whole idea of open source is someone started doing something and put it
out there for people to look at.

The main point now is the 'Filter' and publication. Discovering good modules
is hard, which is why findability is part of the Drupal.org redesign. I
think the effort should be there. Let download counts, peer review and
recommendation lists be the filter, not a review prior to publishing a new
project.

Publish then Filter, not the other way around.

-Greg

-----Original Message-----
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of andrew morton
Sent: Monday, March 09, 2009 6:30 PM
To: development at drupal.org
Subject: Re: [development] Wasting time and effort

Daniel's proposal to moderate the creation of project nodes is really
the only suggestion that I've found compelling in this thread. Having
a checkpoint that requires a maintainer to list other similar modules
and explain how their module is different from other existing ones
would be very helpful.

andrew

On Mon, Mar 9, 2009 at 2:15 PM, Daniel F. Kudwien
<news at unleashedmind.com> wrote:
> One point of his proposal is valid though: We could do better in
preventing
> duplicated modules and efforts.
>
> We have
>
> - CVS sandboxes for experimental code. (I'd argue that almost no one knows
> about sandboxes and how to use them)
>
> - Official projects on drupal.org. (With complete release, issue, and
> versioning systems)
>
> - No "moderation" for new project nodes. (Anyone with a CVS account is
able
> to create anything)
>
>
> Question:
>
> Would it really hurt the process of evolution and innovation in Drupal
when
> a new project ("request") would go into a "new projects queue" first,
where
> all community members could do a quick review and optionally point to a
> possible existing project that could benefit from additional man-power,
> features, and stuff?
>
> Would such a process not even do the opposite - speeding up evolution (by
> not duplicating efforts)?
>
>
> I mean, as a developer, I can review a module's code to find out which
> module is sane to use. ?Regular Drupal users cannot - they have to blindly
> choose one of the modules. ?Whether developer or user, finding out which
> module to choose is a pain, a "waste of time and effort".
>
> Implementing that process would be fairly easy. ?So I can only guess that
> the majority of developers a) either does not know about CVS sandboxes, or
> b) likes to have duplicate efforts, or that c) I'm on crack.
>
> sun
>
>


From dan at coders.co.nz  Tue Mar 10 00:08:20 2009
From: dan at coders.co.nz (Dan Morrison)
Date: Tue, 10 Mar 2009 13:08:20 +1300
Subject: [development] Wasting time and effort - Here's a productive
	suggestion instead
In-Reply-To: <mailman.1327.1236640946.6076.development@drupal.org>
References: <mailman.1327.1236640946.6076.development@drupal.org>
Message-ID: <1EE29059-88EA-40E9-9AAC-97949A164CDE@coders.co.nz>

I tried to post this into the thread earlier, but I may have been  
blanked due to using a different email (? I only use the digest)
Anyway ...
Re Suns suggestion earlier about a review period - I proposed the same  
a long while ago.
[A suggestion for reducing new-duplicated modules : require RFC or  
statement of intent posting]
http://drupal.org/node/316973

PLEASE Look at that thread and you will see many others also against  
*enforcement* ( = manpower & acrimony) but for a generally useful  
community-based process. Note, not a "core developer" gatekeeper team,  
but better visibility and feedback loop to resolve dupes.
It got to the 'nice idea' stage, but no further.

Everyone is welcome to review duplicates over in the  [Duplicated  
Modules hall of shame]
http://groups.drupal.org/duplicated-modules-hall-shame
where these issues are acknowleged, and hopefully being worked  
towards. Please see the wording of the statement of intent over there.

I'd like to keep out of this debate, which is not succeeding in  
convincing either Marcel or everyone else, but :
>
> Well it's not that my proposal is totally unrealistic. Only because no
> one is supporting it does it become so. Would Dries or Angela have
> proposed it, everybody and his dog would be up in flames of enthusiasm
> and surely consider it the right way to go.

It could be that everyone disagrees with it because they think it's a  
bad idea.

If one person says doing something is a stupid idea, they may just be  
being mean or not have had their coffee yet.

If three random people say it's a stupid idea, maybe they're ganging  
up on you. (you could consider what seemed to prompt that)

If half a dozen long-time developers, each who have seen this or  
similar suggestions several times before, try to explain at length  
exactly why a certain approach isn't such a practical idea, consider  
the possibility that they may know what they are talking about.

If the whole world disagrees with you, you may be the messiah, but  
you're probably just wrong about this one thing.

.dan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090310/8563dc8c/attachment-0001.htm 

From drewish at katherinehouse.com  Tue Mar 10 01:51:10 2009
From: drewish at katherinehouse.com (andrew morton)
Date: Mon, 9 Mar 2009 21:51:10 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <00a401c9a121$0f7490e0$2e5db2a0$@com>
References: <49B55186.9090609@citris-uc.org>
	<049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<fab053ce0903091829g3c1baf70x412bbe16886edf51@mail.gmail.com>
	<00a401c9a121$0f7490e0$2e5db2a0$@com>
Message-ID: <fab053ce0903091851n7e4157bey7742d698b77af45b@mail.gmail.com>

I've actually read the book--and the same point made in other parts of
the thread--and I still think that there is something to be said for
making someone who wants to start a new module spend the 20 minutes
searching for prior art and explaining why their work is different.
Far better for the developer to do it once since they understand
exactly what their code does (or they hope it will do), and as a
result of the process have a block of text for the project description
explaining its purpose. That will save everyone evaulating the module
the time of duplicating that research.

I support better d.o filtering but I think the best use of that would
be directed at module developers who may not be aware of existing
projects. I know that I've spent quite a bit of time on projects only
to start discussing it on IRC and have someone point me to a finished
version of my project. Fortuneatly I didn't post my module, end up
with duplication and have to decide if I should keep supporting it or
try to migrate everyone over to the other module. I think it's a
small, one time, price to pay before unleashing your code on the
community.

andrew

On Mon, Mar 9, 2009 at 9:39 PM, Greg Holsclaw <greg at t2media.com> wrote:
> In some good Web2.0 books like Here Comes Everybody: The Power of Organizing
> Without Organizations (by Clay Shirky, with some open source books also to
> his name) and others, the concept of Publish then Filter is a main tenant of
> Open Source and general Internet publishing in general. The old days of
> print media where 'the professionals' had to filter because all the day's
> info just couldn't fit into the printed pages of a newspaper are gone.
>
> The whole idea of open source is someone started doing something and put it
> out there for people to look at.
>
> The main point now is the 'Filter' and publication. Discovering good modules
> is hard, which is why findability is part of the Drupal.org redesign. I
> think the effort should be there. Let download counts, peer review and
> recommendation lists be the filter, not a review prior to publishing a new
> project.
>
> Publish then Filter, not the other way around.
>
> -Greg
>
> -----Original Message-----
> From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
> On Behalf Of andrew morton
> Sent: Monday, March 09, 2009 6:30 PM
> To: development at drupal.org
> Subject: Re: [development] Wasting time and effort
>
> Daniel's proposal to moderate the creation of project nodes is really
> the only suggestion that I've found compelling in this thread. Having
> a checkpoint that requires a maintainer to list other similar modules
> and explain how their module is different from other existing ones
> would be very helpful.
>
> andrew
>
> On Mon, Mar 9, 2009 at 2:15 PM, Daniel F. Kudwien
> <news at unleashedmind.com> wrote:
>> One point of his proposal is valid though: We could do better in
> preventing
>> duplicated modules and efforts.
>>
>> We have
>>
>> - CVS sandboxes for experimental code. (I'd argue that almost no one knows
>> about sandboxes and how to use them)
>>
>> - Official projects on drupal.org. (With complete release, issue, and
>> versioning systems)
>>
>> - No "moderation" for new project nodes. (Anyone with a CVS account is
> able
>> to create anything)
>>
>>
>> Question:
>>
>> Would it really hurt the process of evolution and innovation in Drupal
> when
>> a new project ("request") would go into a "new projects queue" first,
> where
>> all community members could do a quick review and optionally point to a
>> possible existing project that could benefit from additional man-power,
>> features, and stuff?
>>
>> Would such a process not even do the opposite - speeding up evolution (by
>> not duplicating efforts)?
>>
>>
>> I mean, as a developer, I can review a module's code to find out which
>> module is sane to use. ?Regular Drupal users cannot - they have to blindly
>> choose one of the modules. ?Whether developer or user, finding out which
>> module to choose is a pain, a "waste of time and effort".
>>
>> Implementing that process would be fairly easy. ?So I can only guess that
>> the majority of developers a) either does not know about CVS sandboxes, or
>> b) likes to have duplicate efforts, or that c) I'm on crack.
>>
>> sun
>>
>>
>
>

From Matt at NinjitsuWeb.com  Tue Mar 10 01:52:24 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Mon, 09 Mar 2009 21:52:24 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <fab053ce0903091829g3c1baf70x412bbe16886edf51@mail.gmail.com>
References: <49B55186.9090609@citris-uc.org>	<049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<fab053ce0903091829g3c1baf70x412bbe16886edf51@mail.gmail.com>
Message-ID: <49B5C7D8.8020506@NinjitsuWeb.com>

andrew morton wrote:
> Daniel's proposal to moderate the creation of project nodes is really
> the only suggestion that I've found compelling in this thread. Having
> a checkpoint that requires a maintainer to list other similar modules
> and explain how their module is different from other existing ones
> would be very helpful.
>   

As has already been pointed out, we already require an application for 
CVS access. The picture is being painted like anyone off the street can 
just start committing to the repo, and that's just not the case.

Even this level of moderation has it's drawbacks, and here's my true 
story to prove it:

My very first Drupal module was a simple integration with a third party 
service. I applied for my CVS account, and in the meantime, someone else 
who already had a CVS account coded and published a practically 
identical module. Wasted time and effort on their part, because they 
didn't know about my module because I didn't have permission to publish 
it yet.

To be clear: I'm not arguing against reviewing CVS applicants; this 
situation almost certainly would only occur with modules as trivial as 
the one under discussion. I'm just making the point that even the little 
filtration we have now can be counter-productive. We certainly shouldn't 
be adding further restrictions.

Best,

Matt

From drewish at katherinehouse.com  Tue Mar 10 01:59:43 2009
From: drewish at katherinehouse.com (andrew morton)
Date: Mon, 9 Mar 2009 21:59:43 -0400
Subject: [development] Wasting time and effort
In-Reply-To: <49B5C7D8.8020506@NinjitsuWeb.com>
References: <49B55186.9090609@citris-uc.org>
	<049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<fab053ce0903091829g3c1baf70x412bbe16886edf51@mail.gmail.com>
	<49B5C7D8.8020506@NinjitsuWeb.com>
Message-ID: <fab053ce0903091859q35b7bf5do8f22a29a6102c810@mail.gmail.com>

On Mon, Mar 9, 2009 at 9:52 PM, Matt Chapman <Matt at ninjitsuweb.com> wrote:
> As has already been pointed out, we already require an application for CVS
> access. The picture is being painted like anyone off the street can just
> start committing to the repo, and that's just not the case.

I think that's really the problem in a lot of cases. New devs get
screened but existing ones don't bother. I know in my case I've often
done a cursory search but since I know what code I'd need to write, I
just jump right in.

> Even this level of moderation has it's drawbacks, and here's my true story
> to prove it:
>
> My very first Drupal module was a simple integration with a third party
> service. I applied for my CVS account, and in the meantime, someone else who
> already had a CVS account coded and published a practically identical
> module. Wasted time and effort on their part, because they didn't know about
> my module because I didn't have permission to publish it yet.

I think this bit of unused work is really not that large a price to
pay for having multiple duplicate modules sprung out on the community
with no clear differentiation. It's hard to unbreak the egg. Once
there's people using the module you can't really take it back.

andrew

From mpartap at gmx.net  Tue Mar 10 02:37:47 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Tue, 10 Mar 2009 03:37:47 +0100
Subject: [development] Wasting time and effort - Here's a
 productive	suggestion instead
In-Reply-To: <1EE29059-88EA-40E9-9AAC-97949A164CDE@coders.co.nz>
References: <mailman.1327.1236640946.6076.development@drupal.org>
	<1EE29059-88EA-40E9-9AAC-97949A164CDE@coders.co.nz>
Message-ID: <49B5D27B.1070106@gmx.net>

> PLEASE Look at that thread and you will see many others also against
> *enforcement* ( = manpower & acrimony) but for a generally useful
> community-based process.
So enforcement of coding style and not breaking tests is too large of 
a price to pay, now i see.

> Note, not a "core developer" gatekeeper team,
Even after me going to lengths doing 20 or so postings to explain and 
reason what i have in mind, it's amazing people still misunderstand 
what i propose. Is it me or them.

> but better visibility and feedback loop to resolve dupes.
Frigging exactly what i proposed.

> It got to the 'nice idea' stage, but no further.
Well fine, that means any future attempt is doomed to fail, thus 
status quo is stuck and bound to stay. Why does that make me wonder 
what sort of device would be required for making a human being to 
constructively try to understand someone else's perspective and 
subsequently reconsider their own position.

> Everyone is welcome to review duplicates over in the [Duplicated Modules
> hall of shame]
> where these issues are acknowleged, and hopefully being worked towards.
Well i have no clue what IS going on with the various notification and 
poll module incarnations. But if we all hope strongly enough, their 
developers surely will jump over their shadows and team up all by 
themselves.

> I'd like to keep out of this debate, which is not succeeding in
> convincing either Marcel or everyone else, but :
By good rational argument i will be convinced. Feed me :O

> If one person says doing something is a stupid idea, they may just be
> being mean or not have had their coffee yet.
> If three random people say it's a stupid idea, maybe they're ganging up
> on you. (you could consider what seemed to prompt that)
> If half a dozen long-time developers, each who have seen this or similar
> suggestions several times before,
This or similar suggestions - well frankly i posted a detailed 
proposal how exactly a process like this could look like. And sorry, 
in the year i've been on this list, i have not noticed any similar 
proposal (and i just looked again).
Furthermore, every situation is unique, and when circumstances 
changes, old arguments sometimes get invalidated. Which means a clever 
person constantly reconsiders and adapts his opinion to reality 
fluctuations.

> try to explain *at length* exactly why
> a certain approach isn't such a practical idea,
Yeah like 'dont like it because it sux'

> consider the possibility
> that they may know what they are talking about.
Well i am very well considering it, and trust me i'd not have gone on 
on it in lengths if any compelling argument would have been brought up.
Oh and btw, out of a million people asked, how many would have 
considered men ever flying to the moon possible 500 years ago? Times 
change, so do eternal truths.

> If the whole world disagrees with you, you may be the messiah, but
> you're probably just wrong about this one thing.
Well can one be right in that case without being the messiah? because 
that'd be pretty large shoes to fill..
btw abundant opposition happened before in history to non-messiah 
people which were more right than wrong.

rgds.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From greg at t2media.com  Tue Mar 10 02:14:22 2009
From: greg at t2media.com (Greg Holsclaw)
Date: Mon, 9 Mar 2009 19:14:22 -0700
Subject: [development] Wasting time and effort
In-Reply-To: <fab053ce0903091859q35b7bf5do8f22a29a6102c810@mail.gmail.com>
References: <49B55186.9090609@citris-uc.org>
	<049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<fab053ce0903091829g3c1baf70x412bbe16886edf51@mail.gmail.com>
	<49B5C7D8.8020506@NinjitsuWeb.com>
	<fab053ce0903091859q35b7bf5do8f22a29a6102c810@mail.gmail.com>
Message-ID: <00b801c9a125$eda47610$c8ed6230$@com>


>On Mon, Mar 9, 2009 at 9:52 PM, Matt Chapman <Matt at ninjitsuweb.com> wrote:
>> As has already been pointed out, we already require an application for
CVS
>> access. The picture is being painted like anyone off the street can just
>> start committing to the repo, and that's just not the case.

>I think that's really the problem in a lot of cases. New devs get
>screened but existing ones don't bother. I know in my case I've often
>done a cursory search but since I know what code I'd need to write, I
>just jump right in.

Which prove the findability angle exacty!

Many justifications for this filter is to decrease wasted effort (increase
collaboration), but if a review board upon release of your new module
discovers a prior module, you have already wasted your time (and that of the
review board). The only real gain is less module congestion (which is
partially solve every major version of Drupal through module die-off), but
not removal of wasted energy.

Being able to find modules ASAP solves both issues, and thus with limited
resources seems the better place for our energies.

-Greg


From news at unleashedmind.com  Tue Mar 10 02:51:19 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Tue, 10 Mar 2009 03:51:19 +0100
Subject: [development] Wasting time and effort
In-Reply-To: <49B5C7D8.8020506@NinjitsuWeb.com>
Message-ID: <04df01c9a12b$17336680$0200a8c0@structworks.com>

> As has already been pointed out, we already require an 
> application for CVS access. The picture is being painted like 
> anyone off the street can just start committing to the repo, 
> and that's just not the case.

It is.  And I made the best example myself.  If you ever happen(ed) to be in
the need for a Lightbox on your web site, then you are faced with two
duplicate, I mean, really duplicate modules:  Lightbox2 and jLightbox.  The
latter I am guilty for.  And there is nothing I would regret more today.

jLightbox was created "overnight", because Lightbox2 was incompatible with
something else at that time.  What I did not know was:  There was already a
new branch with a complete rewrite of Lightbox2 in CVS that mostly resulted
in being the same as jLightbox.

Today, I am still trying to find some time to merge some minor changes back
into Lightbox2, and more importantly, write a migration path from jLightbox
to Lightbox2.

This is just one tiny example for the annoying mess of senseless module
duplication on drupal.org.


Causes for duplication:

- Developer did not search.

- Developer did search, but existing module uses different lingo.

- Developer did search, but did not realize that existing module does the
same in an abstracted way.

- Developer was not able to imagine that his contribution would be accepted
in existing module. [<-- jLightbox]

- Maintainer of existing module did neither accept the contribution nor
accept developer as co-maintainer.

- Developer was too lazy to grasp the API of existing module, better write a
new one.

- Developer spent weeks of coding in private, now he must release, even if
it's 100% duplicate (ego).

- Developer wants to attract clients (ego).

- Developer does not know how to patch, just learned how to use CVS from the
handbooks.

Possibly more.


Filtering already published projects will get you the same duplicated
results like now, which you still have to research and possibly test.  The
real issue is, however, that there are many projects that would happily
accept contributions, improvements, extensions, and also new co-maintainers.
But instead of trying hard to let developers join forces, we allow silly
duplication, Drupal users have to suffer from in the end.

sun


From greg at t2media.com  Tue Mar 10 05:43:20 2009
From: greg at t2media.com (Greg Holsclaw)
Date: Mon, 9 Mar 2009 22:43:20 -0700
Subject: [development] Wasting time and effort - Here's a productive
	suggestion instead
In-Reply-To: <49B5D27B.1070106@gmx.net>
References: <mailman.1327.1236640946.6076.development@drupal.org>
	<1EE29059-88EA-40E9-9AAC-97949A164CDE@coders.co.nz>
	<49B5D27B.1070106@gmx.net>
Message-ID: <F99613C1-12CE-4F65-9EAE-1C1D5F73CDDB@t2media.com>

Eventually rational minds can conclude that two coherent ideas are  
both valid. You ideas may be valid, but the inertia of the current  
Drupal way (which is rational and funtional) of doing stuff is working.

And it is less us who have convince since we aren't the one working  
against the grain.

Sent from a mobile device.

On Mar 9, 2009, at 7:37 PM, Marcel Partap <mpartap at gmx.net> wrote:

>> PLEASE Look at that thread and you will see many others also against
>> *enforcement* ( = manpower & acrimony) but for a generally useful
>> community-based process.
> So enforcement of coding style and not breaking tests is too large  
> of a price to pay, now i see.
>
>> Note, not a "core developer" gatekeeper team,
> Even after me going to lengths doing 20 or so postings to explain  
> and reason what i have in mind, it's amazing people still  
> misunderstand what i propose. Is it me or them.
>
>> but better visibility and feedback loop to resolve dupes.
> Frigging exactly what i proposed.
>
>> It got to the 'nice idea' stage, but no further.
> Well fine, that means any future attempt is doomed to fail, thus  
> status quo is stuck and bound to stay. Why does that make me wonder  
> what sort of device would be required for making a human being to  
> constructively try to understand someone else's perspective and  
> subsequently reconsider their own position.
>
>> Everyone is welcome to review duplicates over in the [Duplicated  
>> Modules
>> hall of shame]
>> where these issues are acknowleged, and hopefully being worked  
>> towards.
> Well i have no clue what IS going on with the various notification  
> and poll module incarnations. But if we all hope strongly enough,  
> their developers surely will jump over their shadows and team up all  
> by themselves.
>
>> I'd like to keep out of this debate, which is not succeeding in
>> convincing either Marcel or everyone else, but :
> By good rational argument i will be convinced. Feed me :O
>
>> If one person says doing something is a stupid idea, they may just be
>> being mean or not have had their coffee yet.
>> If three random people say it's a stupid idea, maybe they're  
>> ganging up
>> on you. (you could consider what seemed to prompt that)
>> If half a dozen long-time developers, each who have seen this or  
>> similar
>> suggestions several times before,
> This or similar suggestions - well frankly i posted a detailed  
> proposal how exactly a process like this could look like. And sorry,  
> in the year i've been on this list, i have not noticed any similar  
> proposal (and i just looked again).
> Furthermore, every situation is unique, and when circumstances  
> changes, old arguments sometimes get invalidated. Which means a  
> clever person constantly reconsiders and adapts his opinion to  
> reality fluctuations.
>
>> try to explain *at length* exactly why
>> a certain approach isn't such a practical idea,
> Yeah like 'dont like it because it sux'
>
>> consider the possibility
>> that they may know what they are talking about.
> Well i am very well considering it, and trust me i'd not have gone  
> on on it in lengths if any compelling argument would have been  
> brought up.
> Oh and btw, out of a million people asked, how many would have  
> considered men ever flying to the moon possible 500 years ago? Times  
> change, so do eternal truths.
>
>> If the whole world disagrees with you, you may be the messiah, but
>> you're probably just wrong about this one thing.
> Well can one be right in that case without being the messiah?  
> because that'd be pretty large shoes to fill..
> btw abundant opposition happened before in history to non-messiah  
> people which were more right than wrong.
>
> rgds.
>
> -- 
> "Obstacles are those frightful things you see when you take
>  your eyes off your goal."         -- Henry Ford (1863-1947)
>
>  Change the world! Vote: http://hfopi.org/vote-future

From sepeck at gmail.com  Tue Mar 10 06:40:02 2009
From: sepeck at gmail.com (Steven Peck)
Date: Mon, 9 Mar 2009 23:40:02 -0700
Subject: [development] Wasting time and effort
In-Reply-To: <006401c9a100$dc4d86b0$94e89410$@com>
References: <049101c9a0e3$1952b1c0$0200a8c0@structworks.com>
	<325F0B65-D633-4CF3-8610-1990C1029BFC@sentex.net>
	<006401c9a100$dc4d86b0$94e89410$@com>
Message-ID: <a151b5a00903092340q2e1ae5a8kc67f7707f67e22cd@mail.gmail.com>

There are even new modules listed on drupal.org

http://drupal.org/taxonomy/term/14/0/feed

http://drupal.org/node/63589

Steven

On Mon, Mar 9, 2009 at 2:49 PM, Greg Holsclaw <greg at t2media.com> wrote:
>
> -----Original Message-----
> From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
> On Behalf Of Andrew Berry
> Sent: Monday, March 09, 2009 2:38 PM
> To: development at drupal.org
> Subject: Re: [development] Wasting time and effort
>
> On 9-Mar-09, at 2:15 PM, Daniel F. Kudwien wrote:
>
>> Would it really hurt the process of evolution and innovation in
>> Drupal when
>> a new project ("request") would go into a "new projects queue"
>> first, where
>> all community members could do a quick review and optionally point
>> to a
>> possible existing project that could benefit from additional man-
>> power,
>> features, and stuff?
>
> I think this is a good idea. I was having this conversation with some
> at DC; we all noted that for our very first contribution, we did a
> great deal of thinking, planning, and so on, but for subsequent
> modules they tend to go in without as much attention. I'm sure I'm not
> the only one who's written code only to discover after that someone
> else did it under a different name. No one I think really likes
> duplication without reason.
>
> Long term, I think the solution is for search on d.o to continue to
> improve so that it is easy to tell within a few searches if another
> module exists. Until then, a "does this exist" queue or mailing list
> could serve quite nicely.
>
> --Andrew
>
> There are new modules listed at http://drupalmodules.com/new-modules/feed.
> Also, many times before people have used this list to announce new modules,
> or inquire if someone is already working on something which leads exactly to
> the feedback that was suggested.
>
> But I am against the 'request' verbiage that was used in this idea. Gives
> the impression that an idea or module has to be approved before being worked
> on, and that is not an open source ideal at all. In Drupal and other open
> source projects, the hurdle to success or failure should be as low as
> possible, and even parallel modules more adequately search the solution
> space of a problem. All are good things. And yes, the module list has grown
> from hundreds at 4.7, to thousands now, but that problem will persist as
> long as Drupal is leading the pack.
>
> Greg
>
>

From dan at coders.co.nz  Tue Mar 10 07:34:02 2009
From: dan at coders.co.nz (Dan Morrison)
Date: Tue, 10 Mar 2009 20:34:02 +1300
Subject: [development] Wasting time and effort - Here's a productive
	suggestion instead
In-Reply-To: <mailman.1357.1236663825.6076.development@drupal.org>
References: <mailman.1357.1236663825.6076.development@drupal.org>
Message-ID: <537509B5-40F6-4A29-9B40-4ABCB0C93C65@coders.co.nz>

> From: Marcel Partap <mpartap at gmx.net>
>
>> PLEASE Look at that thread and you will see many others also against
>> *enforcement* ( = manpower & acrimony) but for a generally useful
>> community-based process.
> So enforcement of coding style and not breaking tests is too large of
> a price to pay, now i see.

Coding style reviews are good, and can even happen automatically.  
That's trivial.
There is even a process for running automated tests. Although you may  
find that almost no contrib modules HAVE tests. This is a non- 
automatable detail. Modules breaking tests is not an issue for users.

However, neither of these have anything to do with the very real issue  
of DUPLICATION and overlap.

>> Note, not a "core developer" gatekeeper team,
> Even after me going to lengths doing 20 or so postings to explain and
> reason what i have in mind, it's amazing people still misunderstand
> what i propose. Is it me or them.

The ONLY way to actually tell good code from bad code, and tell  
duplicates and redundancy is by informed developer review.
That is the manpower needed. And as noted earlier, it needs to be  
skilled devs, not just popular vote. Which leads us to back to  
requiring housekeeping work by some non-existent cadre.

>> but better visibility and feedback loop to resolve dupes.
> Frigging exactly what i proposed.

No. "Visibility" and feedback on proposed modules was was my  
suggestion last year.
What I saw you propose in [Date: Sun, 08 Mar 2009 16:30:29 +0100] was  
bureaucracy, enforcement, automation, restrictions, vetos, and the  
belief that better code could be automated by :
> what is possible is to come up with an algorithm that leads to
> a statistically significant improvement on the sustainability and
> correctness of decisions.

I just gotta disagree that good, or more importantly - useful and  
unique - code can be judged by an algorithm in a way that will address  
the problem at hand.
If you have such an algorithm handy, please suggest it as an addition  
to coder.module.

> Why does that make me wonder
> what sort of device would be required for making a human being to
> constructively try to understand someone else's perspective and
> subsequently reconsider their own position.

:-)

>
> btw abundant opposition happened before in history to non-messiah
> people which were more right than wrong.

And so you completely miss the point. o_O
Just because lots of experts disagree with you does NOT prove that you  
must be right.
There are a heck of a lot more folk who were told they were wrong -  
and were wrong. Citing an exception only proves the (general) rule.

Whether we are a meritocracy, a democracy, a timocracy or a  
dictatorship (benign or not), your campaign to make contributing to  
Drupal three times harder for everyone is just not getting any traction.
Vast numbers of people already find CVS and patches a heck of an  
obstacle. I've had dozens of probably-OK patches die in the water  
because it there wasn't enough motivation for even one other valid  
developer to help push it through. Requiring a quorum of *10* votes as  
you proposed means that nothing would happen ever.

If it was even conceivable that Drupal contrib became so draconic, it  
would force contributions into the "badlands" (see proposal http://drupal.org/node/307211) 
  and possibly be divisive enough to justify a totally parallel  
repository of 'unvetted but free' code on another site.
I (and many others) don't want to see that happen.

*sigh*
To end on another hopefully constructive suggestion, module voting and  
rating has ALWAYS been discussed and proposed, and is one of the key  
requested features the background of the d.o. redesign. If this comes  
though as providing a top list of recommended or even semi-official  
modules, that is a good thing. But such ranking or classification is  
NOT going to take the form of prohibiting people from contributing new  
innovation. You describe your elaborate voting system as one where not  
enough votes = no commit access. That may be what is turning everyone  
off. Voting for informational purposes, I think we could get behind.  
But making rules that will negatively affect the majority of  
developers and damage the community ... not popular.

It may be possible to rework your proposal in a more practical way -  
but only if it enables the community by shepherding input, not as a  
bully cop that bans input by default.

.dan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090310/ed2b8091/attachment.htm 

From jim at rootyhollow.com  Tue Mar 10 14:02:10 2009
From: jim at rootyhollow.com (Jim Taylor)
Date: Tue, 10 Mar 2009 10:02:10 -0400
Subject: [development] sandbox projects
Message-ID: <2f2379e70903100702h1b78d625jb5a967d23b2f7dd9@mail.gmail.com>

I'm curious is there is a handbook page on developing sandbox projects.  A
Google s/d.o search doesn't turn up much (saw mention of it on a recent
thread and the one module I have contributed had a 3 years old attempt in
there)


-- 
Jim Taylor
Rooty Hollow LLC, Owner
jim at rootyhollow.com
www.rootyhollow.com
(614) 886-5530

Twitter: jalama
Linkedin: http://www.linkedin.com/in/rootyhollow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090310/faf718d0/attachment.htm 

From darrenoh at sidepotsinternational.com  Tue Mar 10 15:09:40 2009
From: darrenoh at sidepotsinternational.com (Darren Oh)
Date: Tue, 10 Mar 2009 11:09:40 -0400
Subject: [development] sandbox projects
In-Reply-To: <2f2379e70903100702h1b78d625jb5a967d23b2f7dd9@mail.gmail.com>
References: <2f2379e70903100702h1b78d625jb5a967d23b2f7dd9@mail.gmail.com>
Message-ID: <6C582D7F-6BA9-4299-A3BE-0D25142ED044@sidepotsinternational.com>

http://drupal.org/node/103704

On Mar 10, 2009, at 10:02 AM, Jim Taylor wrote:

> I'm curious is there is a handbook page on developing sandbox  
> projects.  A Google s/d.o search doesn't turn up much (saw mention  
> of it on a recent thread and the one module I have contributed had a  
> 3 years old attempt in there)

From drupal at dave-cohen.com  Tue Mar 10 16:24:58 2009
From: drupal at dave-cohen.com (Dave Cohen)
Date: Tue, 10 Mar 2009 09:24:58 -0700
Subject: [development] Failed to install HEAD
Message-ID: <200903100924.58159.drupal@dave-cohen.com>

I'm trying to submit a patch which changes a form in install.php.  Because of that change the test bot always fails with "Failed to install HEAD".  At least I'm guessing that's why, the error message really gives no explanation.

Is there something I can include in the patch to make the test bot succeed?

The patch is here: http://drupal.org/node/394282

Thanks,

-Dave

From aldo at caonao.cu  Tue Mar 10 17:50:02 2009
From: aldo at caonao.cu (Aldo Martinez Selleras)
Date: Tue, 10 Mar 2009 13:50:02 -0400
Subject: [development] add a block in my custom php code
In-Reply-To: <49A4220B.70209@logrus.com>
References: <200902231359.06803.aldo@caonao.cu>
	<c538f9410902240831y34588cd1v874184f0312fd32b@mail.gmail.com>
	<49A4220B.70209@logrus.com>
Message-ID: <200903101350.02778.aldo@caonao.cu>

hello everyone...

i have write a custom page where i'll show a custom content generated from the 
URL vars, but i need add a drupal block inside this code, how can i do this!?

     <div class="welcome"><h2>Welcome</h2><p><?php print 
$node->body; ?></p></div>
      </div>
   <div class="popular">
           HERE I NEED ADD A DRUPAL BLOCK
    </div>

-- 
----------------------
Aldo Martinez Selleras
Especialista en Telematica
CITMATEL GND Camaguey
Tel: 53 32 291661
Linux User #364356

From paolomainardi at gmail.com  Tue Mar 10 18:06:02 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Tue, 10 Mar 2009 19:06:02 +0100
Subject: [development] add a block in my custom php code
In-Reply-To: <200903101350.02778.aldo@caonao.cu>
References: <200902231359.06803.aldo@caonao.cu>
	<c538f9410902240831y34588cd1v874184f0312fd32b@mail.gmail.com>
	<49A4220B.70209@logrus.com> <200903101350.02778.aldo@caonao.cu>
Message-ID: <c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>

On Tue, Mar 10, 2009 at 6:50 PM, Aldo Martinez Selleras <aldo at caonao.cu>wrote:

> hello everyone...
>
> i have write a custom page where i'll show a custom content generated from
> the
> URL vars, but i need add a drupal block inside this code, how can i do
> this!?
>
>     <div class="welcome"><h2>Welcome</h2><p><?php print
> $node->body; ?></p></div>
>      </div>
>   <div class="popular">


<?php
$block = module_invoke('block', 'block', 'view', YOUR_BLOCK_ID);
print $block['content'];
?>



>    </div>


You can reveal YOUR_BLOCK_ID from the admin block page or inspecting the id
of the block output generated. ;)

P.

-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090310/c5034ed6/attachment.htm 

From aldo at caonao.cu  Tue Mar 10 18:02:21 2009
From: aldo at caonao.cu (Aldo Martinez Selleras)
Date: Tue, 10 Mar 2009 14:02:21 -0400
Subject: [development] add a block in my custom php code
In-Reply-To: <c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>
References: <200902231359.06803.aldo@caonao.cu>
	<200903101350.02778.aldo@caonao.cu>
	<c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>
Message-ID: <200903101402.21574.aldo@caonao.cu>

and there some way to know the block_ID ?? please!

-- 
----------------------
Aldo Martinez Selleras
Especialista en Telematica
CITMATEL GND Camaguey
Tel: 53 32 291661
Linux User #364356

From paolomainardi at gmail.com  Tue Mar 10 18:16:11 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Tue, 10 Mar 2009 19:16:11 +0100
Subject: [development] add a block in my custom php code
In-Reply-To: <200903101402.21574.aldo@caonao.cu>
References: <200902231359.06803.aldo@caonao.cu>
	<200903101350.02778.aldo@caonao.cu>
	<c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>
	<200903101402.21574.aldo@caonao.cu>
Message-ID: <c538f9410903101116o76d50448u75cc3ddbd8cde8e@mail.gmail.com>

On Tue, Mar 10, 2009 at 7:02 PM, Aldo Martinez Selleras <aldo at caonao.cu>wrote:

> and there some way to know the block_ID ?? please!
>

I'd write some methods to know the block_id....


-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090310/5f3695d0/attachment.htm 

From domenic at workhabit.com  Tue Mar 10 18:21:47 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Tue, 10 Mar 2009 11:21:47 -0700
Subject: [development] add a block in my custom php code
In-Reply-To: <c538f9410903101116o76d50448u75cc3ddbd8cde8e@mail.gmail.com>
References: <200902231359.06803.aldo@caonao.cu>
	<200903101350.02778.aldo@caonao.cu>
	<c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>
	<200903101402.21574.aldo@caonao.cu>
	<c538f9410903101116o76d50448u75cc3ddbd8cde8e@mail.gmail.com>
Message-ID: <e83e0db0903101121r51b550cfj68ef2f16eb563b33@mail.gmail.com>

Is it a block view?

On Tue, Mar 10, 2009 at 11:16 AM, Paolo Mainardi
<paolomainardi at gmail.com> wrote:
>
>
> On Tue, Mar 10, 2009 at 7:02 PM, Aldo Martinez Selleras <aldo at caonao.cu>
> wrote:
>>
>> and there some way to know the block_ID ?? please!
>
> I'd write some methods to know the block_id....
>
>
> --
> Paolo Mainardi
>
> Vice Presidente Assoc.ILDN (http://www.ildn.net)
> Blog: http://www.paolomainardi.com
>



-- 
Domenic Santangelo
senior engineer  |  workhabit,inc.
// email: domenic at workhabit.com  |  web: http://www.workhabit.com
// office: 866-workhabit  |  direct: 916-288-8243

From andrewberry at sentex.net  Tue Mar 10 18:41:16 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Tue, 10 Mar 2009 14:41:16 -0400
Subject: [development] add a block in my custom php code
In-Reply-To: <c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>
References: <200902231359.06803.aldo@caonao.cu>
	<c538f9410902240831y34588cd1v874184f0312fd32b@mail.gmail.com>
	<49A4220B.70209@logrus.com> <200903101350.02778.aldo@caonao.cu>
	<c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>
Message-ID: <09FBD86C-D8B8-40FB-A51C-2257147BEC57@sentex.net>

On 10-Mar-09, at 2:06 PM, Paolo Mainardi wrote:

> <?php
> $block = module_invoke('block', 'block', 'view', YOUR_BLOCK_ID);
> print $block['content'];
> ?>

I would consider creating a new region in your theme instead. Then you  
can assign and move any block to it through the block admin page as  
you see fit. Creating a region is pretty simple; I think the Zen theme  
has a decently documented method of doing it.

--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/20090310/271dcab4/attachment.bin 

From paolomainardi at gmail.com  Tue Mar 10 21:32:39 2009
From: paolomainardi at gmail.com (Paolo Mainardi)
Date: Tue, 10 Mar 2009 22:32:39 +0100
Subject: [development] add a block in my custom php code
In-Reply-To: <09FBD86C-D8B8-40FB-A51C-2257147BEC57@sentex.net>
References: <200902231359.06803.aldo@caonao.cu>
	<c538f9410902240831y34588cd1v874184f0312fd32b@mail.gmail.com>
	<49A4220B.70209@logrus.com> <200903101350.02778.aldo@caonao.cu>
	<c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>
	<09FBD86C-D8B8-40FB-A51C-2257147BEC57@sentex.net>
Message-ID: <c538f9410903101432m76ad82e9ha47f9d3cda642c6b@mail.gmail.com>

On Tue, Mar 10, 2009 at 7:41 PM, Andrew Berry <andrewberry at sentex.net>wrote:

> On 10-Mar-09, at 2:06 PM, Paolo Mainardi wrote:
>
>  <?php
>> $block = module_invoke('block', 'block', 'view', YOUR_BLOCK_ID);
>> print $block['content'];
>> ?>
>>
>
> I would consider creating a new region in your theme instead. Then you can
> assign and move any block to it through the block admin page as you see fit.
> Creating a region is pretty simple; I think the Zen theme has a decently
> documented method of doing it.
>

Yes clear, the region it's the standard way :) This is the "raw" mode to
call directly a block.

-- 
Paolo Mainardi

Vice Presidente Assoc.ILDN (http://www.ildn.net)
Blog: http://www.paolomainardi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090310/b7acc505/attachment.htm>

From karoly at negyesi.net  Tue Mar 10 22:14:46 2009
From: karoly at negyesi.net (Karoly Negyesi)
Date: Tue, 10 Mar 2009 15:14:46 -0700
Subject: [development] Duplicated modules
Message-ID: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>

Hi,

OK all you wiseasses, now you pissed me off enough to bring these
issues into wider public, so tell me what to do in these situations.

1) There is a Drupal module, older than my boots, gets a much needed
rewrite by two guys. Comes a third one, and he is, of course, welcome
to the party. There is a discussion of what we do and what we not to
do. Come next day, said third guy does what we all three agreed not
do. Following a debate, he packs his toys and starts a new project.
Said third guy contributes heavily to Drupal project for extremely
long but quality and quantity does not always correlate.

2) I hand off privatemsg to another maintainer. He wants to go in a
direction which neither me nor someone else even higher in the Drupal
hierarchy agrees with. We all three come to a happy conclusion and the
new maintainer does not go there. Time passes, and another guy,
notorious for starting a parallel project, does exactly the thing we
agreed on not to do and despite he says it was just experiment with
the new Drupal 6 code, the project lives on.

NK

PS. the project moderation queue would undo Drupal because people
would take their not-accepted projects off site. php nuke follows.
PS2. 'mob rule' applied to code does not work. Your precious
drupalmodules.com which I opposed from day one is an excellent
example. captcha rated #2 , cck and views not even in #10, give me a
break, this is broken,.

From domenic at workhabit.com  Tue Mar 10 22:37:14 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Tue, 10 Mar 2009 15:37:14 -0700
Subject: [development] Duplicated modules
In-Reply-To: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
Message-ID: <e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>

On Tue, Mar 10, 2009 at 3:14 PM, Karoly Negyesi <karoly at negyesi.net> wrote:
> so tell me what to do in these situations.
> 1) There is a Drupal module....he packs his toys and starts a new project

So he started his own project, so what. Move on.

> 2) I hand off privatemsg to another maintainer...

Your responsibility is over, move on. If you wanted to decide how it
was run, you shouldn't have given it up :)

> someone else even higher in the Drupal hierarchy
lolwat?

> Time passes, and another guy,
> notorious for starting a parallel project, does exactly the thing we
> agreed on not to do and despite he says it was just experiment with
> the new Drupal 6 code, the project lives on.

Don't see a big deal here...

This circles allllll the way back to what I said a few days ago --
there are modules that are "holy crap, can't live without (cck,
views...)" and the rest are handy if you happen to need them. The Holy
Crap modules are well maintained and the rest are all over the
spectrum. So maybe we need a way to call out "Drupal Seal of Approval"
on the "Good" ones (sort of like Nintendo games) In fact, let's do
that and charge $150 or something to get reviewed for the seal. Plenty
of trusted devs will vet a module for $150.

-D

From morbus at disobey.com  Tue Mar 10 22:41:07 2009
From: morbus at disobey.com (Morbus Iff)
Date: Tue, 10 Mar 2009 18:41:07 -0400
Subject: [development] Duplicated modules
In-Reply-To: <e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
Message-ID: <49B6EC83.2080205@disobey.com>


> spectrum. So maybe we need a way to call out "Drupal Seal of Approval"
> on the "Good" ones (sort of like Nintendo games) In fact, let's do
> that and charge $150 or something to get reviewed for the seal. Plenty
> of trusted devs will vet a module for $150.

To some degree, chx and I already started that with DrupalToughLove.com. 
I've entertained the thought of a seal in the past but, unlike video 
games, one can fix a module to get the seal, then seep back into 
absolute suckitude. It's not a fair or continued assessment.

And we didn't take any money for it (though, my utter lack of time 
devoted, in turn, to paying things, is what killed the project).

-- 
Morbus Iff ( and i twirled my hair and i popped my gum )
Technical: http://www.oreillynet.com/pub/au/779
Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus

From karoly at negyesi.net  Tue Mar 10 22:42:25 2009
From: karoly at negyesi.net (Karoly Negyesi)
Date: Tue, 10 Mar 2009 23:42:25 +0100 (CET)
Subject: [development] Duplicated modules
In-Reply-To: <e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
Message-ID: <E1LhAeX-0007zx-QM@garm.runbox.com>

----- Start Original Message -----
Sent: Tue, 10 Mar 2009 15:37:14 -0700
From: Domenic Santangelo <domenic at workhabit.com>
To: development at drupal.org
Subject: Re: [development] Duplicated modules

> On Tue, Mar 10, 2009 at 3:14 PM, Karoly Negyesi <karoly at negyesi.net> wrote:
> > so tell me what to do in these situations.
> > 1) There is a Drupal module....he packs his toys and starts a new project
> 
> So he started his own project, so what. Move on.

Aye and then I hear until eternity that why does subscriptions and notifications exist. I do not know whether I was right. I wish I knew! I dont. I love when I can code whatever I want because people review it and then someone else makes the decisions. I hate making decisions and living with the responsibility. And even so sometimes we err -- db_rewrite_sql, I look at you... (gone in D7, thanks god)

> > Time passes, and another guy,
> > notorious for starting a parallel project, does exactly the thing we
> > agreed on not to do and despite he says it was just experiment with
> > the new Drupal 6 code, the project lives on.
> 
> Don't see a big deal here...

I would not either if people would not write so passionately against module duplication...

From karoly at negyesi.net  Tue Mar 10 22:45:44 2009
From: karoly at negyesi.net (Karoly Negyesi)
Date: Tue, 10 Mar 2009 23:45:44 +0100 (CET)
Subject: [development] Duplicated modules
In-Reply-To: <49B6EC83.2080205@disobey.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
Message-ID: <E1LhAhk-0000SY-Pp@garm.runbox.com>

Morbus, what's your hourly rate on continuing DTL? I am dead serious. And DTL seal would apply only to a given release. I am pretty sure we can get people to actually pay for that. And you know what? I would not say no to a buck or two either. And finally, I am happy to split 30-70, as I know I work less on this project.

> > spectrum. So maybe we need a way to call out "Drupal Seal of Approval"
> > on the "Good" ones (sort of like Nintendo games) In fact, let's do
> > that and charge $150 or something to get reviewed for the seal. Plenty
> > of trusted devs will vet a module for $150.
> 
> To some degree, chx and I already started that with DrupalToughLove.com. 
> I've entertained the thought of a seal in the past but, unlike video 
> games, one can fix a module to get the seal, then seep back into 
> absolute suckitude. It's not a fair or continued assessment.
> 
> And we didn't take any money for it (though, my utter lack of time 
> devoted, in turn, to paying things, is what killed the project).
> 
> -- 
> Morbus Iff ( and i twirled my hair and i popped my gum )
> Technical: http://www.oreillynet.com/pub/au/779
> Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
> aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
> 

----- End Original Message -----

From domenic at workhabit.com  Tue Mar 10 22:49:52 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Tue, 10 Mar 2009 15:49:52 -0700
Subject: [development] Duplicated modules
In-Reply-To: <E1LhAhk-0000SY-Pp@garm.runbox.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com> <E1LhAhk-0000SY-Pp@garm.runbox.com>
Message-ID: <e83e0db0903101549o79520c10oa63d7764e5daeecc@mail.gmail.com>

On Tue, Mar 10, 2009 at 3:45 PM, Karoly Negyesi <karoly at negyesi.net> wrote:
> Morbus, what's your hourly rate on continuing DTL? I am dead serious. And DTL seal would apply only to a given release. I am pretty sure we can get people to actually pay for that. And you know what? I would not say no to a buck or two either. And finally, I am happy to split 30-70, as I know I work less on this project.

I really liked what I saw on DTL. I would be happy to collaborate, and
I'm sure I can get some of the guys in the shop in as well. Feel free
to ping me directly with ideas if you'd like -- it's a step in the
right direction, at least.

-D

From Matt at NinjitsuWeb.com  Tue Mar 10 23:22:34 2009
From: Matt at NinjitsuWeb.com (Matt Chapman)
Date: Tue, 10 Mar 2009 19:22:34 -0400
Subject: [development] Duplicated modules
In-Reply-To: <E1LhAhk-0000SY-Pp@garm.runbox.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>	<49B6EC83.2080205@disobey.com>
	<E1LhAhk-0000SY-Pp@garm.runbox.com>
Message-ID: <49B6F63A.80809@NinjitsuWeb.com>

Karoly Negyesi wrote:
> Morbus, what's your hourly rate on continuing DTL? I am dead serious. And DTL seal would apply only to a given release. I am pretty sure we can get people to actually pay for that. And you know what? I would not say no to a buck or two either. And finally, I am happy to split 30-70, as I know I work less on this project

How about a chip-in bucket and and system for voting on modules to be 
reviewed apart from maintainer requests?

Can we expect a review of Notifications module? ;-)

-Matt



From tz at it-arts.org  Wed Mar 11 00:23:15 2009
From: tz at it-arts.org (Thomas Zahreddin)
Date: Wed, 11 Mar 2009 01:23:15 +0100
Subject: [development] Duplicated modules
In-Reply-To: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
Message-ID: <1236730995.7845.50.camel@thomas-desktop>

You asked for a suggestion, here are my thoughts:

Am Dienstag, den 10.03.2009, 15:14 -0700 schrieb Karoly Negyesi:
> Hi,
> 
> OK all you wiseasses, now you pissed me off enough to bring these
> issues into wider public, so tell me what to do in these situations.
> 
> 1) There is a Drupal module, older than my boots, gets a much needed
> rewrite by two guys. Comes a third one, and he is, of course, welcome
> to the party. There is a discussion of what we do and what we not to
> do. Come next day, said third guy does what we all three agreed not
> do. Following a debate, he packs his toys and starts a new project.
> Said third guy contributes heavily to Drupal project for extremely
> long but quality and quantity does not always correlate.

So what can we learn form this (and many other stories)?

My answer to all three examples:

we need a better way to make decisions, since this sounds like the third
one does not agree in the end and to lay the responsibility in the hand
of teams: team members should not only be developers of the module, also
developers interested in cooperating / interacting (e.g. via an API)
with this module and _users_ of this module and maybe developers of
drupal core (since this is also a 'module' that will interact with a
contrib module). I want to call this circle decision board. 

These boards / circles follow the principles of decisioning by
sociocracy (no crazy people - a practical approach for some European
companies) feel free to ask for more details and / or check
http://en.wikipedia.org/wiki/Sociocracy .

Means e.g. all decisions are made in consent. Means in difference to
consensus: although I'm not very happy with a decision, I'm able to
agree, because the decision supports the goals of the community as a
whole and the goals of my circle.

Each decision is monitored after a period the circle sets (e.g. one
year, with next release ...)

Each team member (or interested party) can bring up new arguments (e.g.
bugs, performance measurements ..) and can ask to decide again over this
topic - which can be rejected or accepted - the team decides over it's
own topics autonomous.

There shall be a hierarchy (!sic) of circles, with drupal core at the
top and the 'right' to set the principles for the community as a whole.

All circles are interconnected through members, all teams keep public
logbooks with their decisions...(and so on).

The system of sociocracy ensures, that all voices will be heard,
decisions are made based on facts and arguments, also all decisions are
evaluated on a regular basis. So if some 'bugs' show up, there is the
possibility to fix them.

Sociocracy can only be taken as a algorithm, which was invented long
before the times of the Internet and open source communities - so if we
would want to use it for the drupal community is will be necessary to
adopt it to our needs and ability to use the technology.


To all: So please don't start a flame war why it would not work, I'm
aware of some obsolete aspects of this model ? because it was not
invented for the drupal community.

Can you imagen such a system for the drupal community?

I know from using it, that it works. Central is all participants agree
to the goals of the community and are willing to (at least) test the
system.


And in my opinion the groups.drupal.org are a step in this direction ?
but the groups lag (at least) of clear decisioning, a logbook of all
decisions and the evaluation of all decisions.


So I ask who is willing to join a group to discuss the principles of
decisioning and to test the model of sociocracy in this group?


Best

Thomas Zahreddin



> 2) I hand off privatemsg to another maintainer. He wants to go in a
> direction which neither me nor someone else even higher in the Drupal
> hierarchy agrees with. We all three come to a happy conclusion and the
> new maintainer does not go there. Time passes, and another guy,
> notorious for starting a parallel project, does exactly the thing we
> agreed on not to do and despite he says it was just experiment with
> the new Drupal 6 code, the project lives on.
> 
> NK
> 
> PS. the project moderation queue would undo Drupal because people
> would take their not-accepted projects off site. php nuke follows.
> PS2. 'mob rule' applied to code does not work. Your precious
> drupalmodules.com which I opposed from day one is an excellent
> example. captcha rated #2 , cck and views not even in #10, give me a
> break, this is broken,.


From drupal at samboyer.org  Wed Mar 11 01:02:15 2009
From: drupal at samboyer.org (Sam Boyer)
Date: Tue, 10 Mar 2009 20:02:15 -0500
Subject: [development] Duplicated modules
In-Reply-To: <1236730995.7845.50.camel@thomas-desktop>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<1236730995.7845.50.camel@thomas-desktop>
Message-ID: <200903102002.15318.drupal@samboyer.org>


On Tuesday 10 March 2009 19:23:15 Thomas Zahreddin wrote:
> Means e.g. all decisions are made in consent. Means in difference to
> consensus: although I'm not very happy with a decision, I'm able to
> agree, because the decision supports the goals of the community as a
> whole and the goals of my circle.
>
> Can you imagen such a system for the drupal community?

While I'd need to think hard the appropriateness of decisionmaking support 
systems for this specific purpose, I'd agree (surprise surprise!) that these 
types of systems could be a Really Good Thing for the community. If we don't 
go overboard with it. Hell, I even pulled together a KDI proposal to this 
effect :)

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

cheers
Sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.drupal.org/pipermail/development/attachments/20090310/3a1a1dd1/attachment-0001.pgp>

From gerhard at killesreiter.de  Wed Mar 11 01:59:34 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Wed, 11 Mar 2009 02:59:34 +0100
Subject: [development] Duplicated modules
In-Reply-To: <1236730995.7845.50.camel@thomas-desktop>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<1236730995.7845.50.camel@thomas-desktop>
Message-ID: <49B71B06.1090102@killesreiter.de>

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

Thomas Zahreddin schrieb:
> You asked for a suggestion, here are my thoughts:
> 
> Am Dienstag, den 10.03.2009, 15:14 -0700 schrieb Karoly Negyesi:
>> Hi,
>>
>> OK all you wiseasses, now you pissed me off enough to bring these
>> issues into wider public, so tell me what to do in these situations.
>>
>> 1) There is a Drupal module, older than my boots, gets a much needed
>> rewrite by two guys. Comes a third one, and he is, of course, welcome
>> to the party. There is a discussion of what we do and what we not to
>> do. Come next day, said third guy does what we all three agreed not
>> do. Following a debate, he packs his toys and starts a new project.
>> Said third guy contributes heavily to Drupal project for extremely
>> long but quality and quantity does not always correlate.
> 
> So what can we learn form this (and many other stories)?
> 
> My answer to all three examples:
> 
> we need a better way to make decisions, since this sounds like the third
> one does not agree in the end and to lay the responsibility in the hand
> of teams: team members should not only be developers of the module, also
> developers interested in cooperating / interacting (e.g. via an API)
> with this module and _users_ of this module and maybe developers of
> drupal core (since this is also a 'module' that will interact with a
> contrib module). I want to call this circle decision board. 
> 
> These boards / circles follow the principles of decisioning by
> sociocracy (no crazy people - a practical approach for some European
> companies) feel free to ask for more details and / or check
> http://en.wikipedia.org/wiki/Sociocracy .


"Sociocracy is a system of governance using consent-based decision
making among equivalent individuals and an organizational structure
based on cybernetic principles. "

The problem in Open Source Software development is that the individuals
are usually not equivalent.

This is either explicit (one is the maintainer of the project and the
other isn't) or implicit (one is longer with the project or whatever).


> Means e.g. all decisions are made in consent. Means in difference to

Ponies for everybody...?

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

iEYEARECAAYFAkm3GwYACgkQfg6TFvELooSWMgCfXwGTw/dlKEH624V128qFfEAg
TbUAn3Kl/55LXwerQqKDoW0+SdOfvwiy
=wrUU
-----END PGP SIGNATURE-----

From pteglia at gmail.com  Wed Mar 11 02:06:59 2009
From: pteglia at gmail.com (Patrick Teglia)
Date: Tue, 10 Mar 2009 20:06:59 -0600
Subject: [development] Duplicated modules
In-Reply-To: <49B71B06.1090102@killesreiter.de>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<1236730995.7845.50.camel@thomas-desktop>
	<49B71B06.1090102@killesreiter.de>
Message-ID: <bf38af8f0903101906j73978aafm57e6228966872ca9@mail.gmail.com>

oooooh ponies!


On Tue, Mar 10, 2009 at 7:59 PM, Gerhard Killesreiter <
gerhard at killesreiter.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas Zahreddin schrieb:
> > You asked for a suggestion, here are my thoughts:
> >
> > Am Dienstag, den 10.03.2009, 15:14 -0700 schrieb Karoly Negyesi:
> >> Hi,
> >>
> >> OK all you wiseasses, now you pissed me off enough to bring these
> >> issues into wider public, so tell me what to do in these situations.
> >>
> >> 1) There is a Drupal module, older than my boots, gets a much needed
> >> rewrite by two guys. Comes a third one, and he is, of course, welcome
> >> to the party. There is a discussion of what we do and what we not to
> >> do. Come next day, said third guy does what we all three agreed not
> >> do. Following a debate, he packs his toys and starts a new project.
> >> Said third guy contributes heavily to Drupal project for extremely
> >> long but quality and quantity does not always correlate.
> >
> > So what can we learn form this (and many other stories)?
> >
> > My answer to all three examples:
> >
> > we need a better way to make decisions, since this sounds like the third
> > one does not agree in the end and to lay the responsibility in the hand
> > of teams: team members should not only be developers of the module, also
> > developers interested in cooperating / interacting (e.g. via an API)
> > with this module and _users_ of this module and maybe developers of
> > drupal core (since this is also a 'module' that will interact with a
> > contrib module). I want to call this circle decision board.
> >
> > These boards / circles follow the principles of decisioning by
> > sociocracy (no crazy people - a practical approach for some European
> > companies) feel free to ask for more details and / or check
> > http://en.wikipedia.org/wiki/Sociocracy .
>
>
> "Sociocracy is a system of governance using consent-based decision
> making among equivalent individuals and an organizational structure
> based on cybernetic principles. "
>
> The problem in Open Source Software development is that the individuals
> are usually not equivalent.
>
> This is either explicit (one is the maintainer of the project and the
> other isn't) or implicit (one is longer with the project or whatever).
>
>
> > Means e.g. all decisions are made in consent. Means in difference to
>
> Ponies for everybody...?
>
> Cheers,
>        Gerhard
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkm3GwYACgkQfg6TFvELooSWMgCfXwGTw/dlKEH624V128qFfEAg
> TbUAn3Kl/55LXwerQqKDoW0+SdOfvwiy
> =wrUU
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090310/f7ecebfa/attachment.htm>

From andrewberry at sentex.net  Wed Mar 11 02:24:05 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Tue, 10 Mar 2009 22:24:05 -0400
Subject: [development] Duplicated modules
In-Reply-To: <49B6EC83.2080205@disobey.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
Message-ID: <76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>

On 10-Mar-09, at 6:41 PM, Morbus Iff wrote:

> To some degree, chx and I already started that with  
> DrupalToughLove.com.

DTL looked to be very promising. I found the reviews done to be  
practical in that even though they weren't my modules, they still had  
good suggestions to apply elsewhere. I was disappointed not to see  
more reviews. If you had a donation widget set up I think it would get  
some use, especially if it allowed those donating to vote on a  
module(s) to be reviewed.

--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/20090310/2bdd0ab7/attachment.bin>

From darthclue at gmail.com  Wed Mar 11 02:36:43 2009
From: darthclue at gmail.com (Darth Clue)
Date: Tue, 10 Mar 2009 21:36:43 -0500
Subject: [development] Duplicated modules
In-Reply-To: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
Message-ID: <49B723BB.8040607@gmail.com>

I'm fairly new to the Drupal community and I'm also still getting over 
having my gallbladder removed so if I make no sense or come across in a 
way that offends you it is not intentional.

I think duplicated modules suck.  They dilute the water and make it more 
difficult to determine what to do if you have no experience with the 
software.  There is no easy solution to this problem.  It's something 
that requires one of the parties to accept that the work they have done 
should be undone which is a hard thing to do.  Feedback from experienced 
users and developers ala DTL is awesome to us noobs.  I dove headlong 
into the process and took over a module that is critical to a project 
that I'm working on.  I took over another module at the request of 
others who wanted to see it ported to D6.  After doing so I discovered 
that there was another module that does about the same thing.  I'm still 
waiting to see what the port of it looks like before I decide whether or 
not they are actually duplicates.  I've considered submitting patches 
for the menu system to enhance it's permissioning but have yet to do so 
due to a lack of time.

Introducing bureaucracy and paperwork into the process will reduce the 
number of people who are willing to spend time on Drupal and will 
degrade it's value.  I spend my day trying to convince others that as a 
CMS Drupal is our best choice because it is open source and because of 
the community that keeps it alive.

People like chx, webchick, and morbus are the very reason that I am 
still using Drupal and still pushing for it's usage in the projects that 
I'm involved in.  Core addresses the basics and stays out of the way 
when I need to do more.

And since it isn't heard enough, THANK YOU, to everyone who contributes 
to Drupal.  Your work, energy, and time have made it easier for me to do 
my job.

Jonathan Dale (aka Darthclue)

Karoly Negyesi wrote:
> Hi,
>
> OK all you wiseasses, now you pissed me off enough to bring these
> issues into wider public, so tell me what to do in these situations.
>
> 1) There is a Drupal module, older than my boots, gets a much needed
> rewrite by two guys. Comes a third one, and he is, of course, welcome
> to the party. There is a discussion of what we do and what we not to
> do. Come next day, said third guy does what we all three agreed not
> do. Following a debate, he packs his toys and starts a new project.
> Said third guy contributes heavily to Drupal project for extremely
> long but quality and quantity does not always correlate.
>
> 2) I hand off privatemsg to another maintainer. He wants to go in a
> direction which neither me nor someone else even higher in the Drupal
> hierarchy agrees with. We all three come to a happy conclusion and the
> new maintainer does not go there. Time passes, and another guy,
> notorious for starting a parallel project, does exactly the thing we
> agreed on not to do and despite he says it was just experiment with
> the new Drupal 6 code, the project lives on.
>
> NK
>
> PS. the project moderation queue would undo Drupal because people
> would take their not-accepted projects off site. php nuke follows.
> PS2. 'mob rule' applied to code does not work. Your precious
> drupalmodules.com which I opposed from day one is an excellent
> example. captcha rated #2 , cck and views not even in #10, give me a
> break, this is broken,.
>
>   


From larry at garfieldtech.com  Wed Mar 11 03:04:15 2009
From: larry at garfieldtech.com (Larry Garfield)
Date: Tue, 10 Mar 2009 22:04:15 -0500
Subject: [development]
 =?iso-8859-1?q?An_alternative_to_common_thinking_in?=
 =?iso-8859-1?q?_5-=3E_6=09migration?=
In-Reply-To: <49B5968A.4020008@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>
	<49B5968A.4020008@gmx.net>
Message-ID: <200903102204.15810.larry@garfieldtech.com>

On Monday 09 March 2009 5:22:02 pm Marcel Partap wrote:

> Well of course but i really missed some voices from those high-profile
> developers. BTW nothing would change for them, especially no increase
> in work-load.

Except that those high-profile developers would need to troll through contrib 
to vote on stuff.

> > Don't take this personally
>
> Course not, but i would have hoped for some support. Without any
> community backing surely my idea does sound silly.

Perhaps the lack of community backing is a sign that the idea really is silly?  
If you want a "crowdsourced" approach to module maintenance, well, the crowd 
is right now voting against your idea in droves.  That should tell you 
something.

> > Neither of which have a very good track record of actually getting
> > things done in a volunteer driven open source community where
> > inspiration and enthusiasm is the biggest driver behind doing
> > anything.
>
> Who is trying to stop that. By preventing bull sh1t code from being
> committed to the official contrib? C'mon! We could easily set up a
> testing repository, set up a drupal-patches mailing list and nice up
> the issue tracker to facilitate more code centric work on stuff.

You can already get email notifications of every single post to the issue queue 
if you want them.  Yet another mailing list for that would be a big step 
backward.


> If anyone has a more viable solution at hand, i'm more than willing to
> surrender my effort to their proposal. Right now all i've heard is
> votes for natural selection. Surely that is one approach to it, but at
> least not my favorite.
> Also, almost every possible use case is covered by one or the other D6
> module, making that 'no more innovation' argument really not that
> convincing. What is the point of producing D7 at all? Restructuring!
> How is that case invalid for non-core modules, simply don't see it.
> Furthermore, simply don't like the fact that individuals hold the keys
> to modules. The linux kernel f.e. handles this very differently:
> contributors get mentioned in the file header.
> Really, the linux approach of development is what i think drupal
> should hand pick some points from.

Once again, as others have pointed out, you're mapping to the Linux module, 
um, wrong.  Drupal core is to Linux kernel as Views is to KDE.  Does KDE not 
get to commit something unless kernel devs sign off on it?  Of course not, that 
would be insane.  But it would get rid of that pesky "Do I use Gnome or KDE?" 
question.  Duplication is just wasted effort, right?

>  > And for a lot of modules (eg my
> > own), they simply don't have a user base capable of evaluating the
> > quality of the commit
>
> Code voting for developers only of course - sure all this needs
> implementing. Where's a will, there's a way.

The vast majority of contrib modules have exactly one person who knows the 
code at all, much less well enough to be able to vet and vote intelligently on 
a patch.  So it would fall to those "high level" devs to pick up the slack so 
that things could even get committed.  We're kinda busy already. :-)

> Noone wants that, not even crazy me. But my belief still is: if we
> really want to find a way to improve the process, we can do it. If i
> stand alone, this is not a fight i'll waste my blood on.

I think it should be apparent by now that you do stand alone on this issue.

> BTW, i really wished i had the time to code all the stuff i'd like to,
> but obligations (you know.. school, work and stuff *g) shrink my
> visions to small compact pressed clumps that lay around. It would
> simply need some outside support to inflate them again, but convincing
> people to support something unknown nowadays doesn't seem to be too
> easy. Ah well.. back to work, the profane.
> regards

Convincing people to support something unknown shouldn't be easy.  It should 
have to prove itself.  It can happen, but it takes time and generally only 
happens if the idea really does have merit.  The development process for D7 
core has changed considerably, for the better, because we only made process 
changes that made sense to those involved and that reduced workload rather 
than increasing it.

Once again, the fact that no one else supports this proposal should tell you 
something about it.

-- 
Larry Garfield
larry at garfieldtech.com

From jcfiala at gmail.com  Wed Mar 11 04:48:35 2009
From: jcfiala at gmail.com (John Fiala)
Date: Tue, 10 Mar 2009 22:48:35 -0600
Subject: [development] Duplicated modules
In-Reply-To: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
Message-ID: <d59865cb0903102148u3ec5ca96v5d522775df52728b@mail.gmail.com>

Personally, I think duplication in modules is fine.  The modules that
are useful will get used, the modules that aren't useful will
eventually fall off.  Sure, time and effort is being duplicated but -
this is the developer's choice to duplicate the effort.  And sometimes
new ideas or methods of doing things can arise from duplications that
can be incorporated into other modules or places.

-- 
John Fiala

From dmitrig01 at gmail.com  Wed Mar 11 04:59:09 2009
From: dmitrig01 at gmail.com (Dmitri Gaskin)
Date: Tue, 10 Mar 2009 21:59:09 -0700
Subject: [development] Duplicated modules
In-Reply-To: <d59865cb0903102148u3ec5ca96v5d522775df52728b@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<d59865cb0903102148u3ec5ca96v5d522775df52728b@mail.gmail.com>
Message-ID: <ED114941-3529-48E6-905D-11AEEA18D5D1@gmail.com>

That would be good, unless we don't have ratings for modules, so no  
one knows what's good.

And drupalmodules.com just doesn't work (see chx's comment above).

Dmitri

On Mar 10, 2009, at 9:48 PM, John Fiala wrote:

> Personally, I think duplication in modules is fine.  The modules that
> are useful will get used, the modules that aren't useful will
> eventually fall off.  Sure, time and effort is being duplicated but -
> this is the developer's choice to duplicate the effort.  And sometimes
> new ideas or methods of doing things can arise from duplications that
> can be incorporated into other modules or places.
>
> -- 
> John Fiala


From martin at tomes.org.uk  Wed Mar 11 08:52:40 2009
From: martin at tomes.org.uk (Martin Tomes)
Date: Wed, 11 Mar 2009 08:52:40 +0000
Subject: [development] Duplicated modules
In-Reply-To: <ED114941-3529-48E6-905D-11AEEA18D5D1@gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<d59865cb0903102148u3ec5ca96v5d522775df52728b@mail.gmail.com>
	<ED114941-3529-48E6-905D-11AEEA18D5D1@gmail.com>
Message-ID: <e9dcdfe0903110152t23649170iaa15c40a81fd1a26@mail.gmail.com>

On Wed, Mar 11, 2009 at 4:59 AM, Dmitri Gaskin <dmitrig01 at gmail.com> wrote:

> That would be good, unless we don't have ratings for modules, so no one
> knows what's good.
>

A count of how many sites use that module would be very helpful indeed, I
have downloaded modules and then discarded them so download count isn't very
helpful. I know there are ethical issues with this, but the update module
knows what is in use and given a site owners permission could log that on
drupal.org.

-- 
Martin Tomes
martin at tomes.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/d3d4e028/attachment.htm>

From catch56 at googlemail.com  Wed Mar 11 08:57:47 2009
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 11 Mar 2009 08:57:47 +0000
Subject: [development] Duplicated modules
In-Reply-To: <e9dcdfe0903110152t23649170iaa15c40a81fd1a26@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<d59865cb0903102148u3ec5ca96v5d522775df52728b@mail.gmail.com>
	<ED114941-3529-48E6-905D-11AEEA18D5D1@gmail.com>
	<e9dcdfe0903110152t23649170iaa15c40a81fd1a26@mail.gmail.com>
Message-ID: <fa5724270903110157o4d1cacb8t11a99bb739379361@mail.gmail.com>

> A count of how many sites use that module would be very helpful indeed, I
> have downloaded modules and then discarded them so download count isn't very
> helpful. I know there are ethical issues with this, but the update module
> knows what is in use and given a site owners permission could log that on
> drupal.org.
>
>

You mean like this?
http://drupal.org/project/usage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/0cfd9f67/attachment.htm>

From martin at tomes.org.uk  Wed Mar 11 09:10:14 2009
From: martin at tomes.org.uk (Martin Tomes)
Date: Wed, 11 Mar 2009 09:10:14 +0000
Subject: [development] Duplicated modules
In-Reply-To: <fa5724270903110157o4d1cacb8t11a99bb739379361@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<d59865cb0903102148u3ec5ca96v5d522775df52728b@mail.gmail.com>
	<ED114941-3529-48E6-905D-11AEEA18D5D1@gmail.com>
	<e9dcdfe0903110152t23649170iaa15c40a81fd1a26@mail.gmail.com>
	<fa5724270903110157o4d1cacb8t11a99bb739379361@mail.gmail.com>
Message-ID: <e9dcdfe0903110210u2bc12206xd47f7aee2e8b010c@mail.gmail.com>

On Wed, Mar 11, 2009 at 8:57 AM, Nathaniel Catchpole <catch56 at googlemail.com
> wrote:

>
> A count of how many sites use that module would be very helpful indeed, I
>> have downloaded modules and then discarded them so download count isn't very
>> helpful. I know there are ethical issues with this, but the update module
>> knows what is in use and given a site owners permission could log that on
>> drupal.org.
>>
>>
>
> You mean like this?
> http://drupal.org/project/usage
>
>
Yes:-)

-- 
Martin Tomes
martin at tomes.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/b526f3d4/attachment.htm>

From mpartap at gmx.net  Wed Mar 11 10:12:23 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Wed, 11 Mar 2009 11:12:23 +0100
Subject: [development] An alternative to common thinking in 5-> 6
	migration
In-Reply-To: <200903102204.15810.larry@garfieldtech.com>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>	<49B5968A.4020008@gmx.net>
	<200903102204.15810.larry@garfieldtech.com>
Message-ID: <49B78E87.3060000@gmx.net>

> Except that those high-profile developers would need to troll
> through contrib to vote on stuff.
Would not. On the contrary, all people writing Drupal code could
handle all Drupal non-core code as a collective.

> Perhaps the lack of community backing is a sign that the idea
> really is silly?
Well my professor for the lecture 'quality management' came up with
several examples where there was absolutely no support for ordered
quality assurance procedures until something bad happened, at which
point someone from the institute went in for counseling and after
leaving everybody at the company highly supported the introduction of
a structured approach to quality management on the process. It may
seem to increase the amount of work needed at first, but really in the
end it does the opposite.
So no - i still don't think the idea is silly, as i understand it.
However many times my points have been misinterpreted so maybe i just
didn't make myself clear in the first place. Shame on me.

> If you want a "crowdsourced" approach to module maintenance, well,
> the crowd is right now voting against your idea in droves.  That
> should tell you something.
Yeah, but nothing about the viability of the idea of a different
approach to non-core code. And opinions change with the tides..

> You can already get email notifications of every single post to
> the issue queue if you want them.  Yet another mailing list for
> that would be a big step backward.
Well maybe all the supporting infrastructure already in place just
isn't the best it could be. Furthermore personally i still see huge
benefit in a single drupal-patches mailing list that would allow me to
take part in deciding where the code goes in a different way than
filing reports - why let wrong code get in the first place.

>> Really, the linux approach of development is what i think drupal
>>  should hand pick some points from.
> Once again, as others have pointed out, you're mapping to the
> Linux module, um, wrong.  Drupal core is to Linux kernel as Views
> is to KDE.
How can you tell me the analogy i chose is wrong? The point is not the
different layers of software but the development process. You could
also compare the SLOC of codes, or the amount of code contributors, or
the average color of the project's bike shed.

> Does KDE not get to commit something unless kernel devs sign off
> on it?  Of course not, that would be insane.
That point is so totally void.

> But it would get rid of that pesky "Do I use Gnome or KDE?"
> question. Duplication is just wasted effort, right?
Like i'm getting myself involved in another flame war, nice try.

> The vast majority of contrib modules have exactly one person who
> knows the code at all
Which is a *problem* that a different development model would address.

> , much less well enough to be able to vet and vote intelligently on
> a patch.  So it would fall to those "high level" devs to pick up
> the slack so that things could even get committed.  We're kinda
> busy already. :-)
As long as you don't _really try to imagine_ how it could work you're
not going to understand it anyways.

> I think it should be apparent by now that you do stand alone on
> this issue.
Well it is apparent to me that noone brought up any compelling
arguments against it (besides 'dont like'). Some people however voiced
their annoyance about the current situation - especially with module
duplication - which has not been addressed adequately by anyone. Also
up to now, the only approach to tackle the other existing real problem 
of overloaded, unresponsive and uncooperative module maintainers which 
hold the sole keys is mine. No alternative concept (except the new 
project queue idea, which has been already mentioned to not catch many 
of the cases) has been proposed. Yet if nothing is done, shit will 
just again hit the fan.

> Once again, the fact that no one else supports this proposal
> should tell you something about it.
Yes, that it isn't supported, which basically cancels it. That does
not imply however it would not work, nor that it would not improve
overall code quality, avoid module duplication and on the long run
prove to be a scalable development process.

The people i'd really like to have heard an opinion of are people like 
Dries, Angela and the maintainers of overly complex modules (CCK and 
Views mainly) however. But now the jury has made up their mind it is 
too late for the idea anyways.
  regards, marcel.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From tz at it-arts.org  Wed Mar 11 10:45:30 2009
From: tz at it-arts.org (Thomas Zahreddin)
Date: Wed, 11 Mar 2009 11:45:30 +0100
Subject: [development] An alternative to common thinking in 5-> 6
 migration
In-Reply-To: <49B78E87.3060000@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>
	<49B5968A.4020008@gmx.net> <200903102204.15810.larry@garfieldtech.com>
	<49B78E87.3060000@gmx.net>
Message-ID: <1236768330.6469.10.camel@thomas-desktop>

Hallo,

i agree very much to all your posting in the last days (did not check
older ones ;-) )

i suggested in the attached mail to change the decision making process
in the drupal community.

Some people agreed and i want to start a group (if it not exists) that
creates a proposal for the decision making process.

Are you willing to join such a group on groups.drupal.org?


Best 
Thomas Zahreddin



Am Mittwoch, den 11.03.2009, 11:12 +0100 schrieb Marcel Partap:
> > Except that those high-profile developers would need to troll
> > through contrib to vote on stuff.
> Would not. On the contrary, all people writing Drupal code could
> handle all Drupal non-core code as a collective.
> 
> > Perhaps the lack of community backing is a sign that the idea
> > really is silly?
> Well my professor for the lecture 'quality management' came up with
> several examples where there was absolutely no support for ordered
> quality assurance procedures until something bad happened, at which
> point someone from the institute went in for counseling and after
> leaving everybody at the company highly supported the introduction of
> a structured approach to quality management on the process. It may
> seem to increase the amount of work needed at first, but really in the
> end it does the opposite.
> So no - i still don't think the idea is silly, as i understand it.
> However many times my points have been misinterpreted so maybe i just
> didn't make myself clear in the first place. Shame on me.
> 
> > If you want a "crowdsourced" approach to module maintenance, well,
> > the crowd is right now voting against your idea in droves.  That
> > should tell you something.
> Yeah, but nothing about the viability of the idea of a different
> approach to non-core code. And opinions change with the tides..
> 
> > You can already get email notifications of every single post to
> > the issue queue if you want them.  Yet another mailing list for
> > that would be a big step backward.
> Well maybe all the supporting infrastructure already in place just
> isn't the best it could be. Furthermore personally i still see huge
> benefit in a single drupal-patches mailing list that would allow me to
> take part in deciding where the code goes in a different way than
> filing reports - why let wrong code get in the first place.
> 
> >> Really, the linux approach of development is what i think drupal
> >>  should hand pick some points from.
> > Once again, as others have pointed out, you're mapping to the
> > Linux module, um, wrong.  Drupal core is to Linux kernel as Views
> > is to KDE.
> How can you tell me the analogy i chose is wrong? The point is not the
> different layers of software but the development process. You could
> also compare the SLOC of codes, or the amount of code contributors, or
> the average color of the project's bike shed.
> 
> > Does KDE not get to commit something unless kernel devs sign off
> > on it?  Of course not, that would be insane.
> That point is so totally void.
> 
> > But it would get rid of that pesky "Do I use Gnome or KDE?"
> > question. Duplication is just wasted effort, right?
> Like i'm getting myself involved in another flame war, nice try.
> 
> > The vast majority of contrib modules have exactly one person who
> > knows the code at all
> Which is a *problem* that a different development model would address.
> 
> > , much less well enough to be able to vet and vote intelligently on
> > a patch.  So it would fall to those "high level" devs to pick up
> > the slack so that things could even get committed.  We're kinda
> > busy already. :-)
> As long as you don't _really try to imagine_ how it could work you're
> not going to understand it anyways.
> 
> > I think it should be apparent by now that you do stand alone on
> > this issue.
> Well it is apparent to me that noone brought up any compelling
> arguments against it (besides 'dont like'). Some people however voiced
> their annoyance about the current situation - especially with module
> duplication - which has not been addressed adequately by anyone. Also
> up to now, the only approach to tackle the other existing real problem 
> of overloaded, unresponsive and uncooperative module maintainers which 
> hold the sole keys is mine. No alternative concept (except the new 
> project queue idea, which has been already mentioned to not catch many 
> of the cases) has been proposed. Yet if nothing is done, shit will 
> just again hit the fan.
> 
> > Once again, the fact that no one else supports this proposal
> > should tell you something about it.
> Yes, that it isn't supported, which basically cancels it. That does
> not imply however it would not work, nor that it would not improve
> overall code quality, avoid module duplication and on the long run
> prove to be a scalable development process.
> 
> The people i'd really like to have heard an opinion of are people like 
> Dries, Angela and the maintainers of overly complex modules (CCK and 
> Views mainly) however. But now the jury has made up their mind it is 
> too late for the idea anyways.
>   regards, marcel.
> 
-------------- next part --------------
An embedded message was scrubbed...
From: Thomas Zahreddin <tz at it-arts.org>
Subject: Re: [development] Duplicated modules
Date: Wed, 11 Mar 2009 01:23:15 +0100
Size: 8704
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/409fe53f/attachment-0001.eml>

From mail at webthatworks.it  Wed Mar 11 11:40:45 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Wed, 11 Mar 2009 12:40:45 +0100
Subject: [development] Duplicated modules
In-Reply-To: <76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
	<76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
Message-ID: <20090311124045.2c844960@dawn.webthatworks.it>

On Tue, 10 Mar 2009 22:24:05 -0400
Andrew Berry <andrewberry at sentex.net> wrote:

> On 10-Mar-09, at 6:41 PM, Morbus Iff wrote:
> 
> > To some degree, chx and I already started that with  
> > DrupalToughLove.com.
> 
> DTL looked to be very promising. I found the reviews done to be  
> practical in that even though they weren't my modules, they still

Jumping in here... not strictly related to these 2 posts.

There are thousands modules.
If you restrict your interest to 3 or 4 to evaluate a review is
useful.
If you can't even find the best candidates to compare, a review is
like someone donating you a Ferrari and leaving it in an unknown
place in Atacama.

What I'd find useful would be
- better categorisation system and better search system on categories
- a flag to check if a module provides an API or is just an
  application
- an activity index (average lines of code changed/time)
- a issue queue index (how many issues open, how much people
  subscribed to them, % of issues closed)

Asking developers to list similar modules is asking for good will.
Asking for good will generally is not enough, rewarding good will is
better.
If developers could classify better their modules it would be easier
to search for similar modules and developers could make easier to
find their own creatures too.
Coming up with a good categorisation system isn't easy. I think
debtag is trying to achieve a similar target, but I don't know how
successfully and how much of their efforts we could share.

In each project page there is a link to statistics... but if you're
comparing projects you've to open one more page for comparing and
the statistics aren't synthetic enough.

What I generally end up doing is open 2 to 4 categories, skim
through the modules, open several other tabs, read the description
of the modules I've opened, shrink the selection as much as
possible... download the modules and look at the code, README etc...
if really forced install the survivors.

Somehow once I have few candidates even if a review of the module
may be helpful the decision is going to be based on details that
hardly could be expressed synthetically and are very "context"
sensitive (specific to the situation I'm trying to solve).
At this level you just have to hope the maintainer of the project
spent some time to describe what makes its creature special to
select further before testing/looking at the code.
I don't think developers find very rewarding adding descriptions,
maybe they would find more rewarding adding feature lists.
Still developers may write modules for very different reasons.
I think having a community that *may* support your module *could* be
a good reason to promote the diffusion of your module... but it may
not be the case... and still you may be contributing in a valuable
way to drupal community.

Maybe we could let people (other than the maintainers) to
"categorise" the project.
After all every user have to read the list of projects before
choosing one, compare them etc... this efforts are collectively
repeated thousands time. It's a pity they get wasted.
Use cloud tagging for similarity and categories.
And this is rewarding for users... they are going to search through
modules more than one time... if they could tag them they would
lower their efforts the next time.

I hope that every module developer started as a potential module
user so he searched at least once in the projects to see is
something was fit for its need.
Even if I'm planning to start a "duplicate" I'm interested to know
other people's approach to my similar problem.

I really don't see duplication as a problem.

If you've bad developers... even if they could easily find similar
modules they may find silly reasons to start new ones.
But there may be thousands good reasons for duplication:
- a maintainer is not willing to accept changes
- framework modules vs. ready to use modules
- deadlines
- ...
A successful project is not determined by "code quality" alone and
not every time developers may have common interests.

Determining if there is no real good reason for duplicating the
functionality of a project is not an easy task.
There may be time when the developer is just an asshole... in that
case I doubt you can direct his efforts to a more valuable target
convincing him to submit patches to another project.
So the cost/missed return of one more project developed by an
asshole is just the cost in searching through modules, not the sum
of the cost of searching through modules and the missed contribution
of one more developer to an existing project.

On the other hand if you're not dealing with an asshole, he may have
had his good reasons to start a new project.

Consider that there are modules you could write in an hour and it
may take more than an hour to search through the project list and
learn how certain modules have to be used... and even when you may
find one that nearly fit your needs, it may not just fit your needs
as much the one you may write.

Of course this is going to happen for the very simplest modules but
still the effort of looking through all the list of available modules
impact the community much more than having few duplicates of small
modules.

Lowering the cost of searching and comparing will lower the
duplicates.

Furthermore... how can you cheaply know if a new module is a
duplicate without good search tools? Let alone evaluating if a
duplicate will negatively impact the community.

Every *effort* to regulate duplication of modules have to pass
through better tools to search through modules.
Every *effort* to regulate duplication is an *effort* and sincerely
the return looks dubious.

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


From mpartap at gmx.net  Wed Mar 11 11:41:23 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Wed, 11 Mar 2009 12:41:23 +0100
Subject: [development] An alternative to common thinking in 5-> 6
	migration
In-Reply-To: <1236768330.6469.10.camel@thomas-desktop>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>	<49B5968A.4020008@gmx.net>
	<200903102204.15810.larry@garfieldtech.com>	<49B78E87.3060000@gmx.net>
	<1236768330.6469.10.camel@thomas-desktop>
Message-ID: <49B7A363.6090001@gmx.net>

> Are you willing to join such a group on groups.drupal.org?
Yeah sure your mail and willing to support that.. however i might be 
going to the army soon which means i am not sure how much time i will 
be able to spend on drupal development.. That's why i wanted to get it 
sorted 'quickly'..
However if none of the developers would adopt such a process, pretty 
much all our efforts would be void in the first place. And by the way 
i am also not sure we should call it political names ;)
...also in the end the problem of actually making decisions is a small 
part of the cake that needs to be baked. More important are most 
efficient tools to better facilitate casual code reviewing, and to 
gather some folks to start working on the stuff that could be made 
into frameworks (messaging, notification, web forms)..
..
marcel
(clueless on how to go on)

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From news at unleashedmind.com  Wed Mar 11 11:50:54 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Wed, 11 Mar 2009 12:50:54 +0100
Subject: [development] An alternative to common thinking in 5->
	6migration
In-Reply-To: <49B78E87.3060000@gmx.net>
Message-ID: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>

> Well it is apparent to me that noone brought up any 
> compelling arguments against it (besides 'dont like'). Some 
> people however voiced their annoyance about the current 
> situation - especially with module duplication - which has 
> not been addressed adequately by anyone. Also up to now, the 
> only approach to tackle the other existing real problem of 
> overloaded, unresponsive and uncooperative module maintainers 
> which hold the sole keys is mine. No alternative concept 
> (except the new project queue idea, which has been already 
> mentioned to not catch many of the cases) has been proposed. 
> Yet if nothing is done, shit will just again hit the fan.
>   regards, marcel.

Previous posters brought up arguments, but you obviously did not understand
them.

Refining the list:

Unresovable causes for duplication:

- Developer wants to implement things differently than maintainer and is
unable to agree with maintainer.

- Maintainer of existing module does not accept developer's contribution and
also does not accept developer as co-maintainer.

- Developer takes over existing project and turns it into something that was
never intended.


Resolvable causes for duplication:

- Developer did not search.

- Developer did search, but existing module uses different lingo.

- Developer did search, but did not realize that existing module does the
same in an abstracted way.

- Developer was not able to imagine that his contribution would be accepted
in existing module.

- Developer was too lazy to grasp the API of existing module, better write a
new one.

- Developer spent weeks of coding in private, now he must release, even if
it's 100% duplicate (ego).

- Developer did not know about CVS sandboxes.

- Developer wants to attract clients (ego).

- Developer does not know how to patch, just learned how to use CVS from the
handbooks.


Given this list, a new project moderation queue would possibly be able to
eliminate 75% of duplication causes.

So what if this moderation would _blindly_ accept the above mentioned,
unresolvable causes as reasons for creating a new project without further
backtalk?

I could even imagine that the content of this queue can be very interesting
for all Drupalers - "I'd like to create a module that does X." - "Why don't
you use Y with Z?" - "Bingo!"


sun


From damz at prealable.org  Wed Mar 11 11:52:33 2009
From: damz at prealable.org (Damien Tournoud)
Date: Wed, 11 Mar 2009 12:52:33 +0100
Subject: [development] An alternative to common thinking in 5-> 6
	migration
In-Reply-To: <49B7A363.6090001@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>
	<49B5968A.4020008@gmx.net> <200903102204.15810.larry@garfieldtech.com>
	<49B78E87.3060000@gmx.net> <1236768330.6469.10.camel@thomas-desktop>
	<49B7A363.6090001@gmx.net>
Message-ID: <e821df550903110452p1e13f070od624c31448702c6c@mail.gmail.com>

On Wed, Mar 11, 2009 at 12:41 PM, Marcel Partap <mpartap at gmx.net> wrote:

> Are you willing to join such a group on groups.drupal.org?
>>
> Yeah sure your mail and willing to support that.. however i might be going
> to the army soon which means i am not sure how much time i will be able to
> spend on drupal development.. That's why i wanted to get it sorted
> 'quickly'..


Your points about Drupal community decision process might be valid, but your
attitude and methods are completely wrong. You can't jump and say "you are
doing that wrong, I'll tell you how you need to do that, and you will have
to implement what I say yourself, because I'll not be around, why don't you
do that? please do that quickly!". No wonder why you are pissing everyone
off.

Next time, try this instead: "hey, I think we are doing that wrong, I
believe that we can do better. I'm ready to try to implement that if some
people are willing to try my proposal. I'll be there to experiment and after
some time, we could decide if we want to go on or not."

Damien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/44d3d10f/attachment.htm>

From earnie at users.sourceforge.net  Wed Mar 11 12:28:41 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Wed, 11 Mar 2009 08:28:41 -0400
Subject: [development] Duplicated modules
In-Reply-To: <e9dcdfe0903110152t23649170iaa15c40a81fd1a26@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<d59865cb0903102148u3ec5ca96v5d522775df52728b@mail.gmail.com>
	<ED114941-3529-48E6-905D-11AEEA18D5D1@gmail.com>
	<e9dcdfe0903110152t23649170iaa15c40a81fd1a26@mail.gmail.com>
Message-ID: <20090311082841.any6y8kytgggo0cw@mail.progw.org>

Quoting Martin Tomes <martin at tomes.org.uk>:

> On Wed, Mar 11, 2009 at 4:59 AM, Dmitri Gaskin <dmitrig01 at gmail.com> wrote:
>
>> That would be good, unless we don't have ratings for modules, so no one
>> knows what's good.
>>
>
> A count of how many sites use that module would be very helpful indeed, I
> have downloaded modules and then discarded them so download count isn't very
> helpful. I know there are ethical issues with this, but the update module
> knows what is in use and given a site owners permission could log that on
> drupal.org.
>

The update module has no idea how many production sites are using a 
module.  I for one disable the module for production sites.  There are 
others that do the same.  Then there are the development sites that try 
out the module and may never use them.  How is that different from the 
download count?

The download count is just a measure of how many looked at the 
possibility of using the module.  And then their are the stupid noobs 
(me included) who download modules just for the hell of it, try it out 
and then toss it aside.  It was a learning process to discover what 
Drupal is about.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From mpartap at gmx.net  Wed Mar 11 12:45:14 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Wed, 11 Mar 2009 13:45:14 +0100
Subject: [development] An alternative to common thinking in
	5->	6migration
In-Reply-To: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
Message-ID: <49B7B25A.2060006@gmx.net>

> Previous posters brought up arguments, but you obviously did not understand
> them.
???
Where are those? Despite
- it would place all load upon a small load of developers who are 
already overloaded (not true)
- would stiffle innovation (hardly true - restriction only on repo 
commits)
- don't like it because it messes with my ways (can't argue with that)
there was no argument i am aware of, and none of those strike me as 
real compelling evidence quality restriction would be a bad idea.

> So what if this moderation would _blindly_ accept the above mentioned,
> unresolvable causes as reasons for creating a new project without further
> backtalk?
?? huh ??
The point was to make every non-core code just as community-maintained 
as core, but have a wider circle of people working on it. So how would 
the situation of an unresolvable conflict arises, if each area of 
functionality gets its own carefully and expandable framework, and 
code is okayed by the community? Don't get what you're trying to say, 
sorry.

> I could even imagine that the content of this queue can be very interesting
> for all Drupalers
Well that's the point. Have all Drupalers maintain the modules, not 
just a specific maintainer. Just like core, but supported by better 
tools..

regards marcel.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mpartap at gmx.net  Wed Mar 11 12:49:13 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Wed, 11 Mar 2009 13:49:13 +0100
Subject: [development] An alternative to common thinking in 5->
	6	migration
In-Reply-To: <e821df550903110452p1e13f070od624c31448702c6c@mail.gmail.com>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>	<49B5968A.4020008@gmx.net>
	<200903102204.15810.larry@garfieldtech.com>	<49B78E87.3060000@gmx.net>
	<1236768330.6469.10.camel@thomas-desktop>	<49B7A363.6090001@gmx.net>
	<e821df550903110452p1e13f070od624c31448702c6c@mail.gmail.com>
Message-ID: <49B7B349.8050605@gmx.net>

 > You can't jump and say
> "you are doing that wrong, I'll tell you how you need to do that, and
> you will have to implement what I say yourself, because I'll not be
> around, why don't you do that? please do that quickly!".
I never said that. The point about maybe having not much time i did 
only in this last point.
> No wonder why you are pissing everyone off.
You make me think rude things i will not post.

> Next time, try this instead: "hey, I think we are doing that wrong, I
> believe that we can do better. I'm ready to try to implement that if
> some people are willing to try my proposal. I'll be there to experiment
> and after some time, we could decide if we want to go on or not."
Which is exactly what i did with my original posting!


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From earnie at users.sourceforge.net  Wed Mar 11 13:02:31 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Wed, 11 Mar 2009 09:02:31 -0400
Subject: [development] Failed to install HEAD
In-Reply-To: <200903100924.58159.drupal@dave-cohen.com>
References: <200903100924.58159.drupal@dave-cohen.com>
Message-ID: <20090311090231.qhhsc65mqu0c8wok@mail.progw.org>

Quoting Dave Cohen <drupal at dave-cohen.com>:

> I'm trying to submit a patch which changes a form in install.php.  
> Because of that change the test bot always fails with "Failed to 
> install HEAD".  At least I'm guessing that's why, the error message 
> really gives no explanation.
>
> Is there something I can include in the patch to make the test bot succeed?
>
> The patch is here: http://drupal.org/node/394282
>

Try applying the patch to a clean HEAD checkout.  This should tell you 
more about why the testbot has an issue.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From news at unleashedmind.com  Wed Mar 11 13:03:20 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Wed, 11 Mar 2009 14:03:20 +0100
Subject: [development] Duplicated modules
In-Reply-To: <49B7B25A.2060006@gmx.net>
Message-ID: <068e01c9a249$c1383b50$0200a8c0@structworks.com>

> Where are those? Despite ...

You obviously do not want to understand those arguments.  I don't want to
repeat what has been stated by others before.

> The point was to make every non-core code just as 
> community-maintained as core, but have a wider circle of 
> people working on it. So how would the situation of an 
> unresolvable conflict arises, if each area of functionality 
> gets its own carefully and expandable framework, and code is 
> okayed by the community? Don't get what you're trying to say, sorry.

You are rather talking about a distributed versioning system like git, where
anyone can do anything anywhere.  Some people are already investigating
that, but that discussion has been moved elsewhere.

> > I could even imagine that the content of this queue can be very 
> > interesting for all Drupalers
> Well that's the point. Have all Drupalers maintain the 
> modules, not just a specific maintainer. Just like core, but 
> supported by better tools..

See above.  Also, I was talking about a moderation queue, which would have
an effect on new, potentially duplicated projects (not existing), trying to
prevent the issue at all in the first place.

sun


From andrewberry at sentex.net  Wed Mar 11 13:40:56 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Wed, 11 Mar 2009 09:40:56 -0400
Subject: [development] An alternative to common thinking in 5->
	6migration
In-Reply-To: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
Message-ID: <8DDA678C-D133-43F0-B3F3-36DFB0C52FB3@sentex.net>

On 11-Mar-09, at 7:50 AM, Daniel F. Kudwien wrote:

> Given this list, a new project moderation queue would possibly be  
> able to
> eliminate 75% of duplication causes.

I was going to suggest that we create a group to simply try this  
method out among those who are on this list and interested. But it  
looks like a group all ready exists!

http://groups.drupal.org/contributed-module-ideas

If it had the ability to tag a post with applicable modules, it might  
be very good. That way, you could do a listing of all posts where the  
solution was "views". A field for "use cases" might be good too.  
There's the site-wide tags field; is it possible to add taxonomy  
vocabularies per group with og?

--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/20090311/590c3bbd/attachment.bin>

From arthur at 24b6.net  Wed Mar 11 13:47:04 2009
From: arthur at 24b6.net (arthur)
Date: Wed, 11 Mar 2009 09:47:04 -0400
Subject: [development] Duplicated modules
In-Reply-To: <76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
	<76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
Message-ID: <0BBBC895-546A-4444-B1DC-A4603AD30AC1@24b6.net>

 From my perspective, one of the reasons why the question of  
duplication has been an issue lately is that the community of  
developers has grown dramatically in the last few years. For many of  
us, when we started working with drupal we basically knew every module  
that was in the CVS repo- I'm not sure this is even possible anymore.

I think that the question of duplication is maybe the wrong question-  
for me, I'd like to frame things more in the vein of "how do we help  
contrib modules have better apis, larger support base, and better  
functionality?". The Drupal Tough Love project I think is one aspect  
to how we do this- strong peer review can be a really good foundation  
to build upon. Secondly, I think we've seen groups of developers  
gathering around specific functionality  which has created at team  
people helping push contrib code toward core. I would like to see this  
model expanded- not specifically to push code toward core, but to  
address areas of functionality that need more coordination.

For example, myself, Aaron Winborn, Alex UA, Darrell O'Pry, Roger  
Lopez,  Drewish, Travist and a number of other folks have started a  
very active conversation of how to address the issue of rich media in  
drupal as a whole. While each of us maintains multiple projects, some  
of which very much duplicate aspects of one another's work, we are  
attempting to create a common set of tools which will enrich all of  
our projects.

We know there are going to be edge cases and duplication of effort  
here and there- this is completely fine- the point of our work,  
however, is to provide a common tool kit for developers who want to  
build off of the joint work and have better integration with the  
common code and each other's projects. We are actively trying to get  
as many developers on board with this project so that people who are  
currently doing work can plan for this functionality as well as help  
direct the project.

For me, I don't want to tell people what to do or how to work. I do  
however, want to help provide the tools and community that can help  
people develop high quality work that benefits the entire drupal  
community.

---------------------------------------------------
arthur at 24b6.net


On Mar 10, 2009, at 10:24 PM, Andrew Berry wrote:

> On 10-Mar-09, at 6:41 PM, Morbus Iff wrote:
>
>> To some degree, chx and I already started that with  
>> DrupalToughLove.com.
>
> DTL looked to be very promising. I found the reviews done to be  
> practical in that even though they weren't my modules, they still  
> had good suggestions to apply elsewhere. I was disappointed not to  
> see more reviews. If you had a donation widget set up I think it  
> would get some use, especially if it allowed those donating to vote  
> on a module(s) to be reviewed.
>
> --Andrew






From pinglaura at gmail.com  Wed Mar 11 13:51:44 2009
From: pinglaura at gmail.com (Laura Scott)
Date: Wed, 11 Mar 2009 07:51:44 -0600
Subject: [development] An alternative to common thinking in 5-> 6
	migration
In-Reply-To: <49B78E87.3060000@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>	<49B5968A.4020008@gmx.net>
	<200903102204.15810.larry@garfieldtech.com>
	<49B78E87.3060000@gmx.net>
Message-ID: <BC22534A-DDC5-4550-A1CC-D7C022A5C9B1@gmail.com>

On Wednesday 11 March 2009, at 4:12 am, Marcel Partap wrote:

>> Except that those high-profile developers would need to troll
>> through contrib to vote on stuff.
> Would not. On the contrary, all people writing Drupal code could
> handle all Drupal non-core code as a collective.

I see this as one fundamental misconception of what this community is.  
It's a do-ocracy. The results are from people doing -- scratching  
their own itch -- not from people working as drones or workers in a  
hive collective. The best innovation often comes when someone develops  
a better way to build the mousetrap. Forcing that innovation to  
collaborate with the existing hegemony in that feature area or go away  
is not going to be conducive to active development contributions, imho.

In the free market, there are many instances of companies  
"duplicating" efforts out there, often with great success.

There are many cases where "duplications" in contrib have resulted in  
better modules and the deprecation of the previous project. CCK's  
replacing of Flexinode is one example of many. We just did an upgrade  
of a site from 4.7 to 6, and at least half the modules did not have  
upgrade paths. However, nearly all of those had /better/ solutions  
available in Drupal 6, developed by different developers, found under  
different project names. In the end, the website is better than before.

> The people i'd really like to have heard an opinion of are people  
> like Dries, Angela and the maintainers of overly complex modules  
> (CCK and Views mainly) however. But now the jury has made up their  
> mind it is too late for the idea anyways.

This statement, to my mind, is an illustration of why this gatekeeper  
approach could not work effectively in this community. You are stating  
that you are feeling stifled and not getting the response you want.  
Imagine that feeling from every potential contributor to the  
community, who feels he or she has a great idea but the gatekeepers  
are preventing that contribution for whatever reason.

My suggestion is that if you feel this is such an important thing,  
then don't feel stifled, just do it. Create an index of duplicated  
functionalities in projects, make it searchable, tagable, whatever,  
recruit collaborators, and establish the credibility of this approach.  
And attract people through demonstration, proving the concept. Build  
that collective and outperform all the individual efforts out there.

Laura


From catch56 at googlemail.com  Wed Mar 11 13:56:19 2009
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 11 Mar 2009 13:56:19 +0000
Subject: [development] Failed to install HEAD
In-Reply-To: <200903100924.58159.drupal@dave-cohen.com>
References: <200903100924.58159.drupal@dave-cohen.com>
Message-ID: <fa5724270903110656v74154749j51bc7db0fb27f82c@mail.gmail.com>

I'm pretty sure the test framework install runs a custom script which
depends on the HEAD installer forms. So changes will cause testing failures,
and committing the patch will require the script to be updated to avoid test
bot meltdown. I'd probably try to force your patch to Code Needs Review to
get some manual testing - and see if you can co-ordinate with
Jimmy/boombatower and webchick in irc on how best to deal with it.

Nat

On Tue, Mar 10, 2009 at 4:24 PM, Dave Cohen <drupal at dave-cohen.com> wrote:

> I'm trying to submit a patch which changes a form in install.php.  Because
> of that change the test bot always fails with "Failed to install HEAD".  At
> least I'm guessing that's why, the error message really gives no
> explanation.
>
> Is there something I can include in the patch to make the test bot succeed?
>
> The patch is here: http://drupal.org/node/394282
>
> Thanks,
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/62728202/attachment-0001.htm>

From larry at garfieldtech.com  Wed Mar 11 14:01:26 2009
From: larry at garfieldtech.com (Larry Garfield)
Date: Wed, 11 Mar 2009 09:01:26 -0500
Subject: [development]
 =?iso-8859-1?q?An_alternative_to_common_thinking_in?=
 =?iso-8859-1?q?_5-=3E_=096migration?=
In-Reply-To: <49B7B25A.2060006@gmx.net>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
	<49B7B25A.2060006@gmx.net>
Message-ID: <200903110901.26895.larry@garfieldtech.com>

On Wednesday 11 March 2009 7:45:14 am Marcel Partap wrote:
> > Previous posters brought up arguments, but you obviously did not
> > understand them.

> there was no argument i am aware of, and none of those strike me as
> real compelling evidence quality restriction would be a bad idea.

Did it ever occur to you that as someone proposing a new idea it's up to you 
to present evidence why it's needed, not up to us to provide evidence that 
it's not?  The onus is on you to show that your idea would improve the 
development process.  After 100 or so messages in related threads, you have 
not.  Please don't waste any more electrons repeating the same thing over and 
over.  You had a suggestion, it was rejected, move along to something else.  
Right now all you're doing is wasting everyone's all-too-limited time, time 
that would be better spent reviewing patches.

-- 
Larry Garfield
larry at garfieldtech.com

From kb at 2bits.com  Wed Mar 11 14:04:45 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Wed, 11 Mar 2009 10:04:45 -0400
Subject: [development] An alternative to common thinking in 5-> 6
	migration
In-Reply-To: <BC22534A-DDC5-4550-A1CC-D7C022A5C9B1@gmail.com>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>
	<49B5968A.4020008@gmx.net> <200903102204.15810.larry@garfieldtech.com>
	<49B78E87.3060000@gmx.net>
	<BC22534A-DDC5-4550-A1CC-D7C022A5C9B1@gmail.com>
Message-ID: <4a9fdc630903110704u4535ffb8gfeb33570135c1db1@mail.gmail.com>

Marcel

You mentioned something more than once in two contexts: having requirements
and planning beforehand saves time in the long run, and your professor in a
quality course.

Let me point out again that this is open source and not a corporate
environment, and hence the difference. Basically everything we assumed about
how corporate shops work does not work at all, or not as well in open
source.

Several years ago, when I was with a corporation, we got a professor from
the top Canadian university to present on requirements. He made the point
that the more time you spend on requirements the less time you will spend on
implementation. As an aside, the same concept was being touted in the
business arena in the 80s as "the Japanese way" of management.

When I asked him how does this apply to open source, and the success it had
without this lengthy centralized planning. He did not have an answer.

Once you have hundreds and thousands of contributors who never met each
other, spread across the globe, each scratching their own (or their
client/employer's) itch, we have a new paradigm (yeah, another buzzword).
You have organized chaos.

This is also why Agile/Scrum is showing success, as opposed to the
traditional waterfall method tried and tested for more than half a century.

For us who came from a corporate, or those like you who are still in
academia, it may be hard to adjust at first. But once you "get it", it is a
wonderful thing to watch and join.

So, jump in and "Do". Write about it 6 and 12 months from now and see if you
have changed your mind, and what you learned.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/6daba773/attachment.htm>

From everyone at asifproductions.com  Wed Mar 11 13:41:15 2009
From: everyone at asifproductions.com (As If Productions)
Date: Wed, 11 Mar 2009 06:41:15 -0700
Subject: [development] Duplicated modules
In-Reply-To: <mailman.73.1236775537.17128.development@drupal.org>
References: <mailman.73.1236775537.17128.development@drupal.org>
Message-ID: <20090311134220.WTUA4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>

At 05:45 AM 3/11/2009, Ivan Sergio Borgonovo wrote:
>What I'd find useful would be
>- better categorisation system and better search system on categories

Big +1 on that.

>- a flag to check if a module provides an API or is just an application
>- an activity index (average lines of code changed/time)
>- a issue queue index

Regular +1 on those.

>Maybe we could let people (other than the maintainers) to 
>"categorise" the project.

Best idea I've heard yet.  Ivan, I want to have a beer with you.

>I really don't see duplication as a problem.

Ditto.  In fact I appreciate it.  It's finding the one you need that 
is the problem.  The way I see it, this problem requires a 
taxonomical/navigational solution, not a paradigm shift in 
methodology.  It would have to be an ongoing task/project in its own 
right, but IMHO it's one that could easily be supported by 
less-than-hardcore developers.

LVX
TF


---
As If Productions
http://www.asifproductions.com
Interactive Worlds and Immersive Obsessions


From marcomsousa at gmail.com  Wed Mar 11 14:35:26 2009
From: marcomsousa at gmail.com (Marco Sousa)
Date: Wed, 11 Mar 2009 15:35:26 +0100
Subject: [development] Duplicated modules
In-Reply-To: <20090311134220.WTUA4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>
References: <mailman.73.1236775537.17128.development@drupal.org>
	<20090311134220.WTUA4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>
Message-ID: <a7c849150903110735q537c6da4gd70583641fef23f7@mail.gmail.com>

>Maybe we could let people (other than the maintainers) to "categorise" the
project.

Put "tags" to categorise, to the module that have more than one category..
And limit to 3 or 5 tags per module..


On Wed, Mar 11, 2009 at 2:41 PM, As If Productions <
everyone at asifproductions.com> wrote:

> At 05:45 AM 3/11/2009, Ivan Sergio Borgonovo wrote:
>
>> What I'd find useful would be
>> - better categorisation system and better search system on categories
>>
>
> Big +1 on that.
>
>  - a flag to check if a module provides an API or is just an application
>> - an activity index (average lines of code changed/time)
>> - a issue queue index
>>
>
> Regular +1 on those.
>
>  Maybe we could let people (other than the maintainers) to "categorise" the
>> project.
>>
>
> Best idea I've heard yet.  Ivan, I want to have a beer with you.
>
>  I really don't see duplication as a problem.
>>
>
> Ditto.  In fact I appreciate it.  It's finding the one you need that is the
> problem.  The way I see it, this problem requires a taxonomical/navigational
> solution, not a paradigm shift in methodology.  It would have to be an
> ongoing task/project in its own right, but IMHO it's one that could easily
> be supported by less-than-hardcore developers.
>
> LVX
> TF
>
>
> ---
> As If Productions
> http://www.asifproductions.com
> Interactive Worlds and Immersive Obsessions
>
>


-- 
-------------------------------------
Marco Sousa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/b0c4f6f1/attachment.htm>

From metzlerd at metzlerd.com  Wed Mar 11 15:13:45 2009
From: metzlerd at metzlerd.com (David Metzler)
Date: Wed, 11 Mar 2009 08:13:45 -0700
Subject: [development] An alternative to common thinking in
	5->	6migration
In-Reply-To: <49B7B25A.2060006@gmx.net>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
	<49B7B25A.2060006@gmx.net>
Message-ID: <3C574784-346A-4E5B-A493-22950CDBCB7D@metzlerd.com>


On Mar 11, 2009, at 5:45 AM, Marcel Partap wrote:

>> Previous posters brought up arguments, but you obviously did not  
>> understand
>> them.
> ???
> Where are those? Despite
> - it would place all load upon a small load of developers who are  
> already overloaded (not true)
> - would stiffle innovation (hardly true - restriction only on repo  
> commits)
> - don't like it because it messes with my ways (can't argue with that)
> there was no argument i am aware of, and none of those strike me as  
> real compelling evidence quality restriction would be a bad idea.
>>
To All:
Sounds like there's two threads here, one about avoiding unnecessary  
module duplication and another about improving quality of code that  
does get committed.  We've mostly been talking about the former.  But  
I sort of feel like commit time is way to late to be talking about  
strategies for eliminating module duplication anyway, so.....

The current documentation on drupal.org basically suggests you should:

     * to produce your contribution.
     * to apply for contributor privileges.

In the interest of moving this forward/closing this.  I've opened an  
issue at:

http://drupal.org/node/396946

Which discusses adding guidelines for vetting your module idea. If we  
have a process.  Now there is already the Joining Forces With others  
doc at http://drupal.org/node/23789.  Which describes the desire to  
communicate, but if there's a recommended protocol, perhaps we should  
include it in the basic process description?

To Marcel:
The stifle innovation argument is valid although you've called it  
invalid several times.

You have proposed that 10 (not high profile) developer reviews would  
be required in order to commit code. Assuming you mean what you say  
and the overloaded developers (high profile) don't have an increased  
workload, then that means i need 10 reviews to get my code committed.  
I maintain a non-duplicative module that plays an important role in  
universities that are doing single sign on with drupal.  I have  
struggled with getting ONE person to review my patches, but my code  
does get reviewed at my place of work, outside of the drupal  
commmunity.  This project would likely not be viable on drupal.org  
under the solution you describe.

There are several ways for you to get involved in patch reviews:

1. Play Contrib patch Bingo
2. Filter the project issue queue by Feature Requests that are Ready  
for Review
3. Subscribe to the issue queues of projects you're interested in  
helping with.

I would add my voice to the voice of other that suggest that there  
are more effective ways for us all to spend time improving quality of  
contrib code, the biggest of which could be joining the developer  
documentation effort.


From mail at webthatworks.it  Wed Mar 11 16:16:26 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Wed, 11 Mar 2009 17:16:26 +0100
Subject: [development] An alternative to common thinking in 5->
 6migration
In-Reply-To: <49B7B25A.2060006@gmx.net>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
	<49B7B25A.2060006@gmx.net>
Message-ID: <20090311171626.0b482e4b@dawn.webthatworks.it>

On Wed, 11 Mar 2009 13:45:14 +0100
Marcel Partap <mpartap at gmx.net> wrote:

> > I could even imagine that the content of this queue can be very
> > interesting for all Drupalers
> Well that's the point. Have all Drupalers maintain the modules,
> not just a specific maintainer. Just like core, but supported by
> better tools..

That's not going to happen. Wine and the kernel are far different
projects.

There are already few reviewers for core. Don't expect to have
reviewers for contrib.

It is clearer how core gains from public review.
It's not that clear how a maintainer may gain from code review.
I'm not talking about quality of code... I'm talking about the
interest of the maintainers.

Core and contrib are quite different in terms of speed of
development, purposes, design, coders sub-communities...

People may use drupal infrastructure just if:
- They're looking for public review
- They're looking for co-maintainers
- They're looking for exposure
- They just feel "generous" and they think someone else may make good
  use of their code without bothering them

Release early, release often refers to your users... not to everyone.
If I can't release early and often for *my users* because someone
else is not going to review my patch, I'm going to move my stuff
elsewhere. If someone is pushing my module in a direction that
doesn't fit *my users* I'm going to resist to the change.

Very frequently the maintainer of a module is the one that keeps
contributing the module most.

You're starting from the unproved assumption that for every
maintainer code review and exposure are a larger benefit than keep
on being the steering committee of its own project and that drupal
benefit more from a supposed increase of code quality and reduction
in duplication than having a prolific competitive community of
contributors.
Otherwise you're heading to balkanization of contrib repositories. 

While I agree that natural selection may be suboptimal and
rationally planning and channelling efforts may achieve better
results in a shorter time[1]... natural selection is self testing
and it already happens with no extra effort.
Other theories have to be proved and require efforts to be put in
practice.

Now... if you've something better to substitute to natural selection
and you can prove it is better, that's just the starting point as
Laura Scott pointed out at the end of her post.
If no one feels your hypothesis is worth a test, provide your own
test.
Then maybe you'll reach the point where "d(em)ocracy" and evolution
sucks and you may start complaining ;)
Otherwise there is no reason to accept "intelligent design" as a
real competitor.

[1] let's turn this into a flamewar about XP vs. waterfall vs.
academia vs. corporate vs. opensource vs. emacs as well ;)

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


From drupal.user at albin.net  Wed Mar 11 16:43:06 2009
From: drupal.user at albin.net (John Wilkins)
Date: Wed, 11 Mar 2009 11:43:06 -0500
Subject: [development] Failed to install HEAD
In-Reply-To: <fa5724270903110656v74154749j51bc7db0fb27f82c@mail.gmail.com>
References: <200903100924.58159.drupal@dave-cohen.com>
	<fa5724270903110656v74154749j51bc7db0fb27f82c@mail.gmail.com>
Message-ID: <6A122268-1945-4331-908C-6C58D8C0664C@albin.net>

Please see http://drupal.org/node/371309  "Failed to install HEAD"  
message makes the bot seem like a failure

The bot failure message doesn't explain _why_ it failed. We need to  
change the error message to help people out. This same message  
confused the hell out of me until someone told me it meant the _Drupal  
installer_ was broke after the patch was applied.

  - John

On Mar 11, 2009, at 8:56 AM, Nathaniel Catchpole wrote:

> I'm pretty sure the test framework install runs a custom script  
> which depends on the HEAD installer forms. So changes will cause  
> testing failures, and committing the patch will require the script  
> to be updated to avoid test bot meltdown. I'd probably try to force  
> your patch to Code Needs Review to get some manual testing - and see  
> if you can co-ordinate with Jimmy/boombatower and webchick in irc on  
> how best to deal with it.
>
> Nat
>
> On Tue, Mar 10, 2009 at 4:24 PM, Dave Cohen <drupal at dave-cohen.com>  
> wrote:
> I'm trying to submit a patch which changes a form in install.php.   
> Because of that change the test bot always fails with "Failed to  
> install HEAD".  At least I'm guessing that's why, the error message  
> really gives no explanation.
>
> Is there something I can include in the patch to make the test bot  
> succeed?
>
> The patch is here: http://drupal.org/node/394282
>
> Thanks,
>
> -Dave
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/857b8b19/attachment.htm>

From drupal at dave-cohen.com  Wed Mar 11 17:18:17 2009
From: drupal at dave-cohen.com (Dave Cohen)
Date: Wed, 11 Mar 2009 10:18:17 -0700
Subject: [development] Failed to install HEAD
In-Reply-To: <6A122268-1945-4331-908C-6C58D8C0664C@albin.net>
References: <200903100924.58159.drupal@dave-cohen.com>
	<fa5724270903110656v74154749j51bc7db0fb27f82c@mail.gmail.com>
	<6A122268-1945-4331-908C-6C58D8C0664C@albin.net>
Message-ID: <200903111018.17410.drupal@dave-cohen.com>

Thanks John, I did see your issue already.

I think in my case Nat's comment is correct.   My patch changes the installer form and there's no way to submit a patch which does this and which the test bot accepts.

-Dave

On Wednesday 11 March 2009 09:43:06 John Wilkins wrote:
> Please see http://drupal.org/node/371309  "Failed to install HEAD"  
> message makes the bot seem like a failure
> 
...
> 
>   - John
> 
> On Mar 11, 2009, at 8:56 AM, Nathaniel Catchpole wrote:
> 
> > I'm pretty sure the test framework install runs a custom script  
> > which depends on the HEAD installer forms. So changes will cause  
> > testing failures, and committing the patch will require the script  
> > to be updated to avoid test bot meltdown. I'd probably try to force  
> > your patch to Code Needs Review to get some manual testing - and see  
> > if you can co-ordinate with Jimmy/boombatower and webchick in irc on  
> > how best to deal with it.
> >
> > Nat
> >

From mpartap at gmx.net  Wed Mar 11 21:03:34 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Wed, 11 Mar 2009 22:03:34 +0100
Subject: [development] An alternative to common thinking
	in	5->	6migration
In-Reply-To: <3C574784-346A-4E5B-A493-22950CDBCB7D@metzlerd.com>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>	<49B7B25A.2060006@gmx.net>
	<3C574784-346A-4E5B-A493-22950CDBCB7D@metzlerd.com>
Message-ID: <49B82726.3090502@gmx.net>

> To Marcel:
> The stifle innovation argument is valid although you've called it
> invalid several times.
> You have proposed that 10 (not high profile) developer reviews would
> be required in order to commit code.  Assuming you mean what you say
> and the overloaded developers (high profile) don't have an increased
> workload, then that means i need 10 reviews to get my code committed.
No that was not exactly what i proposed. The proposal (!) was to have 
a patch get autocommitted (if style checks run fine and no tests 
break) by a bot after receiving 10 RTBC vote 'points' and no veto 
status. The fact that needs to be taken into account here is the level 
of coding skills and experience of the reviewing person, f.e. by 
giving people like merlinofchaos chx dries karens etc. (i.e. who have 
proven to be capable working even on especially complex code) a voting 
weight of 10 (or 9 maybe.. or whatever) to allow for quicker commital. 
That'd of course be an arbitrary decision - i'm sure though we could 
come up with something that worked.

> I maintain a non-duplicative module that plays an important role in
> universities that are doing single sign on with drupal.  I have
> struggled with getting ONE person to review my patches, but my code
> does get reviewed at my place of work, outside of the drupal
> commmunity.  This project would likely not be viable on drupal.org
> under the solution you describe.
The solution i described means that you'd post your code to a 
drupal-patches mailing list, which would in turn create a patch queue 
entry. Now anyone just watching could quickly review the code from 
their mail reader and if they feel like making a decision, do so on 
the respective, or leave their comments either by replying to the 
mailing list post or the tracker item, which would in turn be sent to 
the respective other channel. Now once that piece of core - or a 
modified version that gets posted later to the tracker item - receives 
its 10 RTBC points and passes the mentioned checks, it gets committed 
automatically. That at least was my basic idea which of course might 
have plenty space for improvement.

> There are several ways for you to get involved in patch reviews:
>
> 1. Play Contrib patch Bingo
> 2. Filter the project issue queue by Feature Requests that are Ready
> for Review
> 3. Subscribe to the issue queues of projects you're interested in
> helping with.
I like mailing lists. Wine-patches is just great for watching code 
that passes by. It'd be really useful as a tool by itself imho, 
although those other options already exist. You have to agree there is 
a slight but notable difference in actively subscribing/seeking 
something or passively get pushed the new code to your inbox.

> I would add my voice to the voice of other that suggest that there
> are more effective ways for us all to spend time improving quality of
> contrib code, the biggest of which could be joining the developer
> documentation effort.
There already is pretty good documentation and style guides and 
everything available. However, obviously that does *not* prevent 
people from ignoring these, which could simply be cured by a different 
commit policy for the official repository. It might get time for 
people to get accustomed to it, but i still think it would be 
beneficial for the whole drupal project in the long term.

regards marcel.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mail at webthatworks.it  Wed Mar 11 23:55:00 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Thu, 12 Mar 2009 00:55:00 +0100
Subject: [development] An alternative to common thinking in	5->
 6migration
In-Reply-To: <49B82726.3090502@gmx.net>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
	<49B7B25A.2060006@gmx.net>
	<3C574784-346A-4E5B-A493-22950CDBCB7D@metzlerd.com>
	<49B82726.3090502@gmx.net>
Message-ID: <20090312005500.7f3d7f22@dawn.webthatworks.it>

On Wed, 11 Mar 2009 22:03:34 +0100
Marcel Partap <mpartap at gmx.net> wrote:

> > To Marcel:
> > The stifle innovation argument is valid although you've called it
> > invalid several times.
> > You have proposed that 10 (not high profile) developer reviews
> > would be required in order to commit code.  Assuming you mean
> > what you say and the overloaded developers (high profile) don't
> > have an increased workload, then that means i need 10 reviews to
> > get my code committed.
> No that was not exactly what i proposed. The proposal (!) was to
> have a patch get autocommitted (if style checks run fine and no
> tests break) by a bot after receiving 10 RTBC vote 'points' and no
> veto status. The fact that needs to be taken into account here is
> the level of coding skills and experience of the reviewing person,
> f.e. by giving people like merlinofchaos chx dries karens etc.
> (i.e. who have proven to be capable working even on especially
> complex code) a voting weight of 10 (or 9 maybe.. or whatever) to
> allow for quicker commital. That'd of course be an arbitrary
> decision - i'm sure though we could come up with something that
> worked.

I prefer push approach for this kind of stuff rather than pull.
In fact I proposed a feed for just getting changes to docs, api
etc...
I sincerely don't feel comfort with the drupal project
infrastructure. It may be my ignorance or maybe "eat your own dog
food" works to some extent but is not a commandment.
Anyway I think you could obtain a similar effect subscribing to the
feeds of issue queues.

Still I don't feel the review score system is going to work for
contrib.

> I like mailing lists. Wine-patches is just great for watching code 
> that passes by. It'd be really useful as a tool by itself imho, 
> although those other options already exist. You have to agree
> there is a slight but notable difference in actively
> subscribing/seeking something or passively get pushed the new code
> to your inbox.

That's different from imposing review scores on contrib.

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


From larry at garfieldtech.com  Thu Mar 12 01:36:28 2009
From: larry at garfieldtech.com (Larry Garfield)
Date: Wed, 11 Mar 2009 20:36:28 -0500
Subject: [development]
 =?iso-8859-1?q?An_alternative_to_common_thinking_in?=
 =?iso-8859-1?q?=095-_=3E_=096migration?=
In-Reply-To: <49B82726.3090502@gmx.net>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
	<3C574784-346A-4E5B-A493-22950CDBCB7D@metzlerd.com>
	<49B82726.3090502@gmx.net>
Message-ID: <200903112036.28387.larry@garfieldtech.com>

On Wednesday 11 March 2009 4:03:34 pm Marcel Partap wrote:
> > To Marcel:
> > The stifle innovation argument is valid although you've called it
> > invalid several times.
> > You have proposed that 10 (not high profile) developer reviews would
> > be required in order to commit code.  Assuming you mean what you say
> > and the overloaded developers (high profile) don't have an increased
> > workload, then that means i need 10 reviews to get my code committed.
>
> No that was not exactly what i proposed. The proposal (!) was to have
> a patch get autocommitted (if style checks run fine and no tests
> break) by a bot after receiving 10 RTBC vote 'points' and no veto
> status. The fact that needs to be taken into account here is the level
> of coding skills and experience of the reviewing person, f.e. by
> giving people like merlinofchaos chx dries karens etc. (i.e. who have
> proven to be capable working even on especially complex code) a voting
> weight of 10 (or 9 maybe.. or whatever) to allow for quicker commital.
> That'd of course be an arbitrary decision - i'm sure though we could
> come up with something that worked.

So those "uber devs" with veto status would STILL have to police the rest of 
the issues to prevent auto-commits after ten people who don't know what 
they're talking about randomly +1 an issue.  Fail.

If chx saying +1 on a patch against one of my modules makes the patch commit 
without me agreeing, then I will not upload any of my modules to CVS.  Period.  
That's not territoriality, that's basic software architecture.  Any body of 
code needs some sort of directed design so that it maintains some level of 
consistency and coherence.  What you're proposing would actively prevent that.  
Moreover, I may be working toward one particular architectural design decision 
and some other random patch would break it.  Poof, it gets committed and 
breaks what I'm working on.  That is unacceptable.  Period.  Besides, even 
uber-devs screw up big time now and again (more often than most people think), 
and auto-committing in those circumstances just breaks things.

Voting on issues to give maintainers feedback on what users think is a high 
priority?  Sure, that's useful information and I've openly said I'm in favor 
of that before.  But the actual commit process MUST be done by a human, not a 
bot.  

> The solution i described means that you'd post your code to a
> drupal-patches mailing list, which would in turn create a patch queue
> entry. Now anyone just watching could quickly review the code from
> their mail reader and if they feel like making a decision, do so on
> the respective, or leave their comments either by replying to the
> mailing list post or the tracker item, which would in turn be sent to
> the respective other channel. Now once that piece of core - or a
> modified version that gets posted later to the tracker item - receives
> its 10 RTBC points and passes the mentioned checks, it gets committed
> automatically. That at least was my basic idea which of course might
> have plenty space for improvement.

Explain to me how having to email patches to a mailing list and then writing a 
mechanism to parse the patch out and create an issue for it, and then figure 
out if the patch is a follow-up to another patch (which the vast majority of 
patches are), and then losing all of the back and forth discussion that 
happens in the issue queue now is an improvement on having a central location 
for patches and discussion and screen shots that can be easily tracked, to 
which you can already subscribe via RSS or email and have been able to do so 
since long before I was involved in Drupal.

No, on second though, don't explain it.  Just stop.  Your proposal gets worse 
every time you restate it.

> I like mailing lists. Wine-patches is just great for watching code
> that passes by. It'd be really useful as a tool by itself imho,
> although those other options already exist. You have to agree there is
> a slight but notable difference in actively subscribing/seeking
> something or passively get pushed the new code to your inbox.

You like mailing lists.  Great.  I hate spam.  So do most people.  I don't 
think you realize just how many patches are submitted every single day just 
against core, to say nothing of contrib.  Just because you like mailing lists 
doesn't mean we should gut a very effective patch management process.

You want the patch firehose?  Click the subscribe link on any project's issue 
queue and you can get all the push-based notifications your heart desires.  You 
can do this *right now*, without having to create a few hundred hours work for 
other people that will just make it more difficult to develop for a project this 
size.

Really, Marcel.  Do yourself and everyone else a favor and just let it go.  
Your proposal was read, considered, and rejected.  Reasons have been given.  
All you're doing is making yourself look like a crybaby because your pet idea 
was rejected by the people it would affect the most.  Since I'm sure that's not 
what your intent is, I strongly urge you to simply let it go and find some 
other way to contribute.  This proposal is not it.

-- 
Larry Garfield
larry at garfieldtech.com

From drupal at dave-cohen.com  Thu Mar 12 02:20:01 2009
From: drupal at dave-cohen.com (Dave Cohen)
Date: Wed, 11 Mar 2009 19:20:01 -0700
Subject: [development] arg_separator
Message-ID: <200903111920.02506.drupal@dave-cohen.com>

Is there a reason for this in drupal's default settings.php?

ini_set('arg_separator.output',     '&amp;');

From merlin at logrus.com  Thu Mar 12 02:29:27 2009
From: merlin at logrus.com (Earl Miles)
Date: Wed, 11 Mar 2009 19:29:27 -0700
Subject: [development] An alternative to common thinking
	in	5->6	migration
In-Reply-To: <49B5968A.4020008@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>	<49B54F91.2060108@favias.org>	<49B55307.3000702@gmx.net>	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>
	<49B5968A.4020008@gmx.net>
Message-ID: <49B87387.3000205@logrus.com>

Marcel Partap wrote:
> Well of course but i really missed some voices from those high-profile
> developers. BTW nothing would change for them, especially no increase 
> in work-load.

If you would like a voice from a high profile developer, here is my voice:

I find work on core to be incredibly, mind-numbingly dull. Not due to 
the work, but due to the difficulty of getting it committed. If i had to 
go through a gateway process on my own projects, where someone who 
doesn't even necessarily understand the project has to decide whether or 
not it gets committed was in the way, I would certainly have never ended 
up a big time Drupal developer. The openness of contrib allowed me to 
succeed on my own merits.

It has allowed others to fail on their own merits. What it hasn't yet 
done is provided the community a way of letting people know about the 
successes and failures of developers. We need to focus on community 
moderation, not source code moderation.

From drumm at delocalizedham.com  Thu Mar 12 02:30:29 2009
From: drumm at delocalizedham.com (Neil Drumm)
Date: Wed, 11 Mar 2009 19:30:29 -0700
Subject: [development] arg_separator
In-Reply-To: <200903111920.02506.drupal@dave-cohen.com>
References: <200903111920.02506.drupal@dave-cohen.com>
Message-ID: <c96281260903111930g291d6996p6f9e11920aa4eeae@mail.gmail.com>

It has been removed: http://drupal.org/node/303154

-Neil

On Wed, Mar 11, 2009 at 7:20 PM, Dave Cohen <drupal at dave-cohen.com> wrote:
> Is there a reason for this in drupal's default settings.php?
>
> ini_set('arg_separator.output', ? ? '&amp;');
>



-- 
Neil Drumm
http://delocalizedham.com

From s.nerz at orestes-sol.com  Thu Mar 12 10:46:19 2009
From: s.nerz at orestes-sol.com (Sebastian Nerz)
Date: Thu, 12 Mar 2009 11:46:19 +0100
Subject: [development] Duplicated modules
In-Reply-To: <20090311134220.WTUA4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>
References: <mailman.73.1236775537.17128.development@drupal.org>
	<20090311134220.WTUA4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>
Message-ID: <49B8E7FB.9000306@orestes-sol.com>

I can only say that I agreed heartily to this response:

As If Productions schrieb:
> Ditto.  In fact I appreciate it.  It's finding the one you need that is 
> the problem.  The way I see it, this problem requires a 
> taxonomical/navigational solution, not a paradigm shift in methodology.  
> It would have to be an ongoing task/project in its own right, but IMHO 
> it's one that could easily be supported by less-than-hardcore developers.
> 
> LVX
> TF

I apologize for shamelessly promoting my one proposal over the 
mailinglist, but actually, I believe that use-cases (see my proposal at 
http://drupal.org/node/397280 ) could - together with a nice searching 
solution - solve this problem.
Why?
Because use-cases would present a "you want this, you need that"-way of 
viewing modules, not some "I give you xyz" like modules do.

And use-cases could be moderated/developed by "use-case-developers" not 
"module-developers". Why is this an advantage?  A use-case-developer 
would need to think more like a designer then like a developer.
And every developer likes *his* way of developing (for sometimes very 
good reasons). The result is, that we have multiple modules solving the 
same problem (in different ways). Thats wonderful! It's allows for 
evolution of modules (evolution never works with just one set, you need 
multiplicity).

Nevertheless: Use-cases could select *one* of those modules/combinations 
and promote it. When (someday) another module is better, use-cases could 
change. Perhaps there are multiple use-cases solving a given problem. So 
what? As long as they present nice "what you get"/"when to choose this 
use-case" its still easier to decide..

-- 
Mit freundlichen Gr??en / Best regards / Saludos cordiales

*Sebastian Nerz*

___________________________________________
*Orestes*
Eduard-Spranger-Str. 56
D-72076 Tuebingen - Deutschland
Of.  : +49-7071-56519-30 - Fax : +49-7071-56519-31
www.orestes-sol.com <http://www.orestes-sol.com/>
s.nerz at orestes-sol.com <mailto:s.nerz at orestes-sol.com>
___________________________________________

From tomi at vacilando.org  Thu Mar 12 15:02:09 2009
From: tomi at vacilando.org (=?UTF-8?B?VG9tw6HFoSBGw7xsw7ZwcCAodmFjaWxhbmRvLm9yZyk=?=)
Date: Thu, 12 Mar 2009 16:02:09 +0100
Subject: [development] Duplicated modules
In-Reply-To: <20090311134220.WTUA4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>
References: <mailman.73.1236775537.17128.development@drupal.org>
	<20090311134220.WTUA4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>
Message-ID: <593475f90903120802v1e839931ne31a59cc167433e0@mail.gmail.com>

Hi,

I totally agree with Ivan Sergio Borgonovo, As If Productions, and some
others on this issue. Duplication is not such a problem; it is the lack of
useful categorization (module relation, similarity) and lack of efficient
searching that leads to time wasting.

1) I used to use the long page with all modules and search using CTRL+F in
it. That kind of worked for me - I could find related modules, and then read
about them in tabs. But since the long page is broken by pagination, I am
lost. The categories are unhelpful, as is the module search tool. Most of
the time I find related modules by Google site search, but that's
inefficient as well.
Hence: let's aim for better categorization (by maintainers AND the module
users), without limiting the tag count, and for a high-quality search (maybe
autocomplete would be helpful).

2) Duplication means diversity and that means evolution. Even if it hurts
and takes time, I am sure it is the best. In the process of testing
prospective modules, we often discover exciting facets of them, and by
communicating with maintainers we may help some of the projects flourish in
unexpected directions. I would never trust any approval seals. Even download
counts are more useful than any seal, IMHO.
(I am imagining a large ToughGraph or suchlike map of Drupal modules, with
all sorts of groupings and color-coded relations, with explanations on
mouse-touch, etc., that might be lovely for the module jungle exploration!)

Cheers,

Tom?? (vacilando)

--
Tom?? J. F?l?pp
Tomi at vacilando.org
http://vacilando.net



On Wed, Mar 11, 2009 at 14:41, As If Productions <
everyone at asifproductions.com> wrote:

> At 05:45 AM 3/11/2009, Ivan Sergio Borgonovo wrote:
>
>> What I'd find useful would be
>> - better categorisation system and better search system on categories
>>
>
> Big +1 on that.
>
>  - a flag to check if a module provides an API or is just an application
>> - an activity index (average lines of code changed/time)
>> - a issue queue index
>>
>
> Regular +1 on those.
>
>  Maybe we could let people (other than the maintainers) to "categorise" the
>> project.
>>
>
> Best idea I've heard yet.  Ivan, I want to have a beer with you.
>
>  I really don't see duplication as a problem.
>>
>
> Ditto.  In fact I appreciate it.  It's finding the one you need that is the
> problem.  The way I see it, this problem requires a taxonomical/navigational
> solution, not a paradigm shift in methodology.  It would have to be an
> ongoing task/project in its own right, but IMHO it's one that could easily
> be supported by less-than-hardcore developers.
>
> LVX
> TF
>
>
> ---
> As If Productions
> http://www.asifproductions.com
> Interactive Worlds and Immersive Obsessions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090312/66f86697/attachment.htm>

From sepeck at gmail.com  Thu Mar 12 15:57:04 2009
From: sepeck at gmail.com (Steven Peck)
Date: Thu, 12 Mar 2009 08:57:04 -0700
Subject: [development] Duplicated modules
In-Reply-To: <593475f90903120802v1e839931ne31a59cc167433e0@mail.gmail.com>
References: <mailman.73.1236775537.17128.development@drupal.org>
	<20090311134220.WTUA4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>
	<593475f90903120802v1e839931ne31a59cc167433e0@mail.gmail.com>
Message-ID: <a151b5a00903120857xbd44c89uf2d957e968d1591d@mail.gmail.com>

If only there was a drupal.org redesign process people could get
involved with on the groups site.  I mean how neat would that be?  I
think I've read something about that somewhere.  Maybe on one of the
get-involved pages....  perhaps on a front page posting... I am not
sure.

Steven Peck

On Thu, Mar 12, 2009 at 8:02 AM, Tom?? F?l?pp (vacilando.org)
<tomi at vacilando.org> wrote:
> Hi,
>
> I totally agree with Ivan Sergio Borgonovo, As If Productions, and some
> others on this issue. Duplication is not such a problem; it is the lack of
> useful categorization (module relation, similarity) and lack of efficient
> searching that leads to time wasting.
>
> 1) I used to use the long page with all modules and search using CTRL+F in
> it. That kind of worked for me - I could find related modules, and then read
> about them in tabs. But since the long page is broken by pagination, I am
> lost. The categories are unhelpful, as is the module search tool. Most of
> the time I find related modules by Google site search, but that's
> inefficient as well.
> Hence: let's aim for better categorization (by maintainers AND the module
> users), without limiting the tag count, and for a high-quality search (maybe
> autocomplete would be helpful).
>
> 2) Duplication means diversity and that means evolution. Even if it hurts
> and takes time, I am sure it is the best. In the process of testing
> prospective modules, we often discover exciting facets of them, and by
> communicating with maintainers we may help some of the projects flourish in
> unexpected directions. I would never trust any approval seals. Even download
> counts are more useful than any seal, IMHO.
> (I am imagining a large ToughGraph or suchlike map of Drupal modules, with
> all sorts of groupings and color-coded relations, with explanations on
> mouse-touch, etc., that might be lovely for the module jungle exploration!)
>
> Cheers,
>
> Tom?? (vacilando)
>
> --
> Tom?? J. F?l?pp
> Tomi at vacilando.org
> http://vacilando.net
>
>
>
> On Wed, Mar 11, 2009 at 14:41, As If Productions
> <everyone at asifproductions.com> wrote:
>>
>> At 05:45 AM 3/11/2009, Ivan Sergio Borgonovo wrote:
>>>
>>> What I'd find useful would be
>>> - better categorisation system and better search system on categories
>>
>> Big +1 on that.
>>
>>> - a flag to check if a module provides an API or is just an application
>>> - an activity index (average lines of code changed/time)
>>> - a issue queue index
>>
>> Regular +1 on those.
>>
>>> Maybe we could let people (other than the maintainers) to "categorise"
>>> the project.
>>
>> Best idea I've heard yet. ?Ivan, I want to have a beer with you.
>>
>>> I really don't see duplication as a problem.
>>
>> Ditto. ?In fact I appreciate it. ?It's finding the one you need that is
>> the problem. ?The way I see it, this problem requires a
>> taxonomical/navigational solution, not a paradigm shift in methodology. ?It
>> would have to be an ongoing task/project in its own right, but IMHO it's one
>> that could easily be supported by less-than-hardcore developers.
>>
>> LVX
>> TF
>>
>>
>> ---
>> As If Productions
>> http://www.asifproductions.com
>> Interactive Worlds and Immersive Obsessions
>>
>
>

From r.crowther at zen.co.uk  Thu Mar 12 15:44:34 2009
From: r.crowther at zen.co.uk (robert crowther)
Date: Thu, 12 Mar 2009 15:44:34 +0000
Subject: [development] An alternative to common thinking in 5- >
	6migration
Message-ID: <1236872674.17057.22.camel@robert-desktop>

And after Earl, how about a voice from the small fry?

I had an idea for a module. That was half a year ago now. I knew nothing
about Drupal and PHP. I don't even know about how programming culture
works.

After a helpful comment on dev (so how about being kind to frustrated
people who stumble onto here?) I got going. My module is low profile
because I want it to be. It's not ready for the big time. It is proof of
concept. I try to make it clear to anyone who stumbles onto the work
just what it can and can not do.

This story works both ways, I guess. I'm exactly the kind of person some
people would like to clear out. And other people would like to
encourage, in the hope that 1 in 9 of the efforts might hit something
good.

Following David Meltzer yesterday, who sees a couple of basic arguments
on separate threads.... I don't have time to read through all of this,

There is another way of avoiding duplicates, besides review. If the
cataloguing was good, you'd see the duplicates fast. And if cataloguing
was good, you get minor efforts, such as my own, further down the pile.

When I started my module, I searched Drupal modules and came up with 9 -
12 other modules, all in separate places. It took me hours. Not an
adverse criticism folks, I'd rather contrib was big than small. And I'm
another person who will not be applying myself to this right now (though
there is a thought).

Me, I'd rather make suggestions

http://www.soundsnap.com/

Now that is a search facility I like.

Rob


From wdlists at optonline.net  Thu Mar 12 17:01:59 2009
From: wdlists at optonline.net (Walt Daniels)
Date: Thu, 12 Mar 2009 13:01:59 -0400
Subject: [development] An alternative to common thinking in 5-
	>	6migration
In-Reply-To: <1236872674.17057.22.camel@robert-desktop>
References: <1236872674.17057.22.camel@robert-desktop>
Message-ID: <A96E619922F74850A673255077FA031A@Squirt>

How about something like Tagadelic on all the words in the description of
the module. That would encourage people to do better descriptions as well as
being a measure of duplication. Big letters might not be good except for
modules that do something good with CCK or Views which would boost their
size.

-----Original Message-----
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of robert crowther
Sent: Thursday, March 12, 2009 11:45 AM
To: development at drupal.org
Subject: Re: [development] An alternative to common thinking in 5- >
6migration

And after Earl, how about a voice from the small fry?

I had an idea for a module. That was half a year ago now. I knew nothing
about Drupal and PHP. I don't even know about how programming culture
works.

After a helpful comment on dev (so how about being kind to frustrated
people who stumble onto here?) I got going. My module is low profile
because I want it to be. It's not ready for the big time. It is proof of
concept. I try to make it clear to anyone who stumbles onto the work
just what it can and can not do.

This story works both ways, I guess. I'm exactly the kind of person some
people would like to clear out. And other people would like to
encourage, in the hope that 1 in 9 of the efforts might hit something
good.

Following David Meltzer yesterday, who sees a couple of basic arguments
on separate threads.... I don't have time to read through all of this,

There is another way of avoiding duplicates, besides review. If the
cataloguing was good, you'd see the duplicates fast. And if cataloguing
was good, you get minor efforts, such as my own, further down the pile.

When I started my module, I searched Drupal modules and came up with 9 -
12 other modules, all in separate places. It took me hours. Not an
adverse criticism folks, I'd rather contrib was big than small. And I'm
another person who will not be applying myself to this right now (though
there is a thought).

Me, I'd rather make suggestions

http://www.soundsnap.com/

Now that is a search facility I like.

Rob


From karoly at negyesi.net  Thu Mar 12 19:00:50 2009
From: karoly at negyesi.net (Karoly Negyesi)
Date: Thu, 12 Mar 2009 20:00:50 +0100 (CET)
Subject: [development] Duplicated modules
In-Reply-To: <20090311124045.2c844960@dawn.webthatworks.it>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
	<76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
	<20090311124045.2c844960@dawn.webthatworks.it>
Message-ID: <E1Lhq9C-0005kg-Gc@fenris.runbox.com>

> Maybe we could let people (other than the maintainers) to
> "categorise" the project.

Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes and I am sure we will have a few more variations... 

From domenic at workhabit.com  Thu Mar 12 19:54:58 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Thu, 12 Mar 2009 12:54:58 -0700
Subject: [development] Duplicated modules
In-Reply-To: <E1Lhq9C-0005kg-Gc@fenris.runbox.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
	<76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
	<20090311124045.2c844960@dawn.webthatworks.it>
	<E1Lhq9C-0005kg-Gc@fenris.runbox.com>
Message-ID: <e83e0db0903121254y329e4e9et3df8695dceff3189@mail.gmail.com>

On Thu, Mar 12, 2009 at 12:00 PM, Karoly Negyesi <karoly at negyesi.net> wrote:
>> Maybe we could let people (other than the maintainers) to
>> "categorise" the project.
>
> Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes and I am sure we will have a few more variations...
>

If only there was a way to make taxonomy synonyms..................

From karoly at negyesi.net  Thu Mar 12 20:01:53 2009
From: karoly at negyesi.net (Karoly Negyesi)
Date: Thu, 12 Mar 2009 21:01:53 +0100 (CET)
Subject: [development] Duplicated modules
In-Reply-To: <e83e0db0903121254y329e4e9et3df8695dceff3189@mail.gmail.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
	<76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
	<20090311124045.2c844960@dawn.webthatworks.it>
	<E1Lhq9C-0005kg-Gc@fenris.runbox.com>
	<e83e0db0903121254y329e4e9et3df8695dceff3189@mail.gmail.com>
Message-ID: <E1Lhr6H-000508-LT@garm.runbox.com>

> On Thu, Mar 12, 2009 at 12:00 PM, Karoly Negyesi <karoly at negyesi.net> wrote:
> >> Maybe we could let people (other than the maintainers) to
> >> "categorise" the project.
> >
> > Mail, mails, mailing, notify, notifies, notification, subscribe, subscriptions, subscribes and I am sure we will have a few more variations...
> >
> 
> If only there was a way to make taxonomy synonyms..................

And a bunch of people to make use of them... though we seem have a nice amount of site maintainers these days... Maybe, maybe.

From catch56 at googlemail.com  Thu Mar 12 20:12:13 2009
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 12 Mar 2009 20:12:13 +0000
Subject: [development] Duplicated modules
In-Reply-To: <E1Lhr6H-000508-LT@garm.runbox.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
	<76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
	<20090311124045.2c844960@dawn.webthatworks.it>
	<E1Lhq9C-0005kg-Gc@fenris.runbox.com>
	<e83e0db0903121254y329e4e9et3df8695dceff3189@mail.gmail.com>
	<E1Lhr6H-000508-LT@garm.runbox.com>
Message-ID: <fa5724270903121312y5c6d10c2t9676d05fa33da726@mail.gmail.com>

... and a module which automatically resolved synonyms to real terms.

Oh HAI! http://drupal.org/project/synonym_collapsing




> > >> Maybe we could let people (other than the maintainers) to
> > >> "categorise" the project.
> > >
> > > Mail, mails, mailing, notify, notifies, notification, subscribe,
> subscriptions, subscribes and I am sure we will have a few more
> variations...
> > >
> >
> > If only there was a way to make taxonomy synonyms..................
>
> And a bunch of people to make use of them... though we seem have a nice
> amount of site maintainers these days... Maybe, maybe.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090312/45941f90/attachment.htm>

From mail at webthatworks.it  Thu Mar 12 21:07:59 2009
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Thu, 12 Mar 2009 22:07:59 +0100
Subject: [development] Duplicated modules
In-Reply-To: <E1Lhq9C-0005kg-Gc@fenris.runbox.com>
References: <7e270cea0903101514t3abc3fcbv3c7fedbe3873913f@mail.gmail.com>
	<e83e0db0903101537saf7c8ebwdc2d79250a2b476d@mail.gmail.com>
	<49B6EC83.2080205@disobey.com>
	<76DC9E67-FAA6-4103-BA91-7DAA9ADE3B2C@sentex.net>
	<20090311124045.2c844960@dawn.webthatworks.it>
	<E1Lhq9C-0005kg-Gc@fenris.runbox.com>
Message-ID: <20090312220759.07f56f41@dawn.webthatworks.it>

On Thu, 12 Mar 2009 20:00:50 +0100 (CET)
"Karoly Negyesi" <karoly at negyesi.net> wrote:

> > Maybe we could let people (other than the maintainers) to
> > "categorise" the project.

> Mail, mails, mailing, notify, notifies, notification, subscribe,
> subscriptions, subscribes and I am sure we will have a few more
> variations... 

test_drupal=# select * from to_tsvector('pg_catalog.english', 'Mail,
mails, mailing, notify, notifies, notification, subscribe,
subscriptions, subscribes'); to_tsvector
------------------------------------------------------------------
'mail':1,2,3 'notif':6 'notifi':4,5 'subscrib':7,9 'subscript':8

This could be one solution. This dictionary is not configured to use
synonyms, but it's just a matter of configuration for PostgreSQL.
There should be precooked solutions for MySQL as well.
After all if you're making taxonomies searchable

term AND term
(term OR term) and (term OR term)

you're going to solve this problem anyway.

Another solution could be to restrict terms to a selection.
Collect terms from the community for let's say one week, filter
them, post-edit the result and use it.

Auto-completion may help avoiding duplicates.

Just most "voted" terms may appear.

If you expect high load... the project is a success, still the load
of collecting terms should be negligible compared to all the other
things required to drupal.org.
If you don't expect high load... there is no need to worry about
performance of a dictionary.

To add tags people will have to login. Load to filter synonyms
should be tolerable.

If spammers use similar techniques they should have a good ROI.

Now we have ~40 categories. Reach 400 and the categorisation system
will work much better. BIC [1] should have ~6000 leaves.

I could do some research about tools available for mysql.
drupal.org recently moved to solr, solr has support for synonyms.

[1] http://www.bic.org.uk/

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


From bamlhs at hotmail.com  Thu Mar 12 21:08:46 2009
From: bamlhs at hotmail.com (bamlhs at hotmail.com)
Date: Thu, 12 Mar 2009 14:08:46 -0700
Subject: [development] Vacation reply
In-Reply-To: <20090312220759.07f56f41@dawn.webthatworks.it>
Message-ID: <COL0-MC1-F165F38B2C14C4E1AD2952DD69F0@phx.gbl>

An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090312/d650088c/attachment.htm>

From r.crowther at zen.co.uk  Thu Mar 12 22:35:59 2009
From: r.crowther at zen.co.uk (robert crowther)
Date: Thu, 12 Mar 2009 22:35:59 +0000
Subject: [development] contrib categorisation
Message-ID: <1236897359.6428.63.camel@robert-desktop>

Listen, if anyone wants to suggest a better thread title, please do so!

Anyhow, the 'Duplicated Modules' thread has moved in this direction (one
suggestion being that duplicate modules would be more easily avoided if
modules were categorised more freely and finely)

...and the 'An Alternative to Common Thinking' thread has moved in this
direction, as leaning towards natural selection (if I might draw that
analogy without upsetting anyone. If I have, I do apologise, but I hope
you understand the process I am trying to summon) ...whereas at the
moment we have an exciting and spontaneous enthusiasm from the fertile
ground of Drupal core.

But it would be nice to move this part of the discussion aside, I feel?
Hence the new subject line.



Look, I simply glance at dev to keep tabs on things. But I do recall
something about this being talked over before. So I'm sure there is
discussion I am not party to.

RE: Walt Daniels - I've never seen Tagadelic (told you I'm not current)
but a quick look tells me you most certainly get my drift.



SoundSnap has a number of features (many I like),

- A rough overall vocabulary

- Sub categories 
Terms. Don't know who provides these.

- A tagging system 
Now I assume this is free-tagging by contributors. But it works very
well. I use it all the time for cross checking.

Whether these categorisations are actively checked for synonyms or not,
I don't know. I assume that people think carefully about their tagging
though, otherwise their contribution will not show.

- A star rating system.
Now I hardly ever use this, as I may want a 'spitfire takeoff', not a
'spitfire flyby' (if I looked up aircraft). But I might use...

- Download count

- List sorting
I never use it. As with EBay, where I slam everything onto 'Ending
Soonest' (though I do use 'Auctions' and 'Buy-it-now' tabs)

- Comments
Hardly ever use them, because...

- Try before download

and finally

- Search box suggestions
e.g. 'telephone' might suggest 'ring'/'booth'/'operator'. Don't know how
SoundSnap regulate this, but the suggestions are clearly pertinent, even
inspiring.



Differences (between Soundsnap and Contrib)

Soundsnap is actively vetted for content. Don't see how this changes the
argument, but there you are.

You can sum up a sound sample on one line. Actually, I don't see why you
can't sum up a module on one line, but there you go...



Similarities

Errm, I think SoundSnap is Drupal. Just guessing, from the interface and
all.

The base information is probably on a similar scale to contrib.
SoundSnap claim about 100,000 samples. Anyway, they achieve highly
effective searching over a large base. I imagine, given their content,
the searches are pulverising and fine grained... in short, very
intensive.



Further thoughts

The current Drupal system provides SOME of this anyhow. The main missing
bits seem to be,

- A thumpingly big front end.
- Some sub-classification on the front end.
- Tagging.
- A suggestive search.
- Knowing which bits SoundSnap actively administer, and what that would
cost in the Drupal contrib environment.

And maybe

- Encouraging people to produce one or two line distillations of module
descriptions.

I love the idea of a try-before-buy feature. The only analogy I can
think of is to more actively encourage screenshots. This may work in an
EBay fashion - you get no interest without that little picture in on the
left...




Right, and now I feel somewhat embarrassed that I'm not going to do
this, ...well, not now anyhow... so, over to the list,

Rob
 


From sepeck at gmail.com  Thu Mar 12 23:41:09 2009
From: sepeck at gmail.com (Steven Peck)
Date: Thu, 12 Mar 2009 16:41:09 -0700
Subject: [development] contrib categorisation
In-Reply-To: <1236897359.6428.63.camel@robert-desktop>
References: <1236897359.6428.63.camel@robert-desktop>
Message-ID: <a151b5a00903121641m659efbb8o700602707274561@mail.gmail.com>

I would suggest you get involved either on the infrastructure list and
/ or the Drupal.org redesign groups site.

sepeck

On Thu, Mar 12, 2009 at 3:35 PM, robert crowther <r.crowther at zen.co.uk> wrote:
> Listen, if anyone wants to suggest a better thread title, please do so!
>
> Anyhow, the 'Duplicated Modules' thread has moved in this direction (one
> suggestion being that duplicate modules would be more easily avoided if
> modules were categorised more freely and finely)
>
> ...and the 'An Alternative to Common Thinking' thread has moved in this
> direction, as leaning towards natural selection (if I might draw that
> analogy without upsetting anyone. If I have, I do apologise, but I hope
> you understand the process I am trying to summon) ...whereas at the
> moment we have an exciting and spontaneous enthusiasm from the fertile
> ground of Drupal core.
>
> But it would be nice to move this part of the discussion aside, I feel?
> Hence the new subject line.
>
>
>
> Look, I simply glance at dev to keep tabs on things. But I do recall
> something about this being talked over before. So I'm sure there is
> discussion I am not party to.
>
> RE: Walt Daniels - I've never seen Tagadelic (told you I'm not current)
> but a quick look tells me you most certainly get my drift.
>
>
>
> SoundSnap has a number of features (many I like),
>
> - A rough overall vocabulary
>
> - Sub categories
> Terms. Don't know who provides these.
>
> - A tagging system
> Now I assume this is free-tagging by contributors. But it works very
> well. I use it all the time for cross checking.
>
> Whether these categorisations are actively checked for synonyms or not,
> I don't know. I assume that people think carefully about their tagging
> though, otherwise their contribution will not show.
>
> - A star rating system.
> Now I hardly ever use this, as I may want a 'spitfire takeoff', not a
> 'spitfire flyby' (if I looked up aircraft). But I might use...
>
> - Download count
>
> - List sorting
> I never use it. As with EBay, where I slam everything onto 'Ending
> Soonest' (though I do use 'Auctions' and 'Buy-it-now' tabs)
>
> - Comments
> Hardly ever use them, because...
>
> - Try before download
>
> and finally
>
> - Search box suggestions
> e.g. 'telephone' might suggest 'ring'/'booth'/'operator'. Don't know how
> SoundSnap regulate this, but the suggestions are clearly pertinent, even
> inspiring.
>
>
>
> Differences (between Soundsnap and Contrib)
>
> Soundsnap is actively vetted for content. Don't see how this changes the
> argument, but there you are.
>
> You can sum up a sound sample on one line. Actually, I don't see why you
> can't sum up a module on one line, but there you go...
>
>
>
> Similarities
>
> Errm, I think SoundSnap is Drupal. Just guessing, from the interface and
> all.
>
> The base information is probably on a similar scale to contrib.
> SoundSnap claim about 100,000 samples. Anyway, they achieve highly
> effective searching over a large base. I imagine, given their content,
> the searches are pulverising and fine grained... in short, very
> intensive.
>
>
>
> Further thoughts
>
> The current Drupal system provides SOME of this anyhow. The main missing
> bits seem to be,
>
> - A thumpingly big front end.
> - Some sub-classification on the front end.
> - Tagging.
> - A suggestive search.
> - Knowing which bits SoundSnap actively administer, and what that would
> cost in the Drupal contrib environment.
>
> And maybe
>
> - Encouraging people to produce one or two line distillations of module
> descriptions.
>
> I love the idea of a try-before-buy feature. The only analogy I can
> think of is to more actively encourage screenshots. This may work in an
> EBay fashion - you get no interest without that little picture in on the
> left...
>
>
>
>
> Right, and now I feel somewhat embarrassed that I'm not going to do
> this, ...well, not now anyhow... so, over to the list,
>
> Rob
>
>
>

From mistknight at gmail.com  Thu Mar 12 23:51:29 2009
From: mistknight at gmail.com (Ashraf Amayreh)
Date: Fri, 13 Mar 2009 01:51:29 +0200
Subject: [development] add a block in my custom php code
In-Reply-To: <c538f9410903101432m76ad82e9ha47f9d3cda642c6b@mail.gmail.com>
References: <200902231359.06803.aldo@caonao.cu>
	<c538f9410902240831y34588cd1v874184f0312fd32b@mail.gmail.com>
	<49A4220B.70209@logrus.com> <200903101350.02778.aldo@caonao.cu>
	<c538f9410903101106v28a5efbdq44a1ff5a00796db4@mail.gmail.com>
	<09FBD86C-D8B8-40FB-A51C-2257147BEC57@sentex.net>
	<c538f9410903101432m76ad82e9ha47f9d3cda642c6b@mail.gmail.com>
Message-ID: <a53d1b3b0903121651w323e3c46uf9e803316ba8909c@mail.gmail.com>

I think the better way of doing this is to pass regions to the node
template.

Not sure where this is documented, but if you check the phptemplate section
under regions you're bound to find something about it.

On Tue, Mar 10, 2009 at 11:32 PM, Paolo Mainardi <paolomainardi at gmail.com>wrote:

>
>
> On Tue, Mar 10, 2009 at 7:41 PM, Andrew Berry <andrewberry at sentex.net>wrote:
>
>> On 10-Mar-09, at 2:06 PM, Paolo Mainardi wrote:
>>
>>  <?php
>>> $block = module_invoke('block', 'block', 'view', YOUR_BLOCK_ID);
>>> print $block['content'];
>>> ?>
>>>
>>
>> I would consider creating a new region in your theme instead. Then you can
>> assign and move any block to it through the block admin page as you see fit.
>> Creating a region is pretty simple; I think the Zen theme has a decently
>> documented method of doing it.
>>
>
> Yes clear, the region it's the standard way :) This is the "raw" mode to
> call directly a block.
>
> --
> Paolo Mainardi
>
> Vice Presidente Assoc.ILDN (http://www.ildn.net)
> Blog: http://www.paolomainardi.com
>



-- 
Ashraf Amayreh
http://aamayreh.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090313/c7b7317e/attachment.htm>

From mpartap at gmx.net  Fri Mar 13 04:33:43 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Fri, 13 Mar 2009 05:33:43 +0100
Subject: [development] An alternative to common thinking in 5- >
	6migration
In-Reply-To: <200903112036.28387.larry@garfieldtech.com>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>	<3C574784-346A-4E5B-A493-22950CDBCB7D@metzlerd.com>	<49B82726.3090502@gmx.net>
	<200903112036.28387.larry@garfieldtech.com>
Message-ID: <49B9E227.5000603@gmx.net>

>>  That'd of course be an arbitrary decision - i'm sure though we could
>>  come up with something that worked.
> So those "uber devs" with veto status
No no everyone would have be able to vote veto, only clearing would 
need response from a 'veteran' developer.

 > would STILL have to police the rest of
> the issues to prevent auto-commits after ten people who don't know what
> they're talking about randomly +1 an issue.  Fail.
Of course, only people who have landed code in the repo at least once 
do have a vote. Others can only comment, otherwise the code voting 
would be pretty useless.

> If chx saying +1 on a patch against one of my modules makes the patch commit
> without me agreeing, then I will not upload any of my modules to CVS.  Period.
Well i think you quite didn't get that another point of the proposal 
was to take out the concept of individuals as module ow.. maintainers. 
You can submit code, if it's good it gets committed, if not it gets 
improved. Obviously the prospect of loosing ownership of 'their' code 
has brought up some fierce opposition though.

> That's not territoriality, that's basic software architecture.  Any body of
> code needs some sort of directed design so that it maintains some level of
> consistency and coherence.
And to facilitate it, making the community design frameworks for stuff 
common to many modules' detailed functionality would be a start. That 
means that in the next few months, we would take part in this process 
and together engineer those frameworks, as basis for expanding them by 
our pet code later one.

> What you're proposing would actively prevent that.
Duh i thoroughly failed to get people to understand my proposal.

> Moreover, I may be working toward one particular architectural design decision
> and some other random patch would break it. Poof, it gets committed and
> breaks what I'm working on.
So you go and veto it, explaining that you are working on something, 
reasoning why it is the better approach to the problem at hand.
> That is unacceptable.  Period.  Besides, even
> uber-devs screw up big time now and again (more often than most people think),
> and auto-committing in those circumstances just breaks things.
So auto-committing stuff after it received 10 vote 'points' and still 
passing the criterion of breaking no tests and having no coding 
standard collisions is more dangerous than just committing. Sorry, i 
do not follow.

> Voting on issues to give maintainers feedback on what users think is a high
> priority?
Totally not part of what i proposed.
a) no more module maintainers, just (top) contributors.
b) no users voting on code.

> Sure, that's useful information and I've openly said I'm in favor
> of that before.  But the actual commit process MUST be done by a human, not a
> bot.
So other devs acknowledging the code before it gets auto committed 
does not qualify for that description?

> Explain to me how having to email patches to a mailing list and then writing a
> mechanism to parse the patch out and create an issue for it, and then figure
> out if the patch is a follow-up to another patch (which the vast majority of
> patches are), and then losing all of the back and forth discussion that
> happens in the issue queue now is an improvement on having a central location
> for patches and discussion and screen shots that can be easily tracked, to
> which you can already subscribe via RSS or email and have been able to do so
> since long before I was involved in Drupal.
Well obviously it's not, that's why i proposed something different: a 
cleverly integrated solution, where the discussion is synced on the 
mailing list and the patch tracking item.

> No, on second though, don't explain it.  Just stop.  Your proposal gets worse
> every time you restate it.
Maybe people dig deeper and deeper into misunderstanding it, despite 
me correcting that every single time. It does surely seem useless.

>>  I like mailing lists. Wine-patches is just great for watching code
>>  that passes by. It'd be really useful as a tool by itself imho,
>>  although those other options already exist. You have to agree there is
>>  a slight but notable difference in actively subscribing/seeking
>>  something or passively get pushed the new code to your inbox.
> You like mailing lists.  Great.  I hate spam.  So do most people.
So don't frigging subscribe and use the channels you're used to, sheesh.

> I don't think you realize just how many patches are submitted every single day just
> against core, to say nothing of contrib.
a) yes i do and b) so because of the sheer amount of code that flows 
by, quality checks before committing would be a mistake. Sorry that 
does not convince me.

> Just because you like mailing lists
> doesn't mean we should gut a very effective patch management process.
Repeating myself does get ridiculous at some point but anyways: i 
never proposed to kill working operational procedures, because 
obviously that'd be stupid.

> You want the patch firehose?  Click the subscribe link on any project's issue
> queue and you can get all the push-based notifications your heart desires.
Which makes me miss all the other code that is trying to get into the 
repo, what a great idea.

 > Really, Marcel.  Do yourself and everyone else a favor and just let 
it go.
I've already given up on making it happen, i'm just fighting for 
correcting the misunderestimation of the concept.
> Your proposal was read, considered, and rejected.
No, it was read, misunderstood, considered and then rejected.
> Reasons have been given.
Mostly either based on misunderstanding or emotions. And by the way i 
always get aroused by good points in a rational debate so i am 
actually looking for them.

> All you're doing is making yourself look like a crybaby because your pet idea
> was rejected by the people it would affect the most.
Really, i'm not. And how many people do have SVN accounts currently? 
How many of those have voiced their opinion? Does an idea being 
rejected based on gross misunderstanding actually correlate with the idea?

> Since I'm sure that's not
> what your intent is, I strongly urge you to simply let it go and find some
> other way to contribute.
My intent was to propose a solution to the problems i listed in the 
original posting, i am not going to repeat them.

> This proposal is not it.
What your idea of it is is definitly not.
>


-- 
   "Obstacles are those frightful things you see when you take
    your eyes off your goal."         -- Henry Ford (1863-1947)

    Change the world! Vote: http://hfopi.org/vote-future

From mpartap at gmx.net  Fri Mar 13 05:12:37 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Fri, 13 Mar 2009 06:12:37 +0100
Subject: [development] An alternative to common thinking in 5->
	6	migration
In-Reply-To: <4a9fdc630903110704u4535ffb8gfeb33570135c1db1@mail.gmail.com>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>	<49B5968A.4020008@gmx.net>
	<200903102204.15810.larry@garfieldtech.com>	<49B78E87.3060000@gmx.net>	<BC22534A-DDC5-4550-A1CC-D7C022A5C9B1@gmail.com>
	<4a9fdc630903110704u4535ffb8gfeb33570135c1db1@mail.gmail.com>
Message-ID: <49B9EB45.2010109@gmx.net>

On 11/03/09 15:04, Khalid Baheyeldin wrote:
> Marcel
>
> You mentioned something more than once in two contexts: having
> requirements and planning beforehand saves time in the long run, and
> your professor in a quality course.
>
> Let me point out again that this is open source and not a corporate
> environment, and hence the difference. Basically everything we assumed
> about how corporate shops work does not work at all, or not as well in
> open source.
>
> Several years ago, when I was with a corporation, we got a professor
> from the top Canadian university to present on requirements. He made the
> point that the more time you spend on requirements the less time you
> will spend on implementation. As an aside, the same concept was being
> touted in the business arena in the 80s as "the Japanese way" of management.
>
> When I asked him how does this apply to open source, and the success it
> had without this lengthy centralized planning. He did not have an answer.
>
> Once you have hundreds and thousands of contributors who never met each
> other, spread across the globe, each scratching their own (or their
> client/employer's) itch, we have a new paradigm (yeah, another
> buzzword). You have organized chaos.
>
> This is also why Agile/Scrum is showing success, as opposed to the
> traditional waterfall method tried and tested for more than half a century.
>
> For us who came from a corporate, or those like you who are still in
> academia, it may be hard to adjust at first. But once you "get it", it
> is a wonderful thing to watch and join.
>
> So, jump in and "Do". Write about it 6 and 12 months from now and see if
> you have changed your mind, and what you learned.
> --
> Khalid M. Baheyeldin
> 2bits.com <http://2bits.com>, Inc.
> http://2bits.com
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. --   Leonardo da Vinci


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mpartap at gmx.net  Fri Mar 13 05:12:49 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Fri, 13 Mar 2009 06:12:49 +0100
Subject: [development] An alternative to common thinking in 5->
	6migration
In-Reply-To: <20090311171626.0b482e4b@dawn.webthatworks.it>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>	<49B7B25A.2060006@gmx.net>
	<20090311171626.0b482e4b@dawn.webthatworks.it>
Message-ID: <49B9EB51.7010906@gmx.net>

> There are already few reviewers for core. Don't expect to have
> reviewers for contrib.
Well the idea was to convert all people currently posessing an SVN 
account the reviewing collective, not getting additional reviewers. Am 
i interested in the modules i have submitted codes for? Sure i am. Am 
i interested in the code quality / functionality of all the other 
modules aswell? YES i AM - because they all affect what and how i can 
use Drupal to accomplish stuff.

> It is clearer how core gains from public review.
> It's not that clear how a maintainer may gain from code review.
No more maintainers, just contributors.
> I'm not talking about quality of code... I'm talking about the
> interest of the maintainers.
Well take them out of the equation.
Anyone in fear of leaving his title as 'maintainer of module foo' 
should be soothed by the opportunity that per-module commit statics 
provide for fame.

> Core and contrib are quite different in terms of speed of
> development, purposes, design, coders sub-communities...
>
> People may use drupal infrastructure just if:
> - They're looking for public review
> - They're looking for co-maintainers
> - They're looking for exposure
> - They just feel "generous" and they think someone else may make good
>    use of their code without bothering them
Well my belief is that enforcing a community process on all developers 
for any D7 might be a good thing, strengthening the community and 
resulting in better code. And i highly doubt just out of pride people 
would take their module code elsewhere just because they won't be the 
sole 'owner' in the d.o repository.

> Release early, release often refers to your users... not to everyone.
> If I can't release early and often for *my users* because someone
> else is not going to review my patch, I'm going to move my stuff
> elsewhere.
Having your experimental code reside in a staging repository until the 
code is ready for being unleashed onto thousands of sites is too much 
of a pain to take?

 > If someone is pushing my module in a direction that
> doesn't fit *my users* I'm going to resist to the change.
Veto the change, comment on your reasoning. Is too bad of a way to 
handle it?

> Very frequently the maintainer of a module is the one that keeps
> contributing the module most.
So uhhm that'd make them 'top contributor' instead of 'guy who holds 
the golden key'.

> You're starting from the unproved assumption that for every
> maintainer code review and exposure are a larger benefit than keep
> on being the steering committee of its own project and that drupal
> benefit more from a supposed increase of code quality and reduction
> in duplication than having a prolific competitive community of
> contributors.
Difficult to answer.. in my opinion most of the stuff that even can be 
done with a website is already available in some form or another as D6 
module. Taking all this great innovative stuff in contrib, there's 
really not much stuff left to be desired. A lot of this code can be 
just migrated to D7, continuing as in past drupal version jumps. But 
having almost every thinkable use case already covered would allow us 
to take a different direction: cleaning up, merging and refactoring 
the existing modules, transplanting good code and skipping 
not-so-good. The competition that has been going on up to now already 
has created a huge pile of excellent stuff to pick from. Why not make 
the decision to not take the huge pile, but only the best part of it?
Also, frameworks for basic shared functionality should be designed in 
a way that makes them as expandable and REPLACEABLE as possible, i.e. 
clear interface definitions.
Having competition on that basic fundamental level of groundwork 
services (the prime examples again: notifications, web forms) in a 
project of this maturity level at least to me does not seem to be a 
good idea- because it REALLY REALLY isn't. Other people have stated 
why they support that statement.

> Otherwise you're heading to balkanization of contrib repositories.
Really have my doubts people would like to use modules that are not 
from the official d.o repository. Having all code committed only after 
quality reviews have been applied is more of an USP than anything other!

> While I agree that natural selection may be suboptimal and
> rationally planning and channelling efforts may achieve better
> results in a shorter time[1]... natural selection is self testing
> and it already happens with no extra effort.
Yeah so at this point we could look back at the pile of code it 
created and transplant ONLY THE GOOD PARTS of it into the D7 repository.

> Other theories have to be proved and require efforts to be put in
> practice.
Well apparently

> Now... if you've something better to substitute to natural selection
> and you can prove it is better, that's just the starting point as
> Laura Scott pointed out at the end of her post.
How can i prove that on my own? From my level of education on the 
object of process and quality management aswell as open source 
communities, i think it does.

> If no one feels your hypothesis is worth a test, provide your own
> test.
I'd gladly do everything i proposed myself (if only to show off) but 
time is the limiting factor again. Maybe i should have used the time 
debating here with people who misunderstand what i am trying to 
communicate to come up with a design draft for a D7 notification API, duh.

> Then maybe you'll reach the point where "d(em)ocracy" and evolution
> sucks and you may start complaining ;)
There's always this tiny fraction of people warning about shit tending 
towards the fan long before shit gets there. Not only the current 
climate change situation is a good example for that. Why is it that 
the majority can never be convinced to listen to such criticism BEFORE 
TSHTF?


> [1] let's turn this into a flamewar about XP vs. waterfall vs.
> academia vs. corporate vs. opensource vs. emacs as well ;)
ok let's try this: xp is to opensource as emacs is to .. ah well no 
let's not.
marcel, tired of a debate not representing his proposal.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From mpartap at gmx.net  Fri Mar 13 05:35:30 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Fri, 13 Mar 2009 06:35:30 +0100
Subject: [development] An alternative to common thinking in 5->
	6	migration
In-Reply-To: <4a9fdc630903110704u4535ffb8gfeb33570135c1db1@mail.gmail.com>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>	<49B5968A.4020008@gmx.net>
	<200903102204.15810.larry@garfieldtech.com>	<49B78E87.3060000@gmx.net>	<BC22534A-DDC5-4550-A1CC-D7C022A5C9B1@gmail.com>
	<4a9fdc630903110704u4535ffb8gfeb33570135c1db1@mail.gmail.com>
Message-ID: <49B9F0A2.3000507@gmx.net>

(uuhm sorry about the former reply that ehh wasn't ready yet.)


> Let me point out again that this is open source and not a corporate
> environment, and hence the difference. Basically everything we assumed
> about how corporate shops work does not work at all, or not as well in
> open source.
Point true 80%. There are comparable situations, in which similar 
methods can successfully be applied.


> When I asked him how does this apply to open source, and the success it
> had without this lengthy centralized planning. He did not have an answer.
> Once you have hundreds and thousands of contributors who never met each
> other, spread across the globe, each scratching their own (or their
> client/employer's) itch, we have a new paradigm (yeah, another
> buzzword). You have organized chaos.
This it in fact very true. This is the great method of success for 
this kind of software. However as the project grows, you get into a 
situation where the chaos gets too big of a mess. Additionally, one 
thing an evolutionary software development process does achieve is 
building experience. Competition also does help in that phase. BUT 
this all takes part with D6 contrib - and is also creating problems. 
These can be solved by applying methods which are meant to filter by 
quality standards - but ONLY because we have such a huge stash of 
already working code to pick from! In the whole D6 cycle, i'd never 
have proposed to restrict code committing, just because of all the 
reasons people have brought up in this discussion!
But because we DO have all that GPLed code available, and a great lot 
of skilled coders, we could now shift focus for D7 from creating 
modules for each use case to _building a structure that can handle 
each use case_. We can do so by selecting from all the great code 
there already is - but the process of careful structural design and 
_selecting good code_ is a procedure that will filter out all the 
(small) issues which have come up in the past such as code 
duplication, disregard of coding standards and low quality. If we want 
D7 to really rock as hard as possible, we surely want to minimize 
these problems. That is the reason why i still believe that overlaying 
a new method onto the drupal project and community as it stands now is 
a viable way to go. This would not have been the case at any point in 
time before - simply because we NEEDED the drastic level of 
competition and free form creativity!

> So, jump in and "Do". Write about it 6 and 12 months from now and see if
> you have changed your mind, and what you learned.
Ok well even though i might seem naive and immature at times, i 
actually have 'done', furthermore always reflect and adapt to reality 
as it is. I have been with this great project for almost a year, 
although with low visibility and only few code inside some of core and 
several modules. But i do have a good understanding of how open source 
projects work, really (duh i use hundreds of them, and contributed to 
a handful - still small stuff though, started programming only two 
years ago.. but getting better ;). Sometimes it really *is* all about 
the color of the damn bike shed ^ ^
regards marcel.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From drupal at dwwright.net  Fri Mar 13 06:10:25 2009
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 12 Mar 2009 23:10:25 -0700
Subject: [development] "Accepted" status for issues
In-Reply-To: <49B5493D.1000803@citris-uc.org>
References: <DC3A651F-512D-4A14-AC09-F7854D9236B8@gmail.com>
	<20090308093131.oi37d7htrn4sg8c8@mail.progw.org>
	<2104F763-5C34-4AC4-BEAB-5FA8BA28E264@dwwright.net>
	<49B5493D.1000803@citris-uc.org>
Message-ID: <579387E2-44C4-4562-9DBD-E08F6DE7C9AF@dwwright.net>


On Mar 9, 2009, at 9:52 AM, Tao Starbow wrote:

> I like the idea of managing my list with issue tags.  We'd just need  
> to be able to see them in the table at http://drupal.org/project/ 
> user, and filter by them.  Is there an open issue for this?

Filter, yes:

http://drupal.org/node/389096

Display: not so sure -- there are already complaints that the issue  
tables are way too wide as it is.  I spoke with Mark Boulton in DC  
about redesigning the issue queue tables (something they spent 0  
effort on during their original redesign efforts).  It's a hard  
problem, and he said he wants to think about it more before making any  
specific recommendations to me and the other redesign implementors.

So, for now, the idea is just that you'd be able to filter issues via  
an autocomplete text field, but the tags themselves on the issue  
wouldn't (yet) be displayed in the huge table.  We'd add the tags  
later when we have a good plan for the whole experience.

Cheers,
-Derek (dww)




From drupal at samboyer.org  Fri Mar 13 08:01:37 2009
From: drupal at samboyer.org (Sam Boyer)
Date: Fri, 13 Mar 2009 03:01:37 -0500
Subject: [development] An alternative to common thinking in 5->
	6migration
In-Reply-To: <49B9EB51.7010906@gmx.net>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
	<20090311171626.0b482e4b@dawn.webthatworks.it>
	<49B9EB51.7010906@gmx.net>
Message-ID: <200903130301.41062.drupal@samboyer.org>


On Friday 13 March 2009 00:12:49 Marcel Partap wrote:
> marcel, tired of a debate not representing his proposal.

While I agree with most of the sentiments expressed by Kyle, catch, sun, 
Khalid, Earnie, Anton, Crell, Ivan, Andrew, Earl, and Laura, out of everything 
you've written, I find this part most unsettling. It suggests a deep ignorance 
of how communities like ours work. The community has heard you; whether or not 
we heard what you intended us to is _no longer in your realm of control_. 
Debate may get your point across in school or small groups, but that's not how 
communities work. Ideas take off only when  community members get to own and 
interpret the ideas on their own terms, with respect to their own experience; 
badgering people for doing so is exactly the wrong approach. Personally, I find 
your apparent ignorance of this basic community dynamic to be sufficient 
evidence for not trusting you as a community captain. 

Keep in mind that this is coming from a guy who's spent the better part of a 
year planning, proposing, and advocating group decisionmaking systems for 
drupal. 

So, let me second Larry:

Please, stop.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.drupal.org/pipermail/development/attachments/20090313/ad04bfa7/attachment.pgp>

From mpartap at gmx.net  Fri Mar 13 14:57:11 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Fri, 13 Mar 2009 15:57:11 +0100
Subject: [development] An alternative to common thinking in
	5->	6migration
In-Reply-To: <200903130301.41062.drupal@samboyer.org>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>	<20090311171626.0b482e4b@dawn.webthatworks.it>	<49B9EB51.7010906@gmx.net>
	<200903130301.41062.drupal@samboyer.org>
Message-ID: <49BA7447.5050902@gmx.net>

> evidence for not trusting you as a community captain.
Never did i strive to be any kind of captain, i just tried to help 
with an existing issue that happens to annoy me (and seemingly others).
Guess the next time i'm trying to convince anyone of anything i'll 
make sure to bring the examples upfront (instead of at the end of a 
discussion) so there is no place to be misunderstood in the first place.

> Please, stop.
Fine. You (sceptics) win, i loose. Better luck next time.

regards marcel.

From kb at 2bits.com  Fri Mar 13 15:08:17 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Fri, 13 Mar 2009 11:08:17 -0400
Subject: [development] An alternative to common thinking in 5->
	6migration
In-Reply-To: <49BA7447.5050902@gmx.net>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>
	<20090311171626.0b482e4b@dawn.webthatworks.it>
	<49B9EB51.7010906@gmx.net> <200903130301.41062.drupal@samboyer.org>
	<49BA7447.5050902@gmx.net>
Message-ID: <4a9fdc630903130808i48d300fbw5a84f3b8ef003e7a@mail.gmail.com>

On Fri, Mar 13, 2009 at 10:57 AM, Marcel Partap <mpartap at gmx.net> wrote:

> Please, stop.
>>
> Fine. You (sceptics) win, i loose. Better luck next time.
>


This is not a win or lose situation.

Get involved, contribute, understand the project and community better, then
reevaluate your stance in light of what you learned.

Then see if you still hold the same view or you change your view.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090313/921f0fae/attachment.htm>

From mpartap at gmx.net  Fri Mar 13 15:27:33 2009
From: mpartap at gmx.net (Marcel Partap)
Date: Fri, 13 Mar 2009 16:27:33 +0100
Subject: [development] An alternative to common thinking in
	5->	6migration
In-Reply-To: <4a9fdc630903130808i48d300fbw5a84f3b8ef003e7a@mail.gmail.com>
References: <067a01c9a23f$a23f0c10$0200a8c0@structworks.com>	<20090311171626.0b482e4b@dawn.webthatworks.it>	<49B9EB51.7010906@gmx.net>
	<200903130301.41062.drupal@samboyer.org>	<49BA7447.5050902@gmx.net>
	<4a9fdc630903130808i48d300fbw5a84f3b8ef003e7a@mail.gmail.com>
Message-ID: <49BA7B65.6080907@gmx.net>

> Get involved, contribute, understand the project and community better,
That i have done for one year. How that is not sufficient i do not 
see. And i don't open my mouth that wide if i can not provide solid 
and thoroughly reflected reasoning for my points, which i tried to.

> then reevaluate your stance in light of what you learned.
Constantly doing that, but i would be highly surprised if history 
would really prove me wrong. However of course i'd be more than ready 
to accept that.
regards marcel.


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

From victorkane at gmail.com  Fri Mar 13 16:29:52 2009
From: victorkane at gmail.com (Victor Kane)
Date: Fri, 13 Mar 2009 09:29:52 -0700
Subject: [development] An alternative to common thinking in 5->6
	migration
In-Reply-To: <49B5968A.4020008@gmx.net>
References: <NCEKJGCAHKMOLJLHNKLJAEAIEMAA.nan_wich@bellsouth.net>
	<49B54F91.2060108@favias.org> <49B55307.3000702@gmx.net>
	<45811f70903091430y7e5ba261j2287c8ee488f5a51@mail.gmail.com>
	<49B5968A.4020008@gmx.net>
Message-ID: <ff176450903130929j445f7aa2n6aa99d5c6edf7abb@mail.gmail.com>

Marcel, Drupal uses your idea on Drupal core.

But we aren't linux and wine, we have a core and then a constellation of
contrib.

Best stuff then bubbles up through contrib (example is part of views and cck
going into core for Drupal 7)... contrib is a test tube, a source forge
(which works really well by committing mind farts and then folks vote by
using or not using, community actually decides best quality).
That way we get the most creativity, and the community decides in their
use/reuse/discard attitude towards the modules.

A thousand eyes of feature hungry users informs better than one pair of
expert eyes.

And frees up the expert to do his thing too, instead of bureaucratizing
contrib.

That's the Drupal way, and it rocks (for this particular application)!

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com

On Mon, Mar 9, 2009 at 3:22 PM, Marcel Partap <mpartap at gmx.net> wrote:

> Marcel, I don't know if you've noticed but you haven't managed to
>> visibly convince anyone your solution is a good one.
>>
> Well yes i do have noticed. Apart from 'don't like it' and 'messes
> with our ways' i have not heard any sound counter arguments though,
> but that might well be enough of an argument by itself in such a
> community project.
>
>  Especially not anyone who will bother to try and implement it.
>>
> Well if we all wanted to, we could make it. Easily: it's just a matter
> of breaking habits, and not even that drastically. Btw it works for
> other projects (linux, wine).
>
>  On the contrary, you have a whole host of people saying it isn't a
>> good idea and giving reasons why.
>>
> Like 'nah dont like'. (Almost) noone even picked my arguments in favor
> of such a process, or tried to think up how it could be made to work, or
> even propose something entirely different.
>
>  These people (not me mind you) are the dedicated volunteers that do
>> actually work hard to implement solutions to Drupals problems, and
>> are each in their own way personally responsible for the current
>> success of Drupal today.
>>
> Well of course but i really missed some voices from those high-profile
> developers. BTW nothing would change for them, especially no increase in
> work-load.
>
>  They do understand the background and developer culture of the
>> community, and the reasons behind Drupals success.
>>
> So that implies i don't do that, which is wrong. But to truly achieve
> excellence, sometimes you have to trade in a bad habit (casual
> developers committing code to the central repository) for a bitter
> pill (having all code not from already proven drupal master minds
> undergo a transparent quality screening) for long term profit (cure
> the contrib). It's simply people not liking bitter pills until they
> suffer severely from their sickness.. totally human.
>
>  Don't take this personally
>>
> Course not, but i would have hoped for some support. Without any
> community backing surely my idea does sound silly.
>
>  but your idea and justifications for it have an air of either ivory
>> tower academia or heavyweight process driven enterprise thinking
>> about them.
>>
> Well it's not that my proposal is totally unrealistic. Only because no
> one is supporting it does it become so. Would Dries or Angela have
> proposed it, everybody and his dog would be up in flames of enthusiasm
> and surely consider it the right way to go.
>
>  Neither of which have a very good track record of actually getting
>> things done in a volunteer driven open source community where
>> inspiration and enthusiasm is the biggest driver behind doing
>> anything.
>>
> Who is trying to stop that. By preventing bull sh1t code from being
> committed to the official contrib? C'mon! We could easily set up a
> testing repository, set up a drupal-patches mailing list and nice up
> the issue tracker to facilitate more code centric work on stuff.
>
>  The rate of progress in both Drupal and the supporting
>> infrastructure over that time has been staggering.
>>
> Yes, true. So with all that gained, how are we possibly going to loose
> it through tighter quality management?
>
>  It's a tall order claiming that the environment or culture that
>> achieved that success is broken - especially since people have come
>> along and announced that plenty of times in the past.
>>
> I didn't say it's broken, it just allows unlucky stuff to happen.
> Modifying it a bit could solve the problem for good. Not that this
> step is _required_, but maybe we as a *software* project would _profit_
> from it.
>
>  Why should that claim be correct now, when it has been shown to be
>> false in the past?
>>
> A major core redesign is the best time to make these modifications.
> Why i proposed these changes i hope i have explained sufficiently.
>
>  Your proposal to have every D7 contrib commit vetted by some sort
>> of vote would just drive away the very enthusiasm and inspiration
>> that drew in all the newbie contrib developers that grew up into
>> veteran developers and core contributers (and that would be the
>> single best way to kill Drupal).
>>
> Ahem, no. Why would anyone insist on committing every mind fart to the
> official drupal repository? Heck as stated above, how hard is it to
> have a staging branch?
> The main motivation to even waste my time in this discussion was to
> find a solution to the problems mentioned in the original posting:
>
>> - modules spamming the watchdog table with E_ALL warnings
>> - modules ignoring the style/documentation guide lines
>> - applied insane programming(TM) techniques
>> - undescriptive module names
>> - duplication (partial feature overlap with existing modules).
>>
> If anyone has a more viable solution at hand, i'm more than willing to
> surrender my effort to their proposal. Right now all i've heard is votes for
> natural selection. Surely that is one approach to it, but at least not my
> favorite.
> Also, almost every possible use case is covered by one or the other D6
> module, making that 'no more innovation' argument really not that
> convincing. What is the point of producing D7 at all? Restructuring! How is
> that case invalid for non-core modules, simply don't see it.
> Furthermore, simply don't like the fact that individuals hold the keys to
> modules. The linux kernel f.e. handles this very differently: contributors
> get mentioned in the file header.
> Really, the linux approach of development is what i think drupal should
> hand pick some points from.
>
> > I certainly wouldn't bother releasing any Drupal
>
>> 7 modules if that were the case.
>>
> You must be kidding.
> > And for a lot of modules (eg my
>
>> own), they simply don't have a user base capable of evaluating the
>> quality of the commit
>>
> Code voting for developers only of course - sure all this needs
> implementing. Where's a will, there's a way.
>
>  In nearly all cases, the people doing the voting will know
>> far less about coding or the internals of the module than the
>> author. It won't change much in terms of code quality - it will
>> just add frustration to everyones experience.
>>
> Noone wants that, not even crazy me. But my belief still is: if we really
> want to find a way to improve the process, we can do it. If i stand alone,
> this is not a fight i'll waste my blood on.
>
> BTW, i really wished i had the time to code all the stuff i'd like to, but
> obligations (you know.. school, work and stuff *g) shrink my visions to
> small compact pressed clumps that lay around. It would simply need some
> outside support to inflate them again, but convincing people to support
> something unknown nowadays doesn't seem to be too easy. Ah well.. back to
> work, the profane.
> regards
>
>
>
> --
>  "Obstacles are those frightful things you see when you take
>  your eyes off your goal."         -- Henry Ford (1863-1947)
>
>  Change the world! Vote: http://hfopi.org/vote-future
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090313/5bb6517f/attachment-0001.htm>

From jayllo at gmail.com  Sat Mar 14 22:57:46 2009
From: jayllo at gmail.com (Jay Liu)
Date: Sat, 14 Mar 2009 18:57:46 -0400
Subject: [development] Drupal & Database layout
Message-ID: <FCDE4DC75AFA4E0D9FAD3BFC7FB295A4@Duel>

Hi All,

 

I'd like to write to the drupal database using a Java-Hibernate mapping
however, I can't find any database design documentation.

I guess I just need to know what inserts into which tables when you create a
front page posting.

I'm not a php programmer so I don't have an idea how to go about browsing
through the code.

 

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090314/b488d5f5/attachment.htm>

From jpetso at gmx.at  Sun Mar 15 00:22:29 2009
From: jpetso at gmx.at (Jakob Petsovits)
Date: Sun, 15 Mar 2009 01:22:29 +0100
Subject: [development] Drupal & Database layout
In-Reply-To: <FCDE4DC75AFA4E0D9FAD3BFC7FB295A4@Duel>
References: <FCDE4DC75AFA4E0D9FAD3BFC7FB295A4@Duel>
Message-ID: <200903150122.30448.jpetso@gmx.at>

On Saturday 14 March 2009, Jay Liu wrote:
> I'd like to write to the drupal database using a Java-Hibernate mapping
> however, I can't find any database design documentation.
>
> I guess I just need to know what inserts into which tables when you create
> a front page posting.

The canonical reference is the one that comes with the modules themselves:
the Schema API descriptions in the .install files. You can conveniently browse 
those in the admin area of your site by installing the Schema module.

I also found a graph that might be interesting to you:
http://drupal.org/node/184586
http://www.typo.co.il/~mooffie/tmp/schemagraph/output/

Hope that helps, cheers,
  Jakob


From adam.j.cooper at gmail.com  Sun Mar 15 18:42:25 2009
From: adam.j.cooper at gmail.com (Adam Cooper)
Date: Sun, 15 Mar 2009 18:42:25 +0000
Subject: [development] Loading configuration using 'SERVER_NAME' as opposed
	to 'HTTP_HOST'
Message-ID: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>

Hello all,

It's a (very) long time since I posted to this list. So please excuse  
me if I'm breaking etiquette. I'm attempting to set up a development  
environment that suits my way of working. Using a VMware virtual  
machine (that is as close a replica to my VPS as possible) I've set up  
an apache instance and am adding virtual hosts to it as I go. Up until  
now I've had no issue bring across my current sites. They all are  
single sites and so have been set up in the 'default' configuration. I  
can add an entry to my host machines hosts file (say 'sitename.dev')  
and everything works great.

The problem now is that I have come across one of my multisite  
configurations. I figured I could just set the virtual host  
configuration to have ServerName as my site name (sitename) and then  
ServerAlias in the name I would be accessing it as (sitename.dev).  
Setting UseCanonicalName to 'on' would let me access the site as I  
would expect.

Except, despite this setting SERVER_NAME to the value I expect  
(sitename) my drupal configuration refuses to load. I took a look in  
the bootstrap file and found that the configuration directory is  
loaded from HTTP_HOST.

TL;DR.

So my question is this, why does drupal load it's configuration using  
HTTP_HOST as opposed to SERVER_NAME? Surely SERVER_NAME would allow  
more flexibility and more direct control? Would a patch changing this  
have any chance of being looked at?

Thanks
Adam

From cog.rusty at gmail.com  Sun Mar 15 20:41:03 2009
From: cog.rusty at gmail.com (Cog Rusty)
Date: Sun, 15 Mar 2009 22:41:03 +0200
Subject: [development] Loading configuration using 'SERVER_NAME' as
	opposed to 'HTTP_HOST'
In-Reply-To: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
Message-ID: <a08ea0280903151341y26f002c3m8cfa9d16444dd025@mail.gmail.com>

On Sun, Mar 15, 2009 at 8:42 PM, Adam Cooper <adam.j.cooper at gmail.com> wrote:
> Hello all,
>
> It's a (very) long time since I posted to this list. So please excuse me if
> I'm breaking etiquette. I'm attempting to set up a development environment
> that suits my way of working. Using a VMware virtual machine (that is as
> close a replica to my VPS as possible) I've set up an apache instance and am
> adding virtual hosts to it as I go. Up until now I've had no issue bring
> across my current sites. They all are single sites and so have been set up
> in the 'default' configuration. I can add an entry to my host machines hosts
> file (say 'sitename.dev') and everything works great.
>
> The problem now is that I have come across one of my multisite
> configurations. I figured I could just set the virtual host configuration to
> have ServerName as my site name (sitename) and then ServerAlias in the name
> I would be accessing it as (sitename.dev). Setting UseCanonicalName to 'on'
> would let me access the site as I would expect.
>
> Except, despite this setting SERVER_NAME to the value I expect (sitename) my
> drupal configuration refuses to load. I took a look in the bootstrap file
> and found that the configuration directory is loaded from HTTP_HOST.
>
> TL;DR.
>
> So my question is this, why does drupal load it's configuration using
> HTTP_HOST as opposed to SERVER_NAME? Surely SERVER_NAME would allow more
> flexibility and more direct control? Would a patch changing this have any
> chance of being looked at?


Generally, for Drupal multisites to work under different Apache
configurations, Drupal needs to rely more on the client's HTTP request
rather than the server configuration. You can see a related issue in
http://drupal.org/node/262920


> Thanks
> Adam
>

From mike at mikeyp.net  Sun Mar 15 23:23:13 2009
From: mike at mikeyp.net (Michael Prasuhn)
Date: Sun, 15 Mar 2009 16:23:13 -0700
Subject: [development] Loading configuration using 'SERVER_NAME' as
	opposed to 'HTTP_HOST'
In-Reply-To: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
Message-ID: <0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>

While this may be less clean than desired, how about a symlink from  
drupal/sites/sitename.dev to drupal/sites/sitename.com ?

Surely this would achieve a similar result with no downside to that  
being deployed on the server.

-Mike

__________________
Michael Prasuhn
503.488.5433 office
714.356.0168 cell
503.661.7574 home
mike at mikeyp.net
http://mikeyp.net






From federico.maggi at gmail.com  Mon Mar 16 05:21:32 2009
From: federico.maggi at gmail.com (Maggi Federico)
Date: Sun, 15 Mar 2009 22:21:32 -0700
Subject: [development] grepping for relevant functions/lines
Message-ID: <93F83D93-223E-4945-A2D7-E6B3DB1DA6F2@gmail.com>

Hello List,
	I am new to Drupal and new to this list.

For research purposes, I am surveying code repositories of the top 10  
web applications using a modified version of StatSVN.

Basically, I need to track source changes, over releases, in terms of  
"Lines of Code (LOC) matching a certain regexp".

The functions/lines I am interested in are those somehow involved in  
handling HTTP request/session/response parameters. Of course, I allow  
a certain roughness in the analysis.

I am trying to build a list of such functions/lines. What would you  
suggest to include? What would you grep for if you want to estimate  
the functions that are, even indirectly, related to processing of HTTP  
requests/sessions/responses?

Any input is greatly appreciated. Thanks in advance. Cheers,

-- Federico

From earnie at users.sourceforge.net  Mon Mar 16 11:44:12 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 16 Mar 2009 07:44:12 -0400
Subject: [development] Loading configuration using 'SERVER_NAME'
	as	opposed to 'HTTP_HOST'
In-Reply-To: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
Message-ID: <20090316074412.5f3edvg5uds8cwg0@mail.progw.org>

Quoting Adam Cooper <adam.j.cooper at gmail.com>:

This is more a support question and should be on the support list but 
see below.

>
> The problem now is that I have come across one of my multisite  
> configurations. I figured I could just set the virtual host  
> configuration to have ServerName as my site name (sitename) and then  
> ServerAlias in the name I would be accessing it as (sitename.dev).  
> Setting UseCanonicalName to 'on' would let me access the site as I  
> would expect.
>
> Except, despite this setting SERVER_NAME to the value I expect  
> (sitename) my drupal configuration refuses to load. I took a look in  
> the bootstrap file and found that the configuration directory is  
> loaded from HTTP_HOST.
>

Usually I find the issue with this stems from the fact that the strings 
for the site directory in sites/ cannot be constructed from the 
HTTP_HOST string.  I usually resolve this issue with symlinks to match 
what is expected.  For instance www.sample.com vs sample.com and I 
created a www.sample.com directory under sites.

> TL;DR.
>
> So my question is this, why does drupal load it's configuration using 
>  HTTP_HOST as opposed to SERVER_NAME? Surely SERVER_NAME would allow  
> more flexibility and more direct control? Would a patch changing this 
>  have any chance of being looked at?
>

My question back to you is why isn't HTTP_HOST properly setup?

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From adam.j.cooper at gmail.com  Mon Mar 16 09:39:47 2009
From: adam.j.cooper at gmail.com (Adam Cooper)
Date: Mon, 16 Mar 2009 09:39:47 +0000
Subject: [development] Loading configuration using 'SERVER_NAME' as
	opposed to 'HTTP_HOST'
In-Reply-To: <0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
Message-ID: <04A5D624-3FBB-48E0-B1F4-9EC4A99C5A8A@gmail.com>

> While this may be less clean than desired, how about a symlink from  
> drupal/sites/sitename.dev to drupal/sites/sitename.com ?

This had been my first thought and will probably end up being my  
solution (though as you said it is not as clean as I had hoped).

I had posted this question in order to gauge why things are done the  
way they are and if there was any scope for change.

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 cog.rusty at gmail.com  Mon Mar 16 15:49:56 2009
From: cog.rusty at gmail.com (Cog Rusty)
Date: Mon, 16 Mar 2009 17:49:56 +0200
Subject: [development] Loading configuration using 'SERVER_NAME' as
	opposed to 'HTTP_HOST'
In-Reply-To: <04A5D624-3FBB-48E0-B1F4-9EC4A99C5A8A@gmail.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
	<04A5D624-3FBB-48E0-B1F4-9EC4A99C5A8A@gmail.com>
Message-ID: <a08ea0280903160849r1d7abd5eqfbc91d6fcfbf4ba5@mail.gmail.com>

On Mon, Mar 16, 2009 at 11:39 AM, Adam Cooper <adam.j.cooper at gmail.com> wrote:
>> While this may be less clean than desired, how about a symlink from
>> drupal/sites/sitename.dev to drupal/sites/sitename.com ?
>
> This had been my first thought and will probably end up being my solution
> (though as you said it is not as clean as I had hoped).
>
> I had posted this question in order to gauge why things are done the way
> they are and if there was any scope for change.


To expand a bit on my first answer, I think it is not desirable to
have the right names for the directories under /sites depend on
whether you have set UseCanonicalName to On or Off to match the
ServerName or the ServerAlias. Most users have no control over this
settings and are not even aware of its existence.

The right names for the directories under /sites should follow some
simple unconditional rules, and using HTTP_HOST allows that and
provides the maximum flexibility.


> 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 adam.j.cooper at gmail.com  Mon Mar 16 18:40:42 2009
From: adam.j.cooper at gmail.com (Adam Cooper)
Date: Mon, 16 Mar 2009 18:40:42 +0000
Subject: [development] Loading configuration using 'SERVER_NAME' as
	opposed to 'HTTP_HOST'
In-Reply-To: <20090316074412.5f3edvg5uds8cwg0@mail.progw.org>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<20090316074412.5f3edvg5uds8cwg0@mail.progw.org>
Message-ID: <F0F62DF6-064D-4035-8B03-7B88116A50B4@gmail.com>

> This is more a support question and should be on the support list  
> but see below.

Granted this is could be a support issue, but I had intended to  
(mostly) gauge the validity of a patch to core. Is that not a  
development question?

> My question back to you is why isn't HTTP_HOST properly setup?

AFAICT it is functioning exactly as designed. It returns the value of  
the Host: header as sent by the client. Numerous experiments with  
phpinfo() have confirmed that.

According to the apache docs (and confirmed by the above mentioned  
experiments) if UseCanonicalName is set to 'off' the SERVER_NAME  
variable is set to equal HTTP_HOST. This works great in most all  
cases. If UseCanonicalName is set to 'on' then SERVER_NAME is set to  
whatever 'ServerName' is set to in the apache conf. Seeing as  
UseCanonicalName can be set in the virtual host entry there is no  
problem doing something like this:

<VirtualHost *:80>
	UseCanonicalName On

	ServerName hostname.com
	ServerAlias hostname.dev
</VirtualHost>

If Drupal used the SERVER_NAME variable then accessing the site should  
load the hostname.com configuration regardless of what alias is  
accessed. Seeing as it uses HTTP_HOST it will fail to load a  
configuration.

> Generally, for Drupal multisites to work under different Apache
> configurations, Drupal needs to rely more on the client's HTTP request
> rather than the server configuration. You can see a related issue in
> http://drupal.org/node/262920

I suppose it's swings and roundabouts really. Using HTTP_HOST provides  
a globally predictable outcome. But if the user has access to the  
apache configuration, either by support request or personally, then  
SERVER_NAME provides a more configurable outcome.

I guess I'll just stick with symlinks (they can always be excluded  
from the version control anyway).

Thanks
Adam


From cog.rusty at gmail.com  Mon Mar 16 19:30:26 2009
From: cog.rusty at gmail.com (Cog Rusty)
Date: Mon, 16 Mar 2009 21:30:26 +0200
Subject: [development] Loading configuration using 'SERVER_NAME' as
	opposed to 'HTTP_HOST'
In-Reply-To: <F0F62DF6-064D-4035-8B03-7B88116A50B4@gmail.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<20090316074412.5f3edvg5uds8cwg0@mail.progw.org>
	<F0F62DF6-064D-4035-8B03-7B88116A50B4@gmail.com>
Message-ID: <a08ea0280903161230o166e1794we93ab40c93ed1e5c@mail.gmail.com>

On Mon, Mar 16, 2009 at 8:40 PM, Adam Cooper <adam.j.cooper at gmail.com> wrote:
>> This is more a support question and should be on the support list but see
>> below.
>
> Granted this is could be a support issue, but I had intended to (mostly)
> gauge the validity of a patch to core. Is that not a development question?
>
>> My question back to you is why isn't HTTP_HOST properly setup?
>
> AFAICT it is functioning exactly as designed. It returns the value of the
> Host: header as sent by the client. Numerous experiments with phpinfo() have
> confirmed that.
>
> According to the apache docs (and confirmed by the above mentioned
> experiments) if UseCanonicalName is set to 'off' the SERVER_NAME variable is
> set to equal HTTP_HOST. This works great in most all cases. If
> UseCanonicalName is set to 'on' then SERVER_NAME is set to whatever
> 'ServerName' is set to in the apache conf. Seeing as UseCanonicalName can be
> set in the virtual host entry there is no problem doing something like this:
>
> <VirtualHost *:80>
> ? ? ? ?UseCanonicalName On
>
> ? ? ? ?ServerName hostname.com
> ? ? ? ?ServerAlias hostname.dev
> </VirtualHost>
>
> If Drupal used the SERVER_NAME variable then accessing the site should load
> the hostname.com configuration regardless of what alias is accessed. Seeing
> as it uses HTTP_HOST it will fail to load a configuration.
>
>> Generally, for Drupal multisites to work under different Apache
>> configurations, Drupal needs to rely more on the client's HTTP request
>> rather than the server configuration. You can see a related issue in
>> http://drupal.org/node/262920
>
> I suppose it's swings and roundabouts really. Using HTTP_HOST provides a
> globally predictable outcome. But if the user has access to the apache
> configuration, either by support request or personally, then SERVER_NAME
> provides a more configurable outcome.


Maybe using SERVER_NAME can be considered more configurable on the
server's side, but not on Drupal's side. It makes Drupal's
configuration more dependent on the server's settings, which could
puzzle many people. Using HTTP_HOST the domain can be whatever you
want as long as you can point it to Drupal's index.php by any means
which don't alter the HTTP request.


> I guess I'll just stick with symlinks (they can always be excluded from the
> version control anyway).
>
> Thanks
> Adam
>
>

From earnie at users.sourceforge.net  Mon Mar 16 19:48:08 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 16 Mar 2009 15:48:08 -0400
Subject: [development] Loading configuration using 'SERVER_NAME'
	as	opposed to 'HTTP_HOST'
In-Reply-To: <F0F62DF6-064D-4035-8B03-7B88116A50B4@gmail.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<20090316074412.5f3edvg5uds8cwg0@mail.progw.org>
	<F0F62DF6-064D-4035-8B03-7B88116A50B4@gmail.com>
Message-ID: <20090316154808.1l5jiib1qtdwgcsc@mail.progw.org>

Quoting Adam Cooper <adam.j.cooper at gmail.com>:

>> This is more a support question and should be on the support list  
>> but see below.
>
> Granted this is could be a support issue, but I had intended to  
> (mostly) gauge the validity of a patch to core. Is that not a  
> development question?
>

These types of questions are presented more as a feature request in an 
issue queue.

>> My question back to you is why isn't HTTP_HOST properly setup?
>
> AFAICT it is functioning exactly as designed. It returns the value of 
>  the Host: header as sent by the client. Numerous experiments with  
> phpinfo() have confirmed that.
>
> According to the apache docs (and confirmed by the above mentioned  
> experiments) if UseCanonicalName is set to 'off' the SERVER_NAME  
> variable is set to equal HTTP_HOST. This works great in most all  
> cases. If UseCanonicalName is set to 'on' then SERVER_NAME is set to  
> whatever 'ServerName' is set to in the apache conf. Seeing as  
> UseCanonicalName can be set in the virtual host entry there is no  
> problem doing something like this:
>
> <VirtualHost *:80>
> 	UseCanonicalName On
>
> 	ServerName hostname.com
> 	ServerAlias hostname.dev
> </VirtualHost>
>

Based on the http://drupal.org/node/262920 issue sited below changing to

<VirtualHost *:80>
	UseCanonicalName Off

	ServerName hostname.dev
	ServerAlias hostname.com
</VirtualHost>

Should work for you.

> If Drupal used the SERVER_NAME variable then accessing the site 
> should  load the hostname.com configuration regardless of what alias 
> is  accessed. Seeing as it uses HTTP_HOST it will fail to load a  
> configuration.
>

I don't dislike your proposal maybe a combination of the two would be a 
good solution with HTTP_HOST being used first.  Work up a patch for D7 
and see where it goes.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From earnie at users.sourceforge.net  Mon Mar 16 19:56:14 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 16 Mar 2009 15:56:14 -0400
Subject: [development] Loading configuration using 'SERVER_NAME'
	as	opposed to 'HTTP_HOST'
In-Reply-To: <a08ea0280903161230o166e1794we93ab40c93ed1e5c@mail.gmail.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<20090316074412.5f3edvg5uds8cwg0@mail.progw.org>
	<F0F62DF6-064D-4035-8B03-7B88116A50B4@gmail.com>
	<a08ea0280903161230o166e1794we93ab40c93ed1e5c@mail.gmail.com>
Message-ID: <20090316155614.1c9leoyij68800o0@mail.progw.org>

Quoting Cog Rusty <cog.rusty at gmail.com>:

>> <VirtualHost *:80>
>>        UseCanonicalName On
>>
>>        ServerName hostname.com
>>        ServerAlias hostname.dev
>> </VirtualHost>
>>
--8<--
> Maybe using SERVER_NAME can be considered more configurable on the
> server's side, but not on Drupal's side. It makes Drupal's
> configuration more dependent on the server's settings, which could
> puzzle many people. Using HTTP_HOST the domain can be whatever you
> want as long as you can point it to Drupal's index.php by any means
> which don't alter the HTTP request.
>

The problem isn't getting to index.php the problem is getting to 
sites/hostname.com from a request for hostname.dev.  If SERVER_NAME is 
also considered but after HTTP_HOST then we have the best of both 
worlds.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From steve at yelvington.com  Mon Mar 16 23:44:14 2009
From: steve at yelvington.com (Steve Yelvington)
Date: Mon, 16 Mar 2009 19:44:14 -0400
Subject: [development] Best place to store user data
Message-ID: <49BEE44E.5060709@yelvington.com>

Awhile back I wrote a simple module to fetch my Facebook status line, 
using an open RSS feed, and make a block to display on my blog. The 
fetched data is stored in cache for a limited period.
http://drupal.org/project/fbstatus

I've received a number of requests to upgrade the module to support 
multi-user scenarios. In such a case, cache obviously isn't the right 
place to put the data.

But since there should be no more than  one Facebook account per user, 
it seemed that creating a table (as seen in the Twitter module) would be 
overkill.

So I began looking at using profile fields (requiring profile.module) or 
the serialized user data.

But I'm likely to move the updates into hook_cron, and I can imagine a 
large site having to step through the whole user base, looking for 
statuses needing updates.

So now I'm back at a discrete table.

Is my thinking right?



From larry at garfieldtech.com  Tue Mar 17 00:13:46 2009
From: larry at garfieldtech.com (Larry Garfield)
Date: Mon, 16 Mar 2009 19:13:46 -0500
Subject: [development] Best place to store user data
In-Reply-To: <49BEE44E.5060709@yelvington.com>
References: <49BEE44E.5060709@yelvington.com>
Message-ID: <200903161913.46924.larry@garfieldtech.com>

On Monday 16 March 2009 6:44:14 pm Steve Yelvington wrote:
> Awhile back I wrote a simple module to fetch my Facebook status line,
> using an open RSS feed, and make a block to display on my blog. The
> fetched data is stored in cache for a limited period.
> http://drupal.org/project/fbstatus
>
> I've received a number of requests to upgrade the module to support
> multi-user scenarios. In such a case, cache obviously isn't the right
> place to put the data.

Why obviously?  Cache is for non-persistent data that is expensive to generate 
or retrieve but that you want to have fast access to.  Locally caching 
facebook data seems perfectly reasonable for that.

> But since there should be no more than  one Facebook account per user,
> it seemed that creating a table (as seen in the Twitter module) would be
> overkill.

Why?  There are tons of modules that add one table per user or per node in 
order to extend those entities.  That's the way modules are supposed to work.  
It's why hook_nodeapi op load and hook_user op load exist.  

> So I began looking at using profile fields (requiring profile.module) or
> the serialized user data.

Do not use $user->data.  It's only kept around as a booby trap to break the 
brains of unsuspecting new developers with strange and obscure bugs they do 
not understand.  

Profile.module is not much better, and is hopefully slated for execution in 
Drupal 7.

> But I'm likely to move the updates into hook_cron, and I can imagine a
> large site having to step through the whole user base, looking for
> statuses needing updates.
>
> So now I'm back at a discrete table.
>
> Is my thinking right?

Nothing wrong with a discrete table or the cache in this case.  The main 
question is whether you want to lazy-fetch data on users (and therefore have 
an easy "rebuild all" command; just empty the appropriate cache table) and 
then not be able to query directly against the local data, or want to have to 
maintain your own data tables and handle synchronization of data but have 
persistent, easily-queried-against local tables you could even expose to 
Views.  (Oooo...)

Either way works.  Off the cuff I'd probably go for the discrete table myself, 
but there are good arguments either way.

-- 
Larry Garfield
larry at garfieldtech.com

From steinwrites4u at yahoo.com  Tue Mar 17 00:35:26 2009
From: steinwrites4u at yahoo.com (David Stein)
Date: Mon, 16 Mar 2009 17:35:26 -0700 (PDT)
Subject: [development] Loading configuration using 'SERVER_NAME' as
	opposed to 'HTTP_HOST'
In-Reply-To: <F0F62DF6-064D-4035-8B03-7B88116A50B4@gmail.com>
Message-ID: <352602.58944.qm@web63801.mail.re1.yahoo.com>

Hi
please please? i need to unsubscribe to drupal
help me? their protocols do not work
Thanks?? David stein

--- On Mon, 3/16/09, Adam Cooper <adam.j.cooper at gmail.com> wrote:

From: Adam Cooper <adam.j.cooper at gmail.com>
Subject: Re: [development] Loading configuration using 'SERVER_NAME' as opposed to 'HTTP_HOST'
To: development at drupal.org
Date: Monday, March 16, 2009, 2:40 PM

> This is more a support question and should be on the support list but see
below.

Granted this is could be a support issue, but I had intended to (mostly) gauge
the validity of a patch to core. Is that not a development question?

> My question back to you is why isn't HTTP_HOST properly setup?

AFAICT it is functioning exactly as designed. It returns the value of the Host:
header as sent by the client. Numerous experiments with phpinfo() have confirmed
that.

According to the apache docs (and confirmed by the above mentioned experiments)
if UseCanonicalName is set to 'off' the SERVER_NAME variable is set to
equal HTTP_HOST. This works great in most all cases. If UseCanonicalName is set
to 'on' then SERVER_NAME is set to whatever 'ServerName' is set
to in the apache conf. Seeing as UseCanonicalName can be set in the virtual host
entry there is no problem doing something like this:

<VirtualHost *:80>
	UseCanonicalName On

	ServerName hostname.com
	ServerAlias hostname.dev
</VirtualHost>

If Drupal used the SERVER_NAME variable then accessing the site should load the
hostname.com configuration regardless of what alias is accessed. Seeing as it
uses HTTP_HOST it will fail to load a configuration.

> Generally, for Drupal multisites to work under different Apache
> configurations, Drupal needs to rely more on the client's HTTP request
> rather than the server configuration. You can see a related issue in
> http://drupal.org/node/262920

I suppose it's swings and roundabouts really. Using HTTP_HOST provides a
globally predictable outcome. But if the user has access to the apache
configuration, either by support request or personally, then SERVER_NAME
provides a more configurable outcome.

I guess I'll just stick with symlinks (they can always be excluded from the
version control anyway).

Thanks
Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090316/6a1a9d86/attachment.htm>

From sammys-drupal at synerger.com  Tue Mar 17 01:51:30 2009
From: sammys-drupal at synerger.com (Sammy Spets)
Date: Tue, 17 Mar 2009 12:51:30 +1100
Subject: [development] Loading configuration using 'SERVER_NAME'
 as	opposed to 'HTTP_HOST'
In-Reply-To: <0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
Message-ID: <49BF0222.7020204@synerger.com>

Using a symlink will result in modules, themes and files having an 
incorrect path stored in the database. When you move the site live 
you'll need to have your dev symlink in place for the site to function. 
You could, of course, change all the entries in files and system tables 
to reflect the change (along with any color module variables). Yuck... 
too much work.

Instead of symlinks, set your development machine's 'hosts' file 
(/etc/hosts on linux and %WINDOWS%/system32/drivers/etc/hosts on 
windows) to have sitename.com go to 127.0.0.1 instead of the live site.

You can remove the 'hosts' entry and restart your browser to reach the 
live site again.

An alternative to this is to use sites/sitename.com then have 
dev.sitename.com go to 127.0.0.1 and it'll pick up that site directory 
anyway. Just remember to set your VirtualHost directive to accept 
dev.sitename.com as a ServerAlias.

--
Sammy Spets
Synerger
http://synerger.com


Michael Prasuhn wrote:
> While this may be less clean than desired, how about a symlink from 
> drupal/sites/sitename.dev to drupal/sites/sitename.com ?
>
> Surely this would achieve a similar result with no downside to that 
> being deployed on the server.
>
> -Mike
>
> __________________
> Michael Prasuhn
> 503.488.5433 office
> 714.356.0168 cell
> 503.661.7574 home
> mike at mikeyp.net
> http://mikeyp.net
>
>
>
>
>

From larry at garfieldtech.com  Tue Mar 17 02:17:29 2009
From: larry at garfieldtech.com (Larry Garfield)
Date: Mon, 16 Mar 2009 21:17:29 -0500
Subject: [development]
 =?iso-8859-1?q?Loading_configuration_using_=27SERVE?=
 =?iso-8859-1?q?R=5FNAME=27_as=09opposed_to_=27HTTP=5FHOST=27?=
In-Reply-To: <49BF0222.7020204@synerger.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
	<49BF0222.7020204@synerger.com>
Message-ID: <200903162117.30128.larry@garfieldtech.com>

On Monday 16 March 2009 8:51:30 pm Sammy Spets wrote:
> Using a symlink will result in modules, themes and files having an
> incorrect path stored in the database. When you move the site live
> you'll need to have your dev symlink in place for the site to function.
> You could, of course, change all the entries in files and system tables
> to reflect the change (along with any color module variables). Yuck...
> too much work.

The best solution is a backport of this D7 patch:

http://drupal.org/node/231298

I use it on most of my multi-sites. :-)

-- 
Larry Garfield
larry at garfieldtech.com

From nan_wich at bellsouth.net  Tue Mar 17 03:49:40 2009
From: nan_wich at bellsouth.net (Nancy Wichmann)
Date: Mon, 16 Mar 2009 23:49:40 -0400
Subject: [development] Best place to store user data
In-Reply-To: <49BEE44E.5060709@yelvington.com>
Message-ID: <NCEKJGCAHKMOLJLHNKLJEEHPEMAA.nan_wich@bellsouth.net>

There is nothing wrong with cache, as Crell said. I have done both
techniques. However, one caveat with cache - it is not as persistent as one
would like to think. There are many events that cause it to be cleared.
Using a minimum lifetime also interferes with some very popular (i.e. core)
modules. I have to agree with Crell's conclusion, go with a discreet table
if your data needs to be consistently persistent.


So let me add a bit to the question because I just came across it in a
contrib. Let's say you need one field that exactly matches a core table. Is
it ever okay, upgrades aside, to add that column to the core table? Some
things I've read about D7 seem to indicate this will be okay in D7. The use
of "drupal_write_record"  really makes this a convenient practice.

Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr.

-------------- next part --------------

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.11.15/2003 - Release Date: 3/15/2009 2:07 PM

From weitzman at tejasa.com  Tue Mar 17 11:49:25 2009
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Tue, 17 Mar 2009 07:49:25 -0400
Subject: [development] Best place to store user data
In-Reply-To: <NCEKJGCAHKMOLJLHNKLJEEHPEMAA.nan_wich@bellsouth.net>
References: <49BEE44E.5060709@yelvington.com>
	<NCEKJGCAHKMOLJLHNKLJEEHPEMAA.nan_wich@bellsouth.net>
Message-ID: <6117a7500903170449v2d42e98dtadeebbf743a87904@mail.gmail.com>

> So let me add a bit to the question because I just came across it in a
> contrib. Let's say you need one field that exactly matches a core table. Is
> it ever okay, upgrades aside, to add that column to the core table? Some
> things I've read about D7 seem to indicate this will be okay in D7. The use
> of "drupal_write_record"  really makes this a convenient practice.

Depends on who you ask. My position is that adding a column to a
foreign table is OK if the code will not be shared. IOW, custom code
for your own site. It is especially OK for the user table since it has
built in support for custom columns. I discourage this practice for
Contrib modules since the users of the module are usually unprepared
to evaluate the upgrade risks involved.

From earnie at users.sourceforge.net  Tue Mar 17 12:10:50 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 17 Mar 2009 08:10:50 -0400
Subject: [development] Best place to store user data
In-Reply-To: <6117a7500903170449v2d42e98dtadeebbf743a87904@mail.gmail.com>
References: <49BEE44E.5060709@yelvington.com>
	<NCEKJGCAHKMOLJLHNKLJEEHPEMAA.nan_wich@bellsouth.net>
	<6117a7500903170449v2d42e98dtadeebbf743a87904@mail.gmail.com>
Message-ID: <20090317081050.ivkgn4ztzjc0ooww@mail.progw.org>

Quoting Moshe Weitzman <weitzman at tejasa.com>:

>> So let me add a bit to the question because I just came across it in a
>> contrib. Let's say you need one field that exactly matches a core table. Is
>> it ever okay, upgrades aside, to add that column to the core table? Some
>> things I've read about D7 seem to indicate this will be okay in D7. The use
>> of "drupal_write_record"  really makes this a convenient practice.
>
> Depends on who you ask. My position is that adding a column to a
> foreign table is OK if the code will not be shared. IOW, custom code
> for your own site. It is especially OK for the user table since it has
> built in support for custom columns. I discourage this practice for
> Contrib modules since the users of the module are usually unprepared
> to evaluate the upgrade risks involved.
>

I agree with Moshe but understand the desire to want to add to a table. 
  The correct method for this is to create your own table relating the 
rows of information.  You can CREATE VIEW if you want to avoid needing 
to supply the JOINS.  Views are great for relating row ids to the text 
data you wish to represent.  Writing the relational data is reserved 
for the provided hooks such as hook_nodeapi.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From earnie at users.sourceforge.net  Tue Mar 17 12:51:44 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 17 Mar 2009 08:51:44 -0400
Subject: [development] Loading configuration using 'SERVER_NAME'
	as	opposed to 'HTTP_HOST'
In-Reply-To: <200903162117.30128.larry@garfieldtech.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
	<49BF0222.7020204@synerger.com>
	<200903162117.30128.larry@garfieldtech.com>
Message-ID: <20090317085144.fa2ji7pzt5ogk0sg@mail.progw.org>

Quoting Larry Garfield <larry at garfieldtech.com>:

> On Monday 16 March 2009 8:51:30 pm Sammy Spets wrote:
>> Using a symlink will result in modules, themes and files having an
>> incorrect path stored in the database. When you move the site live
>> you'll need to have your dev symlink in place for the site to function.
>> You could, of course, change all the entries in files and system tables
>> to reflect the change (along with any color module variables). Yuck...
>> too much work.
>
> The best solution is a backport of this D7 patch:
>
> http://drupal.org/node/231298
>
> I use it on most of my multi-sites. :-)
>

I think the better solution to this is to not store the 
files/whatever/file in the DB row and store only file.  The variables 
tell where the files are located so storing the path to the file in the 
row is a normalization issue.  I just moved a site from one host 
service to another and the location for the files changed.  Needless to 
say I had to update the user rows for the avatar's no less.  If the 
variables were used always to create the path and only the file name 
stored in the DB then moving the files directory should have been a 
simple change to the configuration.  I don't have time to work on a 
patch for this idea at the moment but I do have it on my round tuit 
list.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From drewish at katherinehouse.com  Tue Mar 17 17:01:52 2009
From: drewish at katherinehouse.com (andrew morton)
Date: Tue, 17 Mar 2009 10:01:52 -0700
Subject: [development] Loading configuration using 'SERVER_NAME' as
	opposed to 'HTTP_HOST'
In-Reply-To: <20090317085144.fa2ji7pzt5ogk0sg@mail.progw.org>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
	<49BF0222.7020204@synerger.com>
	<200903162117.30128.larry@garfieldtech.com>
	<20090317085144.fa2ji7pzt5ogk0sg@mail.progw.org>
Message-ID: <fab053ce0903171001j42a7478fhbf06229fe0996052@mail.gmail.com>

On Tue, Mar 17, 2009 at 5:51 AM, Earnie Boyd
<earnie at users.sourceforge.net> wrote:
> I think the better solution to this is to not store the files/whatever/file
> in the DB row and store only file. ?The variables tell where the files are
> located so storing the path to the file in the row is a normalization issue.
> ?I just moved a site from one host service to another and the location for
> the files changed. ?Needless to say I had to update the user rows for the
> avatar's no less. ?If the variables were used always to create the path and
> only the file name stored in the DB then moving the files directory should
> have been a simple change to the configuration. ?I don't have time to work
> on a patch for this idea at the moment but I do have it on my round tuit
> list.

As with most Drupal problems there's already an issue for that:
http://drupal.org/node/366464

Looking forward to seeing you in the issue queue,
andrew

From earnie at users.sourceforge.net  Tue Mar 17 21:56:14 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 17 Mar 2009 17:56:14 -0400
Subject: [development] Loading configuration using 'SERVER_NAME'
	as	opposed to 'HTTP_HOST'
In-Reply-To: <fab053ce0903171001j42a7478fhbf06229fe0996052@mail.gmail.com>
References: <AEDEDC25-858D-4C06-8569-EAF2A1AF0386@gmail.com>
	<0468FB3F-04B2-4D7D-983A-44219637D480@mikeyp.net>
	<49BF0222.7020204@synerger.com>
	<200903162117.30128.larry@garfieldtech.com>
	<20090317085144.fa2ji7pzt5ogk0sg@mail.progw.org>
	<fab053ce0903171001j42a7478fhbf06229fe0996052@mail.gmail.com>
Message-ID: <20090317175614.nxv09qmpt4g8sgc0@mail.progw.org>

Quoting andrew morton <drewish at katherinehouse.com>:

> On Tue, Mar 17, 2009 at 5:51 AM, Earnie Boyd
> <earnie at users.sourceforge.net> wrote:
>> I think the better solution to this is to not store the files/whatever/file
>> in the DB row and store only file.  The variables tell where the files are
>> located so storing the path to the file in the row is a normalization issue.
>>  I just moved a site from one host service to another and the location for
>> the files changed.  Needless to say I had to update the user rows for the
>> avatar's no less.  If the variables were used always to create the path and
>> only the file name stored in the DB then moving the files directory should
>> have been a simple change to the configuration.  I don't have time to work
>> on a patch for this idea at the moment but I do have it on my round tuit
>> list.
>
> As with most Drupal problems there's already an issue for that:
> http://drupal.org/node/366464
>
> Looking forward to seeing you in the issue queue,
> andrew

Thanks Andrew.  As I said, I don't have time at the moment but I 
visited the issue and subscribed.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From yinyang at eburg.com  Wed Mar 18 02:19:11 2009
From: yinyang at eburg.com (Gordon Messmer)
Date: Tue, 17 Mar 2009 19:19:11 -0700
Subject: [development] Forms API
Message-ID: <49C05A1F.5080408@eburg.com>

I'm trying to write a new module, and having some trouble with the forms 
API.  I'm deploying this under Drupal 5.  I've been reading the 
tutorials and documentation for the forms API.  A lot of this module is 
cut and paste from the documentation.

I'm able to generate a form properly, and even theme it.  It displays 
properly in my browser.  However, when I submit the form, the _submit 
function isn't called.  The code is here:

http://phantom.dragonsdawn.net/~gordon/customerportal.module

The browser sends the form data via POST, and the web server responds 
with "200 OK", sending back the form HTML.  It doesn't log any errors. 
I have no idea how to go about debugging Drupal to determine why the 
_submit function isn't being called.  Can anyone give me some pointers?

From nevets at tds.net  Wed Mar 18 02:42:50 2009
From: nevets at tds.net (Steve Ringwood)
Date: Tue, 17 Mar 2009 21:42:50 -0500
Subject: [development] Forms API
In-Reply-To: <49C05A1F.5080408@eburg.com>
References: <49C05A1F.5080408@eburg.com>
Message-ID: <49C05FAA.4090106@mailbag.com>

I wonder if it's because you are missing a final call 
drupal_render($form) in your theme function?

Also a suggestion for simplifying your code, when you build the form 
change the loop with invoices to

  while ($invoice = db_fetch_object($invoices)) {
    $fieldname = 'invoice-' . $invoice->invoice;
    $form['invoice'][$invoice->invoice] = array(
      '#type' => 'checkbox',
      '#title' => $invoice->invoice,
      '#default_value' => 0,
      '#cp_data' => array(
        'invoice' => $invoice->invoice,
        'total_due' => $invoice->total_due,
        'date_due' => $invoice->date_due,
        'status' => $invoice->status
      )
    );
  }
  
$form['invoice']['#tree'] = TRUE;

Then instead of looping through the whole form/form values you can loop through invoice
and have the invoice for the key  getting rid of the need for string manipulation.
Some like

  
  foreach ($form['invoice] as $invoice => $element) {

or

  foreach ($form_values['invoice] as $name => $value) {

nevets
  



From prometheus6 at gmail.com  Wed Mar 18 03:20:38 2009
From: prometheus6 at gmail.com (Earl Dunovant)
Date: Tue, 17 Mar 2009 23:20:38 -0400
Subject: [development] Forms API
In-Reply-To: <49C05A1F.5080408@eburg.com>
References: <49C05A1F.5080408@eburg.com>
Message-ID: <c6df037d0903172020h4e292209u41bd48b358248d89@mail.gmail.com>

Simplest solution is to directly assign the submit function to the form.

$form['#submit'][] = 'customerportal_form_submit';

On Tue, Mar 17, 2009 at 10:19 PM, Gordon Messmer <yinyang at eburg.com> wrote:

> I'm trying to write a new module, and having some trouble with the forms
> API.  I'm deploying this under Drupal 5.  I've been reading the tutorials
> and documentation for the forms API.  A lot of this module is cut and paste
> from the documentation.
>
> I'm able to generate a form properly, and even theme it.  It displays
> properly in my browser.  However, when I submit the form, the _submit
> function isn't called.  The code is here:
>
> http://phantom.dragonsdawn.net/~gordon/customerportal.module<http://phantom.dragonsdawn.net/%7Egordon/customerportal.module>
>
> The browser sends the form data via POST, and the web server responds with
> "200 OK", sending back the form HTML.  It doesn't log any errors. I have no
> idea how to go about debugging Drupal to determine why the _submit function
> isn't being called.  Can anyone give me some pointers?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090317/9bd95c5d/attachment.htm>

From recidive at gmail.com  Wed Mar 18 03:25:34 2009
From: recidive at gmail.com (Henrique Recidive)
Date: Wed, 18 Mar 2009 00:25:34 -0300
Subject: [development] Forms API
In-Reply-To: <49C05A1F.5080408@eburg.com>
References: <49C05A1F.5080408@eburg.com>
Message-ID: <841684fe0903172025g24a36ae8yd3c3f73c0e68e215@mail.gmail.com>

2009/3/17 Gordon Messmer <yinyang at eburg.com>:
> I'm trying to write a new module, and having some trouble with the forms
> API. ?I'm deploying this under Drupal 5. ?I've been reading the tutorials
> and documentation for the forms API. ?A lot of this module is cut and paste
> from the documentation.
>
> I'm able to generate a form properly, and even theme it. ?It displays
> properly in my browser. ?However, when I submit the form, the _submit
> function isn't called. ?The code is here:
>
> http://phantom.dragonsdawn.net/~gordon/customerportal.module
>
> The browser sends the form data via POST, and the web server responds with
> "200 OK", sending back the form HTML. ?It doesn't log any errors. I have no
> idea how to go about debugging Drupal to determine why the _submit function
> isn't being called. ?Can anyone give me some pointers?

Try changing that line:

$output .= drupal_render($form['submit']);

To:

$output .= drupal_render();

in your theme function.

From merlin at logrus.com  Wed Mar 18 04:15:15 2009
From: merlin at logrus.com (Earl Miles)
Date: Tue, 17 Mar 2009 21:15:15 -0700
Subject: [development] Forms API
In-Reply-To: <49C05A1F.5080408@eburg.com>
References: <49C05A1F.5080408@eburg.com>
Message-ID: <49C07553.5060802@logrus.com>

Gordon Messmer wrote:
> I'm trying to write a new module, and having some trouble with the forms 
> API.  I'm deploying this under Drupal 5.  I've been reading the 
> tutorials and documentation for the forms API.  A lot of this module is 
> cut and paste from the documentation.
> 
> I'm able to generate a form properly, and even theme it.  It displays 
> properly in my browser.  However, when I submit the form, the _submit 
> function isn't called.  The code is here:
> 
> http://phantom.dragonsdawn.net/~gordon/customerportal.module
> 
> The browser sends the form data via POST, and the web server responds 
> with "200 OK", sending back the form HTML.  It doesn't log any errors. I 
> have no idea how to go about debugging Drupal to determine why the 
> _submit function isn't being called.  Can anyone give me some pointers?

You don't have a drupal_render($form) at the end which gets all the 
hidden fields that are necessary, like the form id and form token.

From yinyang at eburg.com  Wed Mar 18 05:32:00 2009
From: yinyang at eburg.com (Gordon Messmer)
Date: Tue, 17 Mar 2009 22:32:00 -0700
Subject: [development] Forms API
In-Reply-To: <49C05FAA.4090106@mailbag.com>
References: <49C05A1F.5080408@eburg.com> <49C05FAA.4090106@mailbag.com>
Message-ID: <49C08750.1010509@eburg.com>

Steve Ringwood wrote:
> I wonder if it's because you are missing a final call 
> drupal_render($form) in your theme function?

That's exactly it.  I really appreciate everyone who pointed that out. 
The example in the documentation does exactly that, I simply didn't 
understand its significance.  Thanks.

> Also a suggestion for simplifying your code, when you build the form 
> change the loop with invoices to
> 
>  while ($invoice = db_fetch_object($invoices)) {
>    $fieldname = 'invoice-' . $invoice->invoice;
>    $form['invoice'][$invoice->invoice] = array(
...
> $form['invoice']['#tree'] = TRUE;

I took your advice here, too.  It really only saved one line of string 
manipulation, since the theme still has to skip over elements that start 
with '#', but at least the submit() function is clearer.  Plus I 
understand the "#tree" thing a little better, which is good. :)


From yinyang at eburg.com  Wed Mar 18 05:32:30 2009
From: yinyang at eburg.com (Gordon Messmer)
Date: Tue, 17 Mar 2009 22:32:30 -0700
Subject: [development] Forms API
In-Reply-To: <c6df037d0903172020h4e292209u41bd48b358248d89@mail.gmail.com>
References: <49C05A1F.5080408@eburg.com>
	<c6df037d0903172020h4e292209u41bd48b358248d89@mail.gmail.com>
Message-ID: <49C0876E.9090504@eburg.com>

Earl Dunovant wrote:
> Simplest solution is to directly assign the submit function to the form.
> $form['#submit'][] = 'customerportal_form_submit';

I had actually tried that at one point. :)

Thanks.

From prometheus6 at gmail.com  Wed Mar 18 12:36:53 2009
From: prometheus6 at gmail.com (Earl Dunovant)
Date: Wed, 18 Mar 2009 08:36:53 -0400
Subject: [development] Forms API
In-Reply-To: <49C0876E.9090504@eburg.com>
References: <49C05A1F.5080408@eburg.com>
	<c6df037d0903172020h4e292209u41bd48b358248d89@mail.gmail.com>
	<49C0876E.9090504@eburg.com>
Message-ID: <c6df037d0903180536o644b5adat4ce44e2595023809@mail.gmail.com>

I have  to remember the solution, I suppose. I'm a module guy, not a theme
guy...

On Wed, Mar 18, 2009 at 1:32 AM, Gordon Messmer <yinyang at eburg.com> wrote:

> Earl Dunovant wrote:
>
>> Simplest solution is to directly assign the submit function to the form.
>> $form['#submit'][] = 'customerportal_form_submit';
>>
>
> I had actually tried that at one point. :)
>
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090318/5da1eb74/attachment.htm>

From aldo at caonao.cu  Thu Mar 19 21:13:52 2009
From: aldo at caonao.cu (Aldo Martinez Selleras)
Date: Thu, 19 Mar 2009 17:13:52 -0400
Subject: [development] $breadcrumb
Message-ID: <200903191713.53128.aldo@caonao.cu>

can i modify the $breadcrumb array contents???
i mean, add a item, or delete a item ??

-- 
----------------------
Aldo Martinez Selleras
Especialista en Telematica
CITMATEL GND Camaguey
Tel: 53 32 291661
Linux User #364356

From killshot91 at comcast.net  Thu Mar 19 21:24:54 2009
From: killshot91 at comcast.net (Steve Edwards)
Date: Thu, 19 Mar 2009 14:24:54 -0700
Subject: [development] $breadcrumb
In-Reply-To: <200903191713.53128.aldo@caonao.cu>
References: <200903191713.53128.aldo@caonao.cu>
Message-ID: <49C2B826.7070709@comcast.net>

http://api.drupal.org/api/function/drupal_set_breadcrumb/6

Aldo Martinez Selleras wrote:
> can i modify the $breadcrumb array contents???
> i mean, add a item, or delete a item ??
> 

From ezra at growingventuresolutions.com  Thu Mar 19 21:28:32 2009
From: ezra at growingventuresolutions.com (Ezra B. Gildesgame)
Date: Thu, 19 Mar 2009 17:28:32 -0400
Subject: [development] $breadcrumb
In-Reply-To: <200903191713.53128.aldo@caonao.cu>
References: <200903191713.53128.aldo@caonao.cu>
Message-ID: <ccbb750f0903191428i2a81442bh4a0e2814d3096d3b@mail.gmail.com>

When wondering about whether a Drupal API function exists, it's
usually a good idea to type related text into the autocomplete box on
that page and see what pops up.

http://api.drupal.org/api/function/drupal_set_breadcrumb/6

http://api.drupal.org/api/function/drupal_get_breadcrumb/6


Ezra

On Thu, Mar 19, 2009 at 5:13 PM, Aldo Martinez Selleras <aldo at caonao.cu> wrote:
> can i modify the $breadcrumb array contents???
> i mean, add a item, or delete a item ??
>
> --
> ----------------------
> Aldo Martinez Selleras
> Especialista en Telematica
> CITMATEL GND Camaguey
> Tel: 53 32 291661
> Linux User #364356
>



-- 
Ezra Barnett Gildesgame
http://growingventuresolutions.com
http://ezra-g.com

From drupal.beginner at wechange.org  Fri Mar 20 00:48:20 2009
From: drupal.beginner at wechange.org (augustin (beginner))
Date: Fri, 20 Mar 2009 08:48:20 +0800
Subject: [development] $breadcrumb
In-Reply-To: <200903191713.53128.aldo@caonao.cu>
References: <200903191713.53128.aldo@caonao.cu>
Message-ID: <200903200848.21531.drupal.beginner@wechange.org>

On Friday 20 March 2009 05:13:52 Aldo Martinez Selleras wrote:
> can i modify the $breadcrumb array contents???
> i mean, add a item, or delete a item ??

search for breadcrumbs in the Drupal 7 issue queue. There are a few issues 
that limit the useability of breadcrumbs and the current api.

[...]

Ok, here it is:
http://drupal.org/node/150854

Blessings,

Augustin.


From drupal-devel at webchick.net  Fri Mar 20 02:56:25 2009
From: drupal-devel at webchick.net (Angela Byron)
Date: Thu, 19 Mar 2009 22:56:25 -0400
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-6
Message-ID: <0FB637B0-37C6-4D0F-8945-E5FF11D7F477@webchick.net>

Hey there, Drupal people!

Time for the monthly unstable release! Lots of goodies this time...  
For module developers who wish to get a jump on upgrading their  
modules to Drupal 7 ahead of time, check out http://drupal.org/node/224333 
  for a list of API changes.

Remember: there are only 165 days left until code freeze, when we must  
cease and desist all world domination plans until Drupal 8! http://drupal.org/community-initiatives/drupal-core 
  has a nice list of all the current initiatives going on (feel free  
to add your own as well!). If you're looking for the places to make  
the biggest splash, those are them. :) Or, if you're just getting your  
feet wet with patching and want something a bit easier to cut your  
teeth on, try tackling one of the issues listed at http://drupal.org/patch/novice 
! Friendly volunteers are always available in #drupal in  
irc.freenode.net to offer assistance.

With that out of the way, here are some of the highlights of   
DRUPAL-7-0-UNSTABLE-6 (full release notes attached at the end).

- In JavaScript-y news, Drupal 7 now comes with jQuery 1.3.2 and  
jQuery Forms 2.21. it's also now possible to use jQuery alongside  
other JS libraries (Prototype, etc.)! This requires a small change to  
your JS code that you can do even now in Drupal 6 as a best practice.  
See http://drupal.org/node/224333#javascript_compatibility for more  
details. You can also now reference external JS files from  
drupal_add_js() rather than having to do silly workarounds with  
drupal_set_html_head(). Yay for consistency!

- Massive re-working of image handling libraries (basically ImageAPI  
in core), which gives us important groundwork towards ImageCache in  
core http://drupal.org/node/371374 and even possibly ImageField in  
core. OoOoOoo... :)

- The new database system (DBTNG) now supports pager and tablesort  
queries via "extenders," which means that we can now work on  
converting pretty much all of Drupal core queries to DBTNG. Feel free  
to pick off an issue from http://drupal.org/project/issues/3060/term/ 
131 if you'd like to get a head start on learning this essential part  
of Drupal.

- For designers, lots of exciting news! First, page.tpl.php now has  
some nice, cleaner markup to make it easier for CSS designers to jump  
in and start theming without any PHP knowledge. w00t! Next up:  
node.tpl.php: http://drupal.org/node/382870. Also, our aging, ugly  
pals Bluemarine, Chameleon, and Pushbutton have been retired from core  
so they no longer offend designers new to Drupal and make them think  
that apart from Garland, all Drupal can ever be is ugly and non- 
standards compliant. ;) Hooray! Thanks to JohnAlbin, who took a hit  
for the team, they're still in contrib if anyone needs them. :)

- Drupal 6 -> Drupal 7 core upgrades should actually work now without  
any manual monkeying with settings.php! :) Yay!

- A new filter was added which will let you post a link to <a  
href="[internal:node/123]">About Us</a> and automatically figure out  
the right path.

-Angie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090319/5a25a625/attachment-0001.html>
-------------- next part --------------


From rob at robshouse.net  Fri Mar 20 10:04:05 2009
From: rob at robshouse.net (Robert Douglass)
Date: Fri, 20 Mar 2009 11:04:05 +0100
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-6
In-Reply-To: <0FB637B0-37C6-4D0F-8945-E5FF11D7F477@webchick.net>
References: <0FB637B0-37C6-4D0F-8945-E5FF11D7F477@webchick.net>
Message-ID: <334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>

>
> - The new database system (DBTNG) now supports pager and tablesort  
> queries via "extenders," which means that we can now work on  
> converting pretty much all of Drupal core queries to DBTNG. Feel  
> free to pick off an issue from http://drupal.org/project/issues/3060/term/131 
>  if you'd like to get a head start on learning this essential part  
> of Drupal.


Can these extenders be used to make pagers that *DON'T* do a pager  
query, but just go to the next chunk until there isn't any? The reason  
I ask is that the current pager system barfs with millions of nodes.  
Queries like "SELECT COUNT(*) FROM node WHERE status = 1 AND promoted  
= 1" take enormous amounts of time to execute with millions of nodes,  
but are a part of every q=node front page. There are other examples.

From weitzman at tejasa.com  Fri Mar 20 12:10:26 2009
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Fri, 20 Mar 2009 08:10:26 -0400
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-6
In-Reply-To: <334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>
References: <0FB637B0-37C6-4D0F-8945-E5FF11D7F477@webchick.net>
	<334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>
Message-ID: <6117a7500903200510q7d59d5ehf222cafbaa9a6963@mail.gmail.com>

Yes, the extender system allows for mini pagers and such which can
have better performance and fewer features. Here is a great article
describing some techniques:
http://www.mysqlperformanceblog.com/2008/09/24/four-ways-to-optimize-paginated-displays/.

As for your specific example of the front page query, an alternate
approach for such a site is to swap in a materialized view -
http://drupal.org/project/materialized_view (no code in CVS yet)

On Fri, Mar 20, 2009 at 6:04 AM, Robert Douglass <rob at robshouse.net> wrote:
>>
>> - The new database system (DBTNG) now supports pager and tablesort queries
>> via "extenders," which means that we can now work on converting pretty much
>> all of Drupal core queries to DBTNG. Feel free to pick off an issue from
>> http://drupal.org/project/issues/3060/term/131?if you'd like to get a head
>> start on learning this essential part of Drupal.
>
>
> Can these extenders be used to make pagers that *DON'T* do a pager query,
> but just go to the next chunk until there isn't any? The reason I ask is
> that the current pager system barfs with millions of nodes. Queries like
> "SELECT COUNT(*) FROM node WHERE status = 1 AND promoted = 1" take enormous
> amounts of time to execute with millions of nodes, but are a part of every
> q=node front page. There are other examples.
>

From morbus at disobey.com  Fri Mar 20 12:13:35 2009
From: morbus at disobey.com (Morbus Iff)
Date: Fri, 20 Mar 2009 08:13:35 -0400
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-6
In-Reply-To: <334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>
References: <0FB637B0-37C6-4D0F-8945-E5FF11D7F477@webchick.net>
	<334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>
Message-ID: <49C3886F.2030208@disobey.com>

>> - The new database system (DBTNG) now supports pager and tablesort  
>> queries via "extenders," which means that we can now work on  
>> converting pretty much all of Drupal core queries to DBTNG. Feel  
>> free to pick off an issue from http://drupal.org/project/issues/3060/term/131 
>>  if you'd like to get a head start on learning this essential part  
>> of Drupal.
> 
> Can these extenders be used to make pagers that *DON'T* do a pager  
> query, but just go to the next chunk until there isn't any? The reason  
> I ask is that the current pager system barfs with millions of nodes.  
> Queries like "SELECT COUNT(*) FROM node WHERE status = 1 AND promoted  
> = 1" take enormous amounts of time to execute with millions of nodes,  
> but are a part of every q=node front page. There are other examples.

I've a pet peeve annoyance on pagers too: can they work without database 
queries yet? ;) About a dozen times over the years, I've had a need to 
use pagers, but couldn't becauase it wasn't a single query (or, worse, 
it was the result of a hook call, where there was no database activity 
going on at all...)

-- 
Morbus Iff ( there is no morbus, there is only zuul! )
Technical: http://www.oreillynet.com/pub/au/779
Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus

From litrik at norio.be  Fri Mar 20 12:19:40 2009
From: litrik at norio.be (Litrik De Roy)
Date: Fri, 20 Mar 2009 13:19:40 +0100
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-6
In-Reply-To: <49C3886F.2030208@disobey.com>
References: <0FB637B0-37C6-4D0F-8945-E5FF11D7F477@webchick.net>
	<334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>
	<49C3886F.2030208@disobey.com>
Message-ID: <b00aa8ce0903200519l4246ad3ere59d6bf45b85760@mail.gmail.com>

On Fri, Mar 20, 2009 at 13:13, Morbus Iff <morbus at disobey.com> wrote:
> I've a pet peeve annoyance on pagers too: can they work without database
> queries yet? ;) About a dozen times over the years, I've had a need to use
> pagers, but couldn't becauase it wasn't a single query (or, worse, it was
> the result of a hook call, where there was no database activity going on at
> all...)

I have reused Drupal's pager in combination with data retrieved using SOAP.
I have described it in this blog post:
http://www.norio.be/blog/2008/07/reusing-drupals-pager-non-sql-data

-- 
Litrik De Roy
Norio ICT Consulting - http://www.norio.be/

From morbus at disobey.com  Fri Mar 20 13:01:37 2009
From: morbus at disobey.com (Morbus Iff)
Date: Fri, 20 Mar 2009 09:01:37 -0400
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-6
In-Reply-To: <b00aa8ce0903200519l4246ad3ere59d6bf45b85760@mail.gmail.com>
References: <0FB637B0-37C6-4D0F-8945-E5FF11D7F477@webchick.net>	<334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>	<49C3886F.2030208@disobey.com>
	<b00aa8ce0903200519l4246ad3ere59d6bf45b85760@mail.gmail.com>
Message-ID: <49C393B1.9070000@disobey.com>

> On Fri, Mar 20, 2009 at 13:13, Morbus Iff <morbus at disobey.com> wrote:
>> I've a pet peeve annoyance on pagers too: can they work without database
>> queries yet? ;) About a dozen times over the years, I've had a need to use
>> pagers, but couldn't becauase it wasn't a single query (or, worse, it was
>> the result of a hook call, where there was no database activity going on at
>> all...)
> 
> I have reused Drupal's pager in combination with data retrieved using SOAP.
> http://www.norio.be/blog/2008/07/reusing-drupals-pager-non-sql-data

Yep, that's how I've done it in the past too. A bit ooky, really.

-- 
Morbus Iff ( notice how he deftly sidesteps the panty issue. )
Technical: http://www.oreillynet.com/pub/au/779
Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus

From earnie at users.sourceforge.net  Fri Mar 20 13:14:20 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Fri, 20 Mar 2009 09:14:20 -0400
Subject: [development] $breadcrumb
In-Reply-To: <ccbb750f0903191428i2a81442bh4a0e2814d3096d3b@mail.gmail.com>
References: <200903191713.53128.aldo@caonao.cu>
	<ccbb750f0903191428i2a81442bh4a0e2814d3096d3b@mail.gmail.com>
Message-ID: <20090320091420.slnu5byao9xcwwwc@mail.progw.org>

Quoting "Ezra B. Gildesgame" <ezra at growingventuresolutions.com>:

> When wondering about whether a Drupal API function exists, it's
> usually a good idea to type related text into the autocomplete box on
> that page and see what pops up.
>

While this is a good suggestion the limit of the autocomplete list may 
cause you to not find what you need so be sure to click the ``Search'' 
button for a list of all things breadcrumbs (or whatever value).

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From metzlerd at metzlerd.com  Fri Mar 20 18:02:05 2009
From: metzlerd at metzlerd.com (David Metzler)
Date: Fri, 20 Mar 2009 11:02:05 -0700
Subject: [development] global $user unavaialable?
Message-ID: <657008A9-4C2B-47F0-BB87-69140D6F94DC@metzlerd.com>

I'm working on implementing a new cas_server module that allows  
drupal accounts to be used as a single - sign on source.  I have a  
drupal 5 site issues a redirect to a drupal 6 site, and when I  
redirect to that page I don't find that the $user global is  
populated.  Is there some function or include that I should b calling  
to make sure that this data is there?

Code snippet that isn't returning correct data.

global $user
if ($user->uid) {
   drupal_set_message('user logged in');
}
else {
   drupal_set_message('User not logged in');
}

Note that if I click on any other link in the drupal page.  I show as  
being logged in, but the redirect to this page does not load the  
$user variable.

Developing against drupal 6.10


From stewsnooze at gmail.com  Fri Mar 20 18:22:55 2009
From: stewsnooze at gmail.com (Stewart Robinson)
Date: Fri, 20 Mar 2009 18:22:55 +0000
Subject: [development] global $user unavaialable?
In-Reply-To: <657008A9-4C2B-47F0-BB87-69140D6F94DC@metzlerd.com>
References: <657008A9-4C2B-47F0-BB87-69140D6F94DC@metzlerd.com>
Message-ID: <b84e952a0903201122j12f9e721lba81af3f176b204b@mail.gmail.com>

Is this code snippet in the page callback or a hook function?

Hook_boot and some others run before the user has been loaded

On 3/20/09, David Metzler <metzlerd at metzlerd.com> wrote:
> I'm working on implementing a new cas_server module that allows
> drupal accounts to be used as a single - sign on source.  I have a
> drupal 5 site issues a redirect to a drupal 6 site, and when I
> redirect to that page I don't find that the $user global is
> populated.  Is there some function or include that I should b calling
> to make sure that this data is there?
>
> Code snippet that isn't returning correct data.
>
> global $user
> if ($user->uid) {
>    drupal_set_message('user logged in');
> }
> else {
>    drupal_set_message('User not logged in');
> }
>
> Note that if I click on any other link in the drupal page.  I show as
> being logged in, but the redirect to this page does not load the
> $user variable.
>
> Developing against drupal 6.10
>
>

-- 
Sent from my mobile device

From metzlerd at metzlerd.com  Fri Mar 20 18:25:46 2009
From: metzlerd at metzlerd.com (David Metzler)
Date: Fri, 20 Mar 2009 11:25:46 -0700
Subject: [development] global $user unavaialable?
In-Reply-To: <b84e952a0903201122j12f9e721lba81af3f176b204b@mail.gmail.com>
References: <657008A9-4C2B-47F0-BB87-69140D6F94DC@metzlerd.com>
	<b84e952a0903201122j12f9e721lba81af3f176b204b@mail.gmail.com>
Message-ID: <2E462425-4E83-4D97-A4C5-F50838958873@metzlerd.com>

Page callback. Tried both NORMAL_MENU_ITEM and CALLBACK.

Dave
On Mar 20, 2009, at 11:22 AM, Stewart Robinson wrote:

> Is this code snippet in the page callback or a hook function?
>
> Hook_boot and some others run before the user has been loaded
>
> On 3/20/09, David Metzler <metzlerd at metzlerd.com> wrote:
>> I'm working on implementing a new cas_server module that allows
>> drupal accounts to be used as a single - sign on source.  I have a
>> drupal 5 site issues a redirect to a drupal 6 site, and when I
>> redirect to that page I don't find that the $user global is
>> populated.  Is there some function or include that I should b calling
>> to make sure that this data is there?
>>
>> Code snippet that isn't returning correct data.
>>
>> global $user
>> if ($user->uid) {
>>    drupal_set_message('user logged in');
>> }
>> else {
>>    drupal_set_message('User not logged in');
>> }
>>
>> Note that if I click on any other link in the drupal page.  I show as
>> being logged in, but the redirect to this page does not load the
>> $user variable.
>>
>> Developing against drupal 6.10
>>
>>
>
> -- 
> Sent from my mobile device


From weitzman at tejasa.com  Fri Mar 20 18:30:05 2009
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Fri, 20 Mar 2009 14:30:05 -0400
Subject: [development] global $user unavaialable?
In-Reply-To: <657008A9-4C2B-47F0-BB87-69140D6F94DC@metzlerd.com>
References: <657008A9-4C2B-47F0-BB87-69140D6F94DC@metzlerd.com>
Message-ID: <6117a7500903201130j198ae380mc127aca63b37bd41@mail.gmail.com>

that snippit tests if the user is logged in, not if $user is
populated. you could have a full anonymous $user object.

the basic loading of a $user gets triggerred by session_start() but if
you have to call that on your own you are way off the beaten path in
Drupal and really need to grok whats happenning step by step in order
to assure security and code sanity. that gives a basic $user object.
If you need it call, you might have to call user_load() yourself.

On Fri, Mar 20, 2009 at 2:02 PM, David Metzler <metzlerd at metzlerd.com> wrote:
> I'm working on implementing a new cas_server module that allows drupal
> accounts to be used as a single - sign on source. ?I have a drupal 5 site
> issues a redirect to a drupal 6 site, and when I redirect to that page I
> don't find that the $user global is populated. ?Is there some function or
> include that I should b calling to make sure that this data is there?
>
> Code snippet that isn't returning correct data.
>
> global $user
> if ($user->uid) {
> ?drupal_set_message('user logged in');
> }
> else {
> ?drupal_set_message('User not logged in');
> }
>
> Note that if I click on any other link in the drupal page. ?I show as being
> logged in, but the redirect to this page does not load the $user variable.
>
> Developing against drupal 6.10
>
>

From larry at garfieldtech.com  Fri Mar 20 18:30:31 2009
From: larry at garfieldtech.com (larry at garfieldtech.com)
Date: Fri, 20 Mar 2009 13:30:31 -0500
Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-6
In-Reply-To: <334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>
References: <0FB637B0-37C6-4D0F-8945-E5FF11D7F477@webchick.net>
	<334C4CD6-9FD9-495D-A549-310C7203F4D6@robshouse.net>
Message-ID: <49C3E0C7.5060301@garfieldtech.com>

Robert Douglass wrote:
>>
>> - The new database system (DBTNG) now supports pager and tablesort 
>> queries via "extenders," which means that we can now work on 
>> converting pretty much all of Drupal core queries to DBTNG. Feel free 
>> to pick off an issue from 
>> http://drupal.org/project/issues/3060/term/131 if you'd like to get a 
>> head start on learning this essential part of Drupal.
> 
> Can these extenders be used to make pagers that *DON'T* do a pager 
> query, but just go to the next chunk until there isn't any? The reason I 
> ask is that the current pager system barfs with millions of nodes. 
> Queries like "SELECT COUNT(*) FROM node WHERE status = 1 AND promoted = 
> 1" take enormous amounts of time to execute with millions of nodes, but 
> are a part of every q=node front page. There are other examples.

That is exactly the goal.  Right now the PagerDefault extender is a 
direct port of the existing procedural code, and therefore is 
horrifically bad and uses global variables that are undocumented and 
have completely obscure names that I cannot follow.  Someone not named 
Crell needs to fix that, hopefully. :-)  But yes, the idea was exactly 
to allow alternate paging mechanisms, at least for the query level 
itself.  The pager UI part is, unfortunately, rather tied to that, and 
still needs refactoring.  Again, someone who is not me needs to own 
that, and maybe even throw a new pager type or two into core.  (I'd be 
totally cool with that!)

--Larry Garfield

From dipench at gmail.com  Mon Mar 23 10:02:36 2009
From: dipench at gmail.com (Dipen)
Date: Mon, 23 Mar 2009 15:32:36 +0530
Subject: [development] PHP checkstyle
Message-ID: <1fcccc8a0903230302m47d57463y6c642288d232e55b@mail.gmail.com>

Hi list,
 After searching google for 1 hr I am still unable to find an equivalent for
java checkstyle for PHP which would play nice with eclipse. I could find
this
http://developer.spikesource.com/wiki/index.php?title=Projects:phpcheckstyleNewsand
one abandoned project with no releases on sourceforge. Does anyone
know
of checkstyle eclipse plugin for PHP (doesnt need to be all featureful).
Also how do you manage this kind of task? Checkstyle eclipse plugin for java
- http://eclipse-cs.sourceforge.net/

Thanks

Dipen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090323/979f9b5f/attachment.htm>

From victorkane at gmail.com  Mon Mar 23 10:11:52 2009
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 23 Mar 2009 07:11:52 -0300
Subject: [development] PHP checkstyle
In-Reply-To: <1fcccc8a0903230302m47d57463y6c642288d232e55b@mail.gmail.com>
References: <1fcccc8a0903230302m47d57463y6c642288d232e55b@mail.gmail.com>
Message-ID: <ff176450903230311r158d5aadp9bea98d4c0c6cb4f@mail.gmail.com>

PHP does have its own built in "lint" (like the one we used to use every day
with C programs).

$ php -l my.module
No syntax errors detected in lcph.module

See http://www.snakelegs.org/2006/05/18/lint-php/ for article.

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com



On Mon, Mar 23, 2009 at 7:02 AM, Dipen <dipench at gmail.com> wrote:

> Hi list,
>  After searching google for 1 hr I am still unable to find an equivalent
> for java checkstyle for PHP which would play nice with eclipse. I could find
> this
> http://developer.spikesource.com/wiki/index.php?title=Projects:phpcheckstyleNewsand one abandoned project with no releases on sourceforge. Does anyone know
> of checkstyle eclipse plugin for PHP (doesnt need to be all featureful).
> Also how do you manage this kind of task? Checkstyle eclipse plugin for java
> - http://eclipse-cs.sourceforge.net/
>
> Thanks
>
> Dipen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090323/b74c84f1/attachment.htm>

From dipench at gmail.com  Mon Mar 23 10:31:53 2009
From: dipench at gmail.com (Dipen)
Date: Mon, 23 Mar 2009 16:01:53 +0530
Subject: [development] PHP checkstyle
In-Reply-To: <ff176450903230311r158d5aadp9bea98d4c0c6cb4f@mail.gmail.com>
References: <1fcccc8a0903230302m47d57463y6c642288d232e55b@mail.gmail.com>
	<ff176450903230311r158d5aadp9bea98d4c0c6cb4f@mail.gmail.com>
Message-ID: <1fcccc8a0903230331w4efe15b9n988d8d8584d71729@mail.gmail.com>

Thanks for that, but I want it for code readability where in I can set
things like "eclipse should show a warning if I am using camelcase for
variables", "If there are more than 100 characters in 1 line of code then it
should present a warning and auto formatter should fold it two lines" the
way checkstyle plugin works for java (give proper checkstyle.xml). Syntax
errors are automatically identified by PDT, I'll look into -l as to what all
features does it provide. But I want something embedded into my IDE which
prompts me of style errors and coding standard errors as I make them.

Thanks again



On Mon, Mar 23, 2009 at 3:41 PM, Victor Kane <victorkane at gmail.com> wrote:

> PHP does have its own built in "lint" (like the one we used to use every
> day with C programs).
>
> $ php -l my.module
> No syntax errors detected in lcph.module
>
> See http://www.snakelegs.org/2006/05/18/lint-php/ for article.
>
> Victor Kane
> http://awebfactory.com.ar
> http://projectflowandtracker.com
>
>
>
>
> On Mon, Mar 23, 2009 at 7:02 AM, Dipen <dipench at gmail.com> wrote:
>
>> Hi list,
>>  After searching google for 1 hr I am still unable to find an equivalent
>> for java checkstyle for PHP which would play nice with eclipse. I could find
>> this
>> http://developer.spikesource.com/wiki/index.php?title=Projects:phpcheckstyleNewsand one abandoned project with no releases on sourceforge. Does anyone know
>> of checkstyle eclipse plugin for PHP (doesnt need to be all featureful).
>> Also how do you manage this kind of task? Checkstyle eclipse plugin for java
>> - http://eclipse-cs.sourceforge.net/
>>
>> Thanks
>>
>> Dipen
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090323/08339c1b/attachment.htm>

From victorkane at gmail.com  Mon Mar 23 10:38:17 2009
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 23 Mar 2009 07:38:17 -0300
Subject: [development] PHP checkstyle
In-Reply-To: <1fcccc8a0903230331w4efe15b9n988d8d8584d71729@mail.gmail.com>
References: <1fcccc8a0903230302m47d57463y6c642288d232e55b@mail.gmail.com> 
	<ff176450903230311r158d5aadp9bea98d4c0c6cb4f@mail.gmail.com> 
	<1fcccc8a0903230331w4efe15b9n988d8d8584d71729@mail.gmail.com>
Message-ID: <ff176450903230338x5a06fd39wd03b8338d9dc097c@mail.gmail.com>

Google on "beautify php eclipse", it seems there are several, one built into
PHPEclipse.

Of course, the main objective should be http://drupal.org/coding-standards

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com


On Mon, Mar 23, 2009 at 7:31 AM, Dipen <dipench at gmail.com> wrote:

> Thanks for that, but I want it for code readability where in I can set
> things like "eclipse should show a warning if I am using camelcase for
> variables", "If there are more than 100 characters in 1 line of code then it
> should present a warning and auto formatter should fold it two lines" the
> way checkstyle plugin works for java (give proper checkstyle.xml). Syntax
> errors are automatically identified by PDT, I'll look into -l as to what all
> features does it provide. But I want something embedded into my IDE which
> prompts me of style errors and coding standard errors as I make them.
>
> Thanks again
>
>
>
> On Mon, Mar 23, 2009 at 3:41 PM, Victor Kane <victorkane at gmail.com> wrote:
>
>> PHP does have its own built in "lint" (like the one we used to use every
>> day with C programs).
>>
>> $ php -l my.module
>> No syntax errors detected in lcph.module
>>
>> See http://www.snakelegs.org/2006/05/18/lint-php/ for article.
>>
>> Victor Kane
>> http://awebfactory.com.ar
>> http://projectflowandtracker.com
>>
>>
>>
>>
>> On Mon, Mar 23, 2009 at 7:02 AM, Dipen <dipench at gmail.com> wrote:
>>
>>> Hi list,
>>>  After searching google for 1 hr I am still unable to find an equivalent
>>> for java checkstyle for PHP which would play nice with eclipse. I could find
>>> this
>>> http://developer.spikesource.com/wiki/index.php?title=Projects:phpcheckstyleNewsand one abandoned project with no releases on sourceforge. Does anyone know
>>> of checkstyle eclipse plugin for PHP (doesnt need to be all featureful).
>>> Also how do you manage this kind of task? Checkstyle eclipse plugin for java
>>> - http://eclipse-cs.sourceforge.net/
>>>
>>> Thanks
>>>
>>> Dipen
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090323/31a583d2/attachment-0001.htm>

From enboig at gmail.com  Mon Mar 23 12:30:50 2009
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Mon, 23 Mar 2009 13:30:50 +0100
Subject: [development] private areas inside Organic Groups
Message-ID: <45a29f450903230530m12738a32r434b7d8c057496c6@mail.gmail.com>

I am developing a module to enable private sections inside any organic
group. The idea is to be able to create a group and define areas like
"paper administration", "human resources", etc...

I have created a module to create and a block to choose be able to
define "staff roles" inside a OG, so now when a user create a node and
have a "staff role" activated, that role should only be visible for
users inside this group and with the "staff role" activated. I supose
I can achieve this using hook_node_grants and
hook_node_access_records, but I don't get how, could anybody give me a
hint?


My nodes are saved with:
realm= 'staff1'
gid=4
view=1
update=1
delete=1

function ogsubroles_node_grants($account, $op) {
   $grup=og_get_group_context();
  if ($_SESSION['ogsubrole_active_'.$grup->nid]) {
    $grants[$_SESSION['ogsubrole_active_'.$grup->nid]] = array(1);
    return $grants; //sempre hem de retornar alguna cosa per fer que
els no valids no es mostrin
  }
  $grants['staff1']=array(1);
  $grants['4']=array(1);
  $grants['view']=array(1);
  return $grants;
}


function ogsubroles_node_access_records($node) {
  $result = db_query('SELECT * FROM {ogsubroles_nodes} WHERE vid =
%d', $node->vid);
  while ($grant = db_fetch_object($result)) {
    $grants[] = array(
      'realm' => $grant->subrole_code,
      'gid' => $grant->gid,
      'grant_view' => 1, //$grant->grant_view,
      'grant_update' => 1, // $grant->grant_update,
      'grant_delete' => 1, //$grant->grant_delete,
    );
  }
  return $grants;
}


-- 
*La vida ?s com una taronja, que esperes a exprimir-la?
*Si creus que l'educaci? ?s cara, prova la ignor?ncia.
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From enboig at gmail.com  Mon Mar 23 13:08:54 2009
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Mon, 23 Mar 2009 14:08:54 +0100
Subject: [development] private areas inside Organic Groups
In-Reply-To: <45a29f450903230530m12738a32r434b7d8c057496c6@mail.gmail.com>
References: <45a29f450903230530m12738a32r434b7d8c057496c6@mail.gmail.com>
Message-ID: <45a29f450903230608y37a00423ka036339f8a54cb9a@mail.gmail.com>

At last I understood how hook_node_grants works; it has to return an
array containing:
$grants['realm'] = array(gid)

On Mon, Mar 23, 2009 at 1:30 PM, Llu?s <enboig at gmail.com> wrote:
> I am developing a module to enable private sections inside any organic
> group. The idea is to be able to create a group and define areas like
> "paper administration", "human resources", etc...
>
> I have created a module to create and a block to choose be able to
> define "staff roles" inside a OG, so now when a user create a node and
> have a "staff role" activated, that role should only be visible for
> users inside this group and with the "staff role" activated. I supose
> I can achieve this using hook_node_grants and
> hook_node_access_records, but I don't get how, could anybody give me a
> hint?
>
>
> My nodes are saved with:
> realm= 'staff1'
> gid=4
> view=1
> update=1
> delete=1
>
> function ogsubroles_node_grants($account, $op) {
> ? $grup=og_get_group_context();
> ?if ($_SESSION['ogsubrole_active_'.$grup->nid]) {
> ? ?$grants[$_SESSION['ogsubrole_active_'.$grup->nid]] = array(1);
> ? ?return $grants; //sempre hem de retornar alguna cosa per fer que
> els no valids no es mostrin
> ?}
> ?$grants['staff1']=array(1);
> ?$grants['4']=array(1);
> ?$grants['view']=array(1);
> ?return $grants;
> }
>
>
> function ogsubroles_node_access_records($node) {
> ?$result = db_query('SELECT * FROM {ogsubroles_nodes} WHERE vid =
> %d', $node->vid);
> ?while ($grant = db_fetch_object($result)) {
> ? ?$grants[] = array(
> ? ? ?'realm' => $grant->subrole_code,
> ? ? ?'gid' => $grant->gid,
> ? ? ?'grant_view' => 1, //$grant->grant_view,
> ? ? ?'grant_update' => 1, // $grant->grant_update,
> ? ? ?'grant_delete' => 1, //$grant->grant_delete,
> ? ?);
> ?}
> ?return $grants;
> }
>
>
> --
> *La vida ?s com una taronja, que esperes a exprimir-la?
> *Si creus que l'educaci? ?s cara, prova la ignor?ncia.
> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
> nom?s una vegada.
> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>



-- 
*La vida ?s com una taronja, que esperes a exprimir-la?
*Si creus que l'educaci? ?s cara, prova la ignor?ncia.
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From andrewberry at sentex.net  Mon Mar 23 15:53:14 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Mon, 23 Mar 2009 11:53:14 -0400
Subject: [development] PHP checkstyle
In-Reply-To: <1fcccc8a0903230331w4efe15b9n988d8d8584d71729@mail.gmail.com>
References: <1fcccc8a0903230302m47d57463y6c642288d232e55b@mail.gmail.com>
	<ff176450903230311r158d5aadp9bea98d4c0c6cb4f@mail.gmail.com>
	<1fcccc8a0903230331w4efe15b9n988d8d8584d71729@mail.gmail.com>
Message-ID: <F626AC0B-08ED-45DC-BAFF-56D1D44DE587@sentex.net>

On 23-Mar-09, at 6:31 AM, Dipen wrote:

> But I want something embedded into my IDE which prompts me of style  
> errors and coding standard errors as I make them.

If you do end up making a proper XML file for Drupal coding standards,  
please be sure to post it in the Developers handbook. I'm sure there  
are many of us who would benefit from such a system.

--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/20090323/b10a3642/attachment.bin>

From metzlerd at metzlerd.com  Mon Mar 23 17:39:51 2009
From: metzlerd at metzlerd.com (David Metzler)
Date: Mon, 23 Mar 2009 10:39:51 -0700
Subject: [development] global $user unavaialable?
In-Reply-To: <6117a7500903201130j198ae380mc127aca63b37bd41@mail.gmail.com>
References: <657008A9-4C2B-47F0-BB87-69140D6F94DC@metzlerd.com>
	<6117a7500903201130j198ae380mc127aca63b37bd41@mail.gmail.com>
Message-ID: <6A42C98B-7A3A-4068-8BF4-A030812AB048@metzlerd.com>

Thanks for pointing out the obvious flaw in my reasoning.  I really  
needed it. (Not sarcasm).  You got me going enough to put my  
debugging on track.

The Session was new because of the difference between navigating to  
http:  vs. navigating to https:  I'd originally logged in to the  
drupal 6  via http, but then the drupal 5 site redirected to https  
url of the site.  Drupal doesn't seem to detect the user as logged  
in.  Oddly enough, only if redirected there from another drupal  
site??? I can't reproduce this behavior when I just navigate to  
different sites with the browser.

Once my module detects that there's no logged in user, it redirects  
to user/login, which presents a login page.  When the user presses  
the submit button on this page, they get an access denied because  
drupal finally detects that the user is already logged in.  I'm a bit  
puzzled as to why it didn't detect this at the inital redirect, and  
really puzzled about the difference in behavior between a redirect,  
and if I just type in the url directly.

Given that this is third party soffware doing the redirect from  
drupal 5, I'm not sure whether this is a bug or not.  I can work  
around the problem by instructing users to change their $base_url on  
the cas server site to make sure that it's always https, or implement  
secure_pages or something like that.

Does anyone with more knowledge of drupal session handling have any  
idea as to why drupal would detect the currently logged in user  
incorrectly when being redirected, but not when typing the url into  
the browser?

On Mar 20, 2009, at 11:30 AM, Moshe Weitzman wrote:

> that snippit tests if the user is logged in, not if $user is
> populated. you could have a full anonymous $user object.
>
> the basic loading of a $user gets triggerred by session_start() but if
> you have to call that on your own you are way off the beaten path in
> Drupal and really need to grok whats happenning step by step in order
> to assure security and code sanity. that gives a basic $user object.
> If you need it call, you might have to call user_load() yourself.
>
> On Fri, Mar 20, 2009 at 2:02 PM, David Metzler  
> <metzlerd at metzlerd.com> wrote:
>> I'm working on implementing a new cas_server module that allows  
>> drupal
>> accounts to be used as a single - sign on source.  I have a drupal  
>> 5 site
>> issues a redirect to a drupal 6 site, and when I redirect to that  
>> page I
>> don't find that the $user global is populated.  Is there some  
>> function or
>> include that I should b calling to make sure that this data is there?
>>
>> Code snippet that isn't returning correct data.
>>
>> global $user
>> if ($user->uid) {
>>  drupal_set_message('user logged in');
>> }
>> else {
>>  drupal_set_message('User not logged in');
>> }
>>
>> Note that if I click on any other link in the drupal page.  I show  
>> as being
>> logged in, but the redirect to this page does not load the $user  
>> variable.
>>
>> Developing against drupal 6.10
>>
>>


From drupal at hatzidakis.org  Mon Mar 23 18:15:16 2009
From: drupal at hatzidakis.org (Fanis Hatzidakis)
Date: Mon, 23 Mar 2009 20:15:16 +0200
Subject: [development] PHP checkstyle
In-Reply-To: <1fcccc8a0903230331w4efe15b9n988d8d8584d71729@mail.gmail.com>
References: <1fcccc8a0903230302m47d57463y6c642288d232e55b@mail.gmail.com> 
	<ff176450903230311r158d5aadp9bea98d4c0c6cb4f@mail.gmail.com> 
	<1fcccc8a0903230331w4efe15b9n988d8d8584d71729@mail.gmail.com>
Message-ID: <614a134e0903231115u28690317r516a13df6ec2d5a5@mail.gmail.com>

PDT doesn't have it but Zend Studio for Eclipse has a php formatter
with profile import/export capability and all the customization
options I can think of. It works very well. I've been using it not
just to keep my code in check but also in order to read code by
others. Just open the file, hit ctrl+shift+F, and it formats the code
based on the currently selected profile.

There's also http://pear.php.net/package/PHP_CodeSniffer which runs
from the cli and reports on code that violates some defined standards.

Cheers,
Fanis


On Mon, Mar 23, 2009 at 12:31, Dipen <dipench at gmail.com> wrote:
> Thanks for that, but I want it for code readability where in I can set
> things like "eclipse should show a warning if I am using camelcase for
> variables", "If there are more than 100 characters in 1 line of code then it
> should present a warning and auto formatter should fold it two lines" the
> way checkstyle plugin works for java (give proper checkstyle.xml). Syntax
> errors are automatically identified by PDT, I'll look into -l as to what all
> features does it provide. But I want something embedded into my IDE which
> prompts me of style errors and coding standard errors as I make them.
> Thanks again
>
>
> On Mon, Mar 23, 2009 at 3:41 PM, Victor Kane <victorkane at gmail.com> wrote:
>>
>> PHP does have its own built in "lint" (like the one we used to use every
>> day with C programs).
>>
>> $ php -l my.module
>> No syntax errors detected in lcph.module
>>
>> See http://www.snakelegs.org/2006/05/18/lint-php/ for article.
>>
>> Victor Kane
>> http://awebfactory.com.ar
>> http://projectflowandtracker.com
>>
>>
>>
>> On Mon, Mar 23, 2009 at 7:02 AM, Dipen <dipench at gmail.com> wrote:
>>>
>>> Hi list,
>>>
>>> ?After searching google for 1 hr I am still unable to find an equivalent
>>> for java checkstyle for PHP which would play nice with eclipse. I could find
>>> this?http://developer.spikesource.com/wiki/index.php?title=Projects:phpcheckstyleNews
>>> and one abandoned project with no releases on sourceforge. Does anyone know
>>> of checkstyle eclipse plugin for PHP (doesnt need to be all featureful).
>>> Also how do you manage this kind of task? Checkstyle eclipse plugin for java
>>> -?http://eclipse-cs.sourceforge.net/
>>> Thanks
>>> Dipen
>>
>
>

From killshot91 at comcast.net  Tue Mar 24 18:46:46 2009
From: killshot91 at comcast.net (Steve Edwards)
Date: Tue, 24 Mar 2009 11:46:46 -0700
Subject: [development] Path Redirect Location Storage
Message-ID: <49C92A96.8080206@comcast.net>

I've been working with a UC module that forces the user to either log in or create a new account before being able to purchase a 
product.  The idea is that once the user has logged in or created the account, they will be redirected back to the node being 
purchased (a class registration in this case).  The way the module is trying to do it is by storing the current location in a 
$_SESSION variable, calling drupal_goto(), and in hook_form_alter(), changing the $form['#redirect'] property to the saved 
location.  The problem is, the $_SESSION array gets wiped out at the end of drupal_goto() after the header is sent to the browser, 
so when the portion of hook_form_alter that will set $form['#redirect'] back to the saved location is called, the variable is 
gone, so the user is left at their profile screen instead of being redirected.

I made a modification to pass the current location (before being directed to /user) to drupal_goto() as the $query parameter (see 
drupal.org/node/409134).  That works fine, as long as the user logs in.  However, if the user needs to create a new account, they 
click on the "Create New Account" link (which goes to /user/register), and the destination parameter is lost from the URL.  The 
data is saved to the session table, so I could query the session table with the session ID to get the URL, but seems sort of messy.

So, can anyone give me an idea of the best way to store the URL so that the user can be redirected back to where they came from 
when they are forced to create a new account?

Thanks.

Steve

From chris.struble at onstance.com  Tue Mar 24 18:42:23 2009
From: chris.struble at onstance.com (chris.struble at onstance.com)
Date: 24 Mar 2009 14:42:23 -0400
Subject: [development] =?utf-8?q?Out_of_Office_-_Re=3A__Path_Redirect_Loca?=
	=?utf-8?q?tion_Storage?=
Message-ID: <20090324184223.2925.qmail@deimos.dns-shield.com>

I regret that I will be unable to respond to email Tuesday, March 24th and Wednesday, March 25th.  If you need to contact me on an urgent matter, please leave a voice message at 503-943-9140.

Regards,
Chris Struble
Business Development Manager
OnStance Web Marketing
Phone: 503-943-9140



From chris.struble at onstance.com  Tue Mar 24 18:42:59 2009
From: chris.struble at onstance.com (chris.struble at onstance.com)
Date: 24 Mar 2009 14:42:59 -0400
Subject: [development] =?utf-8?q?Out_of_Office_-_Re=3A__Out_of_Office_-_Re?=
	=?utf-8?q?=3A__Path_Redirect_Loca=09tion_Storage?=
Message-ID: <20090324184259.3116.qmail@deimos.dns-shield.com>

I regret that I will be unable to respond to email Tuesday, March 24th and Wednesday, March 25th.  If you need to contact me on an urgent matter, please leave a voice message at 503-943-9140.

Regards,
Chris Struble
Business Development Manager
OnStance Web Marketing
Phone: 503-943-9140



From gerhard at killesreiter.de  Tue Mar 24 18:51:34 2009
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Tue, 24 Mar 2009 19:51:34 +0100
Subject: [development] Out of Office - Re: Path Redirect Location Storage
In-Reply-To: <20090324184223.2925.qmail@deimos.dns-shield.com>
References: <20090324184223.2925.qmail@deimos.dns-shield.com>
Message-ID: <49C92BB6.2060902@killesreiter.de>

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

chris.struble at onstance.com schrieb:

> Business Development Manager

What are such people doing on a devel list anyway?

Unsubscribed...

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

iEYEARECAAYFAknJK7YACgkQfg6TFvELooQgdwCgts6eP7dTIoAilISLV7lbVd6x
rbcAoMqkjHgnM/bY7Bt5urPOJV7Njyf6
=DNK+
-----END PGP SIGNATURE-----

From earnie at users.sourceforge.net  Tue Mar 24 19:17:10 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 24 Mar 2009 15:17:10 -0400
Subject: [development] Path Redirect Location Storage
In-Reply-To: <49C92A96.8080206@comcast.net>
References: <49C92A96.8080206@comcast.net>
Message-ID: <20090324151710.yngwwrt82uas40go@mail.progw.org>

Quoting Steve Edwards <killshot91 at comcast.net>:

>
> So, can anyone give me an idea of the best way to store the URL so 
> that the user can be redirected back to where they came from when 
> they are forced to create a new account?
>

?destination=http://sample.com/go/here

or

#destination='go/here'

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


From lewiswright at gmail.com  Tue Mar 24 19:22:49 2009
From: lewiswright at gmail.com (Lewis Wright)
Date: Tue, 24 Mar 2009 19:22:49 +0000
Subject: [development] Path Redirect Location Storage
In-Reply-To: <20090324151710.yngwwrt82uas40go@mail.progw.org>
References: <49C92A96.8080206@comcast.net>
	<20090324151710.yngwwrt82uas40go@mail.progw.org>
Message-ID: <f3eeaf7e0903241222y16305e80kd038b51de42e3291@mail.gmail.com>

#destination='go/here' won't work because anything after the hash is
not sent to the server.

2009/3/24 Earnie Boyd <earnie at users.sourceforge.net>:
> Quoting Steve Edwards <killshot91 at comcast.net>:
>
>>
>> So, can anyone give me an idea of the best way to store the URL so that
>> the user can be redirected back to where they came from when they are forced
>> to create a new account?
>>
>
> ?destination=http://sample.com/go/here
>
> or
>
> #destination='go/here'
>
> --
> Earnie ?http://r-feed.com
> ?Make a Drupal difference and review core patches.
>
> -- http://for-my-kids.com/ ?-- http://www.4offer.biz/
>
>

From killshot91 at comcast.net  Tue Mar 24 19:28:55 2009
From: killshot91 at comcast.net (Steve Edwards)
Date: Tue, 24 Mar 2009 12:28:55 -0700
Subject: [development] Path Redirect Location Storage
In-Reply-To: <20090324151710.yngwwrt82uas40go@mail.progw.org>
References: <49C92A96.8080206@comcast.net>
	<20090324151710.yngwwrt82uas40go@mail.progw.org>
Message-ID: <49C93477.4020900@comcast.net>

I did exactly that.  In my case, I was at /node/add/registration, which is where I wanted to go back to after registration/account 
creation, and redirected the user to /user, i.e.:

   drupal_goto('user',drupal_get_destination());

That takes the user to /mysite.com/user?destination=node%2Fadd%2Fregistration%3Fproduct_nid%3D2.  If he logs in from there, he is 
redirected back to mysite.com/node/add/registration.

However, if he is a new user and needs to create an account first, he clicks on the "Create New Account" link, which takes him to 
/user/register (without ?destination).  Therefore, when he is done registering, there is no ?destination parameter for the Forms 
API, so he stays at the user screen.

The way the module does the redirect after that is in hook_form_alter().  It looks for the 'node_checkout_redirect' variable on 
the user screens, and if it sees it, redirects to whatever is stored there.  But, as I mentioned, since $_SESSION is wiped out at 
the end of drupal_goto(), it doesn't know that the redirect needs to happen.  That's why I'm looking for an alternate storage 
location for that redirection location.

Steve

Earnie Boyd wrote:
> Quoting Steve Edwards <killshot91 at comcast.net>:
> 
>>
>> So, can anyone give me an idea of the best way to store the URL so 
>> that the user can be redirected back to where they came from when they 
>> are forced to create a new account?
>>
> 
> ?destination=http://sample.com/go/here
> 
> or
> 
> #destination='go/here'
> 
> -- 
> Earnie  http://r-feed.com
>  Make a Drupal difference and review core patches.
> 
> -- http://for-my-kids.com/  -- http://www.4offer.biz/
> 
> 

From earnie at users.sourceforge.net  Tue Mar 24 19:48:11 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 24 Mar 2009 19:48:11 +0000
Subject: [development] Path Redirect Location Storage
In-Reply-To: <49C93477.4020900@comcast.net>
References: <49C92A96.8080206@comcast.net>
	<20090324151710.yngwwrt82uas40go@mail.progw.org>
	<49C93477.4020900@comcast.net>
Message-ID: <20090324194811.lz1xaaoa8sso488g@mail.siebunlimited.com>

Quoting Steve Edwards <killshot91 at comcast.net>:

>
> However, if he is a new user and needs to create an account first, he
> clicks on the "Create New Account" link, which takes him to
> /user/register (without ?destination).  Therefore, when he is done
> registering, there is no ?destination parameter for the Forms API, so
> he stays at the user screen.
>
> The way the module does the redirect after that is in
> hook_form_alter().  It looks for the 'node_checkout_redirect' variable
> on the user screens, and if it sees it, redirects to whatever is stored
> there.  But, as I mentioned, since $_SESSION is wiped out at the end of
> drupal_goto(), it doesn't know that the redirect needs to happen.
> That's why I'm looking for an alternate storage location for that
> redirection location.
>

How about the $form_state['storage']?  http://drupal.org/node/144132

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From Alex at ZivTech.com  Tue Mar 24 21:49:07 2009
From: Alex at ZivTech.com (Alex Urevick-Ackelsberg)
Date: Tue, 24 Mar 2009 17:49:07 -0400
Subject: [development] Summer of Code starts... now!
Message-ID: <37b3830e0903241449n46f74823y22da4c201561d85e@mail.gmail.com>

Hi all-

Just wanted to let everyone know that students officially began
submitting applications to participate in the Summer of Code this past
week. In order to insure we get the highest quality students, and the
best projects, it would be great if you could give a spend a few
minutes of your time reviewing and commenting on ideas. If you're
planning on mentoring, you should:

* sign up to the Summer of Code 2009 Mentors group at
http://groups.drupal.org/soc-2009-mentors
* apply to be a mentor on the the Official Summer of Code site at
http://socghop.appspot.com/  (see instructions below in the comments
of this post: http://groups.drupal.org/node/20496#comment-70812 )
* review ideas, create ideas, and most importantly, help the students
navigate through the often choppy community waters on the groups site
and IRC.
* if you're interested mentoring one of the proposed ideas you should
comment on that proposal's discussion to let students know that
mentors are willing to work with them

Also- if you need to reach me and can't find me in the #drupal irc
channel, please feel free to send me an e-mail (alex at zivtech). I
can usually jump on IRC on my iphone if I'm not at a computer, so
please don't hesitate to contact me with any questions, ideas, or
concerns you have.

Thanks!!!

p.s. sorry for the multiple posts, I want to make sure everyone gets
the word that the SoC is in full swing, and that the time is now if
you have an idea for a project or would like to help us find the next
Drupal superstar.

--
Alex Urevick-Ackelsberg
ZivTech, LLC
http://zivtech.com
alex at zivtech.com
office: (267) 940-7737
cell: (215) 866-8956
skype: zivtech
aim: zivtech

From Alex at ZivTech.com  Wed Mar 25 00:25:01 2009
From: Alex at ZivTech.com (Alex Urevick-Ackelsberg)
Date: Tue, 24 Mar 2009 20:25:01 -0400
Subject: [development] Summer of Code starts... now!
In-Reply-To: <37b3830e0903241449n46f74823y22da4c201561d85e@mail.gmail.com>
References: <37b3830e0903241449n46f74823y22da4c201561d85e@mail.gmail.com>
Message-ID: <37b3830e0903241725m71d2356bke8b58e31c0e8ef20@mail.gmail.com>

Hi all-

it seems that people are having problems signing up for the mentors group.
If you want to be on the SoC 2009 Mentors group, please shoot me an e-mail
with your g.d.o user page.

Sorry for the problems!

--
Alex Urevick-Ackelsberg
ZivTech, LLC
http://zivtech.com
alex at zivtech.com
office: (267) 940-7737
cell: (215) 866-8956
skype: zivtech
aim: zivtech


On Tue, Mar 24, 2009 at 5:49 PM, Alex Urevick-Ackelsberg
<Alex at zivtech.com>wrote:

> Hi all-
>
> Just wanted to let everyone know that students officially began
> submitting applications to participate in the Summer of Code this past
> week. In order to insure we get the highest quality students, and the
> best projects, it would be great if you could give a spend a few
> minutes of your time reviewing and commenting on ideas. If you're
> planning on mentoring, you should:
>
> * sign up to the Summer of Code 2009 Mentors group at
> http://groups.drupal.org/soc-2009-mentors
> * apply to be a mentor on the the Official Summer of Code site at
> http://socghop.appspot.com/  (see instructions below in the comments
> of this post: http://groups.drupal.org/node/20496#comment-70812 )
> * review ideas, create ideas, and most importantly, help the students
> navigate through the often choppy community waters on the groups site
> and IRC.
> * if you're interested mentoring one of the proposed ideas you should
> comment on that proposal's discussion to let students know that
> mentors are willing to work with them
>
> Also- if you need to reach me and can't find me in the #drupal irc
> channel, please feel free to send me an e-mail (alex at zivtech). I
> can usually jump on IRC on my iphone if I'm not at a computer, so
> please don't hesitate to contact me with any questions, ideas, or
> concerns you have.
>
> Thanks!!!
>
> p.s. sorry for the multiple posts, I want to make sure everyone gets
> the word that the SoC is in full swing, and that the time is now if
> you have an idea for a project or would like to help us find the next
> Drupal superstar.
>
> --
> Alex Urevick-Ackelsberg
> ZivTech, LLC
> http://zivtech.com
> alex at zivtech.com
> office: (267) 940-7737
> cell: (215) 866-8956
> skype: zivtech
> aim: zivtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090324/4d20df05/attachment-0001.htm>

From amont at 5net.hu  Wed Mar 25 15:07:13 2009
From: amont at 5net.hu (=?ISO-8859-2?Q?=C1mon_Tam=E1s?=)
Date: Wed, 25 Mar 2009 16:07:13 +0100
Subject: [development] Search
Message-ID: <49CA48A1.7040308@5net.hu>

Hello,

I like to add some search result from a different site to drupal. I like 
to show the search results mixed in the other and drupal site. I try to 
use mnogosearch to index the other site, but I can not insert the 
results to the drupal results. How can I make it?



?mon Tam?s

Sitefejleszt? ?s programoz?
-- 
5NET Informatikai Kft.
1062 Budapest, Aradi utca 38. A 3/11
telefon: (1) 461-0205  |  fax: (1) 461-0206
e-mail: amont at 5net.hu  |  web: http://www.5net.hu


From kb at 2bits.com  Wed Mar 25 15:22:01 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Wed, 25 Mar 2009 11:22:01 -0400
Subject: [development] Search
In-Reply-To: <49CA48A1.7040308@5net.hu>
References: <49CA48A1.7040308@5net.hu>
Message-ID: <4a9fdc630903250822l5edfb759g5e9599b8199c4c1b@mail.gmail.com>

This is what we do on a Drupal 5 site. Should work more or less the same on
D6 as well.

In template.php, we include an inc file that handles the XML from the
external site, and then we add "sponsored results". Like so:


function phptemplate_search_page($results, $type) {
  $enable_external = FALSE;

  $external = path_to_theme() . '/something_search.inc';
  if (file_exists($external)) {
    include_once($external);
    if (function_exists('external_search')) {
      $enable_external = TRUE;

      // This is the search term. Remove + in case it is a multiword search
      //$key = trim(preg_replace('/\+/i', ' ', arg(2)));
      $key = arg(2);

      // run the function to get results
      $external_results = external_search($key);

      list($jr_top, $jr_bottom, $jr_sidebar) = $external_results;
    }
  }

  $output = '<dl class="search-results">';

  if ($enable_external) $output .= '<div class="sponsored">' . $jr_top .
'</div>';

  foreach ($results as $entry) {
    $output .= theme('search_item', $entry, $type);
  }

  if ($enable_external) $output .= '<div class="sponsored">' . $jr_bottom .
'</div>';

  $output .= '</dl>';
  $output .= theme('pager', NULL, 10, 0);

  return $output;
}


2009/3/25 ?mon Tam?s <amont at 5net.hu>

> Hello,
>
> I like to add some search result from a different site to drupal. I like to
> show the search results mixed in the other and drupal site. I try to use
> mnogosearch to index the other site, but I can not insert the results to the
> drupal results. How can I make it?
>
>
>
> ?mon Tam?s
>
> Sitefejleszt? ?s programoz?
> --
> 5NET Informatikai Kft.
> 1062 Budapest, Aradi utca 38. A 3/11
> telefon: (1) 461-0205  |  fax: (1) 461-0206
> e-mail: amont at 5net.hu  |  web: http://www.5net.hu
>
>


-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090325/a8119202/attachment.htm>

From amont at 5net.hu  Wed Mar 25 15:48:45 2009
From: amont at 5net.hu (=?ISO-8859-2?Q?=C1mon_Tam=E1s?=)
Date: Wed, 25 Mar 2009 16:48:45 +0100
Subject: [development] Search
In-Reply-To: <4a9fdc630903250822l5edfb759g5e9599b8199c4c1b@mail.gmail.com>
References: <49CA48A1.7040308@5net.hu>
	<4a9fdc630903250822l5edfb759g5e9599b8199c4c1b@mail.gmail.com>
Message-ID: <49CA525D.3010809@5net.hu>

Thanks, but I like to user the other result like the drupal result and I 
like to mix it.

2009-03-25 16:22 keltez?ssel, Khalid Baheyeldin ?rta:
> This is what we do on a Drupal 5 site. Should work more or less the 
> same on D6 as well.
>
> In template.php, we include an inc file that handles the XML from the 
> external site, and then we add "sponsored results". Like so:
>
>
> function phptemplate_search_page($results, $type) {
>   $enable_external = FALSE;
>
>   $external = path_to_theme() . '/something_search.inc';
>   if (file_exists($external)) {
>     include_once($external);
>     if (function_exists('external_search')) {
>       $enable_external = TRUE;
>
>       // This is the search term. Remove + in case it is a multiword 
> search
>       //$key = trim(preg_replace('/\+/i', ' ', arg(2)));
>       $key = arg(2);
>
>       // run the function to get results
>       $external_results = external_search($key);
>
>       list($jr_top, $jr_bottom, $jr_sidebar) = $external_results;
>     }
>   }
>
>   $output = '<dl class="search-results">';
>
>   if ($enable_external) $output .= '<div class="sponsored">' . $jr_top 
> . '</div>';
>
>   foreach ($results as $entry) {
>     $output .= theme('search_item', $entry, $type);
>   }
>
>   if ($enable_external) $output .= '<div class="sponsored">' . 
> $jr_bottom . '</div>';
>
>   $output .= '</dl>';
>   $output .= theme('pager', NULL, 10, 0);
>
>   return $output;
> }
>
>
> 2009/3/25 ?mon Tam?s <amont at 5net.hu <mailto:amont at 5net.hu>>
>
>     Hello,
>
>     I like to add some search result from a different site to drupal.
>     I like to show the search results mixed in the other and drupal
>     site. I try to use mnogosearch to index the other site, but I can
>     not insert the results to the drupal results. How can I make it?
>
>
>
>     ?mon Tam?s
>
>     Sitefejleszt? ?s programoz?
>     -- 
>     5NET Informatikai Kft.
>     1062 Budapest, Aradi utca 38. A 3/11
>     telefon: (1) 461-0205  |  fax: (1) 461-0206
>     e-mail: amont at 5net.hu <mailto:amont at 5net.hu>  |  web:
>     http://www.5net.hu
>
>
>
>
> -- 
> Khalid M. Baheyeldin
> 2bits.com <http://2bits.com>, Inc.
> http://2bits.com
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. --   Leonardo da Vinci


?mon Tam?s
Sitefejleszt? ?s programoz?
-- 
5NET Informatikai Kft.
1062 Budapest, Aradi utca 38. A 3/11
telefon: (1) 461-0205  |  fax: (1) 461-0206
e-mail: amont at 5net.hu  |  web: http://www.5net.hu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090325/f041a431/attachment.htm>

From kb at 2bits.com  Wed Mar 25 16:01:19 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Wed, 25 Mar 2009 12:01:19 -0400
Subject: [development] Search
In-Reply-To: <49CA525D.3010809@5net.hu>
References: <49CA48A1.7040308@5net.hu>
	<4a9fdc630903250822l5edfb759g5e9599b8199c4c1b@mail.gmail.com>
	<49CA525D.3010809@5net.hu>
Message-ID: <4a9fdc630903250901u72fa68bbv2480f0e8d35d12dd@mail.gmail.com>

You can still do that.

You still use the phptemplate_search_page().

Do your own search, and then array_merge() with $results, and then call
theme('search_item') on the combined result.

2009/3/25 ?mon Tam?s <amont at 5net.hu>

>  Thanks, but I like to user the other result like the drupal result and I
> like to mix it.
>
> 2009-03-25 16:22 keltez?ssel, Khalid Baheyeldin ?rta:
>
> This is what we do on a Drupal 5 site. Should work more or less the same on
> D6 as well.
>
> In template.php, we include an inc file that handles the XML from the
> external site, and then we add "sponsored results". Like so:
>
>
> function phptemplate_search_page($results, $type) {
>   $enable_external = FALSE;
>
>   $external = path_to_theme() . '/something_search.inc';
>   if (file_exists($external)) {
>     include_once($external);
>     if (function_exists('external_search')) {
>       $enable_external = TRUE;
>
>       // This is the search term. Remove + in case it is a multiword search
>       //$key = trim(preg_replace('/\+/i', ' ', arg(2)));
>       $key = arg(2);
>
>       // run the function to get results
>       $external_results = external_search($key);
>
>       list($jr_top, $jr_bottom, $jr_sidebar) = $external_results;
>     }
>   }
>
>   $output = '<dl class="search-results">';
>
>   if ($enable_external) $output .= '<div class="sponsored">' . $jr_top .
> '</div>';
>
>   foreach ($results as $entry) {
>     $output .= theme('search_item', $entry, $type);
>   }
>
>   if ($enable_external) $output .= '<div class="sponsored">' . $jr_bottom .
> '</div>';
>
>   $output .= '</dl>';
>   $output .= theme('pager', NULL, 10, 0);
>
>   return $output;
> }
>
>
> 2009/3/25 ?mon Tam?s <amont at 5net.hu>
>
>> Hello,
>>
>> I like to add some search result from a different site to drupal. I like
>> to show the search results mixed in the other and drupal site. I try to use
>> mnogosearch to index the other site, but I can not insert the results to the
>> drupal results. How can I make it?
>>
>>
>>
>> ?mon Tam?s
>>
>> Sitefejleszt? ?s programoz?
>> --
>> 5NET Informatikai Kft.
>> 1062 Budapest, Aradi utca 38. A 3/11
>> telefon: (1) 461-0205  |  fax: (1) 461-0206
>> e-mail: amont at 5net.hu  |  web: http://www.5net.hu
>>
>>
>
>
> --
> Khalid M. Baheyeldin
> 2bits.com, Inc.
> http://2bits.com
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. --   Leonardo da Vinci
>
>
>
> ?mon Tam?s
> Sitefejleszt? ?s programoz?
> --
> 5NET Informatikai Kft.
> 1062 Budapest, Aradi utca 38. A 3/11
> telefon: (1) 461-0205  |  fax: (1) 461-0206
> e-mail: amont at 5net.hu  |  web: http://www.5net.hu
>
>


-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090325/45652b38/attachment-0001.htm>

From andrewberry at sentex.net  Wed Mar 25 19:06:11 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Wed, 25 Mar 2009 15:06:11 -0400
Subject: [development] Search
In-Reply-To: <49CA525D.3010809@5net.hu>
References: <49CA48A1.7040308@5net.hu>
	<4a9fdc630903250822l5edfb759g5e9599b8199c4c1b@mail.gmail.com>
	<49CA525D.3010809@5net.hu>
Message-ID: <A57833DF-DC44-44B4-AE64-2B1EE02615E2@sentex.net>

On 25-Mar-09, at 11:48 AM, ?mon Tam?s wrote:

> Thanks, but I like to user the other result like the drupal result  
> and I like to mix it.

You might also be able to do this with hook_search and  
hook_update_index. AFAIK there is no restriction on where the content  
comes from, however it does end up getting indexed in Drupal as well.  
So it's probably not what you want if you all ready have a search  
index on the remote site.

See http://api.drupal.org/api/group/search/6 and http://api.drupal.org/api/function/hook_search/6

--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/20090325/fe9a18ad/attachment.bin>

From enboig at gmail.com  Thu Mar 26 12:31:28 2009
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Thu, 26 Mar 2009 13:31:28 +0100
Subject: [development] calling node_add from another url
Message-ID: <45a29f450903260531q1044aa33md956ecbfa7166628@mail.gmail.com>

I am creating submenus integrated inside a module using OG, I need
something like

  $items['node/%node/proveidors/afegir'] = array(
    'title' => 'Afegir Prov?edor', //trans
    'page callback' => 'node_add',
    'page arguments' => array('proveidor'),
    'access arguments' => array('create',0,$user),
    'access callback' => 'proveidors_access',
    'type' => MENU_LOCAL_TASK,
  );

but it don't work because "node_add" is inside a .inc file; a solution
could be make it an alias of "node/create/proveidor&gid[]%node", where
%node is the id of the organic group, but I don't know how to do this
(neither if it is possible).

Any idea?

thanks

-- 
*La vida ?s com una taronja, que esperes a exprimir-la?
*Si creus que l'educaci? ?s cara, prova la ignor?ncia.
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From mike at mikeyp.net  Thu Mar 26 12:41:19 2009
From: mike at mikeyp.net (Michael Prasuhn)
Date: Thu, 26 Mar 2009 05:41:19 -0700
Subject: [development] calling node_add from another url
In-Reply-To: <45a29f450903260531q1044aa33md956ecbfa7166628@mail.gmail.com>
References: <45a29f450903260531q1044aa33md956ecbfa7166628@mail.gmail.com>
Message-ID: <D53F1A22-2B9C-43E2-AF59-30B1E19A54D9@mikeyp.net>

Try this:

$items['node/%node/proveidors/afegir'] = array(
   'title' => 'Afegir Prov?edor', //trans
   'page callback' => 'node_add',
   'page arguments' => array('proveidor'),
   'access arguments' => array('create',0,$user),
   'access callback' => 'proveidors_access',
   'type' => MENU_LOCAL_TASK,
   'file' => 'node.pages.inc',
   'file path' => drupal_get_path('module', 'node'),
);


-Mike

On Mar 26, 2009, at 5:31 AM, Llu?s wrote:
> I am creating submenus integrated inside a module using OG, I need
> something like
>
>  $items['node/%node/proveidors/afegir'] = array(
>    'title' => 'Afegir Prov?edor', //trans
>    'page callback' => 'node_add',
>    'page arguments' => array('proveidor'),
>    'access arguments' => array('create',0,$user),
>    'access callback' => 'proveidors_access',
>    'type' => MENU_LOCAL_TASK,
>  );
>
> but it don't work because "node_add" is inside a .inc file; a solution
> could be make it an alias of "node/create/proveidor&gid[]%node", where
> %node is the id of the organic group, but I don't know how to do this
> (neither if it is possible).
>
> Any idea?


__________________
Michael Prasuhn
503.488.5433 office
mike at mikeyp.net
http://mikeyp.net






From enboig at gmail.com  Thu Mar 26 13:20:16 2009
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Thu, 26 Mar 2009 14:20:16 +0100
Subject: [development] calling node_add from another url
In-Reply-To: <D53F1A22-2B9C-43E2-AF59-30B1E19A54D9@mikeyp.net>
References: <45a29f450903260531q1044aa33md956ecbfa7166628@mail.gmail.com>
	<D53F1A22-2B9C-43E2-AF59-30B1E19A54D9@mikeyp.net>
Message-ID: <45a29f450903260620i2ed45e4ex569e6967615276ac@mail.gmail.com>

now it works, thanks.

On Thu, Mar 26, 2009 at 1:41 PM, Michael Prasuhn <mike at mikeyp.net> wrote:
> Try this:
>
> $items['node/%node/proveidors/afegir'] = array(
> ?'title' => 'Afegir Prov?edor', //trans
> ?'page callback' => 'node_add',
> ?'page arguments' => array('proveidor'),
> ?'access arguments' => array('create',0,$user),
> ?'access callback' => 'proveidors_access',
> ?'type' => MENU_LOCAL_TASK,
> ?'file' => 'node.pages.inc',
> ?'file path' => drupal_get_path('module', 'node'),
> );
>
>
> -Mike
>
> On Mar 26, 2009, at 5:31 AM, Llu?s wrote:
>>
>> I am creating submenus integrated inside a module using OG, I need
>> something like
>>
>> ?$items['node/%node/proveidors/afegir'] = array(
>> ? 'title' => 'Afegir Prov?edor', //trans
>> ? 'page callback' => 'node_add',
>> ? 'page arguments' => array('proveidor'),
>> ? 'access arguments' => array('create',0,$user),
>> ? 'access callback' => 'proveidors_access',
>> ? 'type' => MENU_LOCAL_TASK,
>> ?);
>>
>> but it don't work because "node_add" is inside a .inc file; a solution
>> could be make it an alias of "node/create/proveidor&gid[]%node", where
>> %node is the id of the organic group, but I don't know how to do this
>> (neither if it is possible).
>>
>> Any idea?
>
>
> __________________
> Michael Prasuhn
> 503.488.5433 office
> mike at mikeyp.net
> http://mikeyp.net
>
>
>
>
>
>



-- 
*La vida ?s com una taronja, que esperes a exprimir-la?
*Si creus que l'educaci? ?s cara, prova la ignor?ncia.
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From drupal.beginner at wechange.org  Fri Mar 27 04:58:57 2009
From: drupal.beginner at wechange.org (augustin (beginner))
Date: Fri, 27 Mar 2009 12:58:57 +0800
Subject: [development] node not fully loaded in hook_view() when previewing
Message-ID: <200903271258.58438.drupal.beginner@wechange.org>

Hello,

In a module with its own node type, the node is not fully loaded when using 
preview.

In hook_load(), I return my own extra fields to the node:
return array('mynodetype' => $extra);

In hook_view(), $node->mynodetype is set when viewing the node, but not when 
editing then previewing the same node. Isn't the node loaded as for a normal 
node view?


I've searched drupal.org but didn't find anything terribly useful.

I found this old forum post:
Philosophy of 'Preview'
http://drupal.org/node/126750

And this old core issue, which I had helped reviewing at the time, but which 
is supposed to be fixed (though it was not said how it was fixed):
node previews broken by missing hook_submit
http://drupal.org/node/104047


Is this a known issue?


Blessings,


Augustin.

From drupal.beginner at wechange.org  Fri Mar 27 07:07:02 2009
From: drupal.beginner at wechange.org (augustin (beginner))
Date: Fri, 27 Mar 2009 15:07:02 +0800
Subject: [development] node not fully loaded in hook_update() in node
	admin form
In-Reply-To: <200903271258.58438.drupal.beginner@wechange.org>
References: <200903271258.58438.drupal.beginner@wechange.org>
Message-ID: <200903271507.03200.drupal.beginner@wechange.org>


Hello again,

I have a different but related problem:
If I update a node (e.g. published /not published) using the admin form at 
admin/content/node , hook_update() does not have the full node either, and 
notices are spewed out because none of my custom fields defined in 
hook_load() are set.

Are hook_view() and hook_update() supposed to node_load() the nodes 
themselves?

Looking back at some of my modules, I see some instances where I have done 
$node =  mynodetype_load($node) to get a full node.


Thanks,

Augustin.

From jpetso at gmx.at  Fri Mar 27 07:46:54 2009
From: jpetso at gmx.at (Jakob Petsovits)
Date: Fri, 27 Mar 2009 08:46:54 +0100
Subject: [development] node not fully loaded in hook_view() when
	previewing
In-Reply-To: <200903271258.58438.drupal.beginner@wechange.org>
References: <200903271258.58438.drupal.beginner@wechange.org>
Message-ID: <200903270846.54410.jpetso@gmx.at>

On Friday 27 March 2009, augustin (beginner) wrote:
> Hello,
>
> In a module with its own node type, the node is not fully loaded when using
> preview.
>
> In hook_load(), I return my own extra fields to the node:
> return array('mynodetype' => $extra);
>
> In hook_view(), $node->mynodetype is set when viewing the node, but not
> when editing then previewing the same node. Isn't the node loaded as for a
> normal node view?

No, because it might not even exist yet in the database ("create content").
However, submitted values as in $form_state['values'] will be merged into the 
node object on preview and save, so you might e.g. add more node properties in 
hook_nodeapi($op='validate'), or stuff.

Cheers,
  j


From earnie at users.sourceforge.net  Fri Mar 27 12:01:00 2009
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Fri, 27 Mar 2009 12:01:00 +0000
Subject: [development] node not fully loaded in hook_update() in
	node	admin form
In-Reply-To: <200903271507.03200.drupal.beginner@wechange.org>
References: <200903271258.58438.drupal.beginner@wechange.org>
	<200903271507.03200.drupal.beginner@wechange.org>
Message-ID: <20090327120100.wz4ip82n4kwkkw0s@mail.siebunlimited.com>

Quoting "augustin (beginner)" <drupal.beginner at wechange.org>:

>
> Hello again,
>
> I have a different but related problem:
> If I update a node (e.g. published /not published) using the admin form at
> admin/content/node , hook_update() does not have the full node either, and
> notices are spewed out because none of my custom fields defined in
> hook_load() are set.
>
> Are hook_view() and hook_update() supposed to node_load() the nodes
> themselves?
>
> Looking back at some of my modules, I see some instances where I have done
> $node =  mynodetype_load($node) to get a full node.
>

You might need to change the weight of your module in the system table  
so that it executes later than the node and/or the taxonomy modules.   
Hooks are called in order of weight and within weight by the ascending  
sort order of the name of the module.  The default weight is zero.   
Otherwise you may have a module installed that is badly mistreating  
the node object.

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

-- http://for-my-kids.com/  -- http://www.4offer.biz/



From larry at garfieldtech.com  Fri Mar 27 19:47:54 2009
From: larry at garfieldtech.com (larry at garfieldtech.com)
Date: Fri, 27 Mar 2009 14:47:54 -0500
Subject: [development] node not fully loaded in hook_view() when
	previewing
In-Reply-To: <200903271258.58438.drupal.beginner@wechange.org>
References: <200903271258.58438.drupal.beginner@wechange.org>
Message-ID: <49CD2D6A.8060403@garfieldtech.com>

augustin (beginner) wrote:
> Hello,
> 
> In a module with its own node type, the node is not fully loaded when using 
> preview.
> 
> In hook_load(), I return my own extra fields to the node:
> return array('mynodetype' => $extra);
> 
> In hook_view(), $node->mynodetype is set when viewing the node, but not when 
> editing then previewing the same node. Isn't the node loaded as for a normal 
> node view?
> 
> 
> I've searched drupal.org but didn't find anything terribly useful.
> 
> I found this old forum post:
> Philosophy of 'Preview'
> http://drupal.org/node/126750
> 
> And this old core issue, which I had helped reviewing at the time, but which 
> is supposed to be fixed (though it was not said how it was fixed):
> node previews broken by missing hook_submit
> http://drupal.org/node/104047
> 
> 
> Is this a known issue?

Sort of.  Remember that despite being called $node what you get for 
preview and insert/update hooks is NOT a node object.  It's 
$form_state['values'].  Unless you call node_save() yourself from 
soemwhere, in which case it IS a node object.  Thus you need to 
structure your node data and your node form additions to parallel each 
other, or stuff breaks horribly in horrific ways.

This is a known design flaw in the node system.  It royally sucks on 
innumerable levels.  I think the most likely solution in the long run is 
"if it's not a Field, sucks to be you, use Fields".

Not a great solution, but it is what it is.

--Larry Garfield

From news at unleashedmind.com  Fri Mar 27 20:29:25 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Fri, 27 Mar 2009 21:29:25 +0100
Subject: [development] Help revolutionize project work and collaboration on
	drupal.org!
Message-ID: <101201c9af1a$b8cd90e0$0200a8c0@structworks.com>

Derek Wright (dww) has been so kind to create a public and focused ChipIn
for the one thing we are all waiting for:

#34496 Add Flag integration [1]

It is a major milestone for the way we work with projects and issues on
drupal.org.  I encourage everyone who would like to see projects emerging
faster, and especially everyone who builds Drupal sites for clients to
contribute to this ChipIn.  It will allow the dedicated developers, Derek
Wright, Chad Philips, and David Strauss, to work on the implementation on
drupal.org.

Benefits for you:

- One-click subscribing to issues of your interest!

  No more need to leave a senseless comment.  No more "+1" or
  "subscribing".  Just click.  Only follow-up when you have something
  relevant to say.

- Know how popular a feature or serious a bug is by the amount of
  subscribers!

  A new way for developers to identify issues that should be done.  A new
  way to identify the needs and interests of users of a module.

- Allow your co-maintainers to co-maintain!

  Finally, anyone will be able to have the same project issue view like
  project owners.  Your co-maintainers see all new issues and issue
  updates like you.  Removing the burden from the primary maintainer!

- A whole new contributor role: sub-maintainers!

  Anyone can easily keep an eye on any project of interest.  You can't code?
  But you know how a module works?  Then you can help with support requests,
  design decisions, documentation issues, and whatnot.  Removing even more
  burden from the project maintainers, meaning: more time to actually DO
  and improve something!

- Get issue updates of all subscribed issues via mail or RSS!

  You'll be able to granularly define for which issues you want e-mail
  notifications.


Read about further details and contribute on
http://3281d.com/2009/03/27/death-to-subscribe-comments

Thanks,
sun

[1] #34496 Add Flag integration
    http://drupal.org/node/34496


From drupal.beginner at wechange.org  Sat Mar 28 11:02:57 2009
From: drupal.beginner at wechange.org (augustin (beginner))
Date: Sat, 28 Mar 2009 19:02:57 +0800
Subject: [development]
	=?utf-8?q?node_not_fully_loaded_in_hook=5Fupdate=28?=
	=?utf-8?q?=29_in_node=09admin_form?=
In-Reply-To: <20090327120100.wz4ip82n4kwkkw0s@mail.siebunlimited.com>
References: <200903271258.58438.drupal.beginner@wechange.org>
	<200903271507.03200.drupal.beginner@wechange.org>
	<20090327120100.wz4ip82n4kwkkw0s@mail.siebunlimited.com>
Message-ID: <200903281902.57569.drupal.beginner@wechange.org>

On Friday 27 March 2009 20:01:00 Earnie Boyd wrote:
> You might need to change the weight of your module in the system table ?
> so that it executes later than the node and/or the taxonomy modules. ?
> Hooks are called in order of weight and within weight by the ascending ?
> sort order of the name of the module. ?The default weight is zero. ?
> Otherwise you may have a module installed that is badly mistreating ?
> the node object.

Thanks. I needed the reminder about module weights. I often forget about it.

Still, my module name is cw.module, it previously had a weight of 0. I have 
just upped the weight to 10 and see no difference.

In any case, since I define the node type cw_charity, cw_charity_load() should 
be called before cw_charity_view() or before cw_charity_update(), which I 
explained does not seem to happen in some special cases (node preview + node 
admin form). 



Augustin.




-- 
http://openteacher.info/
http://overshoot.tv/
http://charityware.info/
http://minguo.info/

From drupal.beginner at wechange.org  Sat Mar 28 11:04:46 2009
From: drupal.beginner at wechange.org (augustin (beginner))
Date: Sat, 28 Mar 2009 19:04:46 +0800
Subject: [development] node not fully loaded in hook_view() when
	previewing
In-Reply-To: <200903270846.54410.jpetso@gmx.at>
References: <200903271258.58438.drupal.beginner@wechange.org>
	<200903270846.54410.jpetso@gmx.at>
Message-ID: <200903281904.47149.drupal.beginner@wechange.org>

On Friday 27 March 2009 15:46:54 Jakob Petsovits wrote:
> No, because it might not even exist yet in the database ("create content").

Yes, this is another scenario that I hadn't mentioned but that I was aware of.

> However, submitted values as in $form_state['values'] will be merged into
> the node object on preview and save, so you might e.g. add more node
> properties in hook_nodeapi($op='validate'), or stuff.

I'll test along those lines, thanks.

Augustin.



-- 
http://openteacher.info/
http://overshoot.tv/
http://charityware.info/
http://minguo.info/

From drupal.beginner at wechange.org  Sat Mar 28 11:15:07 2009
From: drupal.beginner at wechange.org (augustin (beginner))
Date: Sat, 28 Mar 2009 19:15:07 +0800
Subject: [development] node not fully loaded in hook_view() when
	previewing
In-Reply-To: <49CD2D6A.8060403@garfieldtech.com>
References: <200903271258.58438.drupal.beginner@wechange.org>
	<49CD2D6A.8060403@garfieldtech.com>
Message-ID: <200903281915.07430.drupal.beginner@wechange.org>

On Saturday 28 March 2009 03:47:54 larry at garfieldtech.com wrote:
> Sort of. ?Remember that despite being called $node what you get for
> preview and insert/update hooks is NOT a node object. ?It's
> $form_state['values']. ?Unless you call node_save() yourself from
> soemwhere, in which case it IS a node object. ?Thus you need to
> structure your node data and your node form additions to parallel each
> other, or stuff breaks horribly in horrific ways.
>
> This is a known design flaw in the node system. ?It royally sucks on
> innumerable levels. ?I think the most likely solution in the long run is
> "if it's not a Field, sucks to be you, use Fields".
>
> Not a great solution, but it is what it is.

Hmmm, yes. Great comments. Now that you mention it, I had observed this before 
but it didn't really 'click' until now. Thanks.

That's crazy, really. 
The same function hook_view() would be passed either a fully loaded node in 
case of a normal node view OR a half backed, FAPI-ish node in case of a node 
preview (either when creating a new node or editing an existing one). 



> Thus you need to 
> structure your node data and your node form additions to parallel each
> other, or stuff breaks horribly in horrific ways.

I think I am starting to get this... ! ;)

Is this design flaw still applicable in Drupal 7?
Is there an issue about it?


In conclusion, if I understand well the replies I got, the problems I have 
been experiencing are to be expected and I should take care myself to handle 
special cases accordingly. 

Thanks again to all three for your replies.

Blessings,

Augustin.



-- 
http://openteacher.info/
http://overshoot.tv/
http://charityware.info/
http://minguo.info/

From bradflora at gmail.com  Sun Mar 29 10:05:22 2009
From: bradflora at gmail.com (Brad Flora)
Date: Sun, 29 Mar 2009 05:05:22 -0500
Subject: [development] Best way to let a user notify other users about a new
	node they created?
Message-ID: <44f2b760903290305u3c2c5279ye820c95e0d58b8d7@mail.gmail.com>

Hi, list,

I'm running a Drupal-powered social news site and want to give my users some
tools to promote their submissions.

Right now I'm using the excellent Tweet module to let them tweet out their
stories after they go on the site, but I'd like to have something that would
notify other users on my site of the new node, preferably with an e-mail.

Digg's got a feature like this called "Shout."  Are there any existing
modules in Drupal that do this or approximate it?  How else could I better
arm my users to promote their content to other users and across the web.

Thanks

-Brad

P.S. I'm running a D5 site with Drigg as the core of the social news piece.
I'm also using Buddylist for social networking features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090329/36aa5074/attachment.htm>

From jcfiala at gmail.com  Sun Mar 29 13:29:38 2009
From: jcfiala at gmail.com (John Fiala)
Date: Sun, 29 Mar 2009 07:29:38 -0600
Subject: [development] Best way to let a user notify other users about a
	new node they created?
In-Reply-To: <44f2b760903290305u3c2c5279ye820c95e0d58b8d7@mail.gmail.com>
References: <44f2b760903290305u3c2c5279ye820c95e0d58b8d7@mail.gmail.com>
Message-ID: <d59865cb0903290629j39c51b10u436fc3675ea128c9@mail.gmail.com>

You might start with the Actions (http://drupal.org/project/actions)
module - it's a backport of what's in Drupal 6, and I know that allows
you to send out emails at certain times, although I"m not sure how
well it will work for 'sending an email to everyone on your site' -
are you sure you want to hit your users with that much email?

On Sun, Mar 29, 2009 at 4:05 AM, Brad Flora <bradflora at gmail.com> wrote:
> Hi, list,
>
> I'm running a Drupal-powered social news site and want to give my users some
> tools to promote their submissions.
>
> Right now I'm using the excellent Tweet module to let them tweet out their
> stories after they go on the site, but I'd like to have something that would
> notify other users on my site of the new node, preferably with an e-mail.

-- 
John Fiala

From amont at 5net.hu  Mon Mar 30 11:02:44 2009
From: amont at 5net.hu (=?UTF-8?B?w4Ftb24gVGFtw6Fz?=)
Date: Mon, 30 Mar 2009 13:02:44 +0200
Subject: [development] Search
In-Reply-To: <A57833DF-DC44-44B4-AE64-2B1EE02615E2@sentex.net>
References: <49CA48A1.7040308@5net.hu>	<4a9fdc630903250822l5edfb759g5e9599b8199c4c1b@mail.gmail.com>	<49CA525D.3010809@5net.hu>
	<A57833DF-DC44-44B4-AE64-2B1EE02615E2@sentex.net>
Message-ID: <49D0A6D4.1020407@5net.hu>

2009-03-25 20:06 keltez?ssel, Andrew Berry ?rta:
> On 25-Mar-09, at 11:48 AM, ?mon Tam?s wrote:
>
>> Thanks, but I like to user the other result like the drupal result 
>> and I like to mix it.
>
> You might also be able to do this with hook_search and 
> hook_update_index. AFAIK there is no restriction on where the content 
> comes from, however it does end up getting indexed in Drupal as well. 
> So it's probably not what you want if you all ready have a search 
> index on the remote site.
>
> See http://api.drupal.org/api/group/search/6 and 
> http://api.drupal.org/api/function/hook_search/6
>

First I like to use the hook_update_index, but it only can to work with 
node-s, or if I like to insert other content I must use an other type in 
search_index().

Or is there an other indexer, what can index external sites and easy to 
use with drupal? It schould be enough...

?mon Tam?s
Sitefejleszt? ?s programoz?
-- 
5NET Informatikai Kft.
1062 Budapest, Aradi utca 38. A 3/11
telefon: (1) 461-0205  |  fax: (1) 461-0206
e-mail: amont at 5net.hu  |  web: http://www.5net.hu


From nabil at gobrighttree.com  Mon Mar 30 14:04:22 2009
From: nabil at gobrighttree.com (Nabil Alsharif)
Date: Mon, 30 Mar 2009 09:04:22 -0500
Subject: [development] Best way to let a user notify other users about	a
	new node they created?
In-Reply-To: <d59865cb0903290629j39c51b10u436fc3675ea128c9@mail.gmail.com>
References: <44f2b760903290305u3c2c5279ye820c95e0d58b8d7@mail.gmail.com>
	<d59865cb0903290629j39c51b10u436fc3675ea128c9@mail.gmail.com>
Message-ID: <20090330140422.GA4723@al-sa3ek>

If you want to do it yourself you could use hook_nodeapi to capture when a user creates a node. How you want to notify the user is up to you.
On Mon, Mar 30, 2009 at 08:48:41AM -0500, John Fiala wrote:
> You might start with the Actions (http://drupal.org/project/actions)
> module - it's a backport of what's in Drupal 6, and I know that allows
> you to send out emails at certain times, although I"m not sure how
> well it will work for 'sending an email to everyone on your site' -
> are you sure you want to hit your users with that much email?
> 
> On Sun, Mar 29, 2009 at 4:05 AM, Brad Flora <bradflora at gmail.com> wrote:
> > Hi, list,
> >
> > I'm running a Drupal-powered social news site and want to give my users some
> > tools to promote their submissions.
> >
> > Right now I'm using the excellent Tweet module to let them tweet out their
> > stories after they go on the site, but I'd like to have something that would
> > notify other users on my site of the new node, preferably with an e-mail.
> 
> -- 
> John Fiala
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.drupal.org/pipermail/development/attachments/20090330/461aff41/attachment.pgp>

From amont at 5net.hu  Mon Mar 30 15:15:15 2009
From: amont at 5net.hu (=?ISO-8859-2?Q?=C1mon_Tam=E1s?=)
Date: Mon, 30 Mar 2009 17:15:15 +0200
Subject: [development] Changing default search page
Message-ID: <49D0E203.7080100@5net.hu>

Hello,

I written my mnogosearch module. It is working, but I like to use it as 
default search page. For example if somebody search in the search box I 
like to show my results. How can I make it?

?mon Tam?s
Sitefejleszt? ?s programoz?
-- 
5NET Informatikai Kft.
1062 Budapest, Aradi utca 38. A 3/11
telefon: (1) 461-0205  |  fax: (1) 461-0206
e-mail: amont at 5net.hu  |  web: http://www.5net.hu


From andrewberry at sentex.net  Mon Mar 30 18:59:21 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Mon, 30 Mar 2009 14:59:21 -0400
Subject: [development] Search
In-Reply-To: <49D0A6D4.1020407@5net.hu>
References: <49CA48A1.7040308@5net.hu>	<4a9fdc630903250822l5edfb759g5e9599b8199c4c1b@mail.gmail.com>	<49CA525D.3010809@5net.hu>
	<A57833DF-DC44-44B4-AE64-2B1EE02615E2@sentex.net>
	<49D0A6D4.1020407@5net.hu>
Message-ID: <C5CC2162-5938-4BC5-869F-6B39035AEE2B@sentex.net>

On 30-Mar-09, at 7:02 AM, ?mon Tam?s wrote:

> First I like to use the hook_update_index, but it only can to work  
> with node-s, or if I like to insert other content I must use an  
> other type in search_index().

'node' is just a key for the content. You should be able to call  
search_index on whatever content you want. If you look at the function  
comments you'll see it's not bound to nodes specifically.

search_index($unique_id, 'my_external_content',  
$some_fetched_text_from_external_site);

--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/20090330/6385ee9b/attachment.bin>

From enboig at gmail.com  Tue Mar 31 11:26:57 2009
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Tue, 31 Mar 2009 13:26:57 +0200
Subject: [development] remove or give priority to hook_node_grants
Message-ID: <45a29f450903310426m5cc0c090of9934887e17cd7c5@mail.gmail.com>

I am developing a module to create "sub user types" inside OG.
I have been able to modify hook_node_access_records using the
"priority" so in certain cases I override OG access system.

Now I need to "override" the hook_node_grants so In certain cases a
user who should be able to see certain nodes don't see them; how can I
achieve this?

Thanks

-- 
*La vida ?s com una taronja, que esperes a exprimir-la?
*Si creus que l'educaci? ?s cara, prova la ignor?ncia.
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From weitzman at tejasa.com  Tue Mar 31 12:09:21 2009
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Tue, 31 Mar 2009 08:09:21 -0400
Subject: [development] remove or give priority to hook_node_grants
In-Reply-To: <45a29f450903310426m5cc0c090of9934887e17cd7c5@mail.gmail.com>
References: <45a29f450903310426m5cc0c090of9934887e17cd7c5@mail.gmail.com>
Message-ID: <6117a7500903310509y6f57fd56s4cb6fee1a6e717b5@mail.gmail.com>

You no longer need to fiddle with priorities when overriding OG
records - http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/og/modules/og_access/og_access.module?r1=1.29&r2=1.30.

There is currently no hook for adjusting grants.

On Tue, Mar 31, 2009 at 7:26 AM, Llu?s <enboig at gmail.com> wrote:
> I am developing a module to create "sub user types" inside OG.
> I have been able to modify hook_node_access_records using the
> "priority" so in certain cases I override OG access system.
>
> Now I need to "override" the hook_node_grants so In certain cases a
> user who should be able to see certain nodes don't see them; how can I
> achieve this?
>
> Thanks
>
> --
> *La vida ?s com una taronja, que esperes a exprimir-la?
> *Si creus que l'educaci? ?s cara, prova la ignor?ncia.
> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
> nom?s una vegada.
> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>

From flo.thiel+drupal at googlemail.com  Tue Mar 31 12:53:05 2009
From: flo.thiel+drupal at googlemail.com (Florian Thiel)
Date: Tue, 31 Mar 2009 14:53:05 +0200
Subject: [development] Process and technology questionnaire
Message-ID: <f932c74c0903310553y78905521g3421a4777f04257@mail.gmail.com>

Hello drupal developers,

I'm in the process of writing my diploma thesis on the prevention of
web application security vulnerabilities and I'd like to know a bit
about your fine project from the developer's view. It would be great
if you could take a couple of minutes and think about the questions
below.

The questions are mostly open-ended. Not all may apply to all
developers, but I've chosen to not only address project leads.
Elaborate and skip questions at will.

Thank you very much in advance. I will provide you with the
results of my thesis when it's done it you want. There will probably
be some findings about what can be done to prevent security
vulnerabilities, in particular XSS and SQL injections in open source
web applications.

Florian

The questions:

About technical aspects:
- Are you using a web application framework? Which one?
- Do you use explicit data modeling for all business objects in the
  application?
- Do you have a specific layers for input/output validation/filtering?
  (If applicable) What does the input/output layer do (respectively)?
  How? Are you using external libraries? Why? Why not? (for HTML
  sanitation. object-relational mappers, database abstractions with
  prepared statements)?
- (If applicable) What responsibilities do the input/output layers
  have, respectively?
- How do you ensure that all input passed through validation/
  filtering? Do you have an API that must be used?
- Do you provide services to independently developed modules/
  components? Is there a defined API?
- Which other external libraries do you use?

About the development process:
- Is there public documentation about the responsibilities of the
  input/output layers?
- Is there public documentation about *when* input/output validation/
  filtering should happen? (Like: "output filtering must always happen
  in the method that renders the data")
- Do you have automatic tests for the whole system?

Bonus question:
- Do you do manual code review?

From andrewberry at sentex.net  Tue Mar 31 13:37:00 2009
From: andrewberry at sentex.net (Andrew Berry)
Date: Tue, 31 Mar 2009 09:37:00 -0400
Subject: [development] Process and technology questionnaire
In-Reply-To: <f932c74c0903310553y78905521g3421a4777f04257@mail.gmail.com>
References: <f932c74c0903310553y78905521g3421a4777f04257@mail.gmail.com>
Message-ID: <5F1F5286-8AE2-4CB7-90F1-61339EC3CF92@sentex.net>

On 31-Mar-09, at 8:53 AM, Florian Thiel wrote:

> I'm in the process of writing my diploma thesis on the prevention of
> web application security vulnerabilities and I'd like to know a bit
> about your fine project from the developer's view.

Most of these questions can easily be answered between api.drupal.org, http://drupal.org/handbooks 
, http://drupal.org/writing-secure-code, and inspecting the Drupal  
source. If you want to see where the project is going, versus where  
the code is today in the stable release, focus your search on Drupal 7  
(HEAD in CVS).

Good luck!
--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/20090331/cf3593d6/attachment-0001.bin>

From kb at 2bits.com  Tue Mar 31 14:43:25 2009
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Tue, 31 Mar 2009 10:43:25 -0400
Subject: [development] Process and technology questionnaire
In-Reply-To: <f932c74c0903310553y78905521g3421a4777f04257@mail.gmail.com>
References: <f932c74c0903310553y78905521g3421a4777f04257@mail.gmail.com>
Message-ID: <4a9fdc630903310743t2af9f309n442453da9b120fa6@mail.gmail.com>

Florian

I am copying the security team as well in case someone there is interested
in getting in touch with you.

This page http://drupal.org/security-team and the pages under it (linked at
the bottom) will also provide you with some more information about the
security process within Drupal.

And on this page you will find the security advisories, broken into
core/contrib/public service announcements

http://drupal.org/security

On Tue, Mar 31, 2009 at 8:53 AM,

> Hello drupal developers,
>
> I'm in the process of writing my diploma thesis on the prevention of
> web application security vulnerabilities and I'd like to know a bit
> about your fine project from the developer's view. It would be great
> if you could take a couple of minutes and think about the questions
> below.
>
> The questions are mostly open-ended. Not all may apply to all
> developers, but I've chosen to not only address project leads.
> Elaborate and skip questions at will.
>
> Thank you very much in advance. I will provide you with the
> results of my thesis when it's done it you want. There will probably
> be some findings about what can be done to prevent security
> vulnerabilities, in particular XSS and SQL injections in open source
> web applications.
>
> Florian
>
> The questions:
>
> About technical aspects:
> - Are you using a web application framework? Which one?
> - Do you use explicit data modeling for all business objects in the
>  application?
> - Do you have a specific layers for input/output validation/filtering?
>  (If applicable) What does the input/output layer do (respectively)?
>  How? Are you using external libraries? Why? Why not? (for HTML
>  sanitation. object-relational mappers, database abstractions with
>  prepared statements)?
> - (If applicable) What responsibilities do the input/output layers
>  have, respectively?
> - How do you ensure that all input passed through validation/
>  filtering? Do you have an API that must be used?
> - Do you provide services to independently developed modules/
>  components? Is there a defined API?
> - Which other external libraries do you use?
>
> About the development process:
> - Is there public documentation about the responsibilities of the
>  input/output layers?
> - Is there public documentation about *when* input/output validation/
>  filtering should happen? (Like: "output filtering must always happen
>  in the method that renders the data")
> - Do you have automatic tests for the whole system?
>
> Bonus question:
> - Do you do manual code review?
>



-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090331/f74d4d06/attachment.htm>

From enboig at gmail.com  Tue Mar 31 15:32:13 2009
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Tue, 31 Mar 2009 17:32:13 +0200
Subject: [development] remove or give priority to hook_node_grants
In-Reply-To: <6117a7500903310509y6f57fd56s4cb6fee1a6e717b5@mail.gmail.com>
References: <45a29f450903310426m5cc0c090of9934887e17cd7c5@mail.gmail.com>
	<6117a7500903310509y6f57fd56s4cb6fee1a6e717b5@mail.gmail.com>
Message-ID: <45a29f450903310832i7cb789d9r927db5e52f95b436@mail.gmail.com>

That is not resolving my problem.

What I need inside a group is:
- Content addressed to normal subscribers
- Content for the theory teachers of the group
- Content for the practical teachers of the group
- .....

I have created a module which allows you to assign a "profession" to
users inside a group. The user can choose using a profession to
activate. The nodes created with a profession activates are only
visible to those inside the group and having that profession active. I
achieve this using nodeapi and giving my hook_node_access_records more
priority than OG.

My problem is that users with a profession active see also the
"default" group content, which they shouldn't. This is because
"hook_node_grants" is activated by my module and OG module.

So my question is how to remove the "hook_node_grants" of OG?

On Tue, Mar 31, 2009 at 2:09 PM, Moshe Weitzman <weitzman at tejasa.com> wrote:
> You no longer need to fiddle with priorities when overriding OG
> records - http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/og/modules/og_access/og_access.module?r1=1.29&r2=1.30.
>
> There is currently no hook for adjusting grants.
>
> On Tue, Mar 31, 2009 at 7:26 AM, Llu?s <enboig at gmail.com> wrote:
>> I am developing a module to create "sub user types" inside OG.
>> I have been able to modify hook_node_access_records using the
>> "priority" so in certain cases I override OG access system.
>>
>> Now I need to "override" the hook_node_grants so In certain cases a
>> user who should be able to see certain nodes don't see them; how can I
>> achieve this?
>>
>> Thanks
>>
>> --
>> *La vida ?s com una taronja, que esperes a exprimir-la?
>> *Si creus que l'educaci? ?s cara, prova la ignor?ncia.
>> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>> nom?s una vegada.
>> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>>
>



-- 
*La vida ?s com una taronja, que esperes a exprimir-la?
*Si creus que l'educaci? ?s cara, prova la ignor?ncia.
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From sdrreynolds at gmail.com  Tue Mar 31 15:42:32 2009
From: sdrreynolds at gmail.com (Scott Reynolds)
Date: Tue, 31 Mar 2009 11:42:32 -0400
Subject: [development] remove or give priority to hook_node_grants
Message-ID: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com>

Was actually thinking about this the other day. I feel its a lil silly to
have modules provide the priority for access control. I would really love to
develop a drag and drop weight interface for the priority settings.
Essentially, develop a node_access interface that assigns the priority for
all node_access modules exposed currently.

Wondering if theres any traction in that idea, and if so I can start hashing
it out.


> You no longer need to fiddle with priorities when overriding OG
> records -
> http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/og/modules/og_access/og_access.module?r1=1.29&r2=1.30
> .
>
> There is currently no hook for adjusting grants.
>
> On Tue, Mar 31, 2009 at 7:26 AM, Llu?s <enboig at gmail.com> wrote:
> > I am developing a module to create "sub user types" inside OG.
> > I have been able to modify hook_node_access_records using the
> > "priority" so in certain cases I override OG access system.
> >
> > Now I need to "override" the hook_node_grants so In certain cases a
> > user who should be able to see certain nodes don't see them; how can I
> > achieve this?
> >
> > Thanks
> >
> > --
> > *La vida ?s com una taronja, que esperes a exprimir-la?
> > *Si creus que l'educaci? ?s cara, prova la ignor?ncia.
> > *La vida ?s com una moneda, la pots gastar en el que vulguis per?
> > nom?s una vegada.
> > *Abans d'imprimir aquest missatge, pensa en el medi ambient.
> >
>
> --
Scott Reynolds
Cell: 630-254-2474
http://www.scottreynolds.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090331/0be168d3/attachment.htm>

From enboig at gmail.com  Tue Mar 31 15:59:15 2009
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Tue, 31 Mar 2009 17:59:15 +0200
Subject: [development] remove or give priority to hook_node_grants
In-Reply-To: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com>
References: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com>
Message-ID: <45a29f450903310859w27417c7ah4c1a911cf6c7f0f8@mail.gmail.com>

I think this would be great; but it wouldn't solve my problem neither.
How can I "remove" a realm from $grants[$realm]

I tried to "overwrite" it, but it uses arrays and merge them, so it is
impossible.

On Tue, Mar 31, 2009 at 5:42 PM, Scott Reynolds <sdrreynolds at gmail.com> wrote:
> Was actually thinking about this the other day. I feel its a lil silly to
> have modules provide the priority for access control. I would really love to
> develop a drag and drop weight interface for the priority settings.
> Essentially, develop a node_access interface that assigns the priority for
> all node_access modules exposed currently.
>
> Wondering if theres any traction in that idea, and if so I can start hashing
> it out.
>
>>
>> You no longer need to fiddle with priorities when overriding OG
>> records -
>> http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/og/modules/og_access/og_access.module?r1=1.29&r2=1.30.
>>
>> There is currently no hook for adjusting grants.
>>
>> On Tue, Mar 31, 2009 at 7:26 AM, Llu?s <enboig at gmail.com> wrote:
>> > I am developing a module to create "sub user types" inside OG.
>> > I have been able to modify hook_node_access_records using the
>> > "priority" so in certain cases I override OG access system.
>> >
>> > Now I need to "override" the hook_node_grants so In certain cases a
>> > user who should be able to see certain nodes don't see them; how can I
>> > achieve this?
>> >
>> > Thanks
>> >
>> > --
>> > *La vida ?s com una taronja, que esperes a exprimir-la?
>> > *Si creus que l'educaci? ?s cara, prova la ignor?ncia.
>> > *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>> > nom?s una vegada.
>> > *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>> >
>>
> --
> Scott Reynolds
> Cell: 630-254-2474
> http://www.scottreynolds.us
>



-- 
*La vida ?s com una taronja, que esperes a exprimir-la?
*Si creus que l'educaci? ?s cara, prova la ignor?ncia.
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From weitzman at tejasa.com  Tue Mar 31 16:46:31 2009
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Tue, 31 Mar 2009 12:46:31 -0400
Subject: [development] remove or give priority to hook_node_grants
In-Reply-To: <45a29f450903310859w27417c7ah4c1a911cf6c7f0f8@mail.gmail.com>
References: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com> 
	<45a29f450903310859w27417c7ah4c1a911cf6c7f0f8@mail.gmail.com>
Message-ID: <6117a7500903310946w783d1232r6958d8a7a1c5412a@mail.gmail.com>

Just add a drupal_alter() right after all the grants have been
provided. yes, this requires a 1 line hack to core.

On Tue, Mar 31, 2009 at 11:59 AM, Llu?s <enboig at gmail.com> wrote:
> I think this would be great; but it wouldn't solve my problem neither.
> How can I "remove" a realm from $grants[$realm]
>
> I tried to "overwrite" it, but it uses arrays and merge them, so it is
> impossible.
>
> On Tue, Mar 31, 2009 at 5:42 PM, Scott Reynolds <sdrreynolds at gmail.com> wrote:
>> Was actually thinking about this the other day. I feel its a lil silly to
>> have modules provide the priority for access control. I would really love to
>> develop a drag and drop weight interface for the priority settings.
>> Essentially, develop a node_access interface that assigns the priority for
>> all node_access modules exposed currently.
>>
>> Wondering if theres any traction in that idea, and if so I can start hashing
>> it out.
>>
>>>
>>> You no longer need to fiddle with priorities when overriding OG
>>> records -
>>> http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/og/modules/og_access/og_access.module?r1=1.29&r2=1.30.
>>>
>>> There is currently no hook for adjusting grants.
>>>
>>> On Tue, Mar 31, 2009 at 7:26 AM, Llu?s <enboig at gmail.com> wrote:
>>> > I am developing a module to create "sub user types" inside OG.
>>> > I have been able to modify hook_node_access_records using the
>>> > "priority" so in certain cases I override OG access system.
>>> >
>>> > Now I need to "override" the hook_node_grants so In certain cases a
>>> > user who should be able to see certain nodes don't see them; how can I
>>> > achieve this?
>>> >
>>> > Thanks
>>> >
>>> > --
>>> > *La vida ?s com una taronja, que esperes a exprimir-la?
>>> > *Si creus que l'educaci? ?s cara, prova la ignor?ncia.
>>> > *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>>> > nom?s una vegada.
>>> > *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>>> >
>>>
>> --
>> Scott Reynolds
>> Cell: 630-254-2474
>> http://www.scottreynolds.us
>>
>
>
>
> --
> *La vida ?s com una taronja, que esperes a exprimir-la?
> *Si creus que l'educaci? ?s cara, prova la ignor?ncia.
> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
> nom?s una vegada.
> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>

From drupal at dave-cohen.com  Tue Mar 31 18:47:09 2009
From: drupal at dave-cohen.com (David Cohen)
Date: Tue, 31 Mar 2009 11:47:09 -0700
Subject: [development] should I alter the sessions table?
Message-ID: <1238525229.12486.1308274947@webmail.messagingengine.com>

I have a special need, in the Drupal for Facebook modules, to honor a
session key that comes from Facebook, instead of the key Drupal normally
uses.   So far the way I've approached this is to have Drupal use the
passed-in session_key, so the sid column of the sessions table is that
value.  My problem is the the length of these session keys is sometimes
longer than the 64 character limit of the sid column.  According to
Facebook these keys could be 128 characters or even longer.
(http://forum.developers.facebook.com/viewtopic.php?id=21931)

My first thought is to alter Drupal's sessions table.  That is, in my
module's .install file I would alter sessions so that the sid column is
varchar(256) instead of varchar(64).  Is there a performance drawback to
this?  Is it bad form to alter the table this way?

My other options include finding some way to compress the session_key
down to 64 chars.  Or, create a table that maps longer session_keys to
Drupal's sids.  Is there any reason to go with one of these options as
opposed to altering the table?

Thanks in advance,

-Dave



From nan_wich at bellsouth.net  Tue Mar 31 19:04:34 2009
From: nan_wich at bellsouth.net (Nancy Wichmann)
Date: Tue, 31 Mar 2009 15:04:34 -0400
Subject: [development] should I alter the sessions table?
In-Reply-To: <1238525229.12486.1308274947@webmail.messagingengine.com>
Message-ID: <NCEKJGCAHKMOLJLHNKLJOEDDENAA.nan_wich@bellsouth.net>

David Cohen wrote:
> My first thought is to alter Drupal's sessions table

Personally, what I would do (and have done) is to go ahead and alter the
table. Then I would turn around and post a patch to core explaining the use
case. My guess is that this would be accepted (with some arguing of course)
to be put into D7.

Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr.


-------------- next part --------------

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.11.33/2031 - Release Date: 3/30/2009 5:56 PM

From domenic at workhabit.com  Tue Mar 31 19:05:44 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Tue, 31 Mar 2009 12:05:44 -0700
Subject: [development] should I alter the sessions table?
In-Reply-To: <1238525229.12486.1308274947@webmail.messagingengine.com>
References: <1238525229.12486.1308274947@webmail.messagingengine.com>
Message-ID: <e83e0db0903311205n7c03686ar7922cc845ff471a5@mail.gmail.com>

On Tue, Mar 31, 2009 at 11:47 AM, David Cohen <drupal at dave-cohen.com> wrote:

> Is there a performance drawback to
> this?


Probably not a perceptible one - table scans will walk the length of a
varchar, so you'll be walking some 256-length entries when there are
Facebook sessions active... not really a big deal imo.



> Is it bad form to alter the table this way?


That might be the sticking point. I can see some problems arising quickly
from letting modules alter core tables:
-FB Connect sets sid to varchar(256)
-Foo.module, installed later, sets sid to varchar(128)
Now FB Connect doesn't work.

Quick alternate ideas that come to mind:
-Setting a PHP session instead
-Making a mapping table of FB sid -> drupal sid
-Doing what you're considering, but instead storing the FB sids as md5
hashes in the sessions table to keep the varchar(64) constraint
-Some combination of these


-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090331/481d04e9/attachment.htm>

From larry at garfieldtech.com  Tue Mar 31 19:09:10 2009
From: larry at garfieldtech.com (Larry Garfield)
Date: Tue, 31 Mar 2009 14:09:10 -0500
Subject: [development] remove or give priority to hook_node_grants
In-Reply-To: <6117a7500903310946w783d1232r6958d8a7a1c5412a@mail.gmail.com>
References: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com>
	<45a29f450903310859w27417c7ah4c1a911cf6c7f0f8@mail.gmail.com>
	<6117a7500903310946w783d1232r6958d8a7a1c5412a@mail.gmail.com>
Message-ID: <200903311409.10324.larry@garfieldtech.com>

Note that if you make a patch for Drupal 7 to add an alter there, it gets 
committed, and then you make a backport of it, God will only maim a kitten in 
response rather than killing one.  

Translation: Patch please, Lluis!  That would be a great addition to Drupal 7.

On Tuesday 31 March 2009 11:46:31 am Moshe Weitzman wrote:
> Just add a drupal_alter() right after all the grants have been
> provided. yes, this requires a 1 line hack to core.
>
> On Tue, Mar 31, 2009 at 11:59 AM, Llu?s <enboig at gmail.com> wrote:
> > I think this would be great; but it wouldn't solve my problem neither.
> > How can I "remove" a realm from $grants[$realm]
> >
> > I tried to "overwrite" it, but it uses arrays and merge them, so it is
> > impossible.

-- 
Larry Garfield
larry at garfieldtech.com

From recidive at gmail.com  Tue Mar 31 19:18:26 2009
From: recidive at gmail.com (Henrique Recidive)
Date: Tue, 31 Mar 2009 16:18:26 -0300
Subject: [development] should I alter the sessions table?
In-Reply-To: <1238525229.12486.1308274947@webmail.messagingengine.com>
References: <1238525229.12486.1308274947@webmail.messagingengine.com>
Message-ID: <841684fe0903311218k5b4a4d06ka09d3f821e98e1a7@mail.gmail.com>

2009/3/31 David Cohen <drupal at dave-cohen.com>:
> I have a special need, in the Drupal for Facebook modules, to honor a
> session key that comes from Facebook, instead of the key Drupal normally
> uses. ? So far the way I've approached this is to have Drupal use the
> passed-in session_key, so the sid column of the sessions table is that
> value. ?My problem is the the length of these session keys is sometimes
> longer than the 64 character limit of the sid column. ?According to
> Facebook these keys could be 128 characters or even longer.
> (http://forum.developers.facebook.com/viewtopic.php?id=21931)
>
> My first thought is to alter Drupal's sessions table. ?That is, in my
> module's .install file I would alter sessions so that the sid column is
> varchar(256) instead of varchar(64). ?Is there a performance drawback to
> this? ?Is it bad form to alter the table this way?

Surely there will be a performance hit, due to longer indexes.

> My other options include finding some way to compress the session_key
> down to 64 chars. ?Or, create a table that maps longer session_keys to
> Drupal's sids. ?Is there any reason to go with one of these options as
> opposed to altering the table?

Can't you just save you key in a session variable (e.g. $_SESSION['fb_key']) ?

Henrique

> Thanks in advance,
>
> -Dave
>
>
>

From domenic at workhabit.com  Tue Mar 31 19:39:11 2009
From: domenic at workhabit.com (Domenic Santangelo)
Date: Tue, 31 Mar 2009 12:39:11 -0700
Subject: [development] should I alter the sessions table?
In-Reply-To: <841684fe0903311218k5b4a4d06ka09d3f821e98e1a7@mail.gmail.com>
References: <1238525229.12486.1308274947@webmail.messagingengine.com> 
	<841684fe0903311218k5b4a4d06ka09d3f821e98e1a7@mail.gmail.com>
Message-ID: <e83e0db0903311239q4484d5f4w84bc0f71833d98f4@mail.gmail.com>

On Tue, Mar 31, 2009 at 12:18 PM, Henrique Recidive <recidive at gmail.com>wrote:
>
> Surely there will be a performance hit, due to longer indexes.


Barely perceptible, I'd wager. The indexes will only grow (in comparison to
current) when there are entries of length >64 (varchar isn't padded). But
the "session" field is a longtext, so it isn't exactly a high-performing
table as it is. (just looking at a D5 install, YMMV for D6+). But it's
probably beside the point because:

Can't you just save you key in a session variable (e.g. $_SESSION['fb_key'])
> ?
>

^this! :)

-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090331/673f5bac/attachment.htm>

From agentrickard at gmail.com  Tue Mar 31 20:20:20 2009
From: agentrickard at gmail.com (Ken Rickard)
Date: Tue, 31 Mar 2009 16:20:20 -0400
Subject: [development] remove or give priority to hook_node_grants
In-Reply-To: <200903311409.10324.larry@garfieldtech.com>
References: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com>
	<45a29f450903310859w27417c7ah4c1a911cf6c7f0f8@mail.gmail.com>
	<6117a7500903310946w783d1232r6958d8a7a1c5412a@mail.gmail.com>
	<200903311409.10324.larry@garfieldtech.com>
Message-ID: <25b45da00903311320x16ea67e5h5ff3605901df045a@mail.gmail.com>

Larry means "Please work on this existing patch";

 http://drupal.org/node/309007

 -- Ken

On Tue, Mar 31, 2009 at 3:09 PM, Larry Garfield <larry at garfieldtech.com> wrote:
> Note that if you make a patch for Drupal 7 to add an alter there, it gets
> committed, and then you make a backport of it, God will only maim a kitten in
> response rather than killing one.
>
> Translation: Patch please, Lluis! ?That would be a great addition to Drupal 7.
>
> On Tuesday 31 March 2009 11:46:31 am Moshe Weitzman wrote:
>> Just add a drupal_alter() right after all the grants have been
>> provided. yes, this requires a 1 line hack to core.
>>
>> On Tue, Mar 31, 2009 at 11:59 AM, Llu?s <enboig at gmail.com> wrote:
>> > I think this would be great; but it wouldn't solve my problem neither.
>> > How can I "remove" a realm from $grants[$realm]
>> >
>> > I tried to "overwrite" it, but it uses arrays and merge them, so it is
>> > impossible.
>
> --
> Larry Garfield
> larry at garfieldtech.com
>



-- 
Ken Rickard
agentrickard at gmail.com
http://ken.therickards.com

From drupal at dave-cohen.com  Tue Mar 31 20:27:48 2009
From: drupal at dave-cohen.com (David Cohen)
Date: Tue, 31 Mar 2009 13:27:48 -0700
Subject: [development] should I alter the sessions table?
In-Reply-To: <e83e0db0903311239q4484d5f4w84bc0f71833d98f4@mail.gmail.com>
References: <1238525229.12486.1308274947@webmail.messagingengine.com>
	<841684fe0903311218k5b4a4d06ka09d3f821e98e1a7@mail.gmail.com>
	<e83e0db0903311239q4484d5f4w84bc0f71833d98f4@mail.gmail.com>
Message-ID: <1238531268.5695.1308292775@webmail.messagingengine.com>

Here's what I've learned since my original post...

Changing sid from varchar(64) to varchar(255) or shorter would have no
effect on a regular drupal install, because the length of the strings
can still be expressed in 1 byte.  With my modules installed some
session keys would be greater than 64 chars, which could add some
overhead to the index of the table.  (I may be underestimating the
impact of the change, if mysql somehow uses the max length in building a
more efficient index.)

On Tue, 31 Mar 2009 12:39 -0700, "Domenic Santangelo"
<domenic at workhabit.com> wrote:
> On Tue, Mar 31, 2009 at 12:18 PM, Henrique Recidive
> <recidive at gmail.com>wrote:
> >
> Can't you just save you key in a session variable (e.g.
> $_SESSION['fb_key'])
> > ?

Definitely not.  We're talking about the session key, the very thing
that makes it possible for $_SESSION to persist from one request to the
next.  (When serving a Facebook Canvas Page, cookies are not honored and
the session_key _must_ be used instead.)

Facebook's session keys include extra information, like start time and
expiry, which do not contribute to the uniqueness.  (Or so I believe.)
So for the time being I'm trying to solve this problem by truncating the
very long session keys, as that seems easier than altering the table.



From news at unleashedmind.com  Tue Mar 31 20:49:51 2009
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Tue, 31 Mar 2009 22:49:51 +0200
Subject: [development] should I alter the sessions table?
In-Reply-To: <1238531268.5695.1308292775@webmail.messagingengine.com>
Message-ID: <025a01c9b242$3cf8be10$0200a8c0@structworks.com>

> Definitely not.  We're talking about the session key, the 
> very thing that makes it possible for $_SESSION to persist 
> from one request to the next.  (When serving a Facebook 
> Canvas Page, cookies are not honored and the session_key 
> _must_ be used instead.)

This scares me a bit.  Will you make users aware of this core modification?
Or is your module supposed to be used by advanced users only?  At least, it
sounds a bit like the latter.

settings.php:

$conf = array(
  'session_inc' => './sites/all/modules/facebook/session.inc',
);

There, join your own facebook_sessions table and/or do any magic or own
session handling as you like.

sun


From drupal at dave-cohen.com  Tue Mar 31 21:32:17 2009
From: drupal at dave-cohen.com (Dave Cohen)
Date: Tue, 31 Mar 2009 14:32:17 -0700
Subject: [development] should I alter the sessions table?
In-Reply-To: <025a01c9b242$3cf8be10$0200a8c0@structworks.com>
References: <025a01c9b242$3cf8be10$0200a8c0@structworks.com>
Message-ID: <200903311432.18244.drupal@dave-cohen.com>

Yes I do what you suggest, though the code is not identical.  Users of these modules must modify their settings.php to include the module's code.  There's no core modification for this.

-Dave

On Tuesday 31 March 2009 13:49:51 Daniel F. Kudwien wrote:
> > Definitely not.  We're talking about the session key, the 
> > very thing that makes it possible for $_SESSION to persist 
> > from one request to the next.  (When serving a Facebook 
> > Canvas Page, cookies are not honored and the session_key 
> > _must_ be used instead.)
> 
> This scares me a bit.  Will you make users aware of this core modification?
> Or is your module supposed to be used by advanced users only?  At least, it
> sounds a bit like the latter.
> 
> settings.php:
> 
> $conf = array(
>   'session_inc' => './sites/all/modules/facebook/session.inc',
> );
> 
> There, join your own facebook_sessions table and/or do any magic or own
> session handling as you like.
> 
> sun
> 
> 

From enboig at gmail.com  Tue Mar 31 23:22:27 2009
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Wed, 1 Apr 2009 01:22:27 +0200
Subject: [development] remove or give priority to hook_node_grants
In-Reply-To: <25b45da00903311320x16ea67e5h5ff3605901df045a@mail.gmail.com>
References: <7bcb1aa60903310842w25a2d0c4q95c9007b3d11fb7d@mail.gmail.com>
	<45a29f450903310859w27417c7ah4c1a911cf6c7f0f8@mail.gmail.com>
	<6117a7500903310946w783d1232r6958d8a7a1c5412a@mail.gmail.com>
	<200903311409.10324.larry@garfieldtech.com>
	<25b45da00903311320x16ea67e5h5ff3605901df045a@mail.gmail.com>
Message-ID: <45a29f450903311622o51467844t83f0cede061d5cfc@mail.gmail.com>

I will check if the patch is useful to me. If it is, will it manage to drupal6?

On Tue, Mar 31, 2009 at 10:20 PM, Ken Rickard <agentrickard at gmail.com> wrote:
> Larry means "Please work on this existing patch";
>
> ?http://drupal.org/node/309007
>
> ?-- Ken
>
> On Tue, Mar 31, 2009 at 3:09 PM, Larry Garfield <larry at garfieldtech.com> wrote:
>> Note that if you make a patch for Drupal 7 to add an alter there, it gets
>> committed, and then you make a backport of it, God will only maim a kitten in
>> response rather than killing one.
>>
>> Translation: Patch please, Lluis! ?That would be a great addition to Drupal 7.
>>
>> On Tuesday 31 March 2009 11:46:31 am Moshe Weitzman wrote:
>>> Just add a drupal_alter() right after all the grants have been
>>> provided. yes, this requires a 1 line hack to core.
>>>
>>> On Tue, Mar 31, 2009 at 11:59 AM, Llu?s <enboig at gmail.com> wrote:
>>> > I think this would be great; but it wouldn't solve my problem neither.
>>> > How can I "remove" a realm from $grants[$realm]
>>> >
>>> > I tried to "overwrite" it, but it uses arrays and merge them, so it is
>>> > impossible.
>>
>> --
>> Larry Garfield
>> larry at garfieldtech.com
>>
>
>
>
> --
> Ken Rickard
> agentrickard at gmail.com
> http://ken.therickards.com
>



-- 
*La vida ?s com una taronja, que esperes a exprimir-la?
*Si creus que l'educaci? ?s cara, prova la ignor?ncia.
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.