From aclight at gmail.com  Fri Aug  1 00:32:52 2008
From: aclight at gmail.com (Adam Light)
Date: Thu, 31 Jul 2008 19:32:52 -0500
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <4891E1D7.7090209@logrus.com>
References: <48909BD1.2020908@webchick.net>
	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>
	<48909F2A.7030700@webchick.net> <E1KOVbt-0004Ik-Q8@fenris.runbox.com>
	<8290C899-9906-4543-B5B5-FFCFEDDE672A@heydon.com.au>
	<4891E1D7.7090209@logrus.com>
Message-ID: <a008eb250807311732pdec352fm332791fbef27acf6@mail.gmail.com>

On Thu, Jul 31, 2008 at 11:01 AM, Earl Miles <merlin at logrus.com> wrote:
> It seems like it would be difficult to translate our
> current tagging system to SVN and I am concerned that the amount of work to
> do so would be wasted effort. IMO, we have a lot more important problems to
> solve than this.
>

As some of you know, about a year ago I wrote a port of cvslog.module
that uses Subversion instead of CVS, but otherwise is pretty much
identical.  In the process I had to modify the xcvs scripts to
function properly with Subversion.  I've been using this module on a
site I run, and the conventions used on the site are pretty similar to
what's used on d.o, especially relating to the tag and branch naming
conventions.

Basically, the script requires that tags be in /project_name/tags and
branches be in /project_name/branches.  I can't say the scripts are
foolproof, as there are many fewer users on my site, but it's worked
well so far.

The downside is that this is not done using the Versioncontrol API,
and so probably not something that we'd want to use directly on d.o.
But I am pretty confident that we could use SVN and keep pretty
similar conventions.

Adam

From gordon at heydon.com.au  Fri Aug  1 00:36:37 2008
From: gordon at heydon.com.au (Gordon Heydon)
Date: Fri, 1 Aug 2008 10:36:37 +1000
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <1217547145.12087.102.camel@thereishope>
References: <48909BD1.2020908@webchick.net>
	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>
	<48909F2A.7030700@webchick.net>	<E1KOVbt-0004Ik-Q8@fenris.runbox.com>
	<8290C899-9906-4543-B5B5-FFCFEDDE672A@heydon.com.au>
	<4891E1D7.7090209@logrus.com>
	<C3C4E73E-1BFF-4888-825F-4E5C4BC751E5@heydon.com.au>
	<1217547145.12087.102.camel@thereishope>
Message-ID: <54383211-37EA-48CC-983D-4A9CEC6CBFF2@heydon.com.au>

Hi,

On 01/08/2008, at 9:32 AM, Sam Boyer wrote:

> On Fri, 2008-08-01 at 09:00 +1000, Gordon Heydon wrote:
>> Hi,
>> On 01/08/2008, at 2:01 AM, Earl Miles wrote:
>>
>>> Gordon Heydon wrote:
>>>> If it needs to be a centralize RCS, the I hope to SVN mainly
>>>> because the git connectivity is so good, and it really works like
>>>> just another git repository. How ever because SVN doesn't know how
>>>> to tag or branch I don't think that the upstream use of branches
>>>> will work that well.
>>>
>>> This is my concern with SVN. Its idea of tagging and branching is
>>> naive and I find it confusing and also intensive when I end up
>>> checking out all the tags unintentionally. It seems like it would be
>>> difficult to translate our current tagging system to SVN and I am
>>> concerned that the amount of work to do so would be wasted effort.
>>> IMO, we have a lot more important problems to solve than this.
>>
>> Yes this is my major concern with SVN, the total lack of tagging and
>> branching support.
>>
>> Gordon.
>
> This just isn't accurate. Several posts in this discussion - not even
> all of them being mine - have indirectly or directly explained that  
> svn
> does have branching/tagging.

Yes it does have very basic tagging/branching but when you compare  
this is git, dvcs, etc and even cvs they are head and shoulders above  
SVN tagging/branching

Gordon.


From victorkane at gmail.com  Fri Aug  1 01:03:03 2008
From: victorkane at gmail.com (Victor Kane)
Date: Thu, 31 Jul 2008 22:03:03 -0300
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <54383211-37EA-48CC-983D-4A9CEC6CBFF2@heydon.com.au>
References: <48909BD1.2020908@webchick.net>
	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>
	<48909F2A.7030700@webchick.net> <E1KOVbt-0004Ik-Q8@fenris.runbox.com>
	<8290C899-9906-4543-B5B5-FFCFEDDE672A@heydon.com.au>
	<4891E1D7.7090209@logrus.com>
	<C3C4E73E-1BFF-4888-825F-4E5C4BC751E5@heydon.com.au>
	<1217547145.12087.102.camel@thereishope>
	<54383211-37EA-48CC-983D-4A9CEC6CBFF2@heydon.com.au>
Message-ID: <ff176450807311803i11587e04m47852e1743729015@mail.gmail.com>

On Thu, Jul 31, 2008 at 9:36 PM, Gordon Heydon <gordon at heydon.com.au> wrote:

Why "head and shoulders above SVN tagging/branching"?

Could you or others making these kinds of assertions possibly justify them?

They are stated as if they were "self-evident truths".

I used SCCS for over a decade on various flavors of Unix.

CVS was then the new kid on the block, and I used that for a decade and a
half.

Then, SVN, with its very functional tagging and branching system,
brilliantly optimized as the economical copying of pointers, have simplified
everything and given much better support for binary files, precision
directory permissions on the group and user level, a system rich in
pre-process and post-process hooks, an API usable by various languages,
WebDav (read-only) for basic browsing...

The whole idea of this thread is to discuss how Drupal can be firmly rooted
in the tools and workflows that real world developers actually use on an
everyday basis, and for good reason; so as to encourage, as webchick wrote,
best practices, and, making Drupal convenient, adoptable...

Larry Garfield has explained how for a small core of users, a distributed
RCS (such as git, mercurial, etc.) could be superior, but SVN is the most
mainstream, is what people actually use.

git is also creating quite a following among single developers (those not
married to a group) who love the "stand alone", local versioning option
while retaining the option to "push" (commit) to a server...

You go out and contract repository hosting, as I do, for $7 / month I get
unlimited repositories with a TRAC instance for each... cool. Most of these
are offering git also.

With GUI's such as TortoiseSVN and RapidSVN, etc.... it just seems the most
attractive and useful way to go.

The only argument against that might make some sense is what Earl Miles said
about it probably being a lot of hard work perhaps better spent on other
worthy core causes.

Yet there is something to be said for using tools people use and for good
reason.

Victor Kane
http://awebfactory.com.ar



>
>>> Yes this is my major concern with SVN, the total lack of tagging and
>>> branching support.
>>>
>>> Gordon.
>>>
>>
>> This just isn't accurate. Several posts in this discussion - not even
>> all of them being mine - have indirectly or directly explained that svn
>> does have branching/tagging.
>>
>
> Yes it does have very basic tagging/branching but when you compare this is
> git, dvcs, etc and even cvs they are head and shoulders above SVN
> tagging/branching
>
> Gordon.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080731/bd3472e5/attachment.htm 

From larry at garfieldtech.com  Fri Aug  1 04:00:45 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Thu, 31 Jul 2008 23:00:45 -0500
Subject: [development]
	=?utf-8?q?FAQ=3A_Why_is_Drupal_still_using_CVS_when?=
	=?utf-8?q?_X_is_a=09much_better_choice=3F?=
In-Reply-To: <1217547145.12087.102.camel@thereishope>
References: <48909BD1.2020908@webchick.net>
	<C3C4E73E-1BFF-4888-825F-4E5C4BC751E5@heydon.com.au>
	<1217547145.12087.102.camel@thereishope>
Message-ID: <200807312300.46224.larry@garfieldtech.com>

On Thursday 31 July 2008 6:32:25 pm Sam Boyer wrote:
> > Yes this is my major concern with SVN, the total lack of tagging and
> > branching support.
> >
> > Gordon.
>
> This just isn't accurate. Several posts in this discussion - not even
> all of them being mine - have indirectly or directly explained that svn
> does have branching/tagging.
>
> Sam

I think this is a terminology difference, frankly.

In CVS, branching and tagging is an explicit, discrete operation named tag (or 
tag -b, which is just dumb).  You create a tag/branch by saying "Hey, CVS, 
make a branch from here and call it X".  CVS then does some magic copying and 
shuffling behind the scenes.

In SVN, there is no explicit concept of branching and tagging.  The way SVN 
works internally, you can copy files within the repository dirt cheap.  It 
creates essentially the svn equivalent of a hard link in the file system.  
(It's not implemented that way, but it's conceptually similar.)  Because 
copying is always an O(1) operation that takes virtually no extra disk space, 
you "branch" by copying one working copy to a new location within the 
repository.  You can then start committing to that new location and svn 
tracks the changes internally as needed.  The only difference between a 
branch and a tag is a convention to not commit to a tag; CVS would enforce 
that by its very nature, whereas in CVS there is no inherent difference 
between a branch, a tag, and just copying files around.  

Whether SVN's mechanism is more natural and obvious (you can see all your 
branches at once, very useful when different people use different branching 
structures for their modules) or more geeky-obscure (I want to "branch" so 
why do I use the copy command?  What is this, the "Start" button to 
Shutdown?) is a matter of opinion; I've seen both expressed, both in this 
thread and elsewhere.

-- 
Larry Garfield
larry at garfieldtech.com

From drupal-devel at webchick.net  Fri Aug  1 04:23:16 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Fri, 01 Aug 2008 00:23:16 -0400
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much better choice?
In-Reply-To: <200807312300.46224.larry@garfieldtech.com>
References: <48909BD1.2020908@webchick.net>	<C3C4E73E-1BFF-4888-825F-4E5C4BC751E5@heydon.com.au>	<1217547145.12087.102.camel@thereishope>
	<200807312300.46224.larry@garfieldtech.com>
Message-ID: <48928FB4.8040302@webchick.net>

Larry Garfield wrote:
> On Thursday 31 July 2008 6:32:25 pm Sam Boyer wrote:
>>> Yes this is my major concern with SVN, the total lack of tagging and
>>> branching support.
>>>
>>> Gordon.
>> This just isn't accurate. Several posts in this discussion - not even
>> all of them being mine - have indirectly or directly explained that svn
>> does have branching/tagging.
>>
>> Sam
<snip>
> The only difference between a 
> branch and a tag is a convention to not commit to a tag; CVS would enforce 
> that by its very nature, whereas in CVS there is no inherent difference 
> between a branch, a tag, and just copying files around.  

This is true of SVN's default behaviour. I've been schooled this evening 
by Sam that SVN pre-commit hooks can make SVN emulate CVS's definition 
of a tag perfectly. So I'm no longer concerned about this issue.

-Angie


From drupal-devel at webchick.net  Fri Aug  1 04:52:49 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Fri, 01 Aug 2008 00:52:49 -0400
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	better choice?
In-Reply-To: <48909BD1.2020908@webchick.net>
References: <48909BD1.2020908@webchick.net>
Message-ID: <489296A1.9060706@webchick.net>

Angela Byron wrote:
> Since we're all sick of answering this question every week, I've made an 
> attempt at documenting this here:
> 
> http://drupal.org/node/289117
> 
> If someone has some of the old threads laying around and could help 
> flesh that page out (esp. with "here's where you jump in if you want to 
> change this" stuff), that'd be lovely.
> 
> -Angie

Ok, I believe http://drupal.org/node/289117 now reflects most of what 
was covered in this thread:

* Pros and cons of Subversion
* Pros and cons of DVCS (needs work)
* Note that SVN is likely the best choice.
* Fleshed out "How you can help"
* Changed the FAQ to "Why is Drupal still using CVS and how can I help 
change that?" to appease Moshe. :D

I'm sure I'm missing stuff. Please help. The revisions tab is lonely. ;)

-Angie

From adrinux at perlucida.com  Fri Aug  1 13:26:36 2008
From: adrinux at perlucida.com (Adrian Simmons)
Date: Fri, 01 Aug 2008 14:26:36 +0100
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	better choice?
In-Reply-To: <489296A1.9060706@webchick.net>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
Message-ID: <48930F0C.4070000@perlucida.com>


Before we once again leave this subject behinds there's just one more issue 
I'd like to see addressed - that of commitment. We have a clear desire by 
most of the community to move off of CVS, clear arguments as to why and 
where to move too and a pretty clear list of what actually needs to be done.

But we're still in a position where those with the power to veto the 
decision to move altogether (Gerhard, Dries? who else?) appear to be saying 
somehting like: "No, I see no advantages, we're not going to do this."

Can we have a commitment that *if* everything needing to be done that Angie 
kindly listed on http://drupal.org/node/289117 and links therefrom *gets 
done* we *will* move?

Without that I just don't see the community putting in the massive effort 
that's required.

-- 
Adrian Simmons (aka adrinux) <http://perlucida.com>
e-mail <mailto:adrinux at perlucida.com>

From sean at practicalweb.co.uk  Fri Aug  1 14:30:12 2008
From: sean at practicalweb.co.uk (Sean Burlington)
Date: Fri, 01 Aug 2008 15:30:12 +0100
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	better choice?
In-Reply-To: <48930F0C.4070000@perlucida.com>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
Message-ID: <48931DF4.9030606@practicalweb.co.uk>

Adrian Simmons wrote:

> Can we have a commitment that *if* everything needing to be done that 
> Angie kindly listed on http://drupal.org/node/289117 and links therefrom 
> *gets done* we *will* move?
> 

BTW

is it intentional that comments are disabled on that page???

-- 

Sean Burlington

www.practicalweb.co.uk

From drupal at rocktreesky.com  Fri Aug  1 14:47:08 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Fri, 1 Aug 2008 10:47:08 -0400
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much	better choice?
In-Reply-To: <48931DF4.9030606@practicalweb.co.uk>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
	<48931DF4.9030606@practicalweb.co.uk>
Message-ID: <15D49A4B-FDDA-46C8-811B-47096ED63C70@rocktreesky.com>

Yes, it is. :-) Angie turned them off so that the handbook page  
doesn't turn into a discussion (which it has enormous potential to  
do). That is not what the handbook is for. If you see something that  
needs to be corrected on the page, you can file a documentation issue  
for correction (or of on the docs team, edit it). If you want to  
continue *discussion* about it then feel free to start a forum thread  
that points to it.

- Addi

On Aug 1, 2008, at 10:30 AM, Sean Burlington wrote:

> Adrian Simmons wrote:
>
>> Can we have a commitment that *if* everything needing to be done  
>> that Angie kindly listed on http://drupal.org/node/289117 and links  
>> therefrom *gets done* we *will* move?
>
> BTW
>
> is it intentional that comments are disabled on that page???
>
> -- 
>
> Sean Burlington
>
> www.practicalweb.co.uk


From drupal-devel at webchick.net  Fri Aug  1 14:48:52 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Fri, 01 Aug 2008 10:48:52 -0400
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	better choice?
In-Reply-To: <48931DF4.9030606@practicalweb.co.uk>
References: <48909BD1.2020908@webchick.net>
	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>
	<48931DF4.9030606@practicalweb.co.uk>
Message-ID: <48932254.2090002@webchick.net>

Sean Burlington wrote:
> Adrian Simmons wrote:
> 
>> Can we have a commitment that *if* everything needing to be done that 
>> Angie kindly listed on http://drupal.org/node/289117 and links 
>> therefrom *gets done* we *will* move?
>>
> 
> BTW
> 
> is it intentional that comments are disabled on that page???
> 

Yes. Absolutely, completely and utterly intentional. We do not need to 
re-hash this discussion in the handbooks. Let's get our ya-ya's out here 
and then document it there for posterity.

If the reason you want to comment is to start organizing people around 
this topic, make a thread in the revision control group and we can link 
to it from this page. "If you'd like to help, there are efforts going on 
at <link>." If it's not, comment here instead. ;)

-Angie


From sean at practicalweb.co.uk  Fri Aug  1 15:57:08 2008
From: sean at practicalweb.co.uk (Sean Burlington)
Date: Fri, 01 Aug 2008 16:57:08 +0100
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	better choice?
In-Reply-To: <48932254.2090002@webchick.net>
References: <48909BD1.2020908@webchick.net>	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>	<48931DF4.9030606@practicalweb.co.uk>
	<48932254.2090002@webchick.net>
Message-ID: <48933254.3070308@practicalweb.co.uk>

Angela Byron wrote:
> Sean Burlington wrote:
>> Adrian Simmons wrote:
>>
>>> Can we have a commitment that *if* everything needing to be done that 
>>> Angie kindly listed on http://drupal.org/node/289117 and links 
>>> therefrom *gets done* we *will* move?
>>>
>>
>> BTW
>>
>> is it intentional that comments are disabled on that page???
>>
> 
> Yes. Absolutely, completely and utterly intentional. We do not need to 
> re-hash this discussion in the handbooks. Let's get our ya-ya's out here 
> and then document it there for posterity.
> 

sigh... Drupal seems like such a closed shop..

denying comment just adds to the impression

Even if the discussion wasn't useful - why prevent it?!

and without a response to Adrian's question I doubt anyone will put in 
the effort ... and this discussion will come up again.



-- 

Sean Burlington

www.practicalweb.co.uk

From drupal-devel at webchick.net  Fri Aug  1 16:31:29 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Fri, 01 Aug 2008 12:31:29 -0400
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	better choice?
In-Reply-To: <48933254.3070308@practicalweb.co.uk>
References: <48909BD1.2020908@webchick.net>	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>	<48931DF4.9030606@practicalweb.co.uk>	<48932254.2090002@webchick.net>
	<48933254.3070308@practicalweb.co.uk>
Message-ID: <48933A61.10305@webchick.net>

Sean Burlington wrote:

>>> is it intentional that comments are disabled on that page???
>>>
>>
>> Yes. Absolutely, completely and utterly intentional. We do not need to 
>> re-hash this discussion in the handbooks. Let's get our ya-ya's out 
>> here and then document it there for posterity.
>>
> 
> sigh... Drupal seems like such a closed shop..
> 
> denying comment just adds to the impression
> 
> Even if the discussion wasn't useful - why prevent it?!

???

I'm not denying discussion. Discussion can happen here on the mailing 
list (as it has, very healthily so), in the issue tracking/revision 
control groups on groups.drupal.org (which is a great place for 
interested people to collaborate on fixing this), or in the 
Documentation issue queue (if you feel there are errors/omissions -- or 
just join the docs team and you can fix them yourself: 
http://drupal.org/contribute/documentation/join).

The referenced node is a piece of *documentation*. Discussion does not
belong within a piece of documentation, especially not THIS piece of 
documentation whose sole purpose is to aggregate all the various 
discussions that have happened over the years.

> and without a response to Adrian's question I doubt anyone will put in 
> the effort ... and this discussion will come up again.

Yes, that's probably true. I don't think this thread is done yet. :)

-Angie


From jacob at civicactions.com  Fri Aug  1 16:40:33 2008
From: jacob at civicactions.com (Jacob Singh)
Date: Fri, 01 Aug 2008 09:40:33 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	better choice?
In-Reply-To: <48930F0C.4070000@perlucida.com>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
Message-ID: <48933C81.4000906@civicactions.com>

Hi folks,

As a version control junkie, I would be heavily in favor of this
switch.  For development shops, there is an added expense of training /
fixing mistakes when people use CVS.  I've been working in IT for 10yrs,
so I know CVS fairly well (although it is foggy), but many of our
developers are 22-25yrs old and have just heard of CVS the way I have
heard of COBOL :).

I can't say I will volunteer however to fix this across the drupal.org
enterprise.  What I can do if people are interested is help in securing
funding for some people to do it.  I don't know the drupal politics
around this, but I believe this job may simply be too large and complex
to pull off with a volunteer effort.

I don't suppose this is something the Knight foundation would grant
money too, but if not, would it be possible to pass the hat around to
the various Drupal shops to raise money to support a couple people to
take this on full time for a few weeks?

Best,
Jacob Singh

Adrian Simmons wrote:
>
> Before we once again leave this subject behinds there's just one more
> issue I'd like to see addressed - that of commitment. We have a clear
> desire by most of the community to move off of CVS, clear arguments as
> to why and where to move too and a pretty clear list of what actually
> needs to be done.
>
> But we're still in a position where those with the power to veto the
> decision to move altogether (Gerhard, Dries? who else?) appear to be
> saying somehting like: "No, I see no advantages, we're not going to do
> this."
>
> Can we have a commitment that *if* everything needing to be done that
> Angie kindly listed on http://drupal.org/node/289117 and links
> therefrom *gets done* we *will* move?
>
> Without that I just don't see the community putting in the massive
> effort that's required.
>


From drupal at samboyer.org  Fri Aug  1 17:09:46 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Fri, 01 Aug 2008 12:09:46 -0500
Subject: [development] FAQ: Why is Drupal still using CVS when X is
	a	much	better choice?
In-Reply-To: <48933254.3070308@practicalweb.co.uk>
References: <48909BD1.2020908@webchick.net>	<489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>	<48931DF4.9030606@practicalweb.co.uk>
	<48932254.2090002@webchick.net> <48933254.3070308@practicalweb.co.uk>
Message-ID: <1217610586.12087.137.camel@thereishope>

On Fri, 2008-08-01 at 16:57 +0100, Sean Burlington wrote:
> Angela Byron wrote:
> > Sean Burlington wrote:
> >> Adrian Simmons wrote:
> >>
> >>> Can we have a commitment that *if* everything needing to be done that 
> >>> Angie kindly listed on http://drupal.org/node/289117 and links 
> >>> therefrom *gets done* we *will* move?
> >>>
> >>
> >> BTW
> >>
> >> is it intentional that comments are disabled on that page???
> >>
> > 
> > Yes. Absolutely, completely and utterly intentional. We do not need to 
> > re-hash this discussion in the handbooks. Let's get our ya-ya's out here 
> > and then document it there for posterity.
> > 
> 
> sigh... Drupal seems like such a closed shop..
> 
> denying comment just adds to the impression
> 
> Even if the discussion wasn't useful - why prevent it?!
> 
> and without a response to Adrian's question I doubt anyone will put in 
> the effort ... and this discussion will come up again.

*Snip*
?On Thu, 2008-07-31 at 10:19 -0700, Derek Wright wrote:
...
> p.s. Sam, please don't let that stop you from taking over  
> versioncontrol_api.  That'd still be a good thing for project*, even  
> if d.o isn't using SVN or git. ;)

?On Thu, 2008-07-31 at 13:34 -0500, Sam Boyer wrote:
...
> No worries :) As I said in the caveat of my initial response here, I'm
> just providing information, not advocating. Really, even if it doesn't
> sound like it at times :P. I've already taken over vcs api, and will be
> doing what's needed there regardless of how all these decisions play
> out.

*/Snip*

To the extent that working on version control API will contribute to
moving in this direction, I'm committed.


Honestly, my feeling is that Adrian's request puts Dries/Gerhard/whoever
else in an untenable position. It's not that Angie hasn't done an
'empress of open-source awesomeness'-level job with the documentation on
that page. It's that no one vested with the responsibility of managing
something as important as d.o itself can be expected to solidly commit
to implementing an amorphous path forward. ?We may have identified the
right questions on that handbook page, but it doesn't mean they're going
to produce tenable answers. Until we get to the point where either a)
there's a specified proposal on the table (probably with funding
attached to it) that details the process by which we would arrive at a
new system, or b) enough of the necessary coding has already gotten done
that it becomes possible to 'see' our way through to a concrete solution
(which would then STILL need to be written up as a concrete proposal), I
don't think it's fair to ask for any such commitment.

I think that both a) and b) are feasible, and they're not mutually
exclusive. I also tend to think that b) is considerably more likely to
happen for a number of reasons (big surprise that it's the route I'm
personally choosing to pursue), most importantly because it's the route
that connects with work that currently needs doing - on project*, on vcs
api, etc.

And at the end of the day, that's really what I think about all this: if
you want to see a better/smarter/niftier/whatever version control system
in place for drupal, then participate in the drupal do-ocracy and help
shape the tools we have into the tools they could/should be.

Sam


From drupal at dwwright.net  Fri Aug  1 18:18:28 2008
From: drupal at dwwright.net (Derek Wright)
Date: Fri, 1 Aug 2008 11:18:28 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much	 better choice?
In-Reply-To: <48930F0C.4070000@perlucida.com>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
Message-ID: <9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>


On Aug 1, 2008, at 6:26 AM, Adrian Simmons wrote:

> Can we have a commitment that *if* everything needing to be done  
> that Angie kindly listed on http://drupal.org/node/289117 and links  
> therefrom *gets done* we *will* move?

Once upon a time, in a post someone with time and motivation could  
surely find, Dries wrote something to the effect of:

"I'd be happy to switch to something other than CVS _if all the  
dependencies on CVS are safely removed and addressed_".

(approximate quote from memory).

- The #1 dependency on CVS is project_release.module.
- The #2 dependency on CVS is all the CVS account creation stuff.
- The #3 dependency on CVS are the CVS commit log viewing pages,  
links on project nodes, etc.
- The best way to fix all of that is VersionControl API.
- There are pages dedicated to what needs to happen to get us closer,  
already linked from Angie's wonderful document.

If all that work is done, d.o is running VersionControl API with the  
CVS backend, the SVN backend is demonstrated to be stable and working  
on project.drupal.org, we've got the packaging script ported and  
working, we've got the CVS -> SVN import documented and working,  
we've got all the SVN access control worked out (per project like we  
have now, preventing commits to tags, etc, etc), we've got something  
like svn.drupal.org setup care of the OSUOSL, and we've got a team of  
documentation folks lined up to go nuts, I can pretty safely  
guarantee that Dries will say "Yay, go for it!".

That still doesn't answer the question of how the choice of SVN vs.  
XXX will ultimately be decided, nor if decree from Dries is good  
enough for the switch.  The lack of a clear process for making  
decisions like this continues to haunt us.  By default, a decree from  
Dries (if he's willing to make it) carries the day.  If not, I guess  
decree from Dries on how to decide will be necessary.

Meanwhile, it can't possibly hurt to at least move towards project* +  
versioncontrol_cvs as a first (monster) step down this path.  The  
other stuff will be pretty easy (relatively speaking) once that's  
done.  Hurray to Sam for volunteering to help.  But I can assure you  
that more resources will be needed to finish the job.

Cheers,
-Derek (dww)




From drupal at dwwright.net  Fri Aug  1 18:18:34 2008
From: drupal at dwwright.net (Derek Wright)
Date: Fri, 1 Aug 2008 11:18:34 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much	 better choice?
In-Reply-To: <48933C81.4000906@civicactions.com>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
	<48933C81.4000906@civicactions.com>
Message-ID: <01F09991-F8EA-452A-AAA7-BBE7DCE8FF44@dwwright.net>


On Aug 1, 2008, at 9:40 AM, Jacob Singh wrote:

> What I can do if people are interested is help in securing funding  
> for some people to do it.  I don't know the drupal politics around  
> this, but I believe this job may simply be too large and complex to  
> pull off with a volunteer effort.

Hurray, the voice of reason!  Indeed, part of why this hasn't already  
happened is that none of this is my full time job, I don't feel  
*that* strongly about it as a personal itch, and to date, the  
volunteer resources brought to the table have been insufficient to  
drive it home.  Jakob made a heroic effort as a Summer of Code  
project last year, but that wasn't enough.  We've done these sorts of  
fundraising efforts for various d.o infrastructure functionality in  
the past (e.g. the initial push for the release system itself, etc),  
and we'll do more of them in the future (big scale for the d.o  
redesign, small scale for things like a system for packaging up  
installation profiles with a copy of core and all the modules they  
require, and hopefully the D6 upgrade of d.o, etc).  So yes, if you  
want to raise money to help fund the "remove dependencies on CVS and  
pave the way for XXX" effort, please do so.  It will definitely help.

Thanks,
-Derek (dww)





From drupal at samboyer.org  Fri Aug  1 18:32:46 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Fri, 01 Aug 2008 13:32:46 -0500
Subject: [development] FAQ: Why is Drupal still using CVS when X is
	a	much	 better choice?
In-Reply-To: <9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
Message-ID: <1217615566.12087.139.camel@thereishope>

On Fri, 2008-08-01 at 11:18 -0700, Derek Wright wrote:
> On Aug 1, 2008, at 6:26 AM, Adrian Simmons wrote:
> 
> > Can we have a commitment that *if* everything needing to be done  
> > that Angie kindly listed on http://drupal.org/node/289117 and links  
> > therefrom *gets done* we *will* move?
> 
> Once upon a time, in a post someone with time and motivation could  
> surely find, Dries wrote something to the effect of:
> 
> "I'd be happy to switch to something other than CVS _if all the  
> dependencies on CVS are safely removed and addressed_".
> 
> (approximate quote from memory).
> 
> - The #1 dependency on CVS is project_release.module.
> - The #2 dependency on CVS is all the CVS account creation stuff.
> - The #3 dependency on CVS are the CVS commit log viewing pages,  
> links on project nodes, etc.
> - The best way to fix all of that is VersionControl API.
> - There are pages dedicated to what needs to happen to get us closer,  
> already linked from Angie's wonderful document.
> 
> If all that work is done, d.o is running VersionControl API with the  
> CVS backend, the SVN backend is demonstrated to be stable and working  
> on project.drupal.org, we've got the packaging script ported and  
> working, we've got the CVS -> SVN import documented and working,  
> we've got all the SVN access control worked out (per project like we  
> have now, preventing commits to tags, etc, etc), we've got something  
> like svn.drupal.org setup care of the OSUOSL, and we've got a team of  
> documentation folks lined up to go nuts, I can pretty safely  
> guarantee that Dries will say "Yay, go for it!".
> 
> That still doesn't answer the question of how the choice of SVN vs.  
> XXX will ultimately be decided, nor if decree from Dries is good  
> enough for the switch.  The lack of a clear process for making  
> decisions like this continues to haunt us.  By default, a decree from  
> Dries (if he's willing to make it) carries the day.  If not, I guess  
> decree from Dries on how to decide will be necessary.
> 
> Meanwhile, it can't possibly hurt to at least move towards project* +  
> versioncontrol_cvs as a first (monster) step down this path.  The  
> other stuff will be pretty easy (relatively speaking) once that's  
> done.  Hurray to Sam for volunteering to help.  But I can assure you  
> that more resources will be needed to finish the job.

Indeed there will. Help is VERY welcome :)

s

> 
> Cheers,
> -Derek (dww)
> 
> 
> 


From brett at telosstudios.com  Fri Aug  1 18:41:13 2008
From: brett at telosstudios.com (Brett Stoppel)
Date: Fri, 1 Aug 2008 13:41:13 -0500
Subject: [development] EER Diagram for MySQL
Message-ID: <800700680808011141g3e46b9e9td4cab1d207afe41b@mail.gmail.com>

Hi All.

I am in the process of creating an EER Diagram for Drupal with MySQL
Workbench. I have a good start on it, but thought I would ask if one already
exists? I find them really helpful for learning the database side of
applications. If one doesn't exists, is this the right place to ask
questions about the design of the DB? For instance, I am not sure if the
column "aid" in Access, Actions, Actions_id, Authmap are primary keys or if
they are foreign keys. I would love to get a little more done on the diagram
and then upload it for you all to review and make suggestions.

Thanks.

Brett

-- 
Brett Stoppel
Telos Studios
brett at telosstudios.com | 785-218-4493
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080801/f6db0ca7/attachment.htm 

From lyle at ubercart.org  Fri Aug  1 19:23:15 2008
From: lyle at ubercart.org (Lyle Mantooth)
Date: Fri, 01 Aug 2008 15:23:15 -0400
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	 better choice?
In-Reply-To: <9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
References: <48909BD1.2020908@webchick.net>
	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>
	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
Message-ID: <489362A3.9010907@ubercart.org>

Derek Wright wrote:
> Meanwhile, it can't possibly hurt to at least move towards project* + 
> versioncontrol_cvs as a first (monster) step down this path.

Here's something I can try to help with. I'm sure there's a lot of 
research I need to do to get caught up, but this is a concrete goal I 
can work towards.

-- Lyle

From drupal-devel at webchick.net  Fri Aug  1 19:25:42 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Fri, 01 Aug 2008 15:25:42 -0400
Subject: [development] EER Diagram for MySQL
In-Reply-To: <800700680808011141g3e46b9e9td4cab1d207afe41b@mail.gmail.com>
References: <800700680808011141g3e46b9e9td4cab1d207afe41b@mail.gmail.com>
Message-ID: <48936336.4000805@webchick.net>

Brett Stoppel wrote:
> Hi All.
> 
> I am in the process of creating an EER Diagram for Drupal with MySQL 
> Workbench. I have a good start on it, but thought I would ask if one 
> already exists? I find them really helpful for learning the database 
> side of applications. If one doesn't exists, is this the right place to 
> ask questions about the design of the DB? For instance, I am not sure if 
> the column "aid" in Access, Actions, Actions_id, Authmap are primary 
> keys or if they are foreign keys. I would love to get a little more done 
> on the diagram and then upload it for you all to review and make 
> suggestions.

If you open up the module' .install files, or use the Schema module, 
there is already copious documentation on every single field in D6's 
schema. Foreign keys are documented with a particular syntax (I think 
it's {node}.nid but I forget). It'd be neat if you could somehow script 
it somehow so this could be automatically generated from one Drupal 
version to another, and for contributed modules as well.

-Angie, who lost 2 months of her life documenting these fields. ;)

From fgm at osinet.fr  Fri Aug  1 19:43:37 2008
From: fgm at osinet.fr (=?utf-8?Q?Fr=C3=A9d=C3=A9ric_G._MARAND?=)
Date: Fri, 1 Aug 2008 21:43:37 +0200
Subject: [development] EER Diagram for MySQL
In-Reply-To: <800700680808011141g3e46b9e9td4cab1d207afe41b@mail.gmail.com>
References: <800700680808011141g3e46b9e9td4cab1d207afe41b@mail.gmail.com>
Message-ID: <8E1CEE7A68474E62840ED25EFEEE56A5@PCdeMarand>

If you mean ERD, there are a few of them on d.o. and in CVS 
contrib/docs/developer

----- Original Message ----- 
From: Brett Stoppel
To: development at drupal.org
Sent: Friday, August 01, 2008 8:41 PM
Subject: [development] EER Diagram for MySQL


Hi All.

I am in the process of creating an EER Diagram for Drupal with MySQL 
Workbench. I have a good start on it, but thought I would ask if one already 
exists? I find them really helpful for learning the database side of 
applications. If one doesn't exists, is this the right place to ask 
questions about the design of the DB? For instance, I am not sure if the 
column "aid" in Access, Actions, Actions_id, Authmap are primary keys or if 
they are foreign keys. I would love to get a little more done on the diagram 
and then upload it for you all to review and make suggestions.
[...] 


From drupal at dwwright.net  Fri Aug  1 23:26:05 2008
From: drupal at dwwright.net (Derek Wright)
Date: Fri, 1 Aug 2008 16:26:05 -0700
Subject: [development] Drupal CVS outage on Tuesday 2008-08-05,
	11pm-midnight GMT
Message-ID: <A20FD975-F181-47BE-86CA-91DC858B09B4@dwwright.net>

Drupal's CVS repositories will be unavailable for an hour on Tuesday  
2008-08-05 between 11pm and midnight GMT (4pm-5pm US/PDT) while we  
switch over the infrastructure to use SVN instead.

Cheers,
-Derek (dww)


p.s. Just kidding!  But CVS will be down while it moves to a new  
server. ;) Thanks, OSUOSL.




From sirkitree at gmail.com  Fri Aug  1 23:42:00 2008
From: sirkitree at gmail.com (Jerad Bitner)
Date: Fri, 1 Aug 2008 19:42:00 -0400
Subject: [development] Drupal CVS outage on Tuesday 2008-08-05,
	11pm-midnight GMT
In-Reply-To: <A20FD975-F181-47BE-86CA-91DC858B09B4@dwwright.net>
References: <A20FD975-F181-47BE-86CA-91DC858B09B4@dwwright.net>
Message-ID: <215a89c90808011642q2852342fsa24084415fa9dcc7@mail.gmail.com>

HAHAHAHA... how many people just shit themselves?

On Fri, Aug 1, 2008 at 7:26 PM, Derek Wright <drupal at dwwright.net> wrote:

> Drupal's CVS repositories will be unavailable for an hour on Tuesday
> 2008-08-05 between 11pm and midnight GMT (4pm-5pm US/PDT) while we switch
> over the infrastructure to use SVN instead.
>
> Cheers,
> -Derek (dww)
>
>
> p.s. Just kidding!  But CVS will be down while it moves to a new server. ;)
> Thanks, OSUOSL.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080801/d495f9c1/attachment.htm 

From mroswell at gmail.com  Sat Aug  2 00:16:43 2008
From: mroswell at gmail.com (Marjorie Roswell)
Date: Fri, 1 Aug 2008 20:16:43 -0400
Subject: [development] Drupal CVS outage on Tuesday 2008-08-05,
	11pm-midnight GMT
In-Reply-To: <215a89c90808011642q2852342fsa24084415fa9dcc7@mail.gmail.com>
References: <A20FD975-F181-47BE-86CA-91DC858B09B4@dwwright.net>
	<215a89c90808011642q2852342fsa24084415fa9dcc7@mail.gmail.com>
Message-ID: <aa0037c80808011716m5f321772u9a126e9b1478a696@mail.gmail.com>

There are certainly all kinds of humor ..... Oy.

Here's a little acronym-laden poem, an evening break....

Use SVN...
No, CVS!
It's PM now in East US
(I wonder when is GMT?
or how far off from PDT?
The OSUOSL
Is probably the one to tell.

TTFN,

Margie (mroswell)


On Fri, Aug 1, 2008 at 7:42 PM, Jerad Bitner <sirkitree at gmail.com> wrote:
> HAHAHAHA... how many people just shit themselves?
>
> On Fri, Aug 1, 2008 at 7:26 PM, Derek Wright <drupal at dwwright.net> wrote:
>>
>> Drupal's CVS repositories will be unavailable for an hour on Tuesday
>> 2008-08-05 between 11pm and midnight GMT (4pm-5pm US/PDT) while we switch
>> over the infrastructure to use SVN instead.
>>
>> Cheers,
>> -Derek (dww)
>>
>>
>> p.s. Just kidding!  But CVS will be down while it moves to a new server.
>> ;) Thanks, OSUOSL.
>>
>>
>>
>
>

From kathleen at ceardach.com  Sat Aug  2 00:43:00 2008
From: kathleen at ceardach.com (Kathleen Murtagh)
Date: Fri, 1 Aug 2008 20:43:00 -0400
Subject: [development] Drupal CVS outage on Tuesday 2008-08-05,
	11pm-midnight GMT
In-Reply-To: <215a89c90808011642q2852342fsa24084415fa9dcc7@mail.gmail.com>
References: <A20FD975-F181-47BE-86CA-91DC858B09B4@dwwright.net>
	<215a89c90808011642q2852342fsa24084415fa9dcc7@mail.gmail.com>
Message-ID: <1d83e3e60808011743u563e5a5bgb3fce1698fe5d4b3@mail.gmail.com>

My heart did skip a beat, certainly.

On Fri, Aug 1, 2008 at 7:42 PM, Jerad Bitner <sirkitree at gmail.com> wrote:
> HAHAHAHA... how many people just shit themselves?
>
> On Fri, Aug 1, 2008 at 7:26 PM, Derek Wright <drupal at dwwright.net> wrote:
>>
>> Drupal's CVS repositories will be unavailable for an hour on Tuesday
>> 2008-08-05 between 11pm and midnight GMT (4pm-5pm US/PDT) while we switch
>> over the infrastructure to use SVN instead.
>>
>> Cheers,
>> -Derek (dww)
>>
>>
>> p.s. Just kidding!  But CVS will be down while it moves to a new server.
>> ;) Thanks, OSUOSL.

From drupal_development at dropcube.com  Sat Aug  2 01:31:19 2008
From: drupal_development at dropcube.com (Dropcube)
Date: Fri, 01 Aug 2008 20:31:19 -0500
Subject: [development] EER Diagram for MySQL
In-Reply-To: <8E1CEE7A68474E62840ED25EFEEE56A5@PCdeMarand>
References: <800700680808011141g3e46b9e9td4cab1d207afe41b@mail.gmail.com>
	<8E1CEE7A68474E62840ED25EFEEE56A5@PCdeMarand>
Message-ID: <4893B8E7.4080108@dropcube.com>

> If you mean ERD, there are a few of them on d.o. and in CVS 
> contrib/docs/developer
There are also others diagrams here http://drupal.org/node/22754, but  
not sure if they are up to date.

From spennekamp at yahoo.com  Sat Aug  2 12:53:54 2008
From: spennekamp at yahoo.com (sherry)
Date: Sat, 2 Aug 2008 05:53:54 -0700 (PDT)
Subject: [development] howto about git and drupal modules maintain
Message-ID: <313638.97786.qm@web50802.mail.re2.yahoo.com>



Hi I have no idea why I keep getting e mails from alot of your members but do you have a link where I can have someone look into this so I dont get anymore. thanks sherry
spennekamp at yahoo.com

----- Original Message ----
From: "Greg at GrowingVentureSolutions.com" <Greg at GrowingVentureSolutions.com>
To: development at drupal.org; drupal at samboyer.org
Sent: Wednesday, July 30, 2008 11:23:04 PM
Subject: Re: [development] howto about git and drupal modules maintain

I think most folks are happy to put up with cryptic and badly written
if the message is so good ;)? thanks for volunteering to maintain that
module and for the update.

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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080802/5a0738b9/attachment.htm 

From z.stolar at gmail.com  Sun Aug  3 07:14:37 2008
From: z.stolar at gmail.com (Zohar Stolar)
Date: Sun, 03 Aug 2008 10:14:37 +0300
Subject: [development] Choosing the N number for .install's hook_update_N
Message-ID: <48955ADD.1060108@gmail.com>

Is there some policy, or a thumb rule, about choosing the N number for 
.install's hook_update_N?

I've proposed this patch <http://drupal.org/node/288946>, and I chose 
the number of the update to be the next one available.

However, by the time this patch is applied (if it is accepted), it has a 
good chance of failing on this sequential number, if a former patch is 
applied before.

Any directives I should be aware of?


Thanks


--

Zohar Stolar

From kkaefer at gmail.com  Sun Aug  3 08:43:54 2008
From: kkaefer at gmail.com (=?ISO-8859-1?Q?Konstantin_K=E4fer?=)
Date: Sun, 3 Aug 2008 10:43:54 +0200
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <48955ADD.1060108@gmail.com>
References: <48955ADD.1060108@gmail.com>
Message-ID: <1B79E62F-BFBC-4D94-AD3F-D57B5B480916@gmail.com>

The person who commits usually takes care of that. Generally, the next  
available integer is used.

On 03.08.2008, at 09:14, Zohar Stolar wrote:

> Is there some policy, or a thumb rule, about choosing the N number  
> for .install's hook_update_N?
>
> I've proposed this patch <http://drupal.org/node/288946>, and I  
> chose the number of the update to be the next one available.
>
> However, by the time this patch is applied (if it is accepted), it  
> has a good chance of failing on this sequential number, if a former  
> patch is applied before.
>
> Any directives I should be aware of?
>
>
> Thanks
>
>
> --
>
> Zohar Stolar


From info at erikstielstra.nl  Sun Aug  3 21:38:59 2008
From: info at erikstielstra.nl (Erik Stielstra)
Date: Sun, 3 Aug 2008 23:38:59 +0200
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <48955ADD.1060108@gmail.com>
References: <48955ADD.1060108@gmail.com>
Message-ID: <22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>

You find the policy here: http://api.drupal.org/api/function/hook_update_N/7

Erik Stielstra



On 3 aug 2008, at 09:14, Zohar Stolar wrote:

> Is there some policy, or a thumb rule, about choosing the N number  
> for .install's hook_update_N?
>
> I've proposed this patch <http://drupal.org/node/288946>, and I  
> chose the number of the update to be the next one available.
>
> However, by the time this patch is applied (if it is accepted), it  
> has a good chance of failing on this sequential number, if a former  
> patch is applied before.
>
> Any directives I should be aware of?
>
>
> Thanks
>
>
> --
>
> Zohar Stolar


From gotstu at gmail.com  Mon Aug  4 02:12:30 2008
From: gotstu at gmail.com (Stuart Neilson)
Date: Sun, 3 Aug 2008 19:12:30 -0700
Subject: [development] unsubscribe
Message-ID: <7769ee190808031912v530064e5jed6199bb3342aacb@mail.gmail.com>

On Fri, Aug 1, 2008 at 5:43 PM, <development-request at drupal.org> wrote:

> Send development mailing list submissions to
>        development at drupal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.drupal.org/listinfo/development
> or, via email, send a message with subject or body 'help' to
>        development-request at drupal.org
>
> You can reach the person managing the list at
>        development-owner at drupal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of development digest..."
>
>
> Today's Topics:
>
>   1. Re: FAQ: Why is Drupal still using CVS when X is  a       much
>      better choice? (Sam Boyer)
>   2. EER Diagram for MySQL (Brett Stoppel)
>   3. Re: FAQ: Why is Drupal still using CVS when X is a much
>      better choice? (Lyle Mantooth)
>   4. Re: EER Diagram for MySQL (Angela Byron)
>   5. Re: EER Diagram for MySQL (Fr?d?ric G. MARAND)
>   6. Drupal CVS outage on Tuesday 2008-08-05,  11pm-midnight GMT
>      (Derek Wright)
>   7. Re: Drupal CVS outage on Tuesday 2008-08-05,      11pm-midnight
>      GMT (Jerad Bitner)
>   8. Re: Drupal CVS outage on Tuesday 2008-08-05,      11pm-midnight
>      GMT (Marjorie Roswell)
>   9. Re: Drupal CVS outage on Tuesday 2008-08-05,      11pm-midnight
>      GMT (Kathleen Murtagh)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 01 Aug 2008 13:32:46 -0500
> From: Sam Boyer <drupal at samboyer.org>
> Subject: Re: [development] FAQ: Why is Drupal still using CVS when X
>        is      a       much     better choice?
> To: development at drupal.org
> Message-ID: <1217615566.12087.139.camel at thereishope>
> Content-Type: text/plain
>
> On Fri, 2008-08-01 at 11:18 -0700, Derek Wright wrote:
> > On Aug 1, 2008, at 6:26 AM, Adrian Simmons wrote:
> >
> > > Can we have a commitment that *if* everything needing to be done
> > > that Angie kindly listed on http://drupal.org/node/289117 and links
> > > therefrom *gets done* we *will* move?
> >
> > Once upon a time, in a post someone with time and motivation could
> > surely find, Dries wrote something to the effect of:
> >
> > "I'd be happy to switch to something other than CVS _if all the
> > dependencies on CVS are safely removed and addressed_".
> >
> > (approximate quote from memory).
> >
> > - The #1 dependency on CVS is project_release.module.
> > - The #2 dependency on CVS is all the CVS account creation stuff.
> > - The #3 dependency on CVS are the CVS commit log viewing pages,
> > links on project nodes, etc.
> > - The best way to fix all of that is VersionControl API.
> > - There are pages dedicated to what needs to happen to get us closer,
> > already linked from Angie's wonderful document.
> >
> > If all that work is done, d.o is running VersionControl API with the
> > CVS backend, the SVN backend is demonstrated to be stable and working
> > on project.drupal.org, we've got the packaging script ported and
> > working, we've got the CVS -> SVN import documented and working,
> > we've got all the SVN access control worked out (per project like we
> > have now, preventing commits to tags, etc, etc), we've got something
> > like svn.drupal.org setup care of the OSUOSL, and we've got a team of
> > documentation folks lined up to go nuts, I can pretty safely
> > guarantee that Dries will say "Yay, go for it!".
> >
> > That still doesn't answer the question of how the choice of SVN vs.
> > XXX will ultimately be decided, nor if decree from Dries is good
> > enough for the switch.  The lack of a clear process for making
> > decisions like this continues to haunt us.  By default, a decree from
> > Dries (if he's willing to make it) carries the day.  If not, I guess
> > decree from Dries on how to decide will be necessary.
> >
> > Meanwhile, it can't possibly hurt to at least move towards project* +
> > versioncontrol_cvs as a first (monster) step down this path.  The
> > other stuff will be pretty easy (relatively speaking) once that's
> > done.  Hurray to Sam for volunteering to help.  But I can assure you
> > that more resources will be needed to finish the job.
>
> Indeed there will. Help is VERY welcome :)
>
> s
>
> >
> > Cheers,
> > -Derek (dww)
> >
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 1 Aug 2008 13:41:13 -0500
> From: "Brett Stoppel" <brett at telosstudios.com>
> Subject: [development] EER Diagram for MySQL
> To: development at drupal.org
> Message-ID:
>        <800700680808011141g3e46b9e9td4cab1d207afe41b at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi All.
>
> I am in the process of creating an EER Diagram for Drupal with MySQL
> Workbench. I have a good start on it, but thought I would ask if one
> already
> exists? I find them really helpful for learning the database side of
> applications. If one doesn't exists, is this the right place to ask
> questions about the design of the DB? For instance, I am not sure if the
> column "aid" in Access, Actions, Actions_id, Authmap are primary keys or if
> they are foreign keys. I would love to get a little more done on the
> diagram
> and then upload it for you all to review and make suggestions.
>
> Thanks.
>
> Brett
>
> --
> Brett Stoppel
> Telos Studios
> brett at telosstudios.com | 785-218-4493
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.drupal.org/pipermail/development/attachments/20080801/f6db0ca7/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Fri, 01 Aug 2008 15:23:15 -0400
> From: Lyle Mantooth <lyle at ubercart.org>
> Subject: Re: [development] FAQ: Why is Drupal still using CVS when X
>        is a much        better choice?
> To: development at drupal.org
> Message-ID: <489362A3.9010907 at ubercart.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Derek Wright wrote:
> > Meanwhile, it can't possibly hurt to at least move towards project* +
> > versioncontrol_cvs as a first (monster) step down this path.
>
> Here's something I can try to help with. I'm sure there's a lot of
> research I need to do to get caught up, but this is a concrete goal I
> can work towards.
>
> -- Lyle
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 01 Aug 2008 15:25:42 -0400
> From: Angela Byron <drupal-devel at webchick.net>
> Subject: Re: [development] EER Diagram for MySQL
> To: development at drupal.org
> Message-ID: <48936336.4000805 at webchick.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Brett Stoppel wrote:
> > Hi All.
> >
> > I am in the process of creating an EER Diagram for Drupal with MySQL
> > Workbench. I have a good start on it, but thought I would ask if one
> > already exists? I find them really helpful for learning the database
> > side of applications. If one doesn't exists, is this the right place to
> > ask questions about the design of the DB? For instance, I am not sure if
> > the column "aid" in Access, Actions, Actions_id, Authmap are primary
> > keys or if they are foreign keys. I would love to get a little more done
> > on the diagram and then upload it for you all to review and make
> > suggestions.
>
> If you open up the module' .install files, or use the Schema module,
> there is already copious documentation on every single field in D6's
> schema. Foreign keys are documented with a particular syntax (I think
> it's {node}.nid but I forget). It'd be neat if you could somehow script
> it somehow so this could be automatically generated from one Drupal
> version to another, and for contributed modules as well.
>
> -Angie, who lost 2 months of her life documenting these fields. ;)
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 1 Aug 2008 21:43:37 +0200
> From: Fr?d?ric G. MARAND <fgm at osinet.fr>
> Subject: Re: [development] EER Diagram for MySQL
> To: <development at drupal.org>
> Message-ID: <8E1CEE7A68474E62840ED25EFEEE56A5 at PCdeMarand>
> Content-Type: text/plain; format=flowed; charset="utf-8";
>        reply-type=original
>
> If you mean ERD, there are a few of them on d.o. and in CVS
> contrib/docs/developer
>
> ----- Original Message -----
> From: Brett Stoppel
> To: development at drupal.org
> Sent: Friday, August 01, 2008 8:41 PM
> Subject: [development] EER Diagram for MySQL
>
>
> Hi All.
>
> I am in the process of creating an EER Diagram for Drupal with MySQL
> Workbench. I have a good start on it, but thought I would ask if one
> already
> exists? I find them really helpful for learning the database side of
> applications. If one doesn't exists, is this the right place to ask
> questions about the design of the DB? For instance, I am not sure if the
> column "aid" in Access, Actions, Actions_id, Authmap are primary keys or if
> they are foreign keys. I would love to get a little more done on the
> diagram
> and then upload it for you all to review and make suggestions.
> [...]
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 1 Aug 2008 16:26:05 -0700
> From: Derek Wright <drupal at dwwright.net>
> Subject: [development] Drupal CVS outage on Tuesday 2008-08-05,
>        11pm-midnight GMT
> To: Development <development at drupal.org>
> Message-ID: <A20FD975-F181-47BE-86CA-91DC858B09B4 at dwwright.net>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Drupal's CVS repositories will be unavailable for an hour on Tuesday
> 2008-08-05 between 11pm and midnight GMT (4pm-5pm US/PDT) while we
> switch over the infrastructure to use SVN instead.
>
> Cheers,
> -Derek (dww)
>
>
> p.s. Just kidding!  But CVS will be down while it moves to a new
> server. ;) Thanks, OSUOSL.
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 1 Aug 2008 19:42:00 -0400
> From: "Jerad Bitner" <sirkitree at gmail.com>
> Subject: Re: [development] Drupal CVS outage on Tuesday 2008-08-05,
>        11pm-midnight GMT
> To: development at drupal.org
> Message-ID:
>        <215a89c90808011642q2852342fsa24084415fa9dcc7 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> HAHAHAHA... how many people just shit themselves?
>
> On Fri, Aug 1, 2008 at 7:26 PM, Derek Wright <drupal at dwwright.net> wrote:
>
> > Drupal's CVS repositories will be unavailable for an hour on Tuesday
> > 2008-08-05 between 11pm and midnight GMT (4pm-5pm US/PDT) while we switch
> > over the infrastructure to use SVN instead.
> >
> > Cheers,
> > -Derek (dww)
> >
> >
> > p.s. Just kidding!  But CVS will be down while it moves to a new server.
> ;)
> > Thanks, OSUOSL.
> >
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.drupal.org/pipermail/development/attachments/20080801/d495f9c1/attachment-0001.htm
>
> ------------------------------
>
> Message: 8
> Date: Fri, 1 Aug 2008 20:16:43 -0400
> From: "Marjorie Roswell" <mroswell at gmail.com>
> Subject: Re: [development] Drupal CVS outage on Tuesday 2008-08-05,
>        11pm-midnight GMT
> To: development at drupal.org
> Message-ID:
>        <aa0037c80808011716m5f321772u9a126e9b1478a696 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> There are certainly all kinds of humor ..... Oy.
>
> Here's a little acronym-laden poem, an evening break....
>
> Use SVN...
> No, CVS!
> It's PM now in East US
> (I wonder when is GMT?
> or how far off from PDT?
> The OSUOSL
> Is probably the one to tell.
>
> TTFN,
>
> Margie (mroswell)
>
>
> On Fri, Aug 1, 2008 at 7:42 PM, Jerad Bitner <sirkitree at gmail.com> wrote:
> > HAHAHAHA... how many people just shit themselves?
> >
> > On Fri, Aug 1, 2008 at 7:26 PM, Derek Wright <drupal at dwwright.net>
> wrote:
> >>
> >> Drupal's CVS repositories will be unavailable for an hour on Tuesday
> >> 2008-08-05 between 11pm and midnight GMT (4pm-5pm US/PDT) while we
> switch
> >> over the infrastructure to use SVN instead.
> >>
> >> Cheers,
> >> -Derek (dww)
> >>
> >>
> >> p.s. Just kidding!  But CVS will be down while it moves to a new server.
> >> ;) Thanks, OSUOSL.
> >>
> >>
> >>
> >
> >
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 1 Aug 2008 20:43:00 -0400
> From: "Kathleen Murtagh" <kathleen at ceardach.com>
> Subject: Re: [development] Drupal CVS outage on Tuesday 2008-08-05,
>        11pm-midnight GMT
> To: development at drupal.org
> Message-ID:
>        <1d83e3e60808011743u563e5a5bgb3fce1698fe5d4b3 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> My heart did skip a beat, certainly.
>
> On Fri, Aug 1, 2008 at 7:42 PM, Jerad Bitner <sirkitree at gmail.com> wrote:
> > HAHAHAHA... how many people just shit themselves?
> >
> > On Fri, Aug 1, 2008 at 7:26 PM, Derek Wright <drupal at dwwright.net>
> wrote:
> >>
> >> Drupal's CVS repositories will be unavailable for an hour on Tuesday
> >> 2008-08-05 between 11pm and midnight GMT (4pm-5pm US/PDT) while we
> switch
> >> over the infrastructure to use SVN instead.
> >>
> >> Cheers,
> >> -Derek (dww)
> >>
> >>
> >> p.s. Just kidding!  But CVS will be down while it moves to a new server.
> >> ;) Thanks, OSUOSL.
>
>
> ------------------------------
>
> --
> [ Drupal development list | http://lists.drupal.org/ ]
>
> End of development Digest, Vol 68, Issue 4
> ******************************************
>



-- 
Cheers,
Stuart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080803/3c9f2c27/attachment-0001.htm 

From earnie at users.sourceforge.net  Mon Aug  4 16:09:17 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 04 Aug 2008 12:09:17 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
Message-ID: <20080804120917.68verfiy8fmsgw8o@mail.progw.org>

Quoting Erik Stielstra <info at erikstielstra.nl>:

> You find the policy here: http://api.drupal.org/api/function/hook_update_N/7
>

That doesn't answer the OP's question.  I find the numbering a bit 
limiting.  What happens if a module has version 10.  We should change N 
to read D-M-S where D is the Drupal version, M is the module version 
and S is the sequence number of changes with the dash (-) character 
being the delimiter of versions and sequence.  So mymod-7.x-2.1 upgrade 
would be mymod_update_7-2-1().

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


From merlin at logrus.com  Mon Aug  4 16:29:56 2008
From: merlin at logrus.com (Earl Miles)
Date: Mon, 04 Aug 2008 09:29:56 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <20080804120917.68verfiy8fmsgw8o@mail.progw.org>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
Message-ID: <48972E84.1020408@logrus.com>

Earnie Boyd wrote:
> Quoting Erik Stielstra <info at erikstielstra.nl>:
> 
>> You find the policy here: 
>> http://api.drupal.org/api/function/hook_update_N/7
>>
> 
> That doesn't answer the OP's question.  I find the numbering a bit 
> limiting.  What happens if a module has version 10.  We should change N 
> to read D-M-S where D is the Drupal version, M is the module version and 
> S is the sequence number of changes with the dash (-) character being 
> the delimiter of versions and sequence.  So mymod-7.x-2.1 upgrade would 
> be mymod_update_7-2-1().

So the difference between your setup and the setup in the policy is that 
you include a dash -- which I'll mention isn't legal in function names 
-- but is otherwise identical.

Sorry, I don't think adding a character (and let's assume you meant _ 
which is the only legal possibility) actually adds anything; what it 
does do is break the database which requires the update number to be a 
number.

From earnie at users.sourceforge.net  Mon Aug  4 19:29:26 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 04 Aug 2008 15:29:26 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <48972E84.1020408@logrus.com>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
Message-ID: <20080804152926.oxaa3waese6g4sow@mail.progw.org>

Quoting Earl Miles <merlin at logrus.com>:

> Earnie Boyd wrote:
>> Quoting Erik Stielstra <info at erikstielstra.nl>:
>>
>>> You find the policy here: 
>>> http://api.drupal.org/api/function/hook_update_N/7
>>>
>>
>> That doesn't answer the OP's question.  I find the numbering a bit 
>> limiting.  What happens if a module has version 10.  We should 
>> change N to read D-M-S where D is the Drupal version, M is the 
>> module version and S is the sequence number of changes with the dash 
>> (-) character being the delimiter of versions and sequence.  So 
>> mymod-7.x-2.1 upgrade would be mymod_update_7-2-1().
>
> So the difference between your setup and the setup in the policy is 
> that you include a dash -- which I'll mention isn't legal in function 
> names -- but is otherwise identical.
>
> Sorry, I don't think adding a character (and let's assume you meant _ 
> which is the only legal possibility) actually adds anything; what it 
> does do is break the database which requires the update number to be 
> a number.
>

Aside from the malformed function name 
s/mymod_update_7-2-1()/mymod_update_7_2_1(), the document states that 
the current function requires exactly one character for the Drupal 
version, exactly one character for the module version and exactly two 
characters for the sequence number.  This doesn't allow the module or 
Drupal to go to version 10.  Instead of exactly one, one and two we 
need to delimiterize the versions and sequence so that we can expand 
beyond it easily.

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


From drupal at dwwright.net  Mon Aug  4 20:44:40 2008
From: drupal at dwwright.net (Derek Wright)
Date: Mon, 4 Aug 2008 13:44:40 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <20080804152926.oxaa3waese6g4sow@mail.progw.org>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
Message-ID: <C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>


On Aug 4, 2008, at 12:29 PM, Earnie Boyd wrote:

> Aside from the malformed function name s/mymod_update_7-2-1()/ 
> mymod_update_7_2_1(), the document states that the current function  
> requires exactly one character for the Drupal version, exactly one  
> character for the module version and exactly two characters for the  
> sequence number.  This doesn't allow the module or Drupal to go to  
> version 10.  Instead of exactly one, one and two we need to  
> delimiterize the versions and sequence so that we can expand beyond  
> it easily.

A) This is a convention that allows branch-aware updates to work  
without any changes to the core update.php logic, the schema for the  
{system} table, and other places.

B) Nothing about this prevents Drupal from going to version 10.  At  
that point, we go past 9000 and start numbering things 10000.  No  
problem, except a 1 sentence change to the docs.  We don't need a  
delimiter for this.

C) Any contrib with 10 versions of itself for the same version of  
core needs to seriously consider its own release planning.

I know OG is getting close, but arguably, Moshe is leaping major  
numbers too fast (especially since he never supports the older ones,  
and people are basically forced to keep jumping versions all the time  
if they still want bug fixes).  That's really a separate debate to  
have with Moshe in the OG issue queue, it's pretty irrelevant here.   
Point being: some contrib that's up to major version 10 within the  
same version of core is a pretty pathological edge case, and I don't  
think it's worth changing code in update.php, the schema for the  
{system} table, and other parts of core, to handle schema versions  
that aren't simple integers.

Cheers,
-Derek (dww)




From senpai_san at mac.com  Mon Aug  4 21:02:22 2008
From: senpai_san at mac.com (Senpai)
Date: Mon, 04 Aug 2008 14:02:22 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
Message-ID: <D74C4DC2-4BF0-4768-B656-70A1C068F890@mac.com>

> On Aug 4, 2008, at 1:44 PM, Derek Wright wrote:

>
> C) Any contrib with 10 versions of itself for the same version of  
> core needs to seriously consider its own release planning.


Derek,

If the core release cycle stretches out to two years instead of the 12  
month cycle it's in now, will that change or influence your opinions  
on this? Just wondering.
-- 
Joel Farris
"There is a dangerous virus going around called Worm-Overload- 
Recreational-Killer (WORK).  If you receive WORK from any of your  
colleagues, your boss or via an email, DO NOT TOUCH IT!"


From drupal at dwwright.net  Mon Aug  4 21:15:09 2008
From: drupal at dwwright.net (Derek Wright)
Date: Mon, 4 Aug 2008 14:15:09 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <D74C4DC2-4BF0-4768-B656-70A1C068F890@mac.com>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<D74C4DC2-4BF0-4768-B656-70A1C068F890@mac.com>
Message-ID: <7E1A558C-EF08-4808-99D0-593A85B70402@dwwright.net>


On Aug 4, 2008, at 2:02 PM, Senpai wrote:

> If the core release cycle stretches out to two years instead of the  
> 12 month cycle it's in now, will that change or influence your  
> opinions on this? Just wondering.

Not really.  Just like I don't think the right time for a new release  
is after every commit, I also don't think the right time for a whole  
new major version is after every new feature.  10 new "major"  
versions in the span of even 3 years seems like an awful lot.

And, for the purposes of contrib modules, if they know they're going  
to get this crazy, they can use a slightly modified convention with 5  
digit schema numbers for all I care: 1 for core, 2 for major version,  
2 for sequence number.  So, when OG 5.x-10.0 comes out, it'd be with  
a schema update called og_update_51000.  No harm there (assuming the  
OG 6.x-* schema updates start at 600??) -- these numbers are *only*  
relevant within each project, and all of those integers would be  
higher than the previous 59?? updates that ran from the 5.x-9.*  
series.  So long as the desired behavior is attained (update numbers  
keep getting higher, don't conflict on different branches, and moving  
from a release of one major version to another, or to a new version  
of core entirely, gets you the right schema updates), it's fine if  
individual contribs do it a little differently, especially if they  
clearly document why.


Cheers,
-Derek (dww)





From merlin at logrus.com  Mon Aug  4 21:37:06 2008
From: merlin at logrus.com (Earl Miles)
Date: Mon, 04 Aug 2008 14:37:06 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <7E1A558C-EF08-4808-99D0-593A85B70402@dwwright.net>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<D74C4DC2-4BF0-4768-B656-70A1C068F890@mac.com>
	<7E1A558C-EF08-4808-99D0-593A85B70402@dwwright.net>
Message-ID: <48977682.3070707@logrus.com>

Derek Wright wrote:
> Not really.  Just like I don't think the right time for a new release is 
> after every commit, I also don't think the right time for a whole new 
> major version is after every new feature.  10 new "major" versions in 
> the span of even 3 years seems like an awful lot.

I agree with this. Major versions should be pretty major. And while I've 
been excessively major with my major versions in the past, I would 
expect that bumping the major version number of a product has some very 
serious changes to it that will fundamentally change how it or a part of 
it works and/or how you use it.

However, each maintainer must determine his or her own policies in 
regards to these issues.

From sanari9 at gmail.com  Tue Aug  5 02:24:49 2008
From: sanari9 at gmail.com (Sambasiv Rao Yarramsetty)
Date: Mon,  4 Aug 2008 19:24:49 -0700 (PDT)
Subject: [development] Sambasiv Rao wants to add you as a friend
Message-ID: <20080805022449.66525ED0009@web0.grouply.com>

I want to add you as a friend in Grouply so you can see my profile with my
pictures, my groups, and my favorite group messages. 

Here is the link:  http://www.grouply.com/register.php?r=271020&amp;vt=3026539  

Sambasiv Rao 



==================== 
Click  here  to block all emails from Grouply, 495 Seaport Court, Suite
103, Redwood City, CA 94063. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080804/ddefe2fb/attachment-0001.htm 

From earnie at users.sourceforge.net  Tue Aug  5 12:56:02 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 05 Aug 2008 08:56:02 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <48977682.3070707@logrus.com>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<D74C4DC2-4BF0-4768-B656-70A1C068F890@mac.com>
	<7E1A558C-EF08-4808-99D0-593A85B70402@dwwright.net>
	<48977682.3070707@logrus.com>
Message-ID: <20080805085602.t7xw9s6ut56sk4kc@mail.progw.org>

Quoting Earl Miles <merlin at logrus.com>:

> Derek Wright wrote:
>> Not really.  Just like I don't think the right time for a new 
>> release is after every commit, I also don't think the right time for 
>> a whole new major version is after every new feature.  10 new 
>> "major" versions in the span of even 3 years seems like an awful lot.
>
> I agree with this. Major versions should be pretty major. And while 
> I've been excessively major with my major versions in the past, I 
> would expect that bumping the major version number of a product has 
> some very serious changes to it that will fundamentally change how it 
> or a part of it works and/or how you use it.
>

I agree with this.

> However, each maintainer must determine his or her own policies in 
> regards to these issues.
>

And I agree with this which is why we should change the structure to 
allow the module maintainer more discretion toward that policy.

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


From earnie at users.sourceforge.net  Tue Aug  5 13:08:32 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 05 Aug 2008 09:08:32 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
Message-ID: <20080805090832.th12yy5wo3k0s04o@mail.progw.org>

Quoting Derek Wright <drupal at dwwright.net>:

>
> On Aug 4, 2008, at 12:29 PM, Earnie Boyd wrote:
>
>> Aside from the malformed function name s/mymod_update_7-2-1()/ 
>> mymod_update_7_2_1(), the document states that the current function  
>> requires exactly one character for the Drupal version, exactly one  
>> character for the module version and exactly two characters for the  
>> sequence number.  This doesn't allow the module or Drupal to go to  
>> version 10.  Instead of exactly one, one and two we need to  
>> delimiterize the versions and sequence so that we can expand beyond  
>> it easily.
>
> A) This is a convention that allows branch-aware updates to work  
> without any changes to the core update.php logic, the schema for the  
> {system} table, and other places.
>

Well, yes, but it doesn't mean that we can't modify it a little.

> B) Nothing about this prevents Drupal from going to version 10.  At  
> that point, we go past 9000 and start numbering things 10000.  No  
> problem, except a 1 sentence change to the docs.  We don't need a  
> delimiter for this.
>

No, but you still limit the module maintainers.

> C) Any contrib with 10 versions of itself for the same version of  
> core needs to seriously consider its own release planning.
>

The module version should start over with 1 for each major version 
release of Drupal.  That is ridiculous because the version number of 
the module should be relative to its major releases.  So when 
mymod-5.x-2.0 moves to version 6 it will be named mymod-6.x-2.0.

> I know OG is getting close, but arguably, Moshe is leaping major  
> numbers too fast (especially since he never supports the older ones,  
> and people are basically forced to keep jumping versions all the time 
>  if they still want bug fixes).  That's really a separate debate to  
> have with Moshe in the OG issue queue, it's pretty irrelevant here.   
> Point being: some contrib that's up to major version 10 within the  
> same version of core is a pretty pathological edge case, and I don't  
> think it's worth changing code in update.php, the schema for the  
> {system} table, and other parts of core, to handle schema versions  
> that aren't simple integers.
>

Your limitations are your limitations and should not be placed on Moshe 
or anyone else (w.r.t. this subject).  A simple delimiter in the N 
format of hook_update_N would allow for all possible scenarios.

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


From drupal at dwwright.net  Tue Aug  5 17:37:19 2008
From: drupal at dwwright.net (Derek Wright)
Date: Tue, 5 Aug 2008 10:37:19 -0700
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <20080805090832.th12yy5wo3k0s04o@mail.progw.org>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
Message-ID: <D6653DE8-7DFE-49B3-96CB-034F8FD755CD@dwwright.net>


On Aug 5, 2008, at 6:08 AM, Earnie Boyd wrote:

> Your limitations are your limitations and should not be placed on  
> Moshe or anyone else (w.r.t. this subject).

You chose not to quote the parts of my message[1] where I explained  
there's actually no limitation at all, and Moshe or anyone else is  
free to use 2 digits for their major version in the N of hook_update_N 
().

> A simple delimiter in the N format of hook_update_N would allow for  
> all possible scenarios.

You quoted but seem to have not read or understood the part of my  
other message[2] where I explained this isn't "simple":

"A) This is a convention that allows branch-aware updates to work  
*without any changes to the core update.php logic, the schema for the  
{system} table, and other places.*"

Adding another delimiter to hook_update_N() function signatures would  
require a fairly far-reaching patch.  You can see some of the initial  
discussion in the issue[3] where we decided using an integer  
convention was much easier.

Please (re)read all of this before you propose a "simple" delimiter  
for hook_update_N() which would "solve" a "problem" we don't have. :)

Thanks,
-Derek (dww)

[1] http://lists.drupal.org/pipermail/development/2008-August/ 
030682.html
[2] http://lists.drupal.org/pipermail/development/2008-August/ 
030680.html
[3] http://drupal.org/node/64212




From steves at splicer.com  Tue Aug  5 18:24:49 2008
From: steves at splicer.com (Steve Scotten)
Date: Tue, 5 Aug 2008 11:24:49 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <2401EAF8-F6EE-4F40-ACE1-4AD293F2A379@dwwright.net>
References: <48909BD1.2020908@webchick.net>	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>	<48909F2A.7030700@webchick.net>	<E1KOVbt-0004Ik-Q8@fenris.runbox.com>	<E2B1F041-16EF-4BC6-9113-7A12AA8EC431@bryght.com>
	<48919C5A.6000102@killesreiter.de> <4891EAF0.9080600@webchick.net>
	<2401EAF8-F6EE-4F40-ACE1-4AD293F2A379@dwwright.net>
Message-ID: <1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>

On Jul 31, 2008, at 10:46 AM, Derek Wright wrote:
>
>> 4. Much, much more intuitive commands.
>
> This doesn't matter if people already know the CVS commands.  If  
> they don't, we've got handouts, handbooks, screencasts, DrupalCon  
> talks, off-site writeups, and more, explaining what they need to  
> know...  And, as Earl pointed out, the most important commands for  
> tagging and branching are arguably much less intuitive, and those  
> are the ones people seem to have the most trouble with.

For whatever my experience is worth...

I used CVS quite a bit between 1998 and 2001, and then not at all  
until 2003. In 2001 I was still R'ingTFM to do what should have been  
simple stuff. I then had to go back in 2003 and again in 2005 to work  
on old projects and had to relearn CVS each time, and it was like  
learning it for the first time.

Moving from a CVS skillset (such as it was... clearly I never had a  
great grasp on CVS) to an SVN skillset has been easy. I still look up  
commands from time to time, but most of the time I just use it and get  
on with my work.

Bottom line: I have no desire to become any sort of expert or even  
semiexpert in version control. I want version control to be a tool  
subservient to my needs rather than a black hole sucking up my time,  
attention, and overtaxed brain cells.

So I'm ashamed to admit this, but I was granted my CVS account here  
four months ago and I haven't done anything at all. Nothing.  
Realistically, I may never actually contribute to Drupal in any  
meaningful manner, because every time I sit down to do some work it  
becomes a choice between spending a day fixing bugs in code locally  
(which benefits me and no one else) and spending a day (or a week)  
dealing with relearning a version control system (which benefits no  
one at all). Day after day that means that my local codebase is  
becoming better and I'm not helping the community at all.

All this means that I'm just a lazy doofus whose potential for  
contribution is probably worthless anyhow, but the work is getting  
done. I have a client paying me to do this work and another full-time  
developer at my disposal.

Ultimately the life or death of any project where people are  
contributing their time centers around whether those people see  
benefit. Relearning CVS is something that benefits me not at all.  
(Well, that's not true. If I relearn and reinstall CVS I'd get the  
benefit of developers not junior to me reviewing my code). Seriously.  
If I put "knows CVS" on my r?sum? it's not going to get me any new  
projects. At best it might get me

Learning skills is a career move, and asking developers to learn CVS  
is asking them to make a dead-end career move. Hey, here's a skill  
I'll only use once. Yay.

Again, I understand that I haven't made any arguments about the  
technical merits of either CVS or SVN. But I'm neither lazy nor  
stubborn. I have a finite number of hours in the day and have to make  
choices about where I invest my time. Learning swingdancing is fun.  
Improving my SQL skills is profitable. Getting back up to speed with  
CVS is neither fun nor profitable. It's just punishment for wanting to  
help with the Drupal project.

Having forced you to read this whingeing, I'll write a note to myself  
to at least get as far as checking out some code after I get home  
tonight. That is, assuming nothing more important and pleasurable,  
like washing the dishes or  scrubbing my toilet, needs to be done.


Steve

From merlin at logrus.com  Tue Aug  5 18:33:55 2008
From: merlin at logrus.com (Earl Miles)
Date: Tue, 05 Aug 2008 11:33:55 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much better choice?
In-Reply-To: <1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>
References: <48909BD1.2020908@webchick.net>	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>	<48909F2A.7030700@webchick.net>	<E1KOVbt-0004Ik-Q8@fenris.runbox.com>	<E2B1F041-16EF-4BC6-9113-7A12AA8EC431@bryght.com>	<48919C5A.6000102@killesreiter.de>
	<4891EAF0.9080600@webchick.net>	<2401EAF8-F6EE-4F40-ACE1-4AD293F2A379@dwwright.net>
	<1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>
Message-ID: <48989D13.8030906@logrus.com>

Steve Scotten wrote:
> Bottom line: I have no desire to become any sort of expert or even 
> semiexpert in version control. I want version control to be a tool 
> subservient to my needs rather than a black hole sucking up my time, 
> attention, and overtaxed brain cells.

You only need three commands:

cvs checkout
cvs commit
cvs tag

You'll need pretty much the same commands with an svn system as well. If 
this is difficult it is only because you're making it so.

From merlin at logrus.com  Tue Aug  5 18:53:54 2008
From: merlin at logrus.com (Earl Miles)
Date: Tue, 05 Aug 2008 11:53:54 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much better choice?
In-Reply-To: <48989D13.8030906@logrus.com>
References: <48909BD1.2020908@webchick.net>	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>	<48909F2A.7030700@webchick.net>	<E1KOVbt-0004Ik-Q8@fenris.runbox.com>	<E2B1F041-16EF-4BC6-9113-7A12AA8EC431@bryght.com>	<48919C5A.6000102@killesreiter.de>	<4891EAF0.9080600@webchick.net>	<2401EAF8-F6EE-4F40-ACE1-4AD293F2A379@dwwright.net>	<1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>
	<48989D13.8030906@logrus.com>
Message-ID: <4898A1C2.6040908@logrus.com>

Earl Miles wrote:
> Steve Scotten wrote:
>> Bottom line: I have no desire to become any sort of expert or even 
>> semiexpert in version control. I want version control to be a tool 
>> subservient to my needs rather than a black hole sucking up my time, 
>> attention, and overtaxed brain cells.
> 
> You only need three commands:
> 
> cvs checkout
> cvs commit
> cvs tag

I'm wrong. It's a couple more:

cvs up
cvs diff

cvs log is handy but not really needed.

From nan_wich at bellsouth.net  Tue Aug  5 19:15:32 2008
From: nan_wich at bellsouth.net (Nancy Wichmann)
Date: Tue, 5 Aug 2008 15:15:32 -0400
Subject: [development] FAQ: Why is Drupal still using CVS when X is
	amuch better choice?
In-Reply-To: <1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>
Message-ID: <NCEKJGCAHKMOLJLHNKLJAEKMECAA.nan_wich@bellsouth.net>

Steve Scotten said:
> Bottom line: I have no desire to become any sort of expert or even
> semiexpert in version control. I want version control to be a tool
> subservient to my needs rather than a black hole sucking up my time,
> attention, and overtaxed brain cells.

I am pretty certain that I will get no argument from Derek as to my not
being even a semi-expert on CVS.  But I use it and with little trouble.  In
the time you spent writing your email, you could have learned almost
everything you need to maintain a single branch of a module.  Granted,
maintaining more than one branch will take you another 10 minutes to figure
out.

Derek wrote a reply to me that clarified it all much better than anything
else: http://drupal.org/node/197826#comment-649422. I suggest a quick read -
well, okay a careful read.

Nancy E. Wichmann, PMP



No virus found in this outgoing message.
Checked by AVG - http://www.avg.com 
Version: 8.0.138 / Virus Database: 270.5.12/1590 - Release Date: 8/4/2008 8:09 AM


From earnie at users.sourceforge.net  Tue Aug  5 19:35:47 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Tue, 05 Aug 2008 15:35:47 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <D6653DE8-7DFE-49B3-96CB-034F8FD755CD@dwwright.net>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<D6653DE8-7DFE-49B3-96CB-034F8FD755CD@dwwright.net>
Message-ID: <20080805153547.gug63dv7f404cs88@mail.progw.org>

Quoting Derek Wright <drupal at dwwright.net>:

>
> On Aug 5, 2008, at 6:08 AM, Earnie Boyd wrote:
>
>> Your limitations are your limitations and should not be placed on  
>> Moshe or anyone else (w.r.t. this subject).
>
> You chose not to quote the parts of my message[1] where I explained  
> there's actually no limitation at all, and Moshe or anyone else is  
> free to use 2 digits for their major version in the N of 
> hook_update_N ().
>

Sorry, my POV comes from the documentation provided to the module 
developers where it is stated that exactly 1 digit for Drupal, exactly 
1 digit for the module and exactly 2 digits for the sequence is 
expected.  Are you saying the documentation is incorrect?  I raised the 
suggestion because of the documentation.

>
> Please (re)read all of this before you propose a "simple" delimiter  
> for hook_update_N() which would "solve" a "problem" we don't have. :)
>

Will do.

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


From steves at splicer.com  Tue Aug  5 20:10:50 2008
From: steves at splicer.com (Steve Scotten)
Date: Tue, 5 Aug 2008 13:10:50 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <48989D13.8030906@logrus.com>
References: <48909BD1.2020908@webchick.net>	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>	<48909F2A.7030700@webchick.net>	<E1KOVbt-0004Ik-Q8@fenris.runbox.com>	<E2B1F041-16EF-4BC6-9113-7A12AA8EC431@bryght.com>	<48919C5A.6000102@killesreiter.de>
	<4891EAF0.9080600@webchick.net>	<2401EAF8-F6EE-4F40-ACE1-4AD293F2A379@dwwright.net>
	<1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>
	<48989D13.8030906@logrus.com>
Message-ID: <04A41CA6-16BA-4C3F-9734-522215F056F3@splicer.com>

On Aug 5, 2008, at 11:33 AM, Earl Miles wrote:

> Steve Scotten wrote:
>> Bottom line: I have no desire to become any sort of expert or even  
>> semiexpert in version control. I want version control to be a tool  
>> subservient to my needs rather than a black hole sucking up my  
>> time, attention, and overtaxed brain cells.
>
> You only need three commands:
>
> cvs checkout
> cvs commit
> cvs tag
>
> You'll need pretty much the same commands with an svn system as  
> well. If this is difficult it is only because you're making it so.

Well, no, I also have to read up on creating the config files, define  
environment variables and anything else I need to do to get the CVS  
client to speak to another CVS server, since

cvs --help checkout
Usage:
   cvs checkout [-ANPRcflnps] [-r rev] [-D date] [-d dir]
     [-j rev1] [-j rev2] [-k kopt] modules...

doesn't mention servernames or addresses anywhere. I don't remember  
what CVSROOT specifies and I think that's *probably* important  
information to know. Call me silly.

That's assuming that the version I have (1.12.13) is compatible with  
the version we're using around here. It's dated 2005, so I'm guessing  
the odds are about 60/40 in favor.

I'm not saying any of this is insurmountable. I've learned CVS three  
times already, I'm sure I can relearn it and it probably won't get me  
all confused with my SVN commands. I'm not *quite* that braindead. But  
it's still like interviewing for a job and finding out that I'd be  
required to use edlin to write my code. Yeah, it can be done, and  
edlin uses a small set of easy to remember commands, right? I'd still  
have to be pretty desperate to take such a job. (it was bad enough  
working for a place where vi was the only permitted development tool).

It's not about me and I'm not pretending that this is a dealbreaker or  
should be the only consideration. It's just two facts to consider out  
of many: A CVS user can pick up SVN a lot more easily than an SVN user  
can pick up CVS, and SVN is the more useful skillset in the job market  
nowadays. If these are truly irrelevant, accept my apologies for  
piping up.


Steve

From drupal at samboyer.org  Tue Aug  5 20:29:25 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Tue, 05 Aug 2008 15:29:25 -0500
Subject: [development] FAQ: Why is Drupal still using CVS when X is
	a	much better choice?
In-Reply-To: <04A41CA6-16BA-4C3F-9734-522215F056F3@splicer.com>
References: <48909BD1.2020908@webchick.net>
	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>
	<48909F2A.7030700@webchick.net>	<E1KOVbt-0004Ik-Q8@fenris.runbox.com>
	<E2B1F041-16EF-4BC6-9113-7A12AA8EC431@bryght.com>
	<48919C5A.6000102@killesreiter.de> <4891EAF0.9080600@webchick.net>
	<2401EAF8-F6EE-4F40-ACE1-4AD293F2A379@dwwright.net>
	<1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>
	<48989D13.8030906@logrus.com>
	<04A41CA6-16BA-4C3F-9734-522215F056F3@splicer.com>
Message-ID: <1217968165.8435.55.camel@thereishope>

On Tue, 2008-08-05 at 13:10 -0700, Steve Scotten wrote:
> On Aug 5, 2008, at 11:33 AM, Earl Miles wrote:
> 
> > Steve Scotten wrote:
> >> Bottom line: I have no desire to become any sort of expert or even  
> >> semiexpert in version control. I want version control to be a tool  
> >> subservient to my needs rather than a black hole sucking up my  
> >> time, attention, and overtaxed brain cells.
> >
> > You only need three commands:
> >
> > cvs checkout
> > cvs commit
> > cvs tag
> >
> > You'll need pretty much the same commands with an svn system as  
> > well. If this is difficult it is only because you're making it so.
> 
> Well, no, I also have to read up on creating the config files, define  
> environment variables and anything else I need to do to get the CVS  
> client to speak to another CVS server, since
> 
> cvs --help checkout
> Usage:
>    cvs checkout [-ANPRcflnps] [-r rev] [-D date] [-d dir]
>      [-j rev1] [-j rev2] [-k kopt] modules...
> 
> doesn't mention servernames or addresses anywhere. I don't remember  
> what CVSROOT specifies and I think that's *probably* important  
> information to know. Call me silly.
> 
> That's assuming that the version I have (1.12.13) is compatible with  
> the version we're using around here. It's dated 2005, so I'm guessing  
> the odds are about 60/40 in favor.
> 
> I'm not saying any of this is insurmountable. I've learned CVS three  
> times already, I'm sure I can relearn it and it probably won't get me  
> all confused with my SVN commands. I'm not *quite* that braindead. But  
> it's still like interviewing for a job and finding out that I'd be  
> required to use edlin to write my code. Yeah, it can be done, and  
> edlin uses a small set of easy to remember commands, right? I'd still  
> have to be pretty desperate to take such a job. (it was bad enough  
> working for a place where vi was the only permitted development tool).
> 
> It's not about me and I'm not pretending that this is a dealbreaker or  
> should be the only consideration. It's just two facts to consider out  
> of many: A CVS user can pick up SVN a lot more easily than an SVN user  
> can pick up CVS, and SVN is the more useful skillset in the job market  
> nowadays. If these are truly irrelevant, accept my apologies for  
> piping up.
> 
> 
> Steve

Just speaking for myself here, but I do think this line of discussion is
fairly irrelevant, although maybe not for the first reason you'd think
of. The original thread of this conversation focused on some of the
technical pros/cons of the various version control systems that are out
there, and my hope is that we all learned something from that
interchange (I know I sure did).

You've started branching towards the utility of a particular skillset in
the marketplace, Steve, and in my mind, that's a relevant issue to
consider - just not right now. There's a moderately clear path forward
here, and it really starts with getting project* and vcs api where they
need to be. Personally, I feel that these non-technical pro/con
discussions are irrelevant until we've got the technical capability to
make changing vcs a reality - and consequently, I tend to look on such
discussions as time that could've been better spent coding :)

Sam


From merlin at logrus.com  Tue Aug  5 20:30:44 2008
From: merlin at logrus.com (Earl Miles)
Date: Tue, 05 Aug 2008 13:30:44 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much better choice?
In-Reply-To: <04A41CA6-16BA-4C3F-9734-522215F056F3@splicer.com>
References: <48909BD1.2020908@webchick.net>	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>	<48909F2A.7030700@webchick.net>	<E1KOVbt-0004Ik-Q8@fenris.runbox.com>	<E2B1F041-16EF-4BC6-9113-7A12AA8EC431@bryght.com>	<48919C5A.6000102@killesreiter.de>	<4891EAF0.9080600@webchick.net>	<2401EAF8-F6EE-4F40-ACE1-4AD293F2A379@dwwright.net>	<1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>	<48989D13.8030906@logrus.com>
	<04A41CA6-16BA-4C3F-9734-522215F056F3@splicer.com>
Message-ID: <4898B874.8080500@logrus.com>

Steve Scotten wrote:
> On Aug 5, 2008, at 11:33 AM, Earl Miles wrote:
> 
>> Steve Scotten wrote:
>>> Bottom line: I have no desire to become any sort of expert or even 
>>> semiexpert in version control. I want version control to be a tool 
>>> subservient to my needs rather than a black hole sucking up my time, 
>>> attention, and overtaxed brain cells.
>>
>> You only need three commands:
>>
>> cvs checkout
>> cvs commit
>> cvs tag
>>
>> You'll need pretty much the same commands with an svn system as well. 
>> If this is difficult it is only because you're making it so.
> 
> Well, no, I also have to read up on creating the config files, define 
> environment variables and anything else I need to do to get the CVS 
> client to speak to another CVS server, since

I've never touched a cvs config file, nor defined an environment 
variable for it.

> cvs --help checkout
> Usage:
>   cvs checkout [-ANPRcflnps] [-r rev] [-D date] [-d dir]
>     [-j rev1] [-j rev2] [-k kopt] modules...

Luckily, drupal.org knows this command: Available as a page beneath 
http://drupal.org/handbooks/repos (which in turn is beneath 
handbooks/cvs): http://drupal.org/node/321

I wouldn't expect cvs to know where our repositories are anyway, so you 
have to get information from drupal.org on where to check out anyway. 
Conveniently the exact command you need is in the same place...

> That's assuming that the version I have (1.12.13) is compatible with the 
> version we're using around here. It's dated 2005, so I'm guessing the 
> odds are about 60/40 in favor.

If version compatibility were an issue, people would complain. A lot.

> It's not about me and I'm not pretending that this is a dealbreaker or 
> should be the only consideration. It's just two facts to consider out of 
> many: A CVS user can pick up SVN a lot more easily than an SVN user can 
> pick up CVS, and SVN is the more useful skillset in the job market 
> nowadays. If these are truly irrelevant, accept my apologies for piping up.

If you say so, but eh. If we could snap our fingers and switch to svn, 
we would. I promise you, it's a lot easier for you to figure out the CVS 
commands than it is for all of drupal.org to change all of our tools and 
code to use svn instead of cvs.

But that's okay; there's a lot more to maintaining a contribution than 
just using CVS, and if CVS is an impediment for you, I expect the other 
stuff will be worse anyway.

From steves at splicer.com  Tue Aug  5 21:13:06 2008
From: steves at splicer.com (Steve Scotten)
Date: Tue, 5 Aug 2008 14:13:06 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is
	a	much better choice?
In-Reply-To: <1217968165.8435.55.camel@thereishope>
References: <48909BD1.2020908@webchick.net>
	<6117a7500807300952o770411cr32d65113b9419746@mail.gmail.com>
	<48909F2A.7030700@webchick.net>	<E1KOVbt-0004Ik-Q8@fenris.runbox.com>
	<E2B1F041-16EF-4BC6-9113-7A12AA8EC431@bryght.com>
	<48919C5A.6000102@killesreiter.de> <4891EAF0.9080600@webchick.net>
	<2401EAF8-F6EE-4F40-ACE1-4AD293F2A379@dwwright.net>
	<1A94491C-9B6A-41E9-A304-7E87374E781B@splicer.com>
	<48989D13.8030906@logrus.com>
	<04A41CA6-16BA-4C3F-9734-522215F056F3@splicer.com>
	<1217968165.8435.55.camel@thereishope>
Message-ID: <E68E7005-7BF4-4F19-BD27-9195739DD5D0@splicer.com>

On Aug 5, 2008, at 1:29 PM, Sam Boyer wrote:

> irrelevant until we've got the technical capability to
> make changing vcs a reality - and consequently, I tend to look on such
> discussions as time that could've been better spent coding :)

That's fair, though if keeping things as they are is the most  
desirable course, why bother even pursuing the capability to change?  
If the advantages of SVN or some other system are not real advantages  
(or at least not for our purposes) then shouldn't we avoid developing  
the capability to change vcs?

Hahah. OK, I caught myself saying "we" on a whole aspect that I don't  
even want to help with. Forgive me. I'll stop being a buttinsky and go  
back to the stuff I've actually volunteered to do. =^)

Thanks,


Steve

From karoly at negyesi.net  Wed Aug  6 05:11:25 2008
From: karoly at negyesi.net (Karoly Negyesi)
Date: Wed, 06 Aug 2008 07:11:25 +0200 (CEST)
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <20080805153547.gug63dv7f404cs88@mail.progw.org>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<D6653DE8-7DFE-49B3-96CB-034F8FD755CD@dwwright.net>
	<20080805153547.gug63dv7f404cs88@mail.progw.org>
Message-ID: <E1KQbIz-0001nQ-79@fenris.runbox.com>

> Sorry, my POV comes from the documentation provided to the module 
> developers where it is stated that exactly 1 digit for Drupal, exactly 
> 1 digit for the module and exactly 2 digits for the sequence is 
> expected.  Are you saying the documentation is incorrect?  I raised the 
> suggestion because of the documentation.

I really try hard to ignore you but as you are wasting Derek's time I can't this time alas.

Why this would not be enough? it's absolutely, totally unrealistic for any module to have 10 branches for a given Drupal version.

It's equally unrealistic for any branch to have more than a hundred database updates.

So how [digit for Drupalcorenumber][digit for branchnumber][two digits for sequence] is not enough?

I would suspect that as usual you do not have a clue just you are writing that we should do this, change that and so forth. I begged you in the past to stop but you don't. Ah well. Life can't be perfect.

From drupal at dwwright.net  Wed Aug  6 06:47:11 2008
From: drupal at dwwright.net (Derek Wright)
Date: Tue, 5 Aug 2008 23:47:11 -0700
Subject: [development] Choosing the N number for .install's	
	hook_update_N
In-Reply-To: <20080805153547.gug63dv7f404cs88@mail.progw.org>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<D6653DE8-7DFE-49B3-96CB-034F8FD755CD@dwwright.net>
	<20080805153547.gug63dv7f404cs88@mail.progw.org>
Message-ID: <6A4BC7C9-BAC8-4B5B-BF82-FE49C46DEAE5@dwwright.net>


On Aug 5, 2008, at 12:35 PM, Earnie Boyd wrote:

> Are you saying the documentation is incorrect?

I'm saying the documentation is sufficient, because it's covering the  
(overwhelmingly) common case.  Exceptional edge cases for insane and/ 
or prolific contrib maintainers can diverge slightly from the  
documented convention as I've already explained.  I don't believe our  
docs should always cover every edge case and exception. That's what  
makes them exceptions. ;)

Cheers,
-Derek (dww)




From earnie at users.sourceforge.net  Wed Aug  6 12:21:46 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Wed, 06 Aug 2008 08:21:46 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <E1KQbIz-0001nQ-79@fenris.runbox.com>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<D6653DE8-7DFE-49B3-96CB-034F8FD755CD@dwwright.net>
	<20080805153547.gug63dv7f404cs88@mail.progw.org>
	<E1KQbIz-0001nQ-79@fenris.runbox.com>
Message-ID: <20080806082146.wndwl16e98g008c8@mail.progw.org>

Quoting Karoly Negyesi <karoly at negyesi.net>:

>
> So how [digit for Drupalcorenumber][digit for branchnumber][two 
> digits for sequence] is not enough?
>

When digit becomes digits it is not enough.

However I've understood Derek to say that N is just a sequence number 
and [digit for Drupalcorenumber][digit for branchnumber][two digits for 
sequence] is a convention that isn't enforced by code.  So 
mymod_update_1 is sufficient for the update script to find my update.  
The documentation doesn't state that though; so this exercise wasn't a 
waste of time because at least now it is documented in the list 
archives.

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


From morbus at disobey.com  Wed Aug  6 12:38:30 2008
From: morbus at disobey.com (Morbus Iff)
Date: Wed, 06 Aug 2008 08:38:30 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <20080806082146.wndwl16e98g008c8@mail.progw.org>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<D6653DE8-7DFE-49B3-96CB-034F8FD755CD@dwwright.net>	<20080805153547.gug63dv7f404cs88@mail.progw.org>	<E1KQbIz-0001nQ-79@fenris.runbox.com>
	<20080806082146.wndwl16e98g008c8@mail.progw.org>
Message-ID: <48999B46.2080700@disobey.com>

> mymod_update_1 is sufficient for the update script to find my update.  
> The documentation doesn't state that though; so this exercise wasn't a 
> waste of time because at least now it is documented in the list 

That's always worked - that's how it was in Drupal 5. The convention 
preferred in Drupal 6 is merely a human-friendly helper, to more cleanly 
distinguish which version an update is tied to. As long as your updates 
are in sequential numeric order, the convention you use doesn't really, 
truly, matter - the calling code doesn't give a crap.

With that said, I agree with everyone else's sentiment: you're wrong ;)

-- 
Morbus Iff ( i put the demon back in codemonkey )
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 sheldon at prwatch.org  Wed Aug  6 13:54:52 2008
From: sheldon at prwatch.org (Sheldon Rampton)
Date: Wed, 6 Aug 2008 08:54:52 -0500
Subject: [development] : FAQ: Why is Drupal still using CVS when X is a	much
	better choice?
In-Reply-To: <mailman.6399.1218025314.9743.development@drupal.org>
References: <mailman.6399.1218025314.9743.development@drupal.org>
Message-ID: <47A0DEC5-1B24-40D7-B50D-9CBD8EF34E75@prwatch.org>

I've followed a bit of this discussion and just thought I'd throw in  
my two cents.

Personally, I think SVN is easier to learn and use than CVS. I've had  
trouble using CVS to maintain my contrib modules on Drupal.org.  
Probably the worst example occurred when I tried using an applications  
(recommended in the documentation at drupal.org) that was supposed to  
provide a graphical user interface for CVS on my Mac. In practice, it  
just added one more layer of abstraction between me and the actions I  
was trying to take. I ended up calling some command from the  
application menu that I though would commit a change to one of my  
files. Instead it iterated through my entire downloaded collection of  
nearly a hundred Drupal modules, committing changes to all of them  
(including modules that other people had written). Someone else must  
have cleaned up the mess that left behind, because I didn't know how to.

Having said all this, I also recognize that there is value to  
constancy in purpose, and the Drupal repository has a long history of  
being maintained under CVS, which I think would make it rather  
difficult to change over to something else at this point. Rather than  
switching from CVS to something else, it might be better to work on  
improving the documentation, which right now seems rather scattered  
and hard to follow. (It looks like it was written by committee, which  
of course it was.) If someone could come up with the money, I think it  
would be a good idea to hire a skilled technical writer who can go  
through the Drupal documentation systematically with an eye to making  
it more user-friendly.

-------------------------------------------

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: 608-260-9713

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




From andrewberry at sentex.net  Wed Aug  6 17:17:15 2008
From: andrewberry at sentex.net (Andrew Berry)
Date: Wed, 6 Aug 2008 13:17:15 -0400
Subject: [development] : FAQ: Why is Drupal still using CVS when X is
	a	much better choice?
In-Reply-To: <47A0DEC5-1B24-40D7-B50D-9CBD8EF34E75@prwatch.org>
References: <mailman.6399.1218025314.9743.development@drupal.org>
	<47A0DEC5-1B24-40D7-B50D-9CBD8EF34E75@prwatch.org>
Message-ID: <D6246BC7-B8DD-47C3-A1C7-D190F492CAD4@sentex.net>

On 6-Aug-08, at 9:54 AM, Sheldon Rampton wrote:

> Instead it iterated through my entire downloaded collection of  
> nearly a hundred Drupal modules, committing changes to all of them  
> (including modules that other people had written). Someone else must  
> have cleaned up the mess that left behind, because I didn't know how  
> to.

AFAIK you only have permissions to commit to modules which you are a  
maintainer of, so I think your commit would have failed on anything  
other than your projects.

--Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2692 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20080806/410e3c90/attachment.bin 

From freso.dk at gmail.com  Thu Aug  7 08:46:13 2008
From: freso.dk at gmail.com (Frederik 'Freso' S. Olesen)
Date: Thu, 07 Aug 2008 10:46:13 +0200
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <20080805090832.th12yy5wo3k0s04o@mail.progw.org>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
Message-ID: <489AB655.1090604@gmail.com>

Earnie Boyd skrev:
>Quoting Derek Wright <drupal at dwwright.net>:
>>C) Any contrib with 10 versions of itself for the same version of  
>>core needs to seriously consider its own release planning.
>
 >The module version should start over with 1 for each major version
>release of Drupal.  That is ridiculous because the version number of the 
>module should be relative to its major releases.  So when mymod-5.x-2.0 
>moves to version 6 it will be named mymod-6.x-2.0.

Why?

Pathauto 5.x-2.x is functionally (and almost codewise) identical to 
6.x-1.x. Pathauto 6.x-2.x is where new features get in now. Once Drupal 
7 comes along, Pathauto 7.x-1.x will be the branch porting the Pathauto 
6.x code, no matter if we're still at 6.x-2.x, or if we've reached 
6.x-9.x ? the first major Pathauto version branch for Drupal 7 will be 
Pathauto 7.x-1.x.

-- 
Venlig hilsen,
Frederik "Freso" S. Olesen <http://freso.dk/>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/development/attachments/20080807/2ea1115b/attachment.pgp 

From mail at webthatworks.it  Thu Aug  7 09:45:41 2008
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Thu, 7 Aug 2008 11:45:41 +0200
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	 better choice?
In-Reply-To: <9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
Message-ID: <20080807114541.2944341f@dawn.webthatworks.it>

On Fri, 1 Aug 2008 11:18:28 -0700
Derek Wright <drupal at dwwright.net> wrote:

> Once upon a time, in a post someone with time and motivation
> could surely find, Dries wrote something to the effect of:

> "I'd be happy to switch to something other than CVS _if all the  
> dependencies on CVS are safely removed and addressed_".

> (approximate quote from memory).

> - The #1 dependency on CVS is project_release.module.
> - The #2 dependency on CVS is all the CVS account creation stuff.
> - The #3 dependency on CVS are the CVS commit log viewing pages,  
> links on project nodes, etc.
> - The best way to fix all of that is VersionControl API.
> - There are pages dedicated to what needs to happen to get us
> closer, already linked from Angie's wonderful document.

> If all that work is done, d.o is running VersionControl API with

Surfing in look for a bunch of howtos I noticed how many projects
switched from one rcs to another.
All kind and all sizes of projects...
And I wondered why drupal find so hard to switch. Then your mail came
to my mind: dependency.

Other projects "outsourced" the infrastructure for project
management, drupal build its own.
I was wondering what are the advantages of such approach.
Joomla have a much less tied one.
Plone is something in between Drupal and Joomla but still much
nearer to Joomla approach than drupal.

From my "use case" the only disadvantage I can see in a less tied
approach with contrib is security support. This as more to due with
the social/image aspect than the technical aspect.

Other projects seems just to provide a window for contrib. Drupal
seems to "patronize" contrib.

But that's not going to make contrib really better unless you think
you can force education on people.
Dev that never felt the need of a rcs and are forced to use one will
use it in a sloppy way with fewer advantages for the project than
added nuisances.

From _my_ point of view as a user and as a contrib I'd feel happy
with Joomla approach as well.
I don't see any reason to ask for a cvs account on drupal to develop
my modules. I have my project infrastructure and if I hadn't one I
could pick up one from the many offered, building up my preferred mix
of bug tracking system, rcs, documentation system, ...
I may be missing something... if so please tell me what could be the
advantage for contrib and users to use drupal infrastructure for
project management I don't get. Other than publicity what do I get
from drupal infrastructure?

Making it clear (to me and to everyone else) what are the advantages
of using drupal infrastructure for project management would surely
help.
People will use it more and better.
It would be easier to gather the forces to improve it.
It would make it clearer the scope of having a "project"
infrastructure and plan it for its real targets.

I don't think that core has so many tie with project_release.module
and cvs accounts.
I do think that core could take a great advantage if we could use a
DVCS.

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


From earnie at users.sourceforge.net  Thu Aug  7 12:20:29 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 07 Aug 2008 08:20:29 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <489AB655.1090604@gmail.com>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<489AB655.1090604@gmail.com>
Message-ID: <20080807082029.hxgh838shugc04co@mail.progw.org>

Quoting "Frederik 'Freso' S. Olesen" <freso.dk at gmail.com>:

> Earnie Boyd skrev:
>> Quoting Derek Wright <drupal at dwwright.net>:
>>> C) Any contrib with 10 versions of itself for the same version of  
>>> core needs to seriously consider its own release planning.
>>
> >The module version should start over with 1 for each major version
>> release of Drupal.  That is ridiculous because the version number of 
>> the module should be relative to its major releases.  So when 
>> mymod-5.x-2.0 moves to version 6 it will be named mymod-6.x-2.0.
>
> Why?
>
> Pathauto 5.x-2.x is functionally (and almost codewise) identical to 
> 6.x-1.x. Pathauto 6.x-2.x is where new features get in now. Once 
> Drupal 7 comes along, Pathauto 7.x-1.x will be the branch porting the 
> Pathauto 6.x code, no matter if we're still at 6.x-2.x, or if we've 
> reached 6.x-9.x ? the first major Pathauto version branch for 
> Drupal 7 will be Pathauto 7.x-1.x.
>

Because the version of the module is solely independent of the version 
of Drupal.  The version of the module indicates API and/or UI 
differences.  If you have version 2.x of your module in version 5.x of 
Drupal and then change it to version 1.x for version 6.x of Drupal; one 
tends to view the 6.x-1.x as the same interface as 5.x-1.x.

But I'm wrong and will shut the hell up.

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


From aclight at gmail.com  Thu Aug  7 12:40:59 2008
From: aclight at gmail.com (Adam Light)
Date: Thu, 7 Aug 2008 07:40:59 -0500
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <20080807114541.2944341f@dawn.webthatworks.it>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
	<20080807114541.2944341f@dawn.webthatworks.it>
Message-ID: <a008eb250808070540n4b9cb7ddyc256187f8719abc2@mail.gmail.com>

On Thu, Aug 7, 2008 at 4:45 AM, Ivan Sergio Borgonovo
<mail at webthatworks.it> wrote:
> From _my_ point of view as a user and as a contrib I'd feel happy
> with Joomla approach as well.
> I don't see any reason to ask for a cvs account on drupal to develop
> my modules. I have my project infrastructure and if I hadn't one I
> could pick up one from the many offered, building up my preferred mix
> of bug tracking system, rcs, documentation system, ...
> I may be missing something... if so please tell me what could be the
> advantage for contrib and users to use drupal infrastructure for
> project management I don't get. Other than publicity what do I get
> from drupal infrastructure?
>
> Making it clear (to me and to everyone else) what are the advantages
> of using drupal infrastructure for project management would surely
> help.

Feel free to contribute in whatever way you feel best serves your needs.

Using the d.o infrastructure for project management does provide some
real benefits to the user community as a whole and to individual
projects.  First of all, nobody has to worry about finding a service
to use, or building their own.  There are no RCS servers to maintain.
Plus, there is a consistent interface to all of these tools across
projects.

In addition, the update_status module gets its information from
drupal.org.  If your module isn't hosted on d.o, then users of your
module will not be informed of updates, whether these updates include
security fixes, new features, bug fixes, etc.  In addition, third
party sites like drupalmodules that scrape drupal.org will also
probably not know about your module.  Less visibility often means less
contributions from other developers.

Plus, as you mentioned, the d.o security team only monitors projects
hosted on the d.o infrastructure.

Adam

From morbus at disobey.com  Thu Aug  7 13:00:29 2008
From: morbus at disobey.com (Morbus Iff)
Date: Thu, 07 Aug 2008 09:00:29 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <20080807082029.hxgh838shugc04co@mail.progw.org>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
Message-ID: <489AF1ED.9050008@disobey.com>

> Because the version of the module is solely independent of the version 
> of Drupal.  The version of the module indicates API and/or UI 
> differences.  If you have version 2.x of your module in version 5.x of 
> Drupal and then change it to version 1.x for version 6.x of Drupal; one 
> tends to view the 6.x-1.x as the same interface as 5.x-1.x.
> 
> But I'm wrong and will shut the hell up.

Actually, I agree with Earnie here ;)

(Only about module versions being independent of Drupal versions).

-- 
Morbus Iff ( if i could change the future, i'd change the past instead )
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 mail at webthatworks.it  Thu Aug  7 14:26:43 2008
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Thu, 7 Aug 2008 16:26:43 +0200
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much better choice?
In-Reply-To: <a008eb250808070540n4b9cb7ddyc256187f8719abc2@mail.gmail.com>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
	<20080807114541.2944341f@dawn.webthatworks.it>
	<a008eb250808070540n4b9cb7ddyc256187f8719abc2@mail.gmail.com>
Message-ID: <20080807162643.4f98dcf2@dawn.webthatworks.it>

On Thu, 7 Aug 2008 07:40:59 -0500
"Adam Light" <aclight at gmail.com> wrote:

> On Thu, Aug 7, 2008 at 4:45 AM, Ivan Sergio Borgonovo
> <mail at webthatworks.it> wrote:
> > From _my_ point of view as a user and as a contrib I'd feel happy
> > with Joomla approach as well.
> > I don't see any reason to ask for a cvs account on drupal to
> > develop my modules. I have my project infrastructure and if I
> > hadn't one I could pick up one from the many offered, building
> > up my preferred mix of bug tracking system, rcs, documentation
> > system, ... I may be missing something... if so please tell me
> > what could be the advantage for contrib and users to use drupal
> > infrastructure for project management I don't get. Other than
> > publicity what do I get from drupal infrastructure?
> >
> > Making it clear (to me and to everyone else) what are the
> > advantages of using drupal infrastructure for project management
> > would surely help.
> 
> Feel free to contribute in whatever way you feel best serves your
> needs.

> Using the d.o infrastructure for project management does provide
> some real benefits to the user community as a whole and to
> individual projects.  First of all, nobody has to worry about
> finding a service to use, or building their own.  There are no RCS
> servers to maintain. Plus, there is a consistent interface to all
> of these tools across projects.

Drupal could still offer cvs (svn) etc... avoiding the need to look
around without forcing contrib to stick with "drupal way".
I really don't find these advantages worth the effort and pain of
the people maintaining project*. That's just me.
Furthermore the only consistent interface I see is cvs.
If you mean: information for users... the single project pages...
that's what other projects like Joomla or plone are offering without
the need of such a tight coupling with the rcs.

> In addition, the update_status module gets its information from
> drupal.org.  If your module isn't hosted on d.o, then users of your
> module will not be informed of updates, whether these updates
> include security fixes, new features, bug fixes, etc.  In
> addition, third party sites like drupalmodules that scrape
> drupal.org will also probably not know about your module.  Less
> visibility often means less contributions from other developers.

It doesn't mean it could be achieved with other means that will put
a bit more work on contrib devs at the advantage of much less work
on drupal infrastructure and much more freedom for contrib.

We've rss, aggregators... and I think most drupal contrib have a
drupal site.

It doesn't seem that less coupling between the "community plumbing"
aspect and the project management infrastructure is having an
appreciable effect on other project flourishing of extensions.

Furthermore I think that project management needs for core are quite
different to the one of contrib.

In this situation the "status quo" looks better than investing more
resources into project* to support a different rcs.

I still don't feel like an exception seeing more ties than
opportunities in an even more structured project*. Am I?

> Plus, as you mentioned, the d.o security team only monitors
> projects hosted on the d.o infrastructure.

As said... I think the "patronage" of sec team is the most valuable
thing. I wonder if sec team actively scrutinise contrib modules or
just coordinate fix in core and sec announcement for contrib.

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


From gerhard at killesreiter.de  Thu Aug  7 14:48:16 2008
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Thu, 07 Aug 2008 16:48:16 +0200
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much better choice?
In-Reply-To: <20080807162643.4f98dcf2@dawn.webthatworks.it>
References: <48909BD1.2020908@webchick.net>
	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>	<20080807114541.2944341f@dawn.webthatworks.it>	<a008eb250808070540n4b9cb7ddyc256187f8719abc2@mail.gmail.com>
	<20080807162643.4f98dcf2@dawn.webthatworks.it>
Message-ID: <489B0B30.9010509@killesreiter.de>

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

Ivan Sergio Borgonovo schrieb:
> On Thu, 7 Aug 2008 07:40:59 -0500
> "Adam Light" <aclight at gmail.com> wrote:
> 
>> On Thu, Aug 7, 2008 at 4:45 AM, Ivan Sergio Borgonovo
>> <mail at webthatworks.it> wrote:
>>> From _my_ point of view as a user and as a contrib I'd feel happy
>>> with Joomla approach as well.
>>> I don't see any reason to ask for a cvs account on drupal to
>>> develop my modules. I have my project infrastructure and if I
>>> hadn't one I could pick up one from the many offered, building
>>> up my preferred mix of bug tracking system, rcs, documentation
>>> system, ... I may be missing something... if so please tell me
>>> what could be the advantage for contrib and users to use drupal
>>> infrastructure for project management I don't get. Other than
>>> publicity what do I get from drupal infrastructure?
>>>
>>> Making it clear (to me and to everyone else) what are the
>>> advantages of using drupal infrastructure for project management
>>> would surely help.
>> Feel free to contribute in whatever way you feel best serves your
>> needs.
> 
>> Using the d.o infrastructure for project management does provide
>> some real benefits to the user community as a whole and to
>> individual projects.  First of all, nobody has to worry about
>> finding a service to use, or building their own.  There are no RCS
>> servers to maintain. Plus, there is a consistent interface to all
>> of these tools across projects.
> 
> Drupal could still offer cvs (svn) etc... avoiding the need to look
> around without forcing contrib to stick with "drupal way".  I really
> don't find these advantages worth the effort and pain of the people
> maintaining project*. That's just me.

Great, so can you please get lost now? Your inane comments on this
list have annoyed me for the longest time now. Since you probably
don't have the grace to disappear I'll solve the problem my way,
filterlist amended.

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

iD8DBQFImwswfg6TFvELooQRAgL4AKCuxl7pAwaNBftak8yzUWfmGcVG9wCfRNs+
OreHW6KX9a1Xlf0KaeX/XmU=
=zhXa
-----END PGP SIGNATURE-----

From catch56 at googlemail.com  Thu Aug  7 14:56:22 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 7 Aug 2008 15:56:22 +0100
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <20080807162643.4f98dcf2@dawn.webthatworks.it>
References: <48909BD1.2020908@webchick.net> <489296A1.9060706@webchick.net>
	<48930F0C.4070000@perlucida.com>
	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
	<20080807114541.2944341f@dawn.webthatworks.it>
	<a008eb250808070540n4b9cb7ddyc256187f8719abc2@mail.gmail.com>
	<20080807162643.4f98dcf2@dawn.webthatworks.it>
Message-ID: <fa5724270808070756q11d13a9sbd374bf18039c8e1@mail.gmail.com>

 Ivan Sergio Borgonovo wrote:
>
> It doesn't seem that less coupling between the "community plumbing"
> aspect and the project management infrastructure is having an
> appreciable effect on other project flourishing of extensions.
>

For me there's several reasons why the centralised project*
infrastructure is an extremely good thing.
In most cases, other projects don't have modules which are in any way
as interdependent as Drupal's - not just CCK and Views, but modules
like Token, VotingAPI, imagecache and suites like ecommerce and
ubercart where there's a tonne of dependent modules as well, many many
others. Having all these in one place is a massive benefit, and
encourages inter-project collaboration.

Another issue is that if you use a popular module and the developer is
hit by a bus, then assuming it's used by some other people with enough
experience to take it over and enough of a need for it, there's a fair
chance the module will be adopted by a new maintainer - not on some
random website that you might find via searching a year later when
you're looking to upgrade, but right in the same spot. This is in
contrast to jQuery plugins where there'll be a howto on one site,
followed by a plugin on another site, then a different version of the
plugin on someone elses site - none of which have clear version
compatibility - I use jQuery as an example because they actually use
project* on jquery.com for the central project browsing minus the CVS
integration.

While core development is a very different process from contrib,
nearly everyone pointing out how different it is has failed to mention
that almost as many people contribute core patches as have CVS
accounts on drupal.org - for some their patch is their one and only
contribution to Drupal before disappearing again. Not to mention core
uses exactly the same infrastructure as contrib for packaging etc. -
meaning the infrastructure work would be about as much.

Ivan:
> I wonder if sec team actively scrutinise contrib modules or
> just coordinate fix in core and sec announcement for contrib.
>
>

The sec team doesn't go reviewing random contrib modules - there's
about as many contribs released per day as there are security team
members, however there is active support for security issues in
contrib  once reported, so it's more than just releasing an
announcement.

Nat

From drupal at dwwright.net  Thu Aug  7 15:37:01 2008
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 7 Aug 2008 08:37:01 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <489B0B30.9010509@killesreiter.de>
References: <48909BD1.2020908@webchick.net>
	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>	<20080807114541.2944341f@dawn.webthatworks.it>	<a008eb250808070540n4b9cb7ddyc256187f8719abc2@mail.gmail.com>
	<20080807162643.4f98dcf2@dawn.webthatworks.it>
	<489B0B30.9010509@killesreiter.de>
Message-ID: <39796237-4A11-4818-882B-83A61E47BE4D@dwwright.net>


On Aug 7, 2008, at 7:48 AM, Gerhard Killesreiter wrote:

> Since you probably don't have the grace to disappear I'll solve the  
> problem my way, filterlist amended.


Even if he frequently makes inane comments that we regularly disagree  
with, it doesn't mean we should ban him from the list.  While I  
disagree with the thrust of his latest contribution, I think he  
raises questions that need real answers, not a heavy handed "get lost".

Thanks to Adam and Nat for actually answering the questions, which I  
thought were valuable messages for this list to read and consider.

Cheers,
-Derek (dww)




From gerhard at killesreiter.de  Thu Aug  7 15:46:58 2008
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Thu, 07 Aug 2008 17:46:58 +0200
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much better choice?
In-Reply-To: <39796237-4A11-4818-882B-83A61E47BE4D@dwwright.net>
References: <48909BD1.2020908@webchick.net>	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>	<20080807114541.2944341f@dawn.webthatworks.it>	<a008eb250808070540n4b9cb7ddyc256187f8719abc2@mail.gmail.com>	<20080807162643.4f98dcf2@dawn.webthatworks.it>	<489B0B30.9010509@killesreiter.de>
	<39796237-4A11-4818-882B-83A61E47BE4D@dwwright.net>
Message-ID: <489B18F2.3050107@killesreiter.de>

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

Derek Wright schrieb:
> 
> On Aug 7, 2008, at 7:48 AM, Gerhard Killesreiter wrote:
> 
>> Since you probably don't have the grace to disappear I'll solve the
>> problem my way, filterlist amended.
> 
> 
> Even if he frequently makes inane comments that we regularly disagree
> with, it doesn't mean we should ban him from the list.

I never said I would. I've put him in my personal mail filter.


Cheers,
	Gerhard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFImxjyfg6TFvELooQRAgNZAJ9VxzoupTRLenjvXaSFeU+9h1p5bgCeINqc
D5TB770545ho2beHBlorPu4=
=Hlt+
-----END PGP SIGNATURE-----

From drupal at dwwright.net  Thu Aug  7 15:47:44 2008
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 7 Aug 2008 08:47:44 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <489AF1ED.9050008@disobey.com>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
Message-ID: <1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>


On Aug 7, 2008, at 6:00 AM, Morbus Iff wrote:

> Actually, I agree with Earnie here ;)

FWIW, I agree with Freso, instead. ;)

But, that's the miracle of our community (and our tightly integrated  
project/release management system) -- each developer is free to  
decide what makes sense for them. ;)

Cheers,
-Derek (dww)




From amoore5 at ucmerced.edu  Thu Aug  7 16:15:22 2008
From: amoore5 at ucmerced.edu (Adam Moore)
Date: Thu, 07 Aug 2008 09:15:22 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
Message-ID: <489B1F9A.40006@ucmerced.edu>

Derek Wright wrote:
>
> On Aug 7, 2008, at 6:00 AM, Morbus Iff wrote:
>
>> Actually, I agree with Earnie here ;)
>
> FWIW, I agree with Freso, instead. ;)
>
> But, that's the miracle of our community (and our tightly integrated 
> project/release management system) -- each developer is free to decide 
> what makes sense for them. ;)
>
FWIW, coming from an end-user perspective I expect version 6.x-1.x to be 
an older feature set than what 5.x-2.x has.  Also let's say I am 
upgrading from D5 to D6.  If I need to upgrade a module that has an api 
and  I was on 5.x-2.x, at first glance I would feel that going to 
6.x-1.x the api's would not be compatible even though they might be.

From news at unleashedmind.com  Thu Aug  7 16:31:28 2008
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Thu, 7 Aug 2008 18:31:28 +0200
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <489AF1ED.9050008@disobey.com>
Message-ID: <075601c8f8ab$0af00fa0$0200a8c0@structworks.com>

> > Because the version of the module is solely independent of 
> the version 
> > of Drupal.  The version of the module indicates API and/or UI 
> > differences.  If you have version 2.x of your module in 
> version 5.x of 
> > Drupal and then change it to version 1.x for version 6.x of Drupal; 
> > one tends to view the 6.x-1.x as the same interface as 5.x-1.x.
> > 
> > But I'm wrong and will shut the hell up.
> 
> Actually, I agree with Earnie here ;)
> 
> (Only about module versions being independent of Drupal versions).
> 
> --
> Morbus Iff ( if i could change the future, i'd change the 
> past instead )

Also, we have to consider what end-users think about 5.x-2.x and 6.x-1.x.  My interpretation as end-user would even be worse:

There seem to be two versions of this module, version 1 for Drupal 5 and also D6.  And for Drupal 5, there is also a new and probably better version 2 that has not been ported to D6 yet.


This means, we should move this discussion over to the original issue:
http://drupal.org/node/136078

Thanks,
Daniel


From drupal at dwwright.net  Thu Aug  7 16:35:50 2008
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 7 Aug 2008 09:35:50 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <489B1F9A.40006@ucmerced.edu>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
Message-ID: <27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>


On Aug 7, 2008, at 9:15 AM, Adam Moore wrote:

> FWIW, coming from an end-user perspective I expect version 6.x-1.x  
> to be an older feature set than what 5.x-2.x has.

What other software has the very first digit go up and the feature  
set go down?  I'm surprised to hear you have this expectation, and  
I'm curious how wide-spread it is.

One example out of thousands: PHP went from 4.4.* to 5.0.* and no one  
thought "0 is smaller than 4, this must be an older feature set --  
where can I find 5.4.*?"

Cheers,
-Derek (dww)




From amoore5 at ucmerced.edu  Thu Aug  7 16:45:35 2008
From: amoore5 at ucmerced.edu (Adam Moore)
Date: Thu, 07 Aug 2008 09:45:35 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
References: <48955ADD.1060108@gmail.com>
	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>
	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>
	<48972E84.1020408@logrus.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
Message-ID: <489B26AF.70901@ucmerced.edu>

Derek Wright wrote:
>
> What other software has the very first digit go up and the feature set 
> go down?  I'm surprised to hear you have this expectation, and I'm 
> curious how wide-spread it is.
Here are my thoughts.  6.x just tells me what version of drupal it works 
on. I don't take that number into account as to what features that 
module has.   The module version number tells me what version the module 
is on. Let's use CiviCRM as an example.  It has it's own version numbers 
because it is not dependent on Drupal.  Their next version is 2.1.  I 
don't expect it to be 1.1 for D6 and 2.1 for D5. 
>
> One example out of thousands: PHP went from 4.4.* to 5.0.* and no one 
> thought "0 is smaller than 4, this must be an older feature set -- 
> where can I find 5.4.*?"
Let's use Pear as an example of a module for PHP. I don't expect pear to 
be version 1.x for PHP5 and 5.x for PHP4.

Adam

From catch56 at googlemail.com  Thu Aug  7 16:47:52 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 7 Aug 2008 17:47:52 +0100
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
References: <48955ADD.1060108@gmail.com>
	<20080804152926.oxaa3waese6g4sow@mail.progw.org>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
Message-ID: <fa5724270808070947s4fccd374i24a9922ff7a844be@mail.gmail.com>

>
> What other software has the very first digit go up and the feature set go
> down?  I'm surprised to hear you have this expectation, and I'm curious how
> wide-spread it is.
>

I think it arises from the way contrib modules are so intricately
linked to major core versions. When PHP issues a new release, we don't
(usually) have to release a new Drupal version to keep up with it.
Since there's no backwards compatibility for contrib, it's a bit more
complicated.

So, when a module is ported, one of at least three to four situations
might occur:

5.x-1.x branch gets ported to 6.x-1.x branch - just a straight port

5.x-1.x branch gets ported to 6.x-1.x branch - new features are added
to the 6.x-1.x branch during this process

5.x-1.x branch gets a straight port to 6.x-1.x, and 5.x-2.x gets a
straight port to 6.x-2.x

5.x-1.x branch is abandoned, users have to upgrade to 5.x-2.x then to
6.x-1.x (if the maintainer has dropped old updates, like core did in
5-6).

So when looking at a 6.x-1.x (or 2.x) version of a module, you have no
way of knowing whether it's a straight port, or a rewrite, or
somewhere in-between.

It's a bit like computer games - when they release a Grand Theft Auto
game on a new platform, they don't call it GTA1 all over again ;).
That said, I'm undecided on what the ideal path ought to be with this.

Nat

From drupal at samboyer.org  Thu Aug  7 16:49:13 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Thu, 7 Aug 2008 11:49:13 -0500
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much better choice?
In-Reply-To: <20080807162643.4f98dcf2@dawn.webthatworks.it>
References: <48909BD1.2020908@webchick.net>
	<a008eb250808070540n4b9cb7ddyc256187f8719abc2@mail.gmail.com>
	<20080807162643.4f98dcf2@dawn.webthatworks.it>
Message-ID: <200808071149.14005.drupal@samboyer.org>

On Thursday 07 August 2008 09:26:43 Ivan Sergio Borgonovo wrote:
> On Thu, 7 Aug 2008 07:40:59 -0500

> Furthermore I think that project management needs for core are quite
> different to the one of contrib.

This is the only point that I think has much merit. Again, I'm not advocating 
anything, but as our vcs and project management systems evolve, I think we 
ought to keep the possibility of using different vcs mechanisms for core and 
contrib in mind. There are certainly drawbacks, but given that the needs and 
workflows are pretty different, it could, on balance, be beneficial to reflect 
that in the underlying organization of the vcs.

From morbus at disobey.com  Thu Aug  7 16:57:28 2008
From: morbus at disobey.com (Morbus Iff)
Date: Thu, 07 Aug 2008 12:57:28 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>	<20080807082029.hxgh838shugc04co@mail.progw.org>	<489AF1ED.9050008@disobey.com>	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
Message-ID: <489B2978.7080606@disobey.com>

> What other software has the very first digit go up and the feature  
> set go down?  I'm surprised to hear you have this expectation, and  
> I'm curious how wide-spread it is.

I agree with their statements - it's my
same rationale for agreeing with Earnie.

As a developer, the use of 5.x and 6.x wasn't *my choice* - it was 
placed on me (rightfully and logically) by the Drupal package management 
system. When I develop, the world revolves around my module, not Drupal. 
   When my module is "2.0", it's a "major" thing in my software 
development mentality. The fact that it happens to be compatible with 
Drupal 6 is an install pre-requisite, not embedded into its version number.

The display of versioning information on d.o makes it very very easy to 
make a conceptual leap that "5.x" and "6.x" are only /prefixes/ that 
tell me what version of Drupal core there is. I visually ignore that 
info when I'm scanning down for module versions - I want the latest 
version of the *module*, not the latest version of Drupal core and then 
the module.

This is the expectation of a lot of users - people talk about "Views 2" 
not "Views 6.x-1.0" (which doesn't exist, and which nicely demonstrates 
the huge API changes, and confusion, inherent in naming Views the way 
that Freso and yourself are promoting).

> One example out of thousands: PHP went from 4.4.* to 5.0.* and no one  
> thought "0 is smaller than 4, this must be an older feature set --  
> where can I find 5.4.*?"

To flip the question: how many other pieces of modular software (which 
require a parent application) use the same versioning system you're 
promoting: that 5.x-2.0 becomes 6.x-1.0?

The problem with your PHP example is that you're only comparing PHP to 
PHP - you're not comparing an extension of PHP (read: a module for 
Drupal). Looking at any random extension, say, eaccelerator:

   http://eaccelerator.net/

we see that it doesn't follow the proposed version string rationale. 
It's not PHP-4.x-9.5.2 and then PHP-5.x-1.0.0 - it retains its own 
version string that is independent of the parent application - 0.9.5.2 
is for PHP 4, and 0.9.5.3 is for PHP 5 (Note: work with me on this 
example: since eaccelerator doesn't have a version 1 *at all*, I had to 
fake the values a bit to fit the example).

-- 
Morbus Iff ( putting the sanity back in sanity )
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 naheemzaffar at gmail.com  Thu Aug  7 17:04:14 2008
From: naheemzaffar at gmail.com (Naheem Zaffar)
Date: Thu, 7 Aug 2008 18:04:14 +0100
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <489B2978.7080606@disobey.com>
References: <48955ADD.1060108@gmail.com>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>
	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
Message-ID: <3adc77210808071004g79e65282o417a472655f0adfb@mail.gmail.com>

Going down the other side - I almost always expect the Drupal 6
release to be "better than" the latest Drupal 5 Release.

ie, 5.x-9.0 would be worse than 6.x-1.0 if those are the latest
releases on each side.

I was surprised that the new Views was developed as 6.x-2.x-dev. I
expected a "number reset".

From winborn at advomatic.com  Thu Aug  7 17:14:33 2008
From: winborn at advomatic.com (Aaron Winborn)
Date: Thu, 07 Aug 2008 13:14:33 -0400
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <3adc77210808071004g79e65282o417a472655f0adfb@mail.gmail.com>
References: <48955ADD.1060108@gmail.com>
	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>
	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
	<3adc77210808071004g79e65282o417a472655f0adfb@mail.gmail.com>
Message-ID: <489B2D79.3000300@advomatic.com>

Extrapolating this to the future, it is inevitable then that there will 
someday be a Views 10. Hopefully there will be enough indication of this 
that we can make the necessary changes to accommodate in time for it (or 
trust whatever emergent technology is in charge by then to do so).

Naheem Zaffar wrote:
> Going down the other side - I almost always expect the Drupal 6
> release to be "better than" the latest Drupal 5 Release.
>
> ie, 5.x-9.0 would be worse than 6.x-1.0 if those are the latest
> releases on each side.
>
> I was surprised that the new Views was developed as 6.x-2.x-dev. I
> expected a "number reset".
>   


From adrian at bryght.com  Thu Aug  7 17:16:17 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Thu, 7 Aug 2008 19:16:17 +0200
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <489B2978.7080606@disobey.com>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>	<20080807082029.hxgh838shugc04co@mail.progw.org>	<489AF1ED.9050008@disobey.com>	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
Message-ID: <75E3861B-F12D-4BA6-9357-F8B57916B7EA@bryght.com>


On 07 Aug 2008, at 6:57 PM, Morbus Iff wrote:

>
> As a developer, the use of 5.x and 6.x wasn't *my choice* - it was  
> placed on me (rightfully and logically) by the Drupal package  
> management system. When I develop, the world revolves around my  
> module, not Drupal.   When my module is "2.0", it's a "major" thing  
> in my software development mentality. The fact that it happens to be  
> compatible with Drupal 6 is an install pre-requisite, not embedded  
> into its version number.


All of this is irrelevant as changing it now is a pointless exercise  
in complicating our lives for very little benefit.

We'd have to support multiple different version numbers which could  
result in very strange issues down the line.


From news at unleashedmind.com  Thu Aug  7 17:23:40 2008
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Thu, 7 Aug 2008 19:23:40 +0200
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <489B2978.7080606@disobey.com>
Message-ID: <075a01c8f8b2$55b93f50$0200a8c0@structworks.com>

> As a developer, the use of 5.x and 6.x wasn't *my choice* - 
> it was placed on me (rightfully and logically) by the Drupal 
> package management system. When I develop, the world revolves 
> around my module, not Drupal. 

Great argument, but:

Please follow-up on http://drupal.org/node/136078

- NOT ON THE DEVELOPMENT LIST -


Thanks,
Daniel


From morbus at disobey.com  Thu Aug  7 17:24:56 2008
From: morbus at disobey.com (Morbus Iff)
Date: Thu, 07 Aug 2008 13:24:56 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <489B2978.7080606@disobey.com>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>	<20080807082029.hxgh838shugc04co@mail.progw.org>	<489AF1ED.9050008@disobey.com>	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
Message-ID: <489B2FE8.9070700@disobey.com>


Comically, using PHP as an example leads down a fun rabbit hole.

To whit:

  * Modules require Drupal.
  * Drupal require PHP.
  * Modules have their Drupal version in the version string.
  * Drupal should have its PHP version in the version string.

Thus, there will be no Drupal 7. Instead, the previously hoped for 
drupal-7.0.tar.gz will be named drupal-5.2-1.0.tar.gz, to indicate that 
it's the first version that requires PHP 5.2. We'll leave it up to 
webchick and the docs team to explain to people that drupal-5.2.0.tar.gz 
and drupal-5.2-1.0.tar.gz are miles apart in time and feature-set.

-- 
Morbus Iff ( morbus == grumblestiltskin )
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 drupal at dwwright.net  Thu Aug  7 17:27:37 2008
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 7 Aug 2008 10:27:37 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <489B2978.7080606@disobey.com>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>	<20080807082029.hxgh838shugc04co@mail.progw.org>	<489AF1ED.9050008@disobey.com>	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
Message-ID: <7591492E-4398-4650-BA89-9D594405341A@dwwright.net>


On Aug 7, 2008, at 9:57 AM, Morbus Iff wrote:

> I want the latest version of the *module*, not the latest version  
> of Drupal core and then the module.

That's the point of embedding the core version in the version strings  
of contrib in the first place.  What you want is fallacy.  You can't  
possibly not care what version of core you're using, since Drupal is  
inherently non-compatible across versions of core.  In Drupal  
contrib, the world revolves around core.  I just chose to embed that  
indisputable fact into the version strings themselves.

Re views: There's no 5.x-2.*, nor a 6.x-1.*.  So "Views 2" is  
synonymous with "D6 views".  It's irrelevant.  Panels would be a  
better example, since at least there's a 5.x-1.* and a 5.x-2.*  
(though no 6.x-* yet).

OG is a good counter-example.  Moshe is at 5.x-7.3 now, and (thank  
god) he chose to call the first 6.x compatible version 6.x-1.0.   
Otherwise, at his current rate, he would have been at 7.x-21.0 in 2  
years.

Part of the difference is how Earl vs. Moshe chose to make use of  
major versions in their own development workflows.  Roughly speaking,  
every coherent set of new features and bug fixes resulted in a new  
official release of views (5.x-1.5 -> 5.x-1.6), and resulted in a new  
branch/major version for OG (5.x-6.* -> 5.x-7.0).  Given those  
development styles, it makes perfect sense that Earl puts a lot more  
weight into his major versions, and wanted to preserve them, while  
Moshe does/did not.

The main point is this: no matter what we do, the version strings  
alone will confuse people.  No matter what convention anyone follows,  
some people will think "ahh, just as I expected" and others will  
think "WTF?  Where did xxxxxx go?"  Hence the need for clearly stated  
intentions in your release notes and on your project pages.

Plus, the tools can't and shouldn't enforce a certain development/ 
release process on all developers (I'm sure you're all saying "amen"  
at that).  I'm trying to document what I think are reasonable  
practices and try to make sure that the tools don't get in the way of  
people doing sane things, but ultimately, it's totally fine with me  
that Earl and Moshe are using the tools in completely different ways.

I don't think telling Earl: "No, you *MUST* call it views 6.x-1.0" is  
any more helpful than telling Moshe: "No, you *MUST* call it OG  
6.x-8.0".

Can we please forget about trying to force one model on both of them?

Thanks,
-Derek (dww)




From morbus at disobey.com  Thu Aug  7 17:29:22 2008
From: morbus at disobey.com (Morbus Iff)
Date: Thu, 07 Aug 2008 13:29:22 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <75E3861B-F12D-4BA6-9357-F8B57916B7EA@bryght.com>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>	<20080807082029.hxgh838shugc04co@mail.progw.org>	<489AF1ED.9050008@disobey.com>	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>	<489B1F9A.40006@ucmerced.edu>	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>	<489B2978.7080606@disobey.com>
	<75E3861B-F12D-4BA6-9357-F8B57916B7EA@bryght.com>
Message-ID: <489B30F2.101@disobey.com>

> All of this is irrelevant as changing it now is a pointless exercise  
> in complicating our lives for very little benefit. We'd have to
 > support multiple different version numbers which could result in
 > very strange issues down the line.

I'm not advocating that we change it technically. The current system 
allows the developer to make the choice. I'd advocate against making it 
a policy, however, to restart a version number for each core release.

-- 
Morbus Iff ( if god is my witness, god must be blind )
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 morbus at disobey.com  Thu Aug  7 17:37:48 2008
From: morbus at disobey.com (Morbus Iff)
Date: Thu, 07 Aug 2008 13:37:48 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>	<20080807082029.hxgh838shugc04co@mail.progw.org>	<489AF1ED.9050008@disobey.com>	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>	<489B1F9A.40006@ucmerced.edu>	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>	<489B2978.7080606@disobey.com>
	<7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
Message-ID: <489B32EC.3020209@disobey.com>

> Plus, the tools can't and shouldn't enforce a certain development/ 
> release process on all developers (I'm sure you're all saying "amen"  
> at that).  I'm trying to document what I think are reasonable  
> practices and try to make sure that the tools don't get in the way of  
> people doing sane things, but ultimately, it's totally fine with me  
> that Earl and Moshe are using the tools in completely different ways.
> 
> Can we please forget about trying to force one model on both of them?

I wasn't advocating we /force/ any model, merely offering my preference 
of which particular method I find more palatable. We're agreed on the 
basic contention: There's Nothing Wrong and Do It How You'd Like ;)

If you're going to document what *you* think is reasonable, than one 
should also document the *other* camp, especially since we're both 
agreed that both methods have license.

-- 
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 merlin at logrus.com  Thu Aug  7 17:41:12 2008
From: merlin at logrus.com (Earl Miles)
Date: Thu, 07 Aug 2008 10:41:12 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <20080807082029.hxgh838shugc04co@mail.progw.org>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
Message-ID: <489B33B8.8040504@logrus.com>

Earnie Boyd wrote:
> Because the version of the module is solely independent of the version 
> of Drupal.  The version of the module indicates API and/or UI 
> differences.  If you have version 2.x of your module in version 5.x of 
> Drupal and then change it to version 1.x for version 6.x of Drupal; one 
> tends to view the 6.x-1.x as the same interface as 5.x-1.x.
> 
> But I'm wrong and will shut the hell up.

I tend to agree that this is what users -- or at least, I, as a user -- 
would think. Which is why Views 2 is 6.x-2.0 when there was never a 6.x-1.0.

From morbus at disobey.com  Thu Aug  7 17:43:54 2008
From: morbus at disobey.com (Morbus Iff)
Date: Thu, 07 Aug 2008 13:43:54 -0400
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>	<20080807082029.hxgh838shugc04co@mail.progw.org>	<489AF1ED.9050008@disobey.com>	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>	<489B1F9A.40006@ucmerced.edu>	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>	<489B2978.7080606@disobey.com>
	<7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
Message-ID: <489B345A.8070206@disobey.com>

>> I want the latest version of the *module*, not the
 >> latest version of Drupal core and then the module.
> 
> That's the point of embedding the core version in the version strings  
> of contrib in the first place.  What you want is fallacy.  You can't  
> possibly not care what version of core you're using, since Drupal is  
> inherently non-compatible across versions of core.  In Drupal  
> contrib, the world revolves around core.  I just chose to embed that  
> indisputable fact into the version strings themselves.

For what it's worth, you're mixing the _technical_ implications of the 
version number with the _perceptive_ implications of said version 
number. As my remitted quote suggests: I don't visually "see" the 5.x or 
the 6.x because I mentally treat them *solely as compatibility*, not as 
a literal relation to the module's version number.

If the page states:

   6.x-1.0 Recommended for 6.x
   5.x-2.1 Recommended for 5.x

I "see":

   1.0 Recommended for 6.x
   2.1 Recommended for 5.x

and wonder why there's no 2.1 release for 6.x.

Anyways. I'll hush.

SPOILER
SPOILER
SPOILER
SPOILER

-- 
Morbus Iff ( get on the floor. baby, lose control. )
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 merlin at logrus.com  Thu Aug  7 17:45:58 2008
From: merlin at logrus.com (Earl Miles)
Date: Thu, 07 Aug 2008 10:45:58 -0700
Subject: [development] Choosing the N number for .install's	hook_update_N
In-Reply-To: <7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
References: <48955ADD.1060108@gmail.com>	<22187498-D46E-4C60-81D3-562F511E3B0A@erikstielstra.nl>	<20080804120917.68verfiy8fmsgw8o@mail.progw.org>	<48972E84.1020408@logrus.com>	<20080804152926.oxaa3waese6g4sow@mail.progw.org>	<C186A39A-FEDD-4F5F-B772-4834C8392456@dwwright.net>	<20080805090832.th12yy5wo3k0s04o@mail.progw.org>	<489AB655.1090604@gmail.com>	<20080807082029.hxgh838shugc04co@mail.progw.org>	<489AF1ED.9050008@disobey.com>	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>	<489B1F9A.40006@ucmerced.edu>	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>	<489B2978.7080606@disobey.com>
	<7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
Message-ID: <489B34D6.9070402@logrus.com>

Derek Wright wrote:
> Can we please forget about trying to force one model on both of them?

I note, with amusement, that Morbus and Derek (the two most vocal 
representatives of the two sides on this argument) agree on this point.

From jacob at civicactions.com  Thu Aug  7 17:46:58 2008
From: jacob at civicactions.com (Jacob Singh)
Date: Thu, 07 Aug 2008 10:46:58 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
 much	 better choice?
In-Reply-To: <20080807114541.2944341f@dawn.webthatworks.it>
References: <48909BD1.2020908@webchick.net>
	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
	<20080807114541.2944341f@dawn.webthatworks.it>
Message-ID: <489B3512.70209@civicactions.com>

Dww:
Thank you for not bad mouthing Ivan. There is nothing wrong with looking
at other projects and their methods.  Personally, I think Drupal's is
pretty freaking good because the community is massive, and I don't think
it's 100% the software, so something is working there.

However, I feel like Drupal is also becoming more of an app framework
than a CMS, and I think it has a bad architecture for an app framework. 
I use Django when I'm not building a CMS.  I use Wordpress when I need a
blog.

I know it is probably heresy, but why do we have to eat our own hippo
food (a total project management system) in drupal.  Drupal is a CMS! 
There are many excellent project management / vcs suites out there (JIRA
and trac come to mind).  I would much rather see a tight integration
into drupal.org with one of them, than go the direction of continuing
the development of something which is really just maintained for d.o.
and gives nothing back to the rest of the software community while
eating up resources.

What do you guys think?  Would it be cheaper to actually just
re-implement the project management tools in trac and then write the
glue code in python to integrate with d.o.?

Best,
J




From drupal at dwwright.net  Thu Aug  7 17:58:11 2008
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 7 Aug 2008 10:58:11 -0700
Subject: [development] FAQ: Why is Drupal still using CVS when X is a
	much	 better choice?
In-Reply-To: <489B3512.70209@civicactions.com>
References: <48909BD1.2020908@webchick.net>
	<489296A1.9060706@webchick.net>	<48930F0C.4070000@perlucida.com>	<9CD20B5A-B2C4-44A3-A690-8CAA41C31937@dwwright.net>
	<20080807114541.2944341f@dawn.webthatworks.it>
	<489B3512.70209@civicactions.com>
Message-ID: <CEE22751-CB7A-4720-8158-43F7630E1C05@dwwright.net>


On Aug 7, 2008, at 10:46 AM, Jacob Singh wrote:

> Would it be cheaper to actually just re-implement the project  
> management tools in trac and then write the glue code in python to  
> integrate with d.o.?

It's funny you ask...

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

Enjoy,
-Derek (dww)



From juan.fco.rodriguez at gmail.com  Fri Aug  8 13:10:50 2008
From: juan.fco.rodriguez at gmail.com (Juan Rodriguez)
Date: Fri, 8 Aug 2008 15:10:50 +0200
Subject: [development] Question about error_reporting()
Message-ID: <96b30c400808080610n3a3abe60y88a800d42f3674c3@mail.gmail.com>

Hi guys,

I am looking at the implementation of error_reporting:
http://api.drupal.org/api/function/error_handler/5

and I don't understand this line:

  if ($errno & (E_ALL ^ E_NOTICE)) {


does it means that all errors but E_NOTICE are gonna be reported ?
(what I really dont get is the meaning of the ^ php operator....)....

I am trying to understand this code because my watchdog table is
getting full of PHP warning
messages, and I was not able to found a configuration option to filter
this kind of messages.

Would it be possible to change the behaviour to report messages above
or below a specific level like
it is done in php.ini ?

Thanks in advance.

From larry at garfieldtech.com  Fri Aug  8 14:51:20 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Fri, 8 Aug 2008 9:51:20 -0500
Subject: [development] =?utf-8?q?Question_about_error=5Freporting=28=29?=
In-Reply-To: <96b30c400808080610n3a3abe60y88a800d42f3674c3@mail.gmail.com>
References: <96b30c400808080610n3a3abe60y88a800d42f3674c3@mail.gmail.com>
Message-ID: <17010196cd6c7faab66d4f260831fc72@localhost>


The ^ is the bitwise NOT operator in PHP.  PHP defines a bunch of bitmasks to flag different error levels.  E_ALL is the bit mask for "everything except STRICT-level", so that line means "everything except STRICT level but not NOTICE level".

If your watchdog table is filling up with PHP warning messages, then you have a serious bug in your code somewhere.  Do not hide the error.  Fix the bug. :-)  Look at the error message itself to see what the problem is, track it down, and squish it.

--Larry Garfield

On Fri, 8 Aug 2008 15:10:50 +0200, "Juan Rodriguez" <juan.fco.rodriguez at gmail.com> wrote:
> Hi guys,
> 
> I am looking at the implementation of error_reporting:
> http://api.drupal.org/api/function/error_handler/5
> 
> and I don't understand this line:
> 
>   if ($errno & (E_ALL ^ E_NOTICE)) {
> 
> 
> does it means that all errors but E_NOTICE are gonna be reported ?
> (what I really dont get is the meaning of the ^ php operator....)....
> 
> I am trying to understand this code because my watchdog table is
> getting full of PHP warning
> messages, and I was not able to found a configuration option to filter
> this kind of messages.
> 
> Would it be possible to change the behaviour to report messages above
> or below a specific level like
> it is done in php.ini ?
> 
> Thanks in advance.


From earnie at users.sourceforge.net  Fri Aug  8 16:26:34 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Fri, 08 Aug 2008 12:26:34 -0400
Subject: [development] Question about error_reporting()
In-Reply-To: <17010196cd6c7faab66d4f260831fc72@localhost>
References: <96b30c400808080610n3a3abe60y88a800d42f3674c3@mail.gmail.com>
	<17010196cd6c7faab66d4f260831fc72@localhost>
Message-ID: <20080808122634.mg1z1hlb4tdcog8w@mail.progw.org>

Quoting Larry Garfield <larry at garfieldtech.com>:

>
> If your watchdog table is filling up with PHP warning messages, then 
> you have a serious bug in your code somewhere.  Do not hide the 
> error.  Fix the bug. :-)  Look at the error message itself to see 
> what the problem is, track it down, and squish it.
>

There's a few from DRUPAL-5 that happen with every page load such as 
"page not found	2008-08-08 14:56	favicon.ico".  There details of the 
"warning" do not tell me a referrer.  To squash it I tend to "touch 
favicon.ico" in the DocumentRoot directory.

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


From cwgordon7 at cwgordon.com  Fri Aug  8 16:51:56 2008
From: cwgordon7 at cwgordon.com (Charlie Gordon)
Date: Fri, 08 Aug 2008 12:51:56 -0400
Subject: [development] Question about error_reporting()
In-Reply-To: <20080808122634.mg1z1hlb4tdcog8w@mail.progw.org>
References: <96b30c400808080610n3a3abe60y88a800d42f3674c3@mail.gmail.com>	<17010196cd6c7faab66d4f260831fc72@localhost>
	<20080808122634.mg1z1hlb4tdcog8w@mail.progw.org>
Message-ID: <489C79AC.1010107@cwgordon.com>

Huh? That's watchdog() called directly on 404 pages, not an error 
handling problem. It's an IE problem, actually - IE just looks in the 
root directory for favicon.ico ignoring the reference to the favicon in 
the html.

-Charlie

Earnie Boyd wrote:
> There's a few from DRUPAL-5 that happen with every page load such as 
> "page not found    2008-08-08 14:56    favicon.ico".  There details of 
> the "warning" do not tell me a referrer.  To squash it I tend to 
> "touch favicon.ico" in the DocumentRoot directory.
>
> Earnie -- http://for-my-kids.com/
> -- http://give-me-an-offer.com/


From matt at mattfarina.com  Fri Aug  8 17:06:34 2008
From: matt at mattfarina.com (matt at mattfarina.com)
Date: Fri,  8 Aug 2008 13:06:34 -0400
Subject: [development] Question about error_reporting()
In-Reply-To: <20080808122634.mg1z1hlb4tdcog8w@mail.progw.org>
References: <96b30c400808080610n3a3abe60y88a800d42f3674c3@mail.gmail.com>
	<17010196cd6c7faab66d4f260831fc72@localhost>
	<20080808122634.mg1z1hlb4tdcog8w@mail.progw.org>
Message-ID: <20080808130634.dizhiyaoco8kc484@webmail.mattfarina.com>

For the favicon issue see http://drupal.org/node/174940 which is  
looking to be ported to D5 but is already taken care of in versions  
higher than that. You can, also, see http://drupal.org/project/favicon.

Quoting Earnie Boyd <earnie at users.sourceforge.net>:

> Quoting Larry Garfield <larry at garfieldtech.com>:
>
>>
>> If your watchdog table is filling up with PHP warning messages,   
>> then you have a serious bug in your code somewhere.  Do not hide   
>> the error. Fix the bug. :-)  Look at the error message itself to   
>> see what the problem is, track it down, and squish it.
>>
>
> There's a few from DRUPAL-5 that happen with every page load such as
> "page not found	2008-08-08 14:56	favicon.ico".  There details of the
> "warning" do not tell me a referrer.  To squash it I tend to "touch
> favicon.ico" in the DocumentRoot directory.
>
> Earnie -- http://for-my-kids.com/
> -- http://give-me-an-offer.com/



From earnie at users.sourceforge.net  Fri Aug  8 17:58:29 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Fri, 08 Aug 2008 13:58:29 -0400
Subject: [development] Question about error_reporting()
In-Reply-To: <489C79AC.1010107@cwgordon.com>
References: <96b30c400808080610n3a3abe60y88a800d42f3674c3@mail.gmail.com>
	<17010196cd6c7faab66d4f260831fc72@localhost>
	<20080808122634.mg1z1hlb4tdcog8w@mail.progw.org>
	<489C79AC.1010107@cwgordon.com>
Message-ID: <20080808135829.e8louj75fvzkogc4@mail.progw.org>

Quoting Charlie Gordon <cwgordon7 at cwgordon.com>:

> Huh? That's watchdog() called directly on 404 pages, not an error 
> handling problem. It's an IE problem, actually - IE just looks in the 
> root directory for favicon.ico ignoring the reference to the favicon 
> in the html.
>

The OP is looking for ways to cut down on the watchdog entry fluff.  
While PNF errors in the watchdog themselves are not fluff the 
favicon.ico one certainly is.

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


From juan.fco.rodriguez at gmail.com  Fri Aug  8 21:48:10 2008
From: juan.fco.rodriguez at gmail.com (Juan Rodriguez)
Date: Fri, 8 Aug 2008 23:48:10 +0200
Subject: [development] Question about error_reporting()
In-Reply-To: <20080808135829.e8louj75fvzkogc4@mail.progw.org>
References: <96b30c400808080610n3a3abe60y88a800d42f3674c3@mail.gmail.com>
	<17010196cd6c7faab66d4f260831fc72@localhost>
	<20080808122634.mg1z1hlb4tdcog8w@mail.progw.org>
	<489C79AC.1010107@cwgordon.com>
	<20080808135829.e8louj75fvzkogc4@mail.progw.org>
Message-ID: <96b30c400808081448k12b049a4y75224839694c338a@mail.gmail.com>

One more thing,

I think that in this line:

    watchdog('php', t('%message in %file on line %line.',
array('%error' => $types[$errno], '%message' => $message, '%file' =>
$filename, '%line' => $line)), WATCHDOG_ERROR);


%error is not being interpolated, wouldn't it be better something like

t('%error: %message in %file....blablabla....) ?

On Fri, Aug 8, 2008 at 7:58 PM, Earnie Boyd
<earnie at users.sourceforge.net> wrote:
> Quoting Charlie Gordon <cwgordon7 at cwgordon.com>:
>
>> Huh? That's watchdog() called directly on 404 pages, not an error handling
>> problem. It's an IE problem, actually - IE just looks in the root directory
>> for favicon.ico ignoring the reference to the favicon in the html.
>>
>
> The OP is looking for ways to cut down on the watchdog entry fluff.  While
> PNF errors in the watchdog themselves are not fluff the favicon.ico one
> certainly is.
>
> Earnie -- http://for-my-kids.com/
> -- http://give-me-an-offer.com/
>
>



-- 
http://www.linkedin.com/in/yonailo

From darrel.opry at gmail.com  Fri Aug  8 23:05:46 2008
From: darrel.opry at gmail.com (Darrel O'Pry)
Date: Fri, 8 Aug 2008 19:05:46 -0400
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <489B34D6.9070402@logrus.com>
References: <48955ADD.1060108@gmail.com> <489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
	<7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
	<489B34D6.9070402@logrus.com>
Message-ID: <bfcbb6230808081605k6681d47ahb57d1d8af262b00c@mail.gmail.com>

how about function example_update_101010() {};

shouldn't we really just make it binary so we can just add 1's as
necessary.. then all of this 2.x and 5.x stuff becomes irrelevant and we
will only need the 1 and 0.. it seems much simpler.

.darrel.  - who has long since sworn off bugging people about project...
just use it as best you can. I look forward to imagecache 12.x-10.x. no
complaints at all seriously...


On Thu, Aug 7, 2008 at 1:45 PM, Earl Miles <merlin at logrus.com> wrote:

> Derek Wright wrote:
>
>> Can we please forget about trying to force one model on both of them?
>>
>
> I note, with amusement, that Morbus and Derek (the two most vocal
> representatives of the two sides on this argument) agree on this point.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080808/28f44d00/attachment.htm 

From drupal at dwwright.net  Fri Aug  8 23:11:50 2008
From: drupal at dwwright.net (Derek Wright)
Date: Fri, 8 Aug 2008 16:11:50 -0700
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <bfcbb6230808081605k6681d47ahb57d1d8af262b00c@mail.gmail.com>
References: <48955ADD.1060108@gmail.com> <489AB655.1090604@gmail.com>
	<20080807082029.hxgh838shugc04co@mail.progw.org>
	<489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
	<7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
	<489B34D6.9070402@logrus.com>
	<bfcbb6230808081605k6681d47ahb57d1d8af262b00c@mail.gmail.com>
Message-ID: <C970136F-059C-41CA-9BC6-9A1C3496ADA9@dwwright.net>


On Aug 8, 2008, at 4:05 PM, Darrel O'Pry wrote:

> how about function example_update_101010() {};

That'd be the 10th update for version 10.x-10.0. ;)

> .darrel.  - who has long since sworn off bugging people about  
> project... just use it as best you can. I look forward to  
> imagecache 12.x-10.x. no complaints at all seriously...

FYI: this thread has nothing to do with project*.

Cheers,
-Derek (dww)




From darrel.opry at gmail.com  Fri Aug  8 23:39:41 2008
From: darrel.opry at gmail.com (Darrel O'Pry)
Date: Fri, 8 Aug 2008 19:39:41 -0400
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <C970136F-059C-41CA-9BC6-9A1C3496ADA9@dwwright.net>
References: <48955ADD.1060108@gmail.com> <489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
	<7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
	<489B34D6.9070402@logrus.com>
	<bfcbb6230808081605k6681d47ahb57d1d8af262b00c@mail.gmail.com>
	<C970136F-059C-41CA-9BC6-9A1C3496ADA9@dwwright.net>
Message-ID: <bfcbb6230808081639v2c783634l21c15ecdd2c43011@mail.gmail.com>

/me points jovially to his sarcasm hat. in attempt to sidetrack this
conversation enough for it to stop ending up in his inbox.

On Fri, Aug 8, 2008 at 7:11 PM, Derek Wright <drupal at dwwright.net> wrote:

>
> On Aug 8, 2008, at 4:05 PM, Darrel O'Pry wrote:
>
>  how about function example_update_101010() {};
>>
>
> That'd be the 10th update for version 10.x-10.0. ;)
>
>  .darrel.  - who has long since sworn off bugging people about project...
>> just use it as best you can. I look forward to imagecache 12.x-10.x. no
>> complaints at all seriously...
>>
>
> FYI: this thread has nothing to do with project*.
>
> Cheers,
> -Derek (dww)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080808/328df922/attachment.htm 

From drupal at dwwright.net  Fri Aug  8 23:48:00 2008
From: drupal at dwwright.net (Derek Wright)
Date: Fri, 8 Aug 2008 16:48:00 -0700
Subject: [development] Choosing the N number for .install's hook_update_N
In-Reply-To: <bfcbb6230808081639v2c783634l21c15ecdd2c43011@mail.gmail.com>
References: <48955ADD.1060108@gmail.com> <489AF1ED.9050008@disobey.com>
	<1FF4123B-5F38-4BD8-A77B-DF8D126E8D48@dwwright.net>
	<489B1F9A.40006@ucmerced.edu>
	<27565B7E-67AE-470A-8AB9-20DAEE9C5882@dwwright.net>
	<489B2978.7080606@disobey.com>
	<7591492E-4398-4650-BA89-9D594405341A@dwwright.net>
	<489B34D6.9070402@logrus.com>
	<bfcbb6230808081605k6681d47ahb57d1d8af262b00c@mail.gmail.com>
	<C970136F-059C-41CA-9BC6-9A1C3496ADA9@dwwright.net>
	<bfcbb6230808081639v2c783634l21c15ecdd2c43011@mail.gmail.com>
Message-ID: <A272B4FD-DCDF-4338-8B7D-2B92E1D4E114@dwwright.net>


On Aug 8, 2008, at 4:39 PM, Darrel O'Pry wrote:

> /me points jovially to his sarcasm hat.

/me has one, too. ;)

> in attempt to sidetrack this conversation enough for it to stop  
> ending up in his inbox.

it had died until you revived it. ;)

cheers,
-derek






From yuval at avramzon.net  Sat Aug  9 04:57:52 2008
From: yuval at avramzon.net (Yuval Hager)
Date: Sat, 9 Aug 2008 07:57:52 +0300
Subject: [development] [from support] Staging
Message-ID: <200808090758.01373.yuval@avramzon.net>

I'd like to draw the dev list members' attention to a thread from support 
about staging: 
http://lists.drupal.org/pipermail/support/2008-August/009492.html

The reason I am sending this here, is that I believe there is no structured 
and well defined solution to the problem. There are many trials to handle 
this (e.g. even/odd nid numbering scheme, dbscripts), but most of them are 
cumbersome and/or limited in many ways.

I believe this is a very common problem, and that the only real solution 
should come from core. I think the most difficult part here is to separate 
content from configuration. The first step would be how to define what is 
content and what is config (for example - site name - is it a content 
property or a config property?). The next step then would be to find a way to 
transfer config from a staging/dev site onto production, without overwriting 
any content that might have been added there during development.

-- 
Yuval Hager
[T] +972-77-341-4155
[@] yuval at avramzon.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080809/d49932e9/attachment-0001.pgp 

From gina.beisel at gmail.com  Sat Aug  9 12:31:25 2008
From: gina.beisel at gmail.com (Gina Beisel)
Date: Sat, 9 Aug 2008 08:31:25 -0400
Subject: [development] [from support] Staging
In-Reply-To: <200808090758.01373.yuval@avramzon.net>
References: <200808090758.01373.yuval@avramzon.net>
Message-ID: <94f215be0808090531q19370ad4t877fdd1c3ffd4fb1@mail.gmail.com>

I am also plagued with the same issues. I think it would be extremely
beneficial to separate what makes a site go from content. They data is so
mashed up it is hard to know what ports and what does not.
gina
www.wupal.com

On Sat, Aug 9, 2008 at 12:57 AM, Yuval Hager <yuval at avramzon.net> wrote:

> I'd like to draw the dev list members' attention to a thread from support
> about staging:
> http://lists.drupal.org/pipermail/support/2008-August/009492.html
>
> The reason I am sending this here, is that I believe there is no structured
> and well defined solution to the problem. There are many trials to handle
> this (e.g. even/odd nid numbering scheme, dbscripts), but most of them are
> cumbersome and/or limited in many ways.
>
> I believe this is a very common problem, and that the only real solution
> should come from core. I think the most difficult part here is to separate
> content from configuration. The first step would be how to define what is
> content and what is config (for example - site name - is it a content
> property or a config property?). The next step then would be to find a way
> to
> transfer config from a staging/dev site onto production, without
> overwriting
> any content that might have been added there during development.
>
> --
> Yuval Hager
> [T] +972-77-341-4155
> [@] yuval at avramzon.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080809/be5a60e1/attachment.htm 

From adrian at bryght.com  Sat Aug  9 13:15:06 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sat, 9 Aug 2008 15:15:06 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <94f215be0808090531q19370ad4t877fdd1c3ffd4fb1@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<94f215be0808090531q19370ad4t877fdd1c3ffd4fb1@mail.gmail.com>
Message-ID: <1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>

On 09 Aug 2008, at 2:31 PM, Gina Beisel wrote:
> I am also plagued with the same issues. I think it would be  
> extremely beneficial to separate what makes a site go from content.  
> They data is so mashed up it is hard to know what ports and what  
> does not.
> gina

Actually, I think it would be beneficial for us to discuss this  
problem on the list, even if it doesn't make it into core per se.

We need to consider this kind of flexibility in our API's. so that we  
can make it simpler (or even possible) to do this without
having to patch Drupal, or manipulate data dumps with external tools  
(that don't have access to such things as the _schema
hook and any other semantics we might have, or can put in place to  
help solve this problem).

Perhaps we could then build a module or something for Drush which  
could handle the dumping and merging of these partial
data sets in a clean manner. It could use the schema information to  
'understand' what it's importing / exporting.

Anyone have any thoughts on the matter (as I know we have ALL been  
bitten by it before).

From z.stolar at gmail.com  Sat Aug  9 14:09:56 2008
From: z.stolar at gmail.com (Zohar Stolar)
Date: Sat, 09 Aug 2008 17:09:56 +0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>	<94f215be0808090531q19370ad4t877fdd1c3ffd4fb1@mail.gmail.com>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
Message-ID: <489DA534.4030709@gmail.com>


Adrian Rossouw wrote:
>
> Actually, I think it would be beneficial for us to discuss this 
> problem on the list, even if it doesn't make it into core per se.
>
> We need to consider this kind of flexibility in our API's. so that we 
> can make it simpler (or even possible) to do this without
> having to patch Drupal, or manipulate data dumps with external tools 
> (that don't have access to such things as the _schema
> hook and any other semantics we might have, or can put in place to 
> help solve this problem).
>
> Perhaps we could then build a module or something for Drush which 
> could handle the dumping and merging of these partial
> data sets in a clean manner. It could use the schema information to 
> 'understand' what it's importing / exporting.
>
> Anyone have any thoughts on the matter (as I know we have ALL been 
> bitten by it before).
>
The problem is not only in dev->staging->production sense, but also in 
the other direction.
When you change code, or config, you want to be able to push the changes 
into production. But on the same time, you also want to test your 
changes on the staging/dev server, with the latest content (for example, 
when changing the structure/theming of a content type).

As yhager proposed, having two DBs instead of one, may ease things a lot.
One DB will hold content: nodes, revisions, files, users...
The second DB will hold configuration: views, cck structure, modules, 
variables... (this list is highly debatable).

This will allow for two-ways updating - content is pulled down, while 
configuration can be easily pushed up.

If there is enough interest, maybe we can still sneak in a BoF session 
in Szeged, although I believe we'll need much more than one meeting to 
solve this issue ;)


From adrian at bryght.com  Sat Aug  9 14:21:12 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sat, 9 Aug 2008 16:21:12 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <489DA534.4030709@gmail.com>
References: <200808090758.01373.yuval@avramzon.net>	<94f215be0808090531q19370ad4t877fdd1c3ffd4fb1@mail.gmail.com>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com>
Message-ID: <33F3DEBF-A554-481C-A4C3-F4620EBA1C1D@bryght.com>


On 09 Aug 2008, at 4:09 PM, Zohar Stolar wrote:

>
> As yhager proposed, having two DBs instead of one, may ease things a  
> lot.
> One DB will hold content: nodes, revisions, files, users...
> The second DB will hold configuration: views, cck structure,  
> modules, variables... (this list is highly debatable).
Prefixing would work just as well for this.

I was thinking of adding properties to the table definition in schema,  
myself. IE: content / configuration.


From yuval at avramzon.net  Sat Aug  9 16:31:50 2008
From: yuval at avramzon.net (Yuval Hager)
Date: Sat, 9 Aug 2008 19:31:50 +0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <33F3DEBF-A554-481C-A4C3-F4620EBA1C1D@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<489DA534.4030709@gmail.com>
	<33F3DEBF-A554-481C-A4C3-F4620EBA1C1D@bryght.com>
Message-ID: <200808091932.01502.yuval@avramzon.net>

On Saturday 09 August 2008, Adrian Rossouw wrote:
> On 09 Aug 2008, at 4:09 PM, Zohar Stolar wrote:
> > As yhager proposed, having two DBs instead of one, may ease things a
> > lot.
> > One DB will hold content: nodes, revisions, files, users...
> > The second DB will hold configuration: views, cck structure,
> > modules, variables... (this list is highly debatable).
>
> Prefixing would work just as well for this.
>
> I was thinking of adding properties to the table definition in schema,
> myself. IE: content / configuration.

I wish it was that simple. I'm afraid this is not to be solved on the database 
level alone. Some rows in the variable table might count for content, others 
for configuration. CCK, aka the-other-part-of-core, would be a impossible to 
dissect based on post-mortem DB analysis. The menu system can be argued 
about, etc.

-- 
Yuval Hager
[@] yuval at avramzon.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080809/40a530e0/attachment.pgp 

From z.stolar at gmail.com  Sat Aug  9 16:46:48 2008
From: z.stolar at gmail.com (Zohar Stolar)
Date: Sat, 09 Aug 2008 19:46:48 +0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808091932.01502.yuval@avramzon.net>
References: <200808090758.01373.yuval@avramzon.net>	<489DA534.4030709@gmail.com>	<33F3DEBF-A554-481C-A4C3-F4620EBA1C1D@bryght.com>
	<200808091932.01502.yuval@avramzon.net>
Message-ID: <489DC9F8.5030501@gmail.com>


Yuval Hager wrote:

> On Saturday 09 August 2008, Adrian Rossouw wrote:
>   
>> On 09 Aug 2008, at 4:09 PM, Zohar Stolar wrote:
>>     
>>> As yhager proposed, having two DBs instead of one, may ease things a
>>> lot.
>>> One DB will hold content: nodes, revisions, files, users...
>>> The second DB will hold configuration: views, cck structure,
>>> modules, variables... (this list is highly debatable).
>>>       
>> Prefixing would work just as well for this.
>>
>> I was thinking of adding properties to the table definition in schema,
>> myself. IE: content / configuration.
>>     
>
> I wish it was that simple. I'm afraid this is not to be solved on the database 
> level alone. Some rows in the variable table might count for content, others 
> for configuration. CCK, aka the-other-part-of-core, would be a impossible to 
> dissect based on post-mortem DB analysis. The menu system can be argued 
> about, etc.
>
>   
CCK is configuration of the content, not the content itself. Probably a 
separation is possible in CCK's tables.
Menus are content, but the position of their blocks is configuration.
Views are configuration, their results are obviously content.

A rule of the thumb could be: "If I change X, will it change any content?".
If the answer is 'yes', then X is content. Otherwise it's configuration.

From adrian at bryght.com  Sat Aug  9 16:50:05 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sat, 9 Aug 2008 18:50:05 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808091932.01502.yuval@avramzon.net>
References: <200808090758.01373.yuval@avramzon.net>
	<489DA534.4030709@gmail.com>
	<33F3DEBF-A554-481C-A4C3-F4620EBA1C1D@bryght.com>
	<200808091932.01502.yuval@avramzon.net>
Message-ID: <569ED359-5E10-47D0-B0AE-4AE5F3F03AF3@bryght.com>


On 09 Aug 2008, at 6:31 PM, Yuval Hager wrote:

>
> I wish it was that simple. I'm afraid this is not to be solved on  
> the database
> level alone. Some rows in the variable table might count for  
> content, others
> for configuration. CCK, aka the-other-part-of-core, would be a  
> impossible to
> dissect based on post-mortem DB analysis. The menu system can be  
> argued
> about, etc.

Yes, i know. which is why we are having this discussion. I don't think  
this can be solved from
outside of Drupal. We need the information in the code, the example i  
gave was just a first
step that would replicate what we can do at the moment.

You also have nodes / users which might be part of configuration.

From adrian at bryght.com  Sat Aug  9 16:50:50 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sat, 9 Aug 2008 18:50:50 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <489DC9F8.5030501@gmail.com>
References: <200808090758.01373.yuval@avramzon.net>	<489DA534.4030709@gmail.com>	<33F3DEBF-A554-481C-A4C3-F4620EBA1C1D@bryght.com>
	<200808091932.01502.yuval@avramzon.net>
	<489DC9F8.5030501@gmail.com>
Message-ID: <BE57B177-91AA-4253-AA2E-B56BDA790F64@bryght.com>


On 09 Aug 2008, at 6:46 PM, Zohar Stolar wrote:

> CCK is configuration of the content, not the content itself.  
> Probably a separation is possible in CCK's tables.
> Menus are content, but the position of their blocks is configuration.
> Views are configuration, their results are obviously content.

Custom menu items, modified custom menus etc are configuration, not  
content.


From drupal at dave-cohen.com  Sat Aug  9 17:40:18 2008
From: drupal at dave-cohen.com (Dave Cohen)
Date: Sat, 9 Aug 2008 10:40:18 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <489DA534.4030709@gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com>
Message-ID: <200808091040.20320.drupal@dave-cohen.com>

There was a BoF about this at the last DrupalCon.  Doesn't hurt to keep 
talking about it, IMHO.  Someone should propose it for Szeged if it hasn't 
already.

Here's the one from Boston: 
http://boston2008.drupalcon.org/session/updating-and-upgrading-live-sites
Some worthwhile links in the proposal as well as the comments.  Including this 
video of some of the discussion:
http://www.mikiane.com/node/2008/03/04/live-blogging-drupalcon-boston-2008

-Dave

On Saturday 09 August 2008, Zohar Stolar wrote:
> If there is enough interest, maybe we can still sneak in a BoF session
> in Szeged, although I believe we'll need much more than one meeting to
> solve this issue ;)



From drupal at dave-cohen.com  Sat Aug  9 18:35:13 2008
From: drupal at dave-cohen.com (Dave Cohen)
Date: Sat, 9 Aug 2008 11:35:13 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <489DA534.4030709@gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com>
Message-ID: <200808091135.13222.drupal@dave-cohen.com>

Personally, I don't see how two DBs improves things.  In my experience, nodes 
are often "configuration" as well as "content".  Trying to draw that line 
somewhere is a mistake, IMHO.  You might draw the line where it makes sense 
for your sites, but not someone elses.

As you point out, the list is highly debatable.  I think it's undecidable.

-Dave

On Saturday 09 August 2008, Zohar Stolar wrote:
> As yhager proposed, having two DBs instead of one, may ease things a lot.
> One DB will hold content: nodes, revisions, files, users...
> The second DB will hold configuration: views, cck structure, modules,
> variables... (this list is highly debatable).
>
> This will allow for two-ways updating - content is pulled down, while
> configuration can be easily pushed up.
>



From arthur at civicactions.com  Sat Aug  9 19:53:55 2008
From: arthur at civicactions.com (arthur)
Date: Sat, 9 Aug 2008 15:53:55 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808091135.13222.drupal@dave-cohen.com>
References: <200808090758.01373.yuval@avramzon.net>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com>
	<200808091135.13222.drupal@dave-cohen.com>
Message-ID: <05C7ACD9-3A94-4812-AAE0-7D06A1DEE3B4@civicactions.com>

I think a really interesting project is the deploy module (http://drupal.org/project/deploy 
) which I think is an interesting abstract approach to this issue. It  
won't meet everybody's needs, and isn't functionally sufficient yet  
(for content at least), but is a good start, and worth starting a more  
serious conversation of how this problem might be addressed from the  
larger Drupal community. Some of the concepts that Greg has already  
got in place are critical for the staging issue. You can check out a  
talk Greg did on the deploy module at the Seattle Drupal User Group  
here: http://blip.tv/file/1033300

Anyway, food for thought.

a.



On Aug 9, 2008, at 2:35 PM, Dave Cohen wrote:

> Personally, I don't see how two DBs improves things.  In my  
> experience, nodes
> are often "configuration" as well as "content".  Trying to draw that  
> line
> somewhere is a mistake, IMHO.  You might draw the line where it  
> makes sense
> for your sites, but not someone elses.
>
> As you point out, the list is highly debatable.  I think it's  
> undecidable.
>
> -Dave
>
> On Saturday 09 August 2008, Zohar Stolar wrote:
>> As yhager proposed, having two DBs instead of one, may ease things  
>> a lot.
>> One DB will hold content: nodes, revisions, files, users...
>> The second DB will hold configuration: views, cck structure, modules,
>> variables... (this list is highly debatable).
>>
>> This will allow for two-ways updating - content is pulled down, while
>> configuration can be easily pushed up.
>>
>
>

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




From earnie at users.sourceforge.net  Sat Aug  9 19:58:05 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Sat, 09 Aug 2008 15:58:05 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808091135.13222.drupal@dave-cohen.com>
References: <200808090758.01373.yuval@avramzon.net>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com> <200808091135.13222.drupal@dave-cohen.com>
Message-ID: <20080809155805.v399r5wseopwswwc@mail.progw.org>

Quoting Dave Cohen <drupal at dave-cohen.com>:

> Personally, I don't see how two DBs improves things.  In my experience, nodes
> are often "configuration" as well as "content".  Trying to draw that line
> somewhere is a mistake, IMHO.  You might draw the line where it makes sense
> for your sites, but not someone elses.
>

I couldn't agree more.  I think of static page content as 
"configuration" while the dynamic story content as "content".

> As you point out, the list is highly debatable.  I think it's undecidable.
>

Well, at least by what we might decide; it will never fit all 
scenarios.  The best we could do is strive to give what we think is 
best and worst case scenarios.

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


From adrian at bryght.com  Sat Aug  9 20:10:51 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sat, 9 Aug 2008 22:10:51 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <05C7ACD9-3A94-4812-AAE0-7D06A1DEE3B4@civicactions.com>
References: <200808090758.01373.yuval@avramzon.net>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com>
	<200808091135.13222.drupal@dave-cohen.com>
	<05C7ACD9-3A94-4812-AAE0-7D06A1DEE3B4@civicactions.com>
Message-ID: <CDCE7AAC-4609-4D89-8294-7D34D7E9146C@bryght.com>


On 09 Aug 2008, at 9:53 PM, arthur wrote:

> I think a really interesting project is the deploy module (http://drupal.org/project/deploy 
> ) which I think is an interesting abstract approach to this issue.  
> It won't meet everybody's needs, and isn't functionally sufficient  
> yet (for content at least), but is a good start, and worth starting  
> a more serious conversation of how this problem might be addressed  
> from the larger Drupal community. Some of the concepts that Greg has  
> already got in place are critical for the staging issue. You can  
> check out a talk Greg did on the deploy module at the Seattle Drupal  
> User Group here: http://blip.tv/file/1033300

Deploy uses macros, essentially. It captures form submissions and  
resubmits them to the other sites.

The entire drupal_execute / macro functionality was one of the  
tertiary goals of the initial design of fapi, unfortunately we didn't  
make the
design water tight, so it was possible (easy in fact) to write forms  
which didn't work with macros. We would have to vet all the existing  
forms,
and tighten up the API to force it to work consistently across all  
forms, to make deploy work in all cases. A good example of this not  
working
is that cck 1.x forms. cck_import broke most of the time because the  
forms weren't built to work consistently with drupal_execute.

Additionally, deploy only works one way. Which doesn't help in cases  
like this (where content/configuration needs to be moved both  
directions).
The moment you modify anything on the live site, you run into the  
problem where it's impossible to merge the changes back, without  
wiping the
staging / dev database, and resubmitting everything.

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

From arthur at civicactions.com  Sat Aug  9 20:31:31 2008
From: arthur at civicactions.com (arthur)
Date: Sat, 9 Aug 2008 16:31:31 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <CDCE7AAC-4609-4D89-8294-7D34D7E9146C@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com>
	<200808091135.13222.drupal@dave-cohen.com>
	<05C7ACD9-3A94-4812-AAE0-7D06A1DEE3B4@civicactions.com>
	<CDCE7AAC-4609-4D89-8294-7D34D7E9146C@bryght.com>
Message-ID: <C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>


On Aug 9, 2008, at 4:10 PM, Adrian Rossouw wrote:

>
> On 09 Aug 2008, at 9:53 PM, arthur wrote:
>
>> I think a really interesting project is the deploy module (http://drupal.org/project/deploy 
>> ) which I think is an interesting abstract approach to this issue.  
>> It won't meet everybody's needs, and isn't functionally sufficient  
>> yet (for content at least), but is a good start, and worth starting  
>> a more serious conversation of how this problem might be addressed  
>> from the larger Drupal community. Some of the concepts that Greg  
>> has already got in place are critical for the staging issue. You  
>> can check out a talk Greg did on the deploy module at the Seattle  
>> Drupal User Group here: http://blip.tv/file/1033300
>
> Deploy uses macros, essentially. It captures form submissions and  
> resubmits them to the other sites.
>
> The entire drupal_execute / macro functionality was one of the  
> tertiary goals of the initial design of fapi, unfortunately we  
> didn't make the
> design water tight, so it was possible (easy in fact) to write forms  
> which didn't work with macros. We would have to vet all the existing  
> forms,
> and tighten up the API to force it to work consistently across all  
> forms, to make deploy work in all cases. A good example of this not  
> working
> is that cck 1.x forms. cck_import broke most of the time because the  
> forms weren't built to work consistently with drupal_execute.
>
> Additionally, deploy only works one way. Which doesn't help in cases  
> like this (where content/configuration needs to be moved both  
> directions).
> The moment you modify anything on the live site, you run into the  
> problem where it's impossible to merge the changes back, without  
> wiping the
> staging / dev database, and resubmitting everything.

Adrian- I think you're right that it isn't a perfect solution (as it  
currently stands). Beyond what you've mentioned, there are dependency  
chains for users, content and configurations that could get really  
really messy.

That being said, I think it's pretty clear that many people in the  
Drupal community are really interested in a solution for this. A sense  
of agreement of how this problem could be tackled could really foster  
progress. Perhaps I'm being naive, but it does seem like some of the  
tools that various folks in the community are using are getting closer  
to being quite functional for lots of people. With some focused  
development time (a sprint perhaps?), it seems as though some of the  
more daunting pieces (reverting changes for example) might be  
approachable.

Anyway, I was just hoping to bring some awareness to one of the tools  
that does exist now, and could potentially serve as a model to build  
from. Of course, I'm not even the author, so maybe Greg should chime  
in :)



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




From adrian at bryght.com  Sat Aug  9 20:43:35 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sat, 9 Aug 2008 22:43:35 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
References: <200808090758.01373.yuval@avramzon.net>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com>
	<200808091135.13222.drupal@dave-cohen.com>
	<05C7ACD9-3A94-4812-AAE0-7D06A1DEE3B4@civicactions.com>
	<CDCE7AAC-4609-4D89-8294-7D34D7E9146C@bryght.com>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
Message-ID: <BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>


On 09 Aug 2008, at 10:31 PM, arthur wrote:

>
> That being said, I think it's pretty clear that many people in the  
> Drupal community are really interested in a solution for this. A  
> sense of agreement of how this problem could be tackled could really  
> foster progress. Perhaps I'm being naive, but it does seem like some  
> of the tools that various folks in the community are using are  
> getting closer to being quite functional for lots of people. With  
> some focused development time (a sprint perhaps?), it seems as  
> though some of the more daunting pieces (reverting changes for  
> example) might be approachable.
indeed, which is why we are having this discussion.

> Anyway, I was just hoping to bring some awareness to one of the  
> tools that does exist now, and could potentially serve as a model to  
> build from. Of course, I'm not even the author, so maybe Greg should  
> chime in :)
If we intend to build from it, we need to identify the issues relating  
to it, and the work required to make it work perfectly, which is all I  
stated.

We need to inspect all the ways people are currently working around  
this, so we can choose the best mechanism to focus on.


From kathleen at ceardach.com  Sat Aug  9 23:06:19 2008
From: kathleen at ceardach.com (Kathleen Murtagh)
Date: Sat, 9 Aug 2008 19:06:19 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>
	<489DA534.4030709@gmail.com>
	<200808091135.13222.drupal@dave-cohen.com>
	<05C7ACD9-3A94-4812-AAE0-7D06A1DEE3B4@civicactions.com>
	<CDCE7AAC-4609-4D89-8294-7D34D7E9146C@bryght.com>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
Message-ID: <1d83e3e60808091606tefd86dbg14b86caa2e6abecd@mail.gmail.com>

I created the dbscripts module to assist me in many of these issues.
The issues are:

 1. Certain settings should be set differently when in a production
and development environment (like caching)
 2. Content data can be created, deleted and modified in both
production and development
 3. The database schema can change and be manipulated on the fly (ie: CCK)
 4. The development process (and thusly, the recording changes
process) must be fast and minimize hindering the development team

Issue 1 can be solved for any configuration setting that is stored in
the variables table, by setting it in the bottom of the settings.php
file (read the bottom of that file for details).  To expand on this,
it would be great to give more flexibility to allow people to set
configuration settings within a file, instead of the database (could
this also improve performance?).

Issues 2 and 3 are the primary issues.  In issue 2, some people want
the capability to merge more than just content, but certain
configuration settings, too!  Such as blocks, site name, etc.  This is
important to those who allow clients to manipulate what they can
handle on the site, and hire them for the big features.  Issue 3 is
what makes merging this stuff hard.  The dbscripts modules depends
upon the usage of update.php and content_copy in order to merge
content.

Another database issue is that one row can hold different types of
data - content, configuration and user data.  For example, the users
table stores configuration (UID, username), content (email address)
and user data (last visited).  Blocks hold both the content of the
block, and the location of it.  This makes it difficult to easily
merge the changes made to these rows if they were both modified in
development and production.

Lastly, issue 4 is vitally important.  You want to minimize repeating
any steps.  You don't want to have to test a configuration setting,
then repeat all your steps while recording it.  Development needs to
be fast and quick, minimizing the time being used for version control.

My dream is to have automatically created database migrations for
Drupal.  The database is being manipulated constantly, is there
anything preventing us from recording those manipulations?  If we
could somehow record each change made to the database automatically in
their original SQL queries and then export those changes to a set of
incremental files.  We could then run a script that would run through
each of the migration scripts to update the database in your working
space.

Optimally, if there was automatic database migrations, the SQL queries
would have to be specific.  The query should target a specific column
in a row, so then an editor in production could change the content of
a block, while the developer could change the visibility settings.
Effectively, the goal is that both production and development could
manipulate the data on the same row while minimizing conflicts.

This would allow a team to both move database changes "down" from
production to development, and "up" from development to production
with relative ease, even on large databases (which dbscripts can't
handle).

Is this technically possible with Drupal?  Is the barrier just finding
someone who will sit down and do it?  If only I knew more about the
interaction with the database layer, I would do it.  However, my
original goal when creating dbscripts was to do this, but I simply
don't know enough about the database layer.

---
Kathleen Murtagh

From drupal at samboyer.org  Sat Aug  9 23:22:17 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Sat, 9 Aug 2008 18:22:17 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
Message-ID: <200808091822.17895.drupal@samboyer.org>

On Saturday 09 August 2008 15:43:35 Adrian Rossouw wrote:
> On 09 Aug 2008, at 10:31 PM, arthur wrote:
> > That being said, I think it's pretty clear that many people in the
> > Drupal community are really interested in a solution for this. A
> > sense of agreement of how this problem could be tackled could really
> > foster progress. Perhaps I'm being naive, but it does seem like some
> > of the tools that various folks in the community are using are
> > getting closer to being quite functional for lots of people. With
> > some focused development time (a sprint perhaps?), it seems as
> > though some of the more daunting pieces (reverting changes for
> > example) might be approachable.
>
> indeed, which is why we are having this discussion.
>
> > Anyway, I was just hoping to bring some awareness to one of the
> > tools that does exist now, and could potentially serve as a model to
> > build from. Of course, I'm not even the author, so maybe Greg should
> > chime in :)
>
> If we intend to build from it, we need to identify the issues relating
> to it, and the work required to make it work perfectly, which is all I
> stated.
>
> We need to inspect all the ways people are currently working around
> this, so we can choose the best mechanism to focus on.

Given that heyrocker/Greg is now at Palantir, deploy is on our minds...let me 
try to not steal any of his thunder :)

So we've talked a bit about deploy and this general problem of maintaining 
multiple different instances of a given site, where those instances may have 
different purposes/states within the overall workflow; allowing for data & 
changes to flow to/from/around those various different instances is the killer 
problem. I think we came up with a 'holy grail' that had dev state(s), then 
qa, staging, and prod. Primary keys are the big killer there, of course, and 
while I have considerable admiration for the folks who've come up with working 
models for ensuring no primary key conflicts (which afaik are either even/odd 
or start-at-key-X approaches), I'd hope there's agreement that we could do 
better. We've batted some thoughts around, but I'll leave it up to Greg on 
whether or not he feels like they're ripe for public digestion yet - this is 
his baby =)

I will say, though, that there's a basic approach present in deploy which 
_does_ have the potential to become a systemic solution to this problem (IMO): 
it's pluggable. Instead of trying to figure out what data should or shouldn't 
be transferred (which is essentially what we're doing when we pick out parts 
of our db dumps to push/pull), it just presents an API and lets the modules 
implementing it decide the logic that ought to govern synchronizing data 
between various site states. That, to me, seems like the approach most likely 
to end with positive results: deploy abstracts synchronization complexities 
into a simple API. Modules implementing it just have to answer some fairly 
basic questions about how their data is structured, and deploy takes care of 
the rest.

Sam

From adrian at bryght.com  Sun Aug 10 00:59:22 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sun, 10 Aug 2008 02:59:22 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808091822.17895.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
Message-ID: <AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>


On 10 Aug 2008, at 1:22 AM, Sam Boyer wrote:

> Modules implementing it just have to answer some fairly
> basic questions about how their data is structured, and deploy takes  
> care of
> the rest.

Any solution we build has to be modular. If it's kept fairly simple, i  
expect
that there's enough need that most of the important modules
would get covered pretty easily. 

From adrian at bryght.com  Sun Aug 10 01:09:59 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sun, 10 Aug 2008 03:09:59 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808091822.17895.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
Message-ID: <A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>


On 10 Aug 2008, at 1:22 AM, Sam Boyer wrote:

> Given that heyrocker/Greg is now at Palantir, deploy is on our  
> minds...let me
> try to not steal any of his thunder :)

One of the things I would like to see in deploy , or any system we end  
up using,
is the ability to generate a module with a .install file for the  
configuration info
in install and update_x hooks.

This allows developers to version their code and configuration with  
their version tracking
system, and roll out new releases the same way they would normally.


From z.stolar at gmail.com  Sun Aug 10 06:26:34 2008
From: z.stolar at gmail.com (Zohar Stolar)
Date: Sun, 10 Aug 2008 09:26:34 +0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <20080809155805.v399r5wseopwswwc@mail.progw.org>
References: <200808090758.01373.yuval@avramzon.net>	<1B3475CC-72E6-4D27-96A2-EF1C2CADD1E7@bryght.com>	<489DA534.4030709@gmail.com>
	<200808091135.13222.drupal@dave-cohen.com>
	<20080809155805.v399r5wseopwswwc@mail.progw.org>
Message-ID: <489E8A1A.6000708@gmail.com>


Earnie Boyd wrote:

> Quoting Dave Cohen <drupal at dave-cohen.com>:
>
>> Personally, I don't see how two DBs improves things.  In my 
>> experience, nodes
>> are often "configuration" as well as "content".  Trying to draw that 
>> line
>> somewhere is a mistake, IMHO.  You might draw the line where it makes 
>> sense
>> for your sites, but not someone elses.
>>
>
> I couldn't agree more.  I think of static page content as 
> "configuration" while the dynamic story content as "content".
If we take /any/ node as "configuration", we really are in troubles...

Let's think of a classic scenario (before we dive into esoteric ones) 
where the only changes to the DB, on the production site are:
- adding / modifying nodes, comments, files and users
- Any watchdog entries, timestamps or counters, as a result of the above

While on the dev/staging servers, we change the rest:
- views config
- CCKs structure
- block position / config
- probably most of the things under admin/*

Menus are a special case, since adding a menu item on production can be 
considered as adding content, as oppose to changing the menu's block 
position, or changing fields in views.

>
>> As you point out, the list is highly debatable.  I think it's 
>> undecidable.
>>
I assume the reason it seems undecidable is because each one has his/her 
own policies and tricks.
If we come out with a /fairly good/ solution, one that would fit 80% of 
all cases, it will help us adapt ourselves to it.

From gdd at heyrocker.com  Sun Aug 10 07:18:35 2008
From: gdd at heyrocker.com (Greg Dunlap)
Date: Sun, 10 Aug 2008 00:18:35 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
Message-ID: <7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>

When I created Deploy I had a set of goals in mind that I felt a solution
had to meet. I think (hope) that most people will agree that these goals
represent the ideal of what any staging and deployment system should
achieve. Some of this will repeat some of what has already been said
insightfully and thoughtfully above, but I kind of wanted it all put
together in one place.

I wanted to see a solution that focused on what can be done within Drupal,
without modifying core. That includes not modifying the default installs of
core tables (to reserve IDs for instance.) I see a lot of people focusing on
the database when talking about deployment which I think is the wrong way to
look at things. When you're moving a node, you should deal with it the same
way the rest of Drupal does. load it, save it. The only thing missing there
is how do you move it from one place to another. We should use that which
Drupal gives us.

Everything should be deployable - content, comments, taxonomy, users,
configuration, content types, the whole nine yards. When "things" are
deployed their references to other "things" should be preserved. It must
work bi-directionally. If I make a change to my Pathauto config, I should be
able to push it forward. Conversely if a user submits a new comment, that
comment should be able to be pushed back to my staging site (and it should
still be linked to the proper node.) Kathleen makes a good point that we
need to account for things that are different between servers by design.

Modules should be able to hook into the deployment process easily and with a
great deal of flexibility (this is the part I think my module currently gets
pretty right.) This framework could live in core or not, I really think it
doesn't matter in the end. As recently saw with D6 & Views, any module with
a sufficiently large enough install base is "core" in that people won't
build sites without them and won't build modules without integrating with
them. (Please note that I am not implying my module is at anywhere near the
level of Views.) Build a deployment system that solves everyone's problems
and it will get implemented throughout the spectrum.

Any system should also be flexible enough to meet the needs of all users -
that means there should be a point and click UI for non-developers to be
able to deploy things, but also the ability to move the information into
code for traditional deployment as Adrian wants. Things should be able to be
deployed out of cron or published through a timetable. Different sites have
different needs and with a flexible, sensible API this shouldn't be a
problem.

There is really only one thing standing in the way of all of this happening
and that is the fact that we cannot uniquely identify most things between
servers. I create a node on my dev server and it is given the ID of 10. It
goes through my editorial workflow until its done and I push it out. However
on my live site node 10 is a forum post that one of my users made. So my new
node becomes node 11. Now I make a change to this node on my dev site and
there's no way to push the update. The same goes for bringing forum node 10
back to my dev server. This is why all the id-specific hoop-jumping happens.
The only reason Deploy works at all is because I'm pushing around things
like CCK content types that can be uniquely identified through a text string
(the user-specified machine name.)

This whole problem would be much simpler if every "thing" had a GUID. Get
that in place, and building a system to do deployment in the way described
above actually becomes a realistic proposition. As Sam implied I've been
conceptualizing a solution based on this premise, but its been hard finding
time to really work on it. Hopefully soon.

Having made that very long, rambling post (sorry its been a long day and its
late) I think there's a lot of room for many solutions dependent on your
needs, and its unlikely that any "one size fits all" answer will be
forthcoming. Sites have different needs and different resources and
different workflows and thus its natural different solutions will develop.
People like Kathleen and Dave and the Bryght/Raincity folks and many others
have done great work in this sphere and I'm sure will continue to. The more
smart people are thinking about it and working on it, the more ideas and
knowledge will be built which can only lead to good things down the road.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080810/889d9bac/attachment-0001.htm 

From adrian at bryght.com  Sun Aug 10 08:15:32 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sun, 10 Aug 2008 10:15:32 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
Message-ID: <7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>


On 10 Aug 2008, at 9:18 AM, Greg Dunlap wrote:

>
> This whole problem would be much simpler if every "thing" had a  
> GUID. Get that in place, and building a system to do deployment in  
> the way described above actually becomes a realistic proposition. As  
> Sam implied I've been conceptualizing a solution based on this  
> premise, but its been hard finding time to really work on it.  
> Hopefully soon.

We could create an object table pretty simply, and just keep that  
maintained,  with the object type, object area (ie: production,  
staging, etc)
and reference id. And could then just write drivers for each of the  
object types.

Most of the 'drivers' would be really simple, ie; just wrapping  
node_load and node_save or drupal_execute.

We could make it a lot simpler to support the object table by writing  
a very simple fapi submit handler that gets added onto forms that
need to be indexed in the oid table :

$form['#submit']['drupal_object_register'] = array('node', 'nid',  
'area');  // just tells it to use $form_values['nid'] and  
$form_values['area'] when sticking it in the table.

We would also be able to handle versioning, although the idea of  
tracking node revisions like this on a busy site with
revision tracking could get difficult. Add a datestamp on there, and  
you could have the proper order to import objects too.

From victorkane at gmail.com  Sun Aug 10 13:06:33 2008
From: victorkane at gmail.com (Victor Kane)
Date: Sun, 10 Aug 2008 10:06:33 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
Message-ID: <ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>

This whole thread is exceptionally profound and of great interest to
those who spend their days actually using Drupal with clients and
getting sites done.

I think it is correct to avoid a purely database driven analysis of
the problem, and that both the problem and the solution should be
expressed in Drupal terms, that is, Drupal building blocks, like
users, nodes, comments, menus, blocks or panels, that is, different
kinds of entities, their listers and containers.

But the more profound the discussion goes, the more it resembles a
reverse engineering of Drupal. And any approach to X-Ray a Drupal
instance in order to dissect and reassemble it elsewhere, in whole or
in part, unfortunately, is going to smack hard against design
decisions already made in Drupal.

Perhaps it would do well to focus attention on single points capable
of being improved upon: there have been many attempts, there have been
some satisfying solutions implemented, but there is no straightforward
way to export and import node content in Drupal. Forget about
"structural" nodes, for the moment (although that of course is
important, I mean just to simplify).

There is no straightforward way in Drupal to export and import a given
content type's nodes.

No off-the-shelf, simple way of doing it.

I can try to marshall the failed export-import module.
I can more successfully utilize the services module. But in this case
if there are some complications in the field types, I need to write my
own {node-type}.save service.

That is, I cannot export/import content in Drupal without writing PHP code.

I think that is one of the biggest weaknesses that confront us. Deploy
seeks to solve this, but falls down through no fault of its own over
the difficulty of exporting and cleanly importing CCK content type
definitions.

The solution probably exists in terms of extracting all objectively
structural information architecture decisions (panels, menus, blocks)
into text-based version-controllable definitions, together with
configuration elements: currently "serializable" via the Installation
Profile Generators: http://drupal.org/node/180078.

I think a beginning would be to ensure that for Drupal 7 there existed
an export/import facility for node types; and that CCK, Views, Panels
and what-have-you work on improving their individual import/export.

Anything on a grander scale might smack hard against existing Drupal
design decisions.

Victor Kane
http://awebfactory.com.ar

On Sun, Aug 10, 2008 at 5:15 AM, Adrian Rossouw <adrian at bryght.com> wrote:
>
> On 10 Aug 2008, at 9:18 AM, Greg Dunlap wrote:
>
>>
>> This whole problem would be much simpler if every "thing" had a GUID. Get
>> that in place, and building a system to do deployment in the way described
>> above actually becomes a realistic proposition. As Sam implied I've been
>> conceptualizing a solution based on this premise, but its been hard finding
>> time to really work on it. Hopefully soon.
>
> We could create an object table pretty simply, and just keep that
> maintained,  with the object type, object area (ie: production, staging,
> etc)
> and reference id. And could then just write drivers for each of the object
> types.
>
> Most of the 'drivers' would be really simple, ie; just wrapping node_load
> and node_save or drupal_execute.
>
> We could make it a lot simpler to support the object table by writing a very
> simple fapi submit handler that gets added onto forms that
> need to be indexed in the oid table :
>
> $form['#submit']['drupal_object_register'] = array('node', 'nid', 'area');
>  // just tells it to use $form_values['nid'] and $form_values['area'] when
> sticking it in the table.
>
> We would also be able to handle versioning, although the idea of tracking
> node revisions like this on a busy site with
> revision tracking could get difficult. Add a datestamp on there, and you
> could have the proper order to import objects too.
>

From victorkane at gmail.com  Sun Aug 10 13:17:15 2008
From: victorkane at gmail.com (Victor Kane)
Date: Sun, 10 Aug 2008 10:17:15 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
Message-ID: <ff176450808100617x72f7d70bk1c6b721254339bb4@mail.gmail.com>

> This whole problem would be much simpler if every "thing" had a GUID. Get
> that in place, and building a system to do deployment in the way described
> above actually becomes a realistic proposition. As Sam implied I've been
> conceptualizing a solution based on this premise, but its been hard finding
> time to really work on it. Hopefully soon.

Just a quick point on this: if every "thing" had a GUID (that is, a
globally unique identifier (PHP's uniqid is sufficient if it the
prefix parameter is invoked in order to identify the host machine's
MAC, mayble butressed with an addional field based on an aleatory
number, since otherwise duplicate timestamp based id's will be
created), AND if every "thing" were serializable / unserializable (and
here we mustn't forget certain encoding problems). Serializable: take
an in memory object and turn it into a text object that can be stored
in a file, version controlled, deployed via unserialization, etc.).
Then you would have a realistic proposition.

Certainly achievable for nodes, perhaps lots of other stuff, but I
don't know if every "thing" in Drupal required for deployment, site
merging, etc.

Just wanted to extende thoughts in that direction.

From ernst.pluess at gmail.com  Sun Aug 10 13:19:59 2008
From: ernst.pluess at gmail.com (=?ISO-8859-1?Q?Ernst_Pl=FCss?=)
Date: Sun, 10 Aug 2008 15:19:59 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
Message-ID: <27c534c90808100619j4bc1cd7fi312bc324da9328b5@mail.gmail.com>

With the help of a GUID and a timestamp of the last write access in every
table it would be easy to synchronize Databases. If you want to synchronize
only certain elements like varialbes, nodes, users, configuration etc.
modules could provide a hook which

   - just lists the db table to snychronize
   - gets the result of db compaire and let the user decide what will be
   pushed to the other side.

Both things could be handled by the db_query() function, to make sure no one
forgets to touch the access timestamp and creates accurate GUID's.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080810/638406fb/attachment.htm 

From adrian at bryght.com  Sun Aug 10 15:07:49 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sun, 10 Aug 2008 17:07:49 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <27c534c90808100619j4bc1cd7fi312bc324da9328b5@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<27c534c90808100619j4bc1cd7fi312bc324da9328b5@mail.gmail.com>
Message-ID: <FA7A680F-3A2E-405D-ADE4-4510E91736C3@bryght.com>


On 10 Aug 2008, at 3:19 PM, Ernst Pl?ss wrote:
> With the help of a GUID and a timestamp of the last write access in  
> every table it would be easy to synchronize Databases. If you want  
> to synchronize only certain elements like varialbes, nodes, users,  
> configuration etc. modules could provide a hook which
Not all tables have timestamps, and it would require adding a whole  
mess of extra columns.
> just lists the db table to snychronize
> gets the result of db compaire and let the user decide what will be  
> pushed to the other side.
That's a lot of functionality, considering the weird merging of  
tables, and additional foreign keys. Take for example
a simple single -> multi relationship. You'd have to compare the bunch  
of them, and understand how to generate them all.

All this stuff is already in most of the _load functions. It's also a  
LOT easier to compare 2 objects to each other
(take the diff module for instance).

Also, the db updates then get related  very directly to the schema the  
modules export.

> Both things could be handled by the db_query() function, to make  
> sure no one forgets to touch the access timestamp and creates  
> accurate GUID's.

I think that perhaps db_query is too low a level for this, as that  
would add extra cycles on every single query done to the database, and  
probably
also parsing the query (or changing all the db_query calls in core  
with extra parameters).

And it's also not that hard to make sure the access stamp isn't  
changed, and is only related to nodes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080810/9a24eec3/attachment.htm 

From drupal at samboyer.org  Sun Aug 10 14:41:20 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Sun, 10 Aug 2008 09:41:20 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<200808091822.17895.drupal@samboyer.org>
	<A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
Message-ID: <200808100941.21031.drupal@samboyer.org>

On Saturday 09 August 2008 20:09:59 Adrian Rossouw wrote:
> On 10 Aug 2008, at 1:22 AM, Sam Boyer wrote:
> > Given that heyrocker/Greg is now at Palantir, deploy is on our
> > minds...let me
> > try to not steal any of his thunder :)
>
> One of the things I would like to see in deploy , or any system we end
> up using,
> is the ability to generate a module with a .install file for the
> configuration info
> in install and update_x hooks.
>
> This allows developers to version their code and configuration with
> their version tracking
> system, and roll out new releases the same way they would normally.

Sorry, I'm not grokking this idea. What's the use case for generating modules 
and associated update hooks?

From adrian at bryght.com  Sun Aug 10 16:09:14 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Sun, 10 Aug 2008 18:09:14 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808100941.21031.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<200808091822.17895.drupal@samboyer.org>
	<A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
	<200808100941.21031.drupal@samboyer.org>
Message-ID: <BC713AB1-3A1F-4ABC-87BA-8294B25BB55A@bryght.com>

On 10 Aug 2008, at 4:41 PM, Sam Boyer wrote:
> Sorry, I'm not grokking this idea. What's the use case for  
> generating modules
> and associated update hooks?
checking them into your own revisioning system with your own release  
and qa structures,
distributing configurations and more.

Basically keeping your releases in line with each other, so you don't  
have the code, and then a floating
database synch process which doesn't match up directly to your code,  
so you wouldn't have sites trying
to communicate with each other using different versions of modules  
(which might cause incompatibilities).

This way, you upgrade all the sites and the code the way you normally  
would :
svn update; run update.php.

Being able to take any site and going 'You are an install profile  
now', AND keeping that
install profile in synch across later versions without having to have  
to subscribe all the sites
using the install profile to the main synch. (many of those sites  
might not even be yours)

Basically, the dump to module thing takes the long view. Once you have  
done your development,
and you actually want to deploy it in one or more places, you have a  
single atomic package
of everything you need to get the site up and running, to which people  
can add their own content.

From gdd at heyrocker.com  Sun Aug 10 16:22:38 2008
From: gdd at heyrocker.com (Greg Dunlap)
Date: Sun, 10 Aug 2008 09:22:38 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
Message-ID: <7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>

On Sun, Aug 10, 2008 at 6:06 AM, Victor Kane <victorkane at gmail.com> wrote:

The solution probably exists in terms of extracting all objectively
> structural information architecture decisions (panels, menus, blocks)
> into text-based version-controllable definitions, together with
> configuration elements: currently "serializable" via the Installation
> Profile Generators: http://drupal.org/node/180078.
>
> I think a beginning would be to ensure that for Drupal 7 there existed
> an export/import facility for node types; and that CCK, Views, Panels
> and what-have-you work on improving their individual import/export.


Alex Barth recently contact me about exactly this, having come to the exact
same conclusion. He has opened an issue in deploy's issue queue:

http://drupal.org/node/291921

He himself wrote a module quite similar to Deploy called Ports which is
pretty interesting and abstracts import/export a bit beyond what I did.
Maybe he can chime in here about what he's done because I've only taken
really a cursory glance at it.

He also pointed out to me that there are many admin/config level problems
that are currently being worked on individually which could probably help
from some communication. For instance, having well-defined import/export
functionality for all "things" in Drupal would help not only deployment but
install profiles, and probably a bunch of other admin/config-related issues.
I'd love to see everyone discussing their problems in a more public setting,
not here but perhaps in the Change Management group on g.d.o., so we can
pool resources on problems when it makes sense. For all that people seem to
be struggling with these issues, that group is oddly dead.

For more food for thought, there is a ton of interesting discussion in the
comments on my initial blog post about Deploy:

http://heyrocker.com/drupal/content/deployment-and-change-management-framework
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080810/240da26c/attachment.htm 

From yuval at avramzon.net  Sun Aug 10 16:47:49 2008
From: yuval at avramzon.net (Yuval Hager)
Date: Sun, 10 Aug 2008 19:47:49 +0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
Message-ID: <200808101947.49977.yuval@avramzon.net>

On Sunday 10 August 2008, Greg Dunlap wrote:
> This whole problem would be much simpler if every "thing" had a GUID. Get
> that in place, and building a system to do deployment in the way described
> above actually becomes a realistic proposition.

I hope I am not stating the obvious here, but you can get yourself a 
pseudo-GUID if you ask the user for a string that identifies the installation 
(e.g. my-dev, my-staging, my-production) and use that and the object internal 
id to create a GUID (no hashing necessary).
When you import objects INTO an installation you keep a table that maps the 
remote object GUID to the local object GUID. Then you have a well defined one 
to one mapping, and you are able to update the object again, reference to it 
(this comment is for that node), or even send it back if needed. You can also 
keep track of which object came from where if you ever need this kind of 
auditing.

I don't trust arbitrary strings like domain, IP, MAC etc as they have the 
tendency to change. Asking the user for a unique id (and it only has to be 
unique in his world) should be good enough here.

-- 
Yuval Hager
[@] yuval at avramzon.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080810/aa8bec73/attachment.pgp 

From drupal at dave-cohen.com  Sun Aug 10 17:05:00 2008
From: drupal at dave-cohen.com (Dave Cohen)
Date: Sun, 10 Aug 2008 10:05:00 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<200808091822.17895.drupal@samboyer.org>
	<A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
Message-ID: <200808101005.00489.drupal@dave-cohen.com>

I've written about my personal approach in the past: 
http://www.dave-cohen.com/node/1779.  I use hook_form_alter so the update.php 
form always executes on of my update_x hooks.  And that hook imports a file 
with the latest database changes.

I wrote about it here at the time, and received a lot of "you should never use 
hook_form_alter in your .install file" comments.  But I do it anyway.  So I 
agree that a solution should be able to apply changes during update.php.

-Dave

On Saturday 09 August 2008, Adrian Rossouw wrote:
> One of the things I would like to see in deploy , or any system we end
> up using,
> is the ability to generate a module with a .install file for the
> configuration info
> in install and update_x hooks.
>

From ernst.pluess at gmail.com  Sun Aug 10 19:02:30 2008
From: ernst.pluess at gmail.com (=?ISO-8859-1?Q?Ernst_Pl=FCss?=)
Date: Sun, 10 Aug 2008 21:02:30 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <FA7A680F-3A2E-405D-ADE4-4510E91736C3@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<27c534c90808100619j4bc1cd7fi312bc324da9328b5@mail.gmail.com>
	<FA7A680F-3A2E-405D-ADE4-4510E91736C3@bryght.com>
Message-ID: <27c534c90808101202xbbd5b5bh501d60fb589ee877@mail.gmail.com>

2008/8/10 Adrian Rossouw <adrian at bryght.com>

>
> On 10 Aug 2008, at 3:19 PM, Ernst Pl?ss wrote:
>
> With the help of a GUID and a timestamp of the last write access in every
> table it would be easy to synchronize Databases. If you want to synchronize
> only certain elements like varialbes, nodes, users, configuration etc.
> modules could provide a hook which
>
> Not all tables have timestamps, and it would require adding a whole mess of
> extra columns.
>


Adding Timestamp columns would not be to hard. For MySql you don't even have
to change the module code since the DB does everything for you. Up on every
write operation a new timestamp is set automatically.
The GUID would be a little bit harder. AFAIK there's no automatic insertin
of GUIDs for primary keys. But the functionality could be integrated in the
db_xyz functions.



   - just lists the db table to snychronize
   - gets the result of db compaire and let the user decide what will be
   pushed to the other side.

That's a lot of functionality, considering the weird merging of tables, and
> additional foreign keys. Take for examplea simple single -> multi
> relationship. You'd have to compare the bunch of them, and understand how to
> generate them all.
>

For new and updated rows it's actually very easy. First check for the
timestamp. Then check for the GUID. If it's there update the row from the
source db if not insert it. This works always and is not dependant on the
relationships between the tables.
The hard things are the deleted rows. You have to check for every GUID in
the destination db whether it still exists in the source db. If you have a
lot of data this can take a some time.

The hook is meant as a help for modul developers in case you don't want to
migrate a whole db but you let's say a certain node type. So you can do some
filtering or what every makes sense.



> All this stuff is already in most of the _load functions. It's also a LOT
> easier to compare 2 objects to each other
> (take the diff module for instance).
>
> Also, the db updates then get related  very directly to the schema the
> modules export.
>
> Both things could be handled by the db_query() function, to make sure no
> one forgets to touch the access timestamp and creates accurate GUID's.
>
>
> I think that perhaps db_query is too low a level for this, as that would
> add extra cycles on every single query done to the database, and probably
> also parsing the query (or changing all the db_query calls in core with
> extra parameters).
>
> And it's also not that hard to make sure the access stamp isn't changed,
> and is only related to nodes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080810/5295499e/attachment.htm 

From ethan at acquia.com  Sun Aug 10 19:49:58 2008
From: ethan at acquia.com (Ethan Fremen)
Date: Sun, 10 Aug 2008 15:49:58 -0400
Subject: [development] Unique/Random IDs and drupal
Message-ID: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>

Gentlebeings,

I've read the recent thread on devel->staging->deployment, and I  
wanted to share what I've done in the area.

My main interest lies in moving away from monotonically incrementing  
integers as id values so I have a greater chance of being able to  
"shard" the drupal DB for high performance.

As a first step, I am working on moving drupal core to using 64 bit  
integers. It was relatively trivial to change schema to create 64 bit  
tables, but right now there's nothing in schema that marks "foreign  
keys" as also being special.

Would anyone object to schema requiring foreign ID references to be  
marked specially?

Anyway, the direction I'm interested in heading is a 64 bit int +  
creation date timestamp for every row; the two can be combined to form  
a valid UUID if there are useful reasons for doing so.

Note that Postgresql has UUID creating functions and MySQL 5.1 has  
uuid_short() which generates a 64 bit random int based on the UUID  
algorithm.  The UUID() algorithm in mysql 5.0 isn't viable for scaling  
purposes because it's not cluster-safe.

I do have some preliminary performance data on the speed at which one  
can create UUIDs: http://mindlace.net/archives/2008/06/23/generating-uuids-in-php-for-drupal/

I'm very interested in any feedback about the feasibility of at least  
widening the ids to 64 bits in D7.

~ethan

From larry at garfieldtech.com  Sun Aug 10 20:57:27 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Sun, 10 Aug 2008 15:57:27 -0500
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
Message-ID: <200808101557.27583.larry@garfieldtech.com>

On Sunday 10 August 2008 2:49:58 pm Ethan Fremen wrote:
> Gentlebeings,
>
> I've read the recent thread on devel->staging->deployment, and I
> wanted to share what I've done in the area.
>
> My main interest lies in moving away from monotonically incrementing
> integers as id values so I have a greater chance of being able to
> "shard" the drupal DB for high performance.
>
> As a first step, I am working on moving drupal core to using 64 bit
> integers. It was relatively trivial to change schema to create 64 bit
> tables, but right now there's nothing in schema that marks "foreign
> keys" as also being special.
>
> Would anyone object to schema requiring foreign ID references to be
> marked specially?
>
> Anyway, the direction I'm interested in heading is a 64 bit int +
> creation date timestamp for every row; the two can be combined to form
> a valid UUID if there are useful reasons for doing so.
>
> Note that Postgresql has UUID creating functions and MySQL 5.1 has
> uuid_short() which generates a 64 bit random int based on the UUID
> algorithm.  The UUID() algorithm in mysql 5.0 isn't viable for scaling
> purposes because it's not cluster-safe.
>
> I do have some preliminary performance data on the speed at which one
> can create UUIDs:
> http://mindlace.net/archives/2008/06/23/generating-uuids-in-php-for-drupal/
>
> I'm very interested in any feedback about the feasibility of at least
> widening the ids to 64 bits in D7.
>
> ~ethan

There was discussion of including foreign keys in Schema API in Drupal 6, but 
it was dropped after we determined that we couldn't actually do anything with 
that information at the time.  We have to still support MySQL MyISAM tables, 
which are far and away the most common, and those don't support foreign keys.  
(Therefore we can't rely on integrity checking, cascading delete/update, 
etc.)  I believe there was consideration of adding FK support in Drupal 7 to 
allow add-on functionality in places, and I'm certainly open to doing so, but 
not until the existing 300 KB database overhaul patch has landed. :-)

Serial fields are actually very useful, and there's nothing wrong with them.  
In fact, they are a requirement if we want even remotely intelligible URLs.  
nids, uids, tids, etc. are all used in URLs, and most Drupal nodes do not in 
fact have a URL alias on them AFAIK.  If we add some form of GUID to the 
system (which I am not against, and Greg Dunlap has made good arguments for) 
it will have to be in addition to existing serial fields.

We also can't rely on MySQL 5.1 at this point, as it's not even fully stable 
to say nothing of widely deployed.

Given that, I don't see much advantage for 99% of sites to using 64-bit unique 
IDs over 32-bit.  It wouldn't break anything I suppose, but how many Drupal 
sites have the multiple millions of nodes required to run out of the 32-bit 
space?  I can't actually think of any.  

-- 
Larry Garfield
larry at garfieldtech.com

From kkaefer at gmail.com  Sun Aug 10 21:11:46 2008
From: kkaefer at gmail.com (=?ISO-8859-1?Q?Konstantin_K=E4fer?=)
Date: Sun, 10 Aug 2008 23:11:46 +0200
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <200808101557.27583.larry@garfieldtech.com>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
Message-ID: <D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>

> Given that, I don't see much advantage for 99% of sites to using 64- 
> bit unique
> IDs over 32-bit.  It wouldn't break anything I suppose, but how many  
> Drupal
> sites have the multiple millions of nodes required to run out of the  
> 32-bit
> space?  I can't actually think of any.

32 bit allow for more than 4 billion unique IDs. If any site goes over  
it, they can easily change their columns (or rethink their data model).

Konstantin

From ethan at acquia.com  Sun Aug 10 21:47:34 2008
From: ethan at acquia.com (Ethan Fremen)
Date: Sun, 10 Aug 2008 17:47:34 -0400
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <200808101557.27583.larry@garfieldtech.com>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
Message-ID: <CE54EA42-3ADD-4610-8D06-C231F8E6BED2@acquia.com>

On Aug 10, 2008, at 4:57 PM, Larry Garfield wrote:
> There was discussion of including foreign keys in Schema API in  
> Drupal 6, but
> it was dropped after we determined that we couldn't actually do  
> anything with
> that information at the time.  We have to still support MySQL MyISAM  
> tables,
> which are far and away the most common, and those don't support  
> foreign keys.

I don't actually care about schema supporting foreign keys. I just  
want it that when someone puts a reference to a foreign key in their  
schema, they do so using a type that is distinct from 'int'.

> Serial fields are actually very useful, and there's nothing wrong  
> with them.

There are several things wrong with them:

a.) it makes it impossible to shard the DB because you have to  
coordinate what the next sequence ID is, a huge problem with scaling.
b.) it makes it difficult to merge two (or more) existing DBs, whether  
development/production or otherwise.
c.) it means that every drupal site has namespace collisions all over  
the place with every other drupal site.

> In fact, they are a requirement if we want even remotely  
> intelligible URLs.

If by "intelligible" you mean "a small number" then you are correct.

> nids, uids, tids, etc. are all used in URLs, and most Drupal nodes  
> do not in
> fact have a URL alias on them AFAIK.

I was under the impression that pathauto was in wide use.

>  If we add some form of GUID to the
> system (which I am not against, and Greg Dunlap has made good  
> arguments for)
> it will have to be in addition to existing serial fields.

Which will not, in fact, address any of the issues I've outlined above.

> We also can't rely on MySQL 5.1 at this point, as it's not even  
> fully stable
> to say nothing of widely deployed.

I don't disagree. I was sharing the state of my understanding of DB  
support for these sorts of things. I think it is best for drupal to  
generate them itself at the moment.

> Given that, I don't see much advantage for 99% of sites to using 64- 
> bit unique
> IDs over 32-bit.

Use cases for the 99% of sites using a 64 bit unique identifier:
a.) Their content is globally unique across the set of Drupal sites.  
This makes many syndication and federation tasks easier.
b.) They ever wish to join with another site selected at random.

>  It wouldn't break anything I suppose, but how many Drupal
> sites have the multiple millions of nodes required to run out of the  
> 32-bit
> space?  I can't actually think of any.

The set of Drupal sites does. This is like the "we'll never run out of  
a 32 bit identifier" idea with ipv4.

Plus, there's exactly 0 performance difference when using a 64 bit  
machine.

I hope this helps clarify some of the use cases,

~ethan fremen


From ethan at acquia.com  Sun Aug 10 21:52:17 2008
From: ethan at acquia.com (Ethan Fremen)
Date: Sun, 10 Aug 2008 17:52:17 -0400
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
Message-ID: <6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>

On Aug 10, 2008, at 5:11 PM, Konstantin K?fer wrote:
> 32 bit allow for more than 4 billion unique IDs. If any site goes  
> over it, they can easily change their columns (or rethink their data  
> model).

I would definitely accept random 32 bit identifiers as a step in the  
right direction.

That being said, on any 64 bit machine, the 32 bit identifier is  
represented internally as a 64 bit identifier anyway. It is totally  
conceivable to me that the set of drupal sites in existence could  
quickly encounter collisions with a 32 bit identifier.

Again, a driving use case is "two drupal sites that were founded  
independently of any knowledge of each other would like to merge their  
databases".

Whenever you're using a hash function to generate identifiers, having  
a key space that is close to the size of the number of keys  
dramatically increases the chance that a collision will occur. By  
using a 64 bit identifier, we minimize that chance.

Thanks for your feedback,

~ethan fremen

From rob at robshouse.net  Sun Aug 10 22:52:09 2008
From: rob at robshouse.net (Robert Douglass)
Date: Mon, 11 Aug 2008 00:52:09 +0200
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
	<6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>
Message-ID: <2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>

> Again, a driving use case is "two drupal sites that were founded  
> independently of any knowledge of each other would like to merge  
> their databases".

To me, two even more compelling use cases are:

a) sharing global taxonomy vocabularies (the countries of the world  
each have globally unique ids shared across all sites)
b) import/export. This is like the merge example from Ethan but  
perhaps a little more concrete in terms of what people are already  
doing. I could export my blog posts from one site and import them into  
another site and keep the id.
c) global user ids. I always have the same user id on every Drupal site.

From earnie at users.sourceforge.net  Sun Aug 10 23:00:32 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Sun, 10 Aug 2008 19:00:32 -0400
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <CE54EA42-3ADD-4610-8D06-C231F8E6BED2@acquia.com>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<CE54EA42-3ADD-4610-8D06-C231F8E6BED2@acquia.com>
Message-ID: <20080810190032.7pz1ljtqkso4sk4g@mail.progw.org>

Quoting Ethan Fremen <ethan at acquia.com>:

>
> a.) it makes it impossible to shard the DB because you have to  
> coordinate what the next sequence ID is, a huge problem with scaling.
> b.) it makes it difficult to merge two (or more) existing DBs, 
> whether  development/production or otherwise.
> c.) it means that every drupal site has namespace collisions all over 
>  the place with every other drupal site.
>

I think you go about the problem incorrectly.  Any merging of data 
would need to use the Drupal API to do that merge.  You therefore do 
not need to know what the next id is because you simply shouldn't care. 
  When merging the data from DB-2 into DB-1 you do not supply the id's 
to the data from DB-2 and allow Drupal to create new id's in DB-1.  As 
for your supposed namespace collisions between sites, that is the 
nature of all data when two merge to one.  It is the job of the one 
doing the bridging to overcome that issue but overcoming that issue 
shouldn't involve needing to make your id's 64bit.

What do you do with users who have subscribed to both sites?  What do 
you do with nodes with matching titles?  The dilemma you describe can 
only be resolved by the rules set forth by the business acquiring DB-2.

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


From drupal at samboyer.org  Sun Aug 10 23:32:33 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Sun, 10 Aug 2008 18:32:33 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <ff176450808100617x72f7d70bk1c6b721254339bb4@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<ff176450808100617x72f7d70bk1c6b721254339bb4@mail.gmail.com>
Message-ID: <200808101832.45916.drupal@samboyer.org>

On Sunday 10 August 2008 08:17:15 Victor Kane wrote:
> > This whole problem would be much simpler if every "thing" had a GUID. Get
> > that in place, and building a system to do deployment in the way
> > described above actually becomes a realistic proposition. As Sam implied
> > I've been conceptualizing a solution based on this premise, but its been
> > hard finding time to really work on it. Hopefully soon.
>
> Just a quick point on this: if every "thing" had a GUID (that is, a
> globally unique identifier (PHP's uniqid is sufficient if it the
> prefix parameter is invoked in order to identify the host machine's
> MAC, mayble butressed with an addional field based on an aleatory
> number, since otherwise duplicate timestamp based id's will be
> created), AND if every "thing" were serializable / unserializable (and
> here we mustn't forget certain encoding problems). Serializable: take
> an in memory object and turn it into a text object that can be stored
> in a file, version controlled, deployed via unserialization, etc.).
> Then you would have a realistic proposition.
>
> Certainly achievable for nodes, perhaps lots of other stuff, but I
> don't know if every "thing" in Drupal required for deployment, site
> merging, etc.
>
> Just wanted to extende thoughts in that direction.

So if I've missed this in your/others' thoughts Victor, please forgive me, 
but...why are we talking about serializing and unserializing data? As you 
pointed out in your first email:

> There is no straightforward way in Drupal to export and import a given
> content type's nodes.
> 
> No off-the-shelf, simple way of doing it.

I agree. So...why talk about it at all? Deploy uses that approach at present, 
but we needn't be wedded to it. It seems to me that the GUID-based system is 
the thinnest possible way of allowing Deploy to keep track of the fact that 
"Thing A" on server 1 is "Thing B" on server 2. Deploy's API shouldn't be 
aware of what the Things are - just that they need to be checked against each 
other. And then it's up to the module(s) that created (or altered) the Things 
to decide what data comprises them, how to check that data against each other 
on the servers, and then how to resolve differences. The two biggest problems 
with that are handling data changes which have dependency chains (node system 
type changes being the most obvious) and that it could potentially make for an 
API too complex for general consumption. But that seems less insurmountable to 
me than the import/export problem.

Unless I've missed something?

Sam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080810/93821d97/attachment.pgp 

From drupal at samboyer.org  Sun Aug 10 23:56:39 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Sun, 10 Aug 2008 18:56:39 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <BC713AB1-3A1F-4ABC-87BA-8294B25BB55A@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<200808100941.21031.drupal@samboyer.org>
	<BC713AB1-3A1F-4ABC-87BA-8294B25BB55A@bryght.com>
Message-ID: <200808101856.43211.drupal@samboyer.org>

On Sunday 10 August 2008 11:09:14 Adrian Rossouw wrote:
> On 10 Aug 2008, at 4:41 PM, Sam Boyer wrote:
> > Sorry, I'm not grokking this idea. What's the use case for
> > generating modules
> > and associated update hooks?
>
> checking them into your own revisioning system with your own release
> and qa structures,
> distributing configurations and more.
>
> Basically keeping your releases in line with each other, so you don't
> have the code, and then a floating
> database synch process which doesn't match up directly to your code,
> so you wouldn't have sites trying
> to communicate with each other using different versions of modules
> (which might cause incompatibilities).
>
> This way, you upgrade all the sites and the code the way you normally
> would :
> svn update; run update.php.
>
> Being able to take any site and going 'You are an install profile
> now', AND keeping that
> install profile in synch across later versions without having to have
> to subscribe all the sites
> using the install profile to the main synch. (many of those sites
> might not even be yours)
>
> Basically, the dump to module thing takes the long view. Once you have
> done your development,
> and you actually want to deploy it in one or more places, you have a
> single atomic package
> of everything you need to get the site up and running, to which people
> can add their own content.

Gotcha. Ooooh. That is a nifty direction, and definitely one I hadn't thought 
of. In our 'holy grail' server workflow, I did have the idea that different 
parts of the data would flow differently to different servers - but indeed, a 
natural next step would be extending it to generating install profiles. Deploy 
wouldn't know the difference (nor would it care).

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/20080810/7d7c5151/attachment-0001.pgp 

From johan at forngren.com  Mon Aug 11 09:01:05 2008
From: johan at forngren.com (Johan Forngren)
Date: Mon, 11 Aug 2008 11:01:05 +0200
Subject: [development] PHP 4 is dead, long live PHP 4
Message-ID: <2e2a8fca0808110201w7626827ds6029ab8c7490a878@mail.gmail.com>

Yep, no more PHP 4.

The PHP development team would like to announce the immediate availability
> of PHP 4.4.9. It continues to improve the security and the stability of
> the 4.4 branch and all users are strongly encouraged to upgrade to it as
> soon as possible. This release wraps up all the outstanding patches for the
> PHP 4.4 series, and is therefore the *last* PHP 4.4 release.
>

http://www.php.net/archive/2008.php#id2008-08-07-1
http://www.computerworld.com.au/index.php/id;1239055978

-- 
Regards,
Johan Forngren :: http://johan.forngren.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080811/4c9aa55f/attachment.htm 

From victorkane at gmail.com  Mon Aug 11 10:33:49 2008
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 11 Aug 2008 07:33:49 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808101832.45916.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<ff176450808100617x72f7d70bk1c6b721254339bb4@mail.gmail.com>
	<200808101832.45916.drupal@samboyer.org>
Message-ID: <ff176450808110333w48763de6o62b7d359a3e5e071@mail.gmail.com>

The serialization and unserialization of data is included in my
approach to the problem for the purposes of the independent
transmission of nodes from one system to another, as in the case of
one Drupal site availing itself of a node.save service on another
Drupal site.

It also has the purpose of guaranteeing insofar as is possible a text
version of all entities, configurations, including exported views,
content types, panels, hopefully menues and module configurations and
exported variables, for the purposes of continued version control and
hence deployment also (serialization to text, unserialization to
deployment objective).

Here of course, serialization and unserialization is not meant in the
php function sense, and could include marshaling and unmarshaling to
and from XML, and is a cross-language concept.

Victor Kane
http://awebfactory.com.ar

On Sun, Aug 10, 2008 at 8:32 PM, Sam Boyer <drupal at samboyer.org> wrote:
> On Sunday 10 August 2008 08:17:15 Victor Kane wrote:
>> > This whole problem would be much simpler if every "thing" had a GUID. Get
>> > that in place, and building a system to do deployment in the way
>> > described above actually becomes a realistic proposition. As Sam implied
>> > I've been conceptualizing a solution based on this premise, but its been
>> > hard finding time to really work on it. Hopefully soon.
>>
>> Just a quick point on this: if every "thing" had a GUID (that is, a
>> globally unique identifier (PHP's uniqid is sufficient if it the
>> prefix parameter is invoked in order to identify the host machine's
>> MAC, mayble butressed with an addional field based on an aleatory
>> number, since otherwise duplicate timestamp based id's will be
>> created), AND if every "thing" were serializable / unserializable (and
>> here we mustn't forget certain encoding problems). Serializable: take
>> an in memory object and turn it into a text object that can be stored
>> in a file, version controlled, deployed via unserialization, etc.).
>> Then you would have a realistic proposition.
>>
>> Certainly achievable for nodes, perhaps lots of other stuff, but I
>> don't know if every "thing" in Drupal required for deployment, site
>> merging, etc.
>>
>> Just wanted to extende thoughts in that direction.
>
> So if I've missed this in your/others' thoughts Victor, please forgive me,
> but...why are we talking about serializing and unserializing data? As you
> pointed out in your first email:
>
>> There is no straightforward way in Drupal to export and import a given
>> content type's nodes.
>>
>> No off-the-shelf, simple way of doing it.
>
> I agree. So...why talk about it at all? Deploy uses that approach at present,
> but we needn't be wedded to it. It seems to me that the GUID-based system is
> the thinnest possible way of allowing Deploy to keep track of the fact that
> "Thing A" on server 1 is "Thing B" on server 2. Deploy's API shouldn't be
> aware of what the Things are - just that they need to be checked against each
> other. And then it's up to the module(s) that created (or altered) the Things
> to decide what data comprises them, how to check that data against each other
> on the servers, and then how to resolve differences. The two biggest problems
> with that are handling data changes which have dependency chains (node system
> type changes being the most obvious) and that it could potentially make for an
> API too complex for general consumption. But that seems less insurmountable to
> me than the import/export problem.
>
> Unless I've missed something?
>
> Sam
>
>
>

From victorkane at gmail.com  Mon Aug 11 11:20:40 2008
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 11 Aug 2008 08:20:40 -0300
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
	<6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>
	<2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>
Message-ID: <ff176450808110420i504b14aayd572271320af81fa@mail.gmail.com>

OK, but please all take into account that it is not necessarily the
best thing to tie the creation of the UUID to the database at all.

That would be a big mistake and bad design decision and continue the
kind of dependencies that need to be overcome.

There exist many independent UUID libraries (in Java, PHP, etc) as
described in the other thread.

Once created, the UUID of course will be persisted, so the rest of the
discussion is exceedingly fruitful, especially the use cases.

Victor Kane
http://awebfactory.com.ar

On Sun, Aug 10, 2008 at 7:52 PM, Robert Douglass <rob at robshouse.net> wrote:
>> Again, a driving use case is "two drupal sites that were founded
>> independently of any knowledge of each other would like to merge their
>> databases".
>
> To me, two even more compelling use cases are:
>
> a) sharing global taxonomy vocabularies (the countries of the world each
> have globally unique ids shared across all sites)
> b) import/export. This is like the merge example from Ethan but perhaps a
> little more concrete in terms of what people are already doing. I could
> export my blog posts from one site and import them into another site and
> keep the id.
> c) global user ids. I always have the same user id on every Drupal site.
>

From earnie at users.sourceforge.net  Mon Aug 11 12:38:14 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 11 Aug 2008 08:38:14 -0400
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
	<6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>
	<2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>
Message-ID: <20080811083814.i9lrwszi42884g0g@mail.progw.org>

Quoting Robert Douglass <rob at robshouse.net>:

> I could export my blog posts from one site and import them into  
> another site and keep the id.

You could "keep the id" but IMO you shouldn't.  You don't know if there 
may be an existing id in the receiving DB.  The ID is unique to each DB 
and existing values should not be merged from one DB into another.  
That said, the only correct method for merging data from one DB into 
another is to use the API for the receiving DB so that the foreign key 
constraints match appropriately (even for those DB engines not 
supporting foreign key constraints).  In Drupal's case the nid should 
be removed so that a new nid is created or the uid should be removed so 
that a new uid is created.  An import/export API should take into 
consideration this fact and allow for the removal of the ID columns on 
import or export.

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


From rob at robshouse.net  Mon Aug 11 12:49:39 2008
From: rob at robshouse.net (Robert Douglass)
Date: Mon, 11 Aug 2008 14:49:39 +0200
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <20080811083814.i9lrwszi42884g0g@mail.progw.org>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
	<6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>
	<2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>
	<20080811083814.i9lrwszi42884g0g@mail.progw.org>
Message-ID: <E9983CBC-DAD8-4AAA-877F-2DCC85EF278C@robshouse.net>

On Aug 11, 2008, at 2:38 PM, Earnie Boyd wrote:

> Quoting Robert Douglass <rob at robshouse.net>:
>
>> I could export my blog posts from one site and import them into   
>> another site and keep the id.
>
> You could "keep the id" but IMO you shouldn't.  You don't know if  
> there may be an existing id in the receiving DB.  The ID is unique  
> to each DB and existing values should not be merged from one DB into  
> another.  That said, the only correct method for merging data from  
> one DB into another is to use the API for the receiving DB so that  
> the foreign key constraints match appropriately (even for those DB  
> engines not supporting foreign key constraints).  In Drupal's case  
> the nid should be removed so that a new nid is created or the uid  
> should be removed so that a new uid is created.  An import/export  
> API should take into consideration this fact and allow for the  
> removal of the ID columns on import or export.
>
> Earnie -- http://for-my-kids.com/
> -- http://give-me-an-offer.com/
>


No, this is the entire point of Ethan's suggestion. The id's *are*  
globally (meaning universe-wide) unique. Note also that there is no  
inherent suggestion that one *wouldn't* use Drupal APIs. On the  
contrary, this discussion is about extending Drupal APIs (at least  
taking the first incremental step - moving to 64 bit integers). I  
really don't think you can satisfy the use cases discussed thus far  
easily with existing Drupal APIs.

http://en.wikipedia.org/wiki/UUID

"A Universally Unique Identifier (UUID) is an identifier standard used  
in software construction, standardized by the Open Software Foundation  
(OSF) as part of the Distributed Computing Environment (DCE). The  
intent of UUIDs is to enable distributed systems to uniquely identify  
information without significant central coordination. Thus, anyone can  
create a UUID and use it to identify something with reasonable  
confidence that the identifier will never be unintentionally used by  
anyone for anything else. Information labeled with UUIDs can therefore  
be later combined into a single database without needing to resolve  
name conflicts. The most widespread use of this standard is in  
Microsoft's Globally Unique Identifiers (GUIDs). Other significant  
users include Linux's ext2/ext3 filesystem, LUKS encrypted partitions,  
GNOME, KDE, and Mac OS X, all of which use implementations derived  
from the uuid library found in the e2fsprogs package."

From victorkane at gmail.com  Mon Aug 11 14:45:36 2008
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 11 Aug 2008 11:45:36 -0300
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <E9983CBC-DAD8-4AAA-877F-2DCC85EF278C@robshouse.net>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
	<6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>
	<2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>
	<20080811083814.i9lrwszi42884g0g@mail.progw.org>
	<E9983CBC-DAD8-4AAA-877F-2DCC85EF278C@robshouse.net>
Message-ID: <ff176450808110745h2c8e7213s7f7a8014f2ae06f1@mail.gmail.com>

right! but mustn't be database generated, must be generated on
business logic level to avoid dependence on any given persistence

On Mon, Aug 11, 2008 at 9:49 AM, Robert Douglass <rob at robshouse.net> wrote:
> On Aug 11, 2008, at 2:38 PM, Earnie Boyd wrote:
>
>> Quoting Robert Douglass <rob at robshouse.net>:
>>
>>> I could export my blog posts from one site and import them into  another
>>> site and keep the id.
>>
>> You could "keep the id" but IMO you shouldn't.  You don't know if there
>> may be an existing id in the receiving DB.  The ID is unique to each DB and
>> existing values should not be merged from one DB into another.  That said,
>> the only correct method for merging data from one DB into another is to use
>> the API for the receiving DB so that the foreign key constraints match
>> appropriately (even for those DB engines not supporting foreign key
>> constraints).  In Drupal's case the nid should be removed so that a new nid
>> is created or the uid should be removed so that a new uid is created.  An
>> import/export API should take into consideration this fact and allow for the
>> removal of the ID columns on import or export.
>>
>> Earnie -- http://for-my-kids.com/
>> -- http://give-me-an-offer.com/
>>
>
>
> No, this is the entire point of Ethan's suggestion. The id's *are* globally
> (meaning universe-wide) unique. Note also that there is no inherent
> suggestion that one *wouldn't* use Drupal APIs. On the contrary, this
> discussion is about extending Drupal APIs (at least taking the first
> incremental step - moving to 64 bit integers). I really don't think you can
> satisfy the use cases discussed thus far easily with existing Drupal APIs.
>
> http://en.wikipedia.org/wiki/UUID
>
> "A Universally Unique Identifier (UUID) is an identifier standard used in
> software construction, standardized by the Open Software Foundation (OSF) as
> part of the Distributed Computing Environment (DCE). The intent of UUIDs is
> to enable distributed systems to uniquely identify information without
> significant central coordination. Thus, anyone can create a UUID and use it
> to identify something with reasonable confidence that the identifier will
> never be unintentionally used by anyone for anything else. Information
> labeled with UUIDs can therefore be later combined into a single database
> without needing to resolve name conflicts. The most widespread use of this
> standard is in Microsoft's Globally Unique Identifiers (GUIDs). Other
> significant users include Linux's ext2/ext3 filesystem, LUKS encrypted
> partitions, GNOME, KDE, and Mac OS X, all of which use implementations
> derived from the uuid library found in the e2fsprogs package."
>

From alex at developmentseed.org  Mon Aug 11 14:56:41 2008
From: alex at developmentseed.org (Alex Barth)
Date: Mon, 11 Aug 2008 10:56:41 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
Message-ID: <A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>


On Aug 10, 2008, at 12:22 PM, Greg Dunlap wrote:
> On Sun, Aug 10, 2008 at 6:06 AM, Victor Kane <victorkane at gmail.com>  
> wrote:
>
> Alex Barth recently contact me about exactly this, having come to  
> the exact same conclusion. He has opened an issue in deploy's issue  
> queue:
>
> http://drupal.org/node/291921
>
> He himself wrote a module quite similar to Deploy called Ports which  
> is pretty interesting and abstracts import/export a bit beyond what  
> I did. Maybe he can chime in here about what he's done because I've  
> only taken really a cursory glance at it.
>

I'm happy that this discussion is coming up.

I started writing port module for generating installer profiles and  
was then pleasantly surprised to see similarities with Greg's deploy  
module.

At port module's core there is a very simple idea: provide a hook to  
let modules define a matching export and import function. Here is the  
ports hook definition for imagecache for example:

// Implementation of hook_ports()
function imagecache_ports() {
   $ports = array();
   $ports['imagecache_presets']['name'] = t('Image cache presets');
   $ports['imagecache_presets']['export callback'] =  
'imagecache_export_presets';
   $ports['imagecache_presets']['import callback'] =  
'imagecache_import_presets';
   $ports['imagecache_presets']['type'] = PORT_STRUCTURE; // not yet  
implemented
   $ports['imagecache_presets']['version'] = '1.68.2.3';  // not yet  
implemented
   return $ports;
}

This simple approach is pretty powerful, because it makes it really  
easy to generate a single export array that contains all the  
information for importing it on a target site. In its simplest  
applications, you can copy / paste this array to your target site or  
you can use it to generate install functions for an install profile   
(both operations currently supported by port module).

After doing a first proof of concept as a result of a client project,  
I saw how similar certain approaches in deploy module are and got in  
touch with Greg. I had another look at deploy module this weekend: I'm  
actually thinking that a deploy like module and a port like module  
could play very well together by port providing the structure in which  
modules should export and import configuration and deploy providing  
the XML-RPC integration, deployment functionality and the UI.

Another module that could be implemented on top of port module is the  
install profile wizard (recent discussion on a related thread: http://drupal.org/node/230059#comment-957328) 
.

That said, port is a proof of concept, this is the current status and  
limitations:

# Basic hook_ports() system defined
# UI for copy/paste deployment of export data
# UI for generating callable PHP functions
# on-behalf implementations for menus, user roles and permissions,  
module status, content types, imagecache, nodeprofile and spaces.
# while there is a flag for PORT_STRUCTURE and PORT_CONTENT I haven't  
thought deeper about content export/import - I'm just thinking that  
it's a very closely related problem
# while there's a slot for version number, port isn't handling any  
version comparisons atm
# there is no 'update' handling, no notion of mapping
# there is no way of exporting parts of a modules configuration yet.  
While modules can define more than one export / import pair, there's  
no way of exporting just a part of one export function. e. g. export  
only certain imagecache definitions, not all of them. this one should  
be easy.

Ideas for update handling in port: I'm leaning towards not dealing  
with it on this level. In the existing implementation modules would  
deal with create new vs update by themselves. I haven't thought much  
about this though and there might be a smart helper that port could  
provide so that we know on this level what's an update and what's new.

Plans for port: don't know yet. I'm in touch with Greg on deploy and I  
plan to get in touch with Boris Mann on install profile wizards. These  
are the two projects where I see overlap.

I'd be very curious to get your thoughts on port module's approach.

Check out the code here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/alex_b/port/

-

Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633





From mroswell at gmail.com  Mon Aug 11 15:12:18 2008
From: mroswell at gmail.com (Marjorie Roswell)
Date: Mon, 11 Aug 2008 11:12:18 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
	<A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
Message-ID: <aa0037c80808110812o58112ee8o959ca720ff02095a@mail.gmail.com>

ceardach has some awesome scripts for deployment.

http://ceardach.com/blog/tags/deployment
http://drupal.org/project/dbscripts

I haven't tried them yet. But figured I'd introduce them to this conversation.

Margie

From drupal at samboyer.org  Mon Aug 11 15:36:02 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Mon, 11 Aug 2008 10:36:02 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <aa0037c80808110812o58112ee8o959ca720ff02095a@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
	<aa0037c80808110812o58112ee8o959ca720ff02095a@mail.gmail.com>
Message-ID: <200808111036.03163.drupal@samboyer.org>

On Monday 11 August 2008 10:12:18 Marjorie Roswell wrote:
> ceardach has some awesome scripts for deployment.
>
> http://ceardach.com/blog/tags/deployment
> http://drupal.org/project/dbscripts
>
> I haven't tried them yet. But figured I'd introduce them to this
> conversation.
>
> Margie

She introduced them herself on Saturday =)

From adrian at bryght.com  Mon Aug 11 15:42:52 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Mon, 11 Aug 2008 17:42:52 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <aa0037c80808110812o58112ee8o959ca720ff02095a@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
	<A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
	<aa0037c80808110812o58112ee8o959ca720ff02095a@mail.gmail.com>
Message-ID: <3FE4A030-F0AD-4CD4-A442-3BBD9DEEB444@bryght.com>


On 11 Aug 2008, at 5:12 PM, Marjorie Roswell wrote:

> ceardach has some awesome scripts for deployment.
>
> http://ceardach.com/blog/tags/deployment
> http://drupal.org/project/dbscripts

One of the things i like about the 64 bit uid discussion going on in  
parallel, is it removes a lot of need
for the primary key trickery.

you can be sure that stuff you import/export has a unique key, and  
they don't have to be handled in contiguous blocks like
those scripts do it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080811/d08e950c/attachment.htm 

From mhaggerty-lists at trellon.com  Mon Aug 11 16:35:07 2008
From: mhaggerty-lists at trellon.com (Michael Haggerty)
Date: Mon, 11 Aug 2008 12:35:07 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
	<A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
Message-ID: <1586621E-B75A-4C13-9118-A932D1E2DE85@trellon.com>

Reading through this, I got the sense that not everyone is talking  
about the same thing. Something that may be useful is to break the  
problem down into the various areas of staging that need to be  
accounted for.

In Drupal, you really need to stage about 5 types of things (this list  
can grow a bit):

1) Themes - changes to a theme should not be made on a live server

2) Modules - esp. if you are developing a custom module, it should not  
be made on a production server.

3) Content - content CAN be staged on a production server with  
Drupal's publish and workflow features.

4) Dynamic Content - dynamic content cannot really be staged on a  
production server, from the standpoint that you are not going to see  
the different permutations of blocks while information is not published.

5) Users - if you are setting up a bunch of new users, staging them on  
a production server is not a good idea.

There are some strategies I have used in the past to accomplish all of  
these things. Each solution was specific to a client. Short  
description follows, and would love to hear everyone's feedback.

1) Staging themes / moving to production: we had a client who needed  
to alter the layout to specific pages in their site regularly for a 24  
hour period (then change everything back). We set up a staging server  
just for these takeovers. It had a physical reproduction of Drupal and  
the production database. The client would copy the theme under a  
different name, make adjustments to the CSS, and rsync it over to the  
production servers through a simple script.

Simply changing the theme was not a good idea for their purposes, they  
had a lot of blocks that were displaying on different pages in the  
application. We wrote a small module that duplicated records in the  
block table for the new theme, then implemented it. We also added some  
logic for doing this based on time of day.

2) Staging custom modules: the hardest part about staging custom  
modules is ensuring they work with live data. Selenium is a great tool  
for writing short functional tests, we did this extensively on a  
couple of sites and trained the client to construct and perform  
automated functional tests each time they pushed things into production.

3) Content Staging - One of the things people don't always understand  
about staging content is that there are ample workflow controls in  
Drupal to allow users to submit content for editing and review prior  
to publication. We have used workflow + views to create queues for  
content that needs to be reviewed, controlled access to those queues  
based on user role, and used views to track overall workflow  
statistics based on the time things were published. This has been  
effective for everything from small non-profits to large publishing  
sites.

4) Dynamic Content - Sometimes editors want to see the impact content  
will have on dynamically generated pages before publication. This  
comes up especially when we are using panels. Have not found a good  
overall solution and tend to work things out with clients on a case by  
case basis. Some strategies include writing small modules to export /  
import nodes after publication, using web services to grab nodes that  
have been published on a staging site, and cut and paste.

5) Use Staging - Occasionally, we have to import large numbers of  
users on a regular basis. Staging users is always a tricky issue, even  
when we are using open authentication standards like openid. The issue  
is typically getting the permissions right, it can become hard to use  
Drupal's user admin interface when we are talking about 5000 non- 
alphabetical user records. Typically, we write a script to do the  
import and modify user permissions.

This does not deal with moving code from dev into staging, but really  
is just about that QA that needs to happen before moving things into  
production.

M

On Aug 11, 2008, at 10:56 AM, Alex Barth wrote:

>
> On Aug 10, 2008, at 12:22 PM, Greg Dunlap wrote:
>> On Sun, Aug 10, 2008 at 6:06 AM, Victor Kane <victorkane at gmail.com>  
>> wrote:
>>
>> Alex Barth recently contact me about exactly this, having come to  
>> the exact same conclusion. He has opened an issue in deploy's issue  
>> queue:
>>
>> http://drupal.org/node/291921
>>
>> He himself wrote a module quite similar to Deploy called Ports  
>> which is pretty interesting and abstracts import/export a bit  
>> beyond what I did. Maybe he can chime in here about what he's done  
>> because I've only taken really a cursory glance at it.
>>
>
> I'm happy that this discussion is coming up.
>
> I started writing port module for generating installer profiles and  
> was then pleasantly surprised to see similarities with Greg's deploy  
> module.
>
> At port module's core there is a very simple idea: provide a hook to  
> let modules define a matching export and import function. Here is  
> the ports hook definition for imagecache for example:
>
> // Implementation of hook_ports()
> function imagecache_ports() {
>  $ports = array();
>  $ports['imagecache_presets']['name'] = t('Image cache presets');
>  $ports['imagecache_presets']['export callback'] =  
> 'imagecache_export_presets';
>  $ports['imagecache_presets']['import callback'] =  
> 'imagecache_import_presets';
>  $ports['imagecache_presets']['type'] = PORT_STRUCTURE; // not yet  
> implemented
>  $ports['imagecache_presets']['version'] = '1.68.2.3';  // not yet  
> implemented
>  return $ports;
> }
>
> This simple approach is pretty powerful, because it makes it really  
> easy to generate a single export array that contains all the  
> information for importing it on a target site. In its simplest  
> applications, you can copy / paste this array to your target site or  
> you can use it to generate install functions for an install profile   
> (both operations currently supported by port module).
>
> After doing a first proof of concept as a result of a client  
> project, I saw how similar certain approaches in deploy module are  
> and got in touch with Greg. I had another look at deploy module this  
> weekend: I'm actually thinking that a deploy like module and a port  
> like module could play very well together by port providing the  
> structure in which modules should export and import configuration  
> and deploy providing the XML-RPC integration, deployment  
> functionality and the UI.
>
> Another module that could be implemented on top of port module is  
> the install profile wizard (recent discussion on a related thread: http://drupal.org/node/230059#comment-957328) 
> .
>
> That said, port is a proof of concept, this is the current status  
> and limitations:
>
> # Basic hook_ports() system defined
> # UI for copy/paste deployment of export data
> # UI for generating callable PHP functions
> # on-behalf implementations for menus, user roles and permissions,  
> module status, content types, imagecache, nodeprofile and spaces.
> # while there is a flag for PORT_STRUCTURE and PORT_CONTENT I  
> haven't thought deeper about content export/import - I'm just  
> thinking that it's a very closely related problem
> # while there's a slot for version number, port isn't handling any  
> version comparisons atm
> # there is no 'update' handling, no notion of mapping
> # there is no way of exporting parts of a modules configuration yet.  
> While modules can define more than one export / import pair, there's  
> no way of exporting just a part of one export function. e. g. export  
> only certain imagecache definitions, not all of them. this one  
> should be easy.
>
> Ideas for update handling in port: I'm leaning towards not dealing  
> with it on this level. In the existing implementation modules would  
> deal with create new vs update by themselves. I haven't thought much  
> about this though and there might be a smart helper that port could  
> provide so that we know on this level what's an update and what's new.
>
> Plans for port: don't know yet. I'm in touch with Greg on deploy and  
> I plan to get in touch with Boris Mann on install profile wizards.  
> These are the two projects where I see overlap.
>
> I'd be very curious to get your thoughts on port module's approach.
>
> Check out the code here:
> http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/alex_b/port/
>
> -
>
> Alex Barth
> http://www.developmentseed.org/blog
> tel (202) 250-3633
>
>
>
>


From adrian at bryght.com  Mon Aug 11 16:38:30 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Mon, 11 Aug 2008 18:38:30 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <1586621E-B75A-4C13-9118-A932D1E2DE85@trellon.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
	<A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
	<1586621E-B75A-4C13-9118-A932D1E2DE85@trellon.com>
Message-ID: <FC000579-AB3D-4C01-BE72-3AD60C9A40F6@bryght.com>


On 11 Aug 2008, at 6:35 PM, Michael Haggerty wrote:

>
> 1) Themes - changes to a theme should not be made on a live server
>
> 2) Modules - esp. if you are developing a custom module, it should  
> not be made on a production server.
I group these into 'packages'.

they are even stored in the same table.


From drupal at samboyer.org  Mon Aug 11 18:51:31 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Mon, 11 Aug 2008 13:51:31 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <ff176450808110333w48763de6o62b7d359a3e5e071@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<200808101832.45916.drupal@samboyer.org>
	<ff176450808110333w48763de6o62b7d359a3e5e071@mail.gmail.com>
Message-ID: <200808111351.31349.drupal@samboyer.org>

On Monday 11 August 2008 05:33:49 Victor Kane wrote:
> The serialization and unserialization of data is included in my
> approach to the problem for the purposes of the independent
> transmission of nodes from one system to another, as in the case of
> one Drupal site availing itself of a node.save service on another
> Drupal site.
>
> It also has the purpose of guaranteeing insofar as is possible a text
> version of all entities, configurations, including exported views,
> content types, panels, hopefully menues and module configurations and
> exported variables, for the purposes of continued version control and
> hence deployment also (serialization to text, unserialization to
> deployment objective).
>
> Here of course, serialization and unserialization is not meant in the
> php function sense, and could include marshaling and unmarshaling to
> and from XML, and is a cross-language concept.
>
> Victor Kane
> http://awebfactory.com.ar

So my initial reaction was that this was actually a disadvantage - it seemed 
to introduce an extra layer of unnecessary complexity, as it requires pulling 
the data out of the db, coming up with a new storage format, then transferring 
that format and reintegrating it into another db. The backup and project-level 
revisioning control implications are interesting - but that's a wholly 
different axis from the crux of the deployment paradigm, where there's _one_ 
version.

However, on further reflection, I can see there being some strong arguments in 
either direction. Your approach, Victor, makes me drift back to the recent vcs 
thread on this list, as I can't imagine such a system being feasible and 
really scalable without the use  of something like (gasp!) git. Two basic 
reasons for that: 

1. Data integrity assurance: there's nothing like a SHA1 hash to ensure that 
nothing gets corrupted in all the combining/recombining of data through and 
around various servers. And then there's the whole content-addressable 
filesystem bit - I'd conjecture that it would make git exceptionally 
proficient at handling either database dumps or tons of data structured from 
'export' functionality, whichever the case may be. I imagine Kathleen might be 
able to speak more to that. 

2. Security and logic (and speed): if run on a git backend, I'd speculate that 
we could use project-specific ssh keys to encrypt all the synchronizations 
(although that obviously brings up a host of other potential 
requirements/issues). On the logic end, we could build on top of git's system 
for organizing sets of commits to allow for different 'types' of syncs (i.e., 
you're working with different datasets when doing dev <=> qa vs. when you're 
working with live <=> staging). As for speed...well, I'll just call that a 
hunch =)

This approach would require a _lot_ of coding, though. The more immediate-term 
solution that still makes the most sense to me is one where we let modules 
work straight from the data as it exists in the db, and define some logic for 
handling synchronizations that the deploy API can manage. But if all the 
systems are to be implemented...well, then it probably means a pluggable 
Deploy API that allows for different subsystems to handle different segments 
of the overall process.

Sam

From victorkane at gmail.com  Mon Aug 11 19:38:27 2008
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 11 Aug 2008 16:38:27 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808111351.31349.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<200808101832.45916.drupal@samboyer.org>
	<ff176450808110333w48763de6o62b7d359a3e5e071@mail.gmail.com>
	<200808111351.31349.drupal@samboyer.org>
Message-ID: <ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>

Your points are interestng, but I think there may be a lot to what
Greg Dunlap is recommending in terms of thinking in Drupal logic terms
and not database terms.

The image I have in my mind is that the database is kind of a
two-dimensional projection of three dimensions; that is, there may be
many hidden relationships in the process side of things that have to
be taken into account for deployment, especially since the database is
usually considered in purely MySql terms, that is, with fully
transparent relationships between tables.

But given concrete client driven circumstances, of course, in a given
instance with a given set of priorities, I can easily see how what you
are saying could make sense.

Victor

On Mon, Aug 11, 2008 at 3:51 PM, Sam Boyer <drupal at samboyer.org> wrote:
> On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> The serialization and unserialization of data is included in my
>> approach to the problem for the purposes of the independent
>> transmission of nodes from one system to another, as in the case of
>> one Drupal site availing itself of a node.save service on another
>> Drupal site.
>>
>> It also has the purpose of guaranteeing insofar as is possible a text
>> version of all entities, configurations, including exported views,
>> content types, panels, hopefully menues and module configurations and
>> exported variables, for the purposes of continued version control and
>> hence deployment also (serialization to text, unserialization to
>> deployment objective).
>>
>> Here of course, serialization and unserialization is not meant in the
>> php function sense, and could include marshaling and unmarshaling to
>> and from XML, and is a cross-language concept.
>>
>> Victor Kane
>> http://awebfactory.com.ar
>
> So my initial reaction was that this was actually a disadvantage - it seemed
> to introduce an extra layer of unnecessary complexity, as it requires pulling
> the data out of the db, coming up with a new storage format, then transferring
> that format and reintegrating it into another db. The backup and project-level
> revisioning control implications are interesting - but that's a wholly
> different axis from the crux of the deployment paradigm, where there's _one_
> version.
>
> However, on further reflection, I can see there being some strong arguments in
> either direction. Your approach, Victor, makes me drift back to the recent vcs
> thread on this list, as I can't imagine such a system being feasible and
> really scalable without the use  of something like (gasp!) git. Two basic
> reasons for that:
>
> 1. Data integrity assurance: there's nothing like a SHA1 hash to ensure that
> nothing gets corrupted in all the combining/recombining of data through and
> around various servers. And then there's the whole content-addressable
> filesystem bit - I'd conjecture that it would make git exceptionally
> proficient at handling either database dumps or tons of data structured from
> 'export' functionality, whichever the case may be. I imagine Kathleen might be
> able to speak more to that.
>
> 2. Security and logic (and speed): if run on a git backend, I'd speculate that
> we could use project-specific ssh keys to encrypt all the synchronizations
> (although that obviously brings up a host of other potential
> requirements/issues). On the logic end, we could build on top of git's system
> for organizing sets of commits to allow for different 'types' of syncs (i.e.,
> you're working with different datasets when doing dev <=> qa vs. when you're
> working with live <=> staging). As for speed...well, I'll just call that a
> hunch =)
>
> This approach would require a _lot_ of coding, though. The more immediate-term
> solution that still makes the most sense to me is one where we let modules
> work straight from the data as it exists in the db, and define some logic for
> handling synchronizations that the deploy API can manage. But if all the
> systems are to be implemented...well, then it probably means a pluggable
> Deploy API that allows for different subsystems to handle different segments
> of the overall process.
>
> Sam
>

From katherine at esquaredworkshops.com  Mon Aug 11 19:43:32 2008
From: katherine at esquaredworkshops.com (Katherine Senzee)
Date: Mon, 11 Aug 2008 12:43:32 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <3FE4A030-F0AD-4CD4-A442-3BBD9DEEB444@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
	<A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
	<aa0037c80808110812o58112ee8o959ca720ff02095a@mail.gmail.com>
	<3FE4A030-F0AD-4CD4-A442-3BBD9DEEB444@bryght.com>
Message-ID: <da965fc60808111243r1781077fmb0101160b91cb01e@mail.gmail.com>

On Mon, Aug 11, 2008 at 8:42 AM, Adrian Rossouw <adrian at bryght.com> wrote:
> One of the things i like about the 64 bit uid discussion going on in
> parallel, is it removes a lot of need for the primary key trickery.

How complicated would it be to move from sequential ids to UUIDs? This
is something I care about more for aesthetic than technical reasons.
I'd like nodes/users/etc. to be less obviously sequential (hey, look
at that UID, what a n00b).

-- 
Katherine Senzee (ksenzee)
esquaredworkshops.com

From gdd at heyrocker.com  Mon Aug 11 20:25:28 2008
From: gdd at heyrocker.com (Greg Dunlap)
Date: Mon, 11 Aug 2008 13:25:28 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <da965fc60808111243r1781077fmb0101160b91cb01e@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
	<A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
	<aa0037c80808110812o58112ee8o959ca720ff02095a@mail.gmail.com>
	<3FE4A030-F0AD-4CD4-A442-3BBD9DEEB444@bryght.com>
	<da965fc60808111243r1781077fmb0101160b91cb01e@mail.gmail.com>
Message-ID: <7e4a3f280808111325n445a61f2gab9e348f086b617d@mail.gmail.com>

It would be extremely difficult. For instance:

- Upgrading an existing site would be virtually impossible. Every id would
change, plus you would have to update every foreign key reference to every
id throughout core AND contrib.
- For sites not running pathauto, every URL would change.

That's just a couple of the purely technical reasons. I would also add that
a conscious decision was made to move away from PHP-generated IDs in Drupal
6, and it seems to me very unlikely that this will be reversed. There are
several issues around this in the queues. It would offer us up some great
functionality but I just don't see it happening.

Also I like knowing who the n00bs are :P (Hi, my name is Greg Dunlap and I'm
a n00b.)

On Mon, Aug 11, 2008 at 12:43 PM, Katherine Senzee <
katherine at esquaredworkshops.com> wrote:

> On Mon, Aug 11, 2008 at 8:42 AM, Adrian Rossouw <adrian at bryght.com> wrote:
> > One of the things i like about the 64 bit uid discussion going on in
> > parallel, is it removes a lot of need for the primary key trickery.
>
> How complicated would it be to move from sequential ids to UUIDs? This
> is something I care about more for aesthetic than technical reasons.
> I'd like nodes/users/etc. to be less obviously sequential (hey, look
> at that UID, what a n00b).
>
> --
> Katherine Senzee (ksenzee)
> esquaredworkshops.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080811/7ef7db74/attachment.htm 

From drupal at samboyer.org  Mon Aug 11 21:09:44 2008
From: drupal at samboyer.org (Sam Boyer)
Date: Mon, 11 Aug 2008 16:09:44 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<200808111351.31349.drupal@samboyer.org>
	<ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
Message-ID: <200808111609.44411.drupal@samboyer.org>

On Monday 11 August 2008 14:38:27 Victor Kane wrote:
> Your points are interestng, but I think there may be a lot to what
> Greg Dunlap is recommending in terms of thinking in Drupal logic terms
> and not database terms.
>
> The image I have in my mind is that the database is kind of a
> two-dimensional projection of three dimensions; that is, there may be
> many hidden relationships in the process side of things that have to
> be taken into account for deployment, especially since the database is
> usually considered in purely MySql terms, that is, with fully
> transparent relationships between tables.
>
> But given concrete client driven circumstances, of course, in a given
> instance with a given set of priorities, I can easily see how what you
> are saying could make sense.
>
> Victor

At this point then, I suspect we're talking past each other. First, are you 
referring only to the direct-database sync point that I made, or is that also 
in reference to the drupal-object exporting, git-managed system? If it's the 
latter as well as the former, then we've _really_ diverged.

Just because I'm suggesting that there are direct-database syncing solutions 
possible does NOT mean that I'm not thinking in Drupal logic terms. Let me try 
a different, potentially clearer way:

In your approach, it seems to me that the goal is to use existing drupal API 
functions - let's use nodes, so node_load() - to fully build a node object. 
That object is then exported to code, at which point we can do things with 
vcs, etc. During a deployment, we parse in that code and utilize the API 
counterpart to our data-getter function, so node_save(), to push the 
information into the database. Before node_save() is actually run, however,  
we can use something like a GUID system to change primary keys as necessary so 
that we've got the node from server A going into the right associated node on 
server B.

As I said, I can see arguments for that, particularly if it utilizes a git 
backend. And only differs from what I'm proposing in a few ways.

What I'm suggesting stems from Greg's original point about a GUID for every 
'thing'. 'Things' being, to use your words:

On Monday 11 August 2008 05:33:49 Victor Kane wrote:
> ...
> all entities, configurations, including exported views, content types,
> panels, hopefully menues and module configurations and
> exported variables
> ...

Because I agree completely that the _only_ way to arrive at a solution that 
works for drupal is to think in terms of the 'things' (I'm going to say 
'items' from here on out) it makes - not to try to just grab bits of data from 
here and there and hope it all lines up on the other end. I've always thought 
that, and am pretty sure I always will.

My proposal is for a deploy API that would let modules define what these items 
are, and then define a set of behaviors for managing the deployment of those 
items across a variety of different circumstances. For our concrete example, I 
suspect the _first_ thing I'd do in the synchro handler for nodes is to call 
node_load(), then follow it up with some internal logic that...I dunno, there 
are a lot of ways we could go from there. It could dynamically construct a 
delta from the last sync time with the remote server; it could just fire over 
the whole node object. If extension modules need to do something that the node 
module's deploy handler couldn't work out, no problem - those modules just 
need to register their interest in deploy transactions related to the GUID for 
that particular item. On the receiving end, the node module's deploy API 
implementation knows what to expect coming through the pipe and handles it 
accordingly - maybe through node_save(), maybe not.

The advantage here, as I see it, is the potential to drill down _very_ quickly 
on exactly what should be checked during a given changeset. Very quickly as 
in, potentially, a single query. I can't picture the schema for the deploy 
items table, so it may take more, but it could be as simple as a single SELECT 
query that grabs all the items which have been changed/created since the last 
deploy txn, and that that particular deploy txn is interested in (again, a dev 
<=> qa txn != staging <=> live txn), and then it's a simple question of 
iterating through modules that have something to say about how each of the 
items is deployed.

As I said, I can see ways that a git-driven system can probably provide 
similar speed when it comes to drilling down to what items need to be 
considered in a given txn; also, a git-driven system has the added benefit of 
being able to, even when your local system offline, still provide the entire 
version history on demand for _each server_ you've ever connected with on that 
project. Well, assuming your remote git branches are up to date.

As far as I can tell, this is really the kind of thing you're talking about 
when you say:
> ...the database is kind of a two-dimensional projection of three dimensions
> that is, there may be many hidden relationships in the process side of
> things that have to be taken into account for deployment...

I can think of two very different ways of interpreting that metaphor, both of 
which are applicable to the topic at hand. I'm hoping, though, that this 
explanation finally does make clear that I'm _not_ thinking along the lines of 
'how do we make an sqldump better?', but instead about methods for making 
deployment a process that's as smart about drupal data as drupal itself is.

s

>
> On Mon, Aug 11, 2008 at 3:51 PM, Sam Boyer <drupal at samboyer.org> wrote:
> > On Monday 11 August 2008 05:33:49 Victor Kane wrote:
> >> The serialization and unserialization of data is included in my
> >> approach to the problem for the purposes of the independent
> >> transmission of nodes from one system to another, as in the case of
> >> one Drupal site availing itself of a node.save service on another
> >> Drupal site.
> >>
> >> It also has the purpose of guaranteeing insofar as is possible a text
> >> version of all entities, configurations, including exported views,
> >> content types, panels, hopefully menues and module configurations and
> >> exported variables, for the purposes of continued version control and
> >> hence deployment also (serialization to text, unserialization to
> >> deployment objective).
> >>
> >> Here of course, serialization and unserialization is not meant in the
> >> php function sense, and could include marshaling and unmarshaling to
> >> and from XML, and is a cross-language concept.
> >>
> >> Victor Kane
> >> http://awebfactory.com.ar
> >
> > So my initial reaction was that this was actually a disadvantage - it
> > seemed to introduce an extra layer of unnecessary complexity, as it
> > requires pulling the data out of the db, coming up with a new storage
> > format, then transferring that format and reintegrating it into another
> > db. The backup and project-level revisioning control implications are
> > interesting - but that's a wholly different axis from the crux of the
> > deployment paradigm, where there's _one_ version.
> >
> > However, on further reflection, I can see there being some strong
> > arguments in either direction. Your approach, Victor, makes me drift back
> > to the recent vcs thread on this list, as I can't imagine such a system
> > being feasible and really scalable without the use  of something like
> > (gasp!) git. Two basic reasons for that:
> >
> > 1. Data integrity assurance: there's nothing like a SHA1 hash to ensure
> > that nothing gets corrupted in all the combining/recombining of data
> > through and around various servers. And then there's the whole
> > content-addressable filesystem bit - I'd conjecture that it would make
> > git exceptionally proficient at handling either database dumps or tons of
> > data structured from 'export' functionality, whichever the case may be. I
> > imagine Kathleen might be able to speak more to that.
> >
> > 2. Security and logic (and speed): if run on a git backend, I'd speculate
> > that we could use project-specific ssh keys to encrypt all the
> > synchronizations (although that obviously brings up a host of other
> > potential
> > requirements/issues). On the logic end, we could build on top of git's
> > system for organizing sets of commits to allow for different 'types' of
> > syncs (i.e., you're working with different datasets when doing dev <=> qa
> > vs. when you're working with live <=> staging). As for speed...well, I'll
> > just call that a hunch =)
> >
> > This approach would require a _lot_ of coding, though. The more
> > immediate-term solution that still makes the most sense to me is one
> > where we let modules work straight from the data as it exists in the db,
> > and define some logic for handling synchronizations that the deploy API
> > can manage. But if all the systems are to be implemented...well, then it
> > probably means a pluggable Deploy API that allows for different
> > subsystems to handle different segments of the overall process.
> >
> > Sam


From victorkane at gmail.com  Mon Aug 11 21:25:23 2008
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 11 Aug 2008 18:25:23 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808111609.44411.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<200808111351.31349.drupal@samboyer.org>
	<ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
	<200808111609.44411.drupal@samboyer.org>
Message-ID: <ff176450808111425t549f8cc2xa681e596a60c55b@mail.gmail.com>

You make a lot of good points. I guess from here on in, this
discussion should move to the prototype arena, and working together
with Greg, Alex, and others to see what progress can be made.

Victor Kane

On Mon, Aug 11, 2008 at 6:09 PM, Sam Boyer <drupal at samboyer.org> wrote:
> On Monday 11 August 2008 14:38:27 Victor Kane wrote:
>> Your points are interestng, but I think there may be a lot to what
>> Greg Dunlap is recommending in terms of thinking in Drupal logic terms
>> and not database terms.
>>
>> The image I have in my mind is that the database is kind of a
>> two-dimensional projection of three dimensions; that is, there may be
>> many hidden relationships in the process side of things that have to
>> be taken into account for deployment, especially since the database is
>> usually considered in purely MySql terms, that is, with fully
>> transparent relationships between tables.
>>
>> But given concrete client driven circumstances, of course, in a given
>> instance with a given set of priorities, I can easily see how what you
>> are saying could make sense.
>>
>> Victor
>
> At this point then, I suspect we're talking past each other. First, are you
> referring only to the direct-database sync point that I made, or is that also
> in reference to the drupal-object exporting, git-managed system? If it's the
> latter as well as the former, then we've _really_ diverged.
>
> Just because I'm suggesting that there are direct-database syncing solutions
> possible does NOT mean that I'm not thinking in Drupal logic terms. Let me try
> a different, potentially clearer way:
>
> In your approach, it seems to me that the goal is to use existing drupal API
> functions - let's use nodes, so node_load() - to fully build a node object.
> That object is then exported to code, at which point we can do things with
> vcs, etc. During a deployment, we parse in that code and utilize the API
> counterpart to our data-getter function, so node_save(), to push the
> information into the database. Before node_save() is actually run, however,
> we can use something like a GUID system to change primary keys as necessary so
> that we've got the node from server A going into the right associated node on
> server B.
>
> As I said, I can see arguments for that, particularly if it utilizes a git
> backend. And only differs from what I'm proposing in a few ways.
>
> What I'm suggesting stems from Greg's original point about a GUID for every
> 'thing'. 'Things' being, to use your words:
>
> On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> ...
>> all entities, configurations, including exported views, content types,
>> panels, hopefully menues and module configurations and
>> exported variables
>> ...
>
> Because I agree completely that the _only_ way to arrive at a solution that
> works for drupal is to think in terms of the 'things' (I'm going to say
> 'items' from here on out) it makes - not to try to just grab bits of data from
> here and there and hope it all lines up on the other end. I've always thought
> that, and am pretty sure I always will.
>
> My proposal is for a deploy API that would let modules define what these items
> are, and then define a set of behaviors for managing the deployment of those
> items across a variety of different circumstances. For our concrete example, I
> suspect the _first_ thing I'd do in the synchro handler for nodes is to call
> node_load(), then follow it up with some internal logic that...I dunno, there
> are a lot of ways we could go from there. It could dynamically construct a
> delta from the last sync time with the remote server; it could just fire over
> the whole node object. If extension modules need to do something that the node
> module's deploy handler couldn't work out, no problem - those modules just
> need to register their interest in deploy transactions related to the GUID for
> that particular item. On the receiving end, the node module's deploy API
> implementation knows what to expect coming through the pipe and handles it
> accordingly - maybe through node_save(), maybe not.
>
> The advantage here, as I see it, is the potential to drill down _very_ quickly
> on exactly what should be checked during a given changeset. Very quickly as
> in, potentially, a single query. I can't picture the schema for the deploy
> items table, so it may take more, but it could be as simple as a single SELECT
> query that grabs all the items which have been changed/created since the last
> deploy txn, and that that particular deploy txn is interested in (again, a dev
> <=> qa txn != staging <=> live txn), and then it's a simple question of
> iterating through modules that have something to say about how each of the
> items is deployed.
>
> As I said, I can see ways that a git-driven system can probably provide
> similar speed when it comes to drilling down to what items need to be
> considered in a given txn; also, a git-driven system has the added benefit of
> being able to, even when your local system offline, still provide the entire
> version history on demand for _each server_ you've ever connected with on that
> project. Well, assuming your remote git branches are up to date.
>
> As far as I can tell, this is really the kind of thing you're talking about
> when you say:
>> ...the database is kind of a two-dimensional projection of three dimensions
>> that is, there may be many hidden relationships in the process side of
>> things that have to be taken into account for deployment...
>
> I can think of two very different ways of interpreting that metaphor, both of
> which are applicable to the topic at hand. I'm hoping, though, that this
> explanation finally does make clear that I'm _not_ thinking along the lines of
> 'how do we make an sqldump better?', but instead about methods for making
> deployment a process that's as smart about drupal data as drupal itself is.
>
> s
>
>>
>> On Mon, Aug 11, 2008 at 3:51 PM, Sam Boyer <drupal at samboyer.org> wrote:
>> > On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> >> The serialization and unserialization of data is included in my
>> >> approach to the problem for the purposes of the independent
>> >> transmission of nodes from one system to another, as in the case of
>> >> one Drupal site availing itself of a node.save service on another
>> >> Drupal site.
>> >>
>> >> It also has the purpose of guaranteeing insofar as is possible a text
>> >> version of all entities, configurations, including exported views,
>> >> content types, panels, hopefully menues and module configurations and
>> >> exported variables, for the purposes of continued version control and
>> >> hence deployment also (serialization to text, unserialization to
>> >> deployment objective).
>> >>
>> >> Here of course, serialization and unserialization is not meant in the
>> >> php function sense, and could include marshaling and unmarshaling to
>> >> and from XML, and is a cross-language concept.
>> >>
>> >> Victor Kane
>> >> http://awebfactory.com.ar
>> >
>> > So my initial reaction was that this was actually a disadvantage - it
>> > seemed to introduce an extra layer of unnecessary complexity, as it
>> > requires pulling the data out of the db, coming up with a new storage
>> > format, then transferring that format and reintegrating it into another
>> > db. The backup and project-level revisioning control implications are
>> > interesting - but that's a wholly different axis from the crux of the
>> > deployment paradigm, where there's _one_ version.
>> >
>> > However, on further reflection, I can see there being some strong
>> > arguments in either direction. Your approach, Victor, makes me drift back
>> > to the recent vcs thread on this list, as I can't imagine such a system
>> > being feasible and really scalable without the use  of something like
>> > (gasp!) git. Two basic reasons for that:
>> >
>> > 1. Data integrity assurance: there's nothing like a SHA1 hash to ensure
>> > that nothing gets corrupted in all the combining/recombining of data
>> > through and around various servers. And then there's the whole
>> > content-addressable filesystem bit - I'd conjecture that it would make
>> > git exceptionally proficient at handling either database dumps or tons of
>> > data structured from 'export' functionality, whichever the case may be. I
>> > imagine Kathleen might be able to speak more to that.
>> >
>> > 2. Security and logic (and speed): if run on a git backend, I'd speculate
>> > that we could use project-specific ssh keys to encrypt all the
>> > synchronizations (although that obviously brings up a host of other
>> > potential
>> > requirements/issues). On the logic end, we could build on top of git's
>> > system for organizing sets of commits to allow for different 'types' of
>> > syncs (i.e., you're working with different datasets when doing dev <=> qa
>> > vs. when you're working with live <=> staging). As for speed...well, I'll
>> > just call that a hunch =)
>> >
>> > This approach would require a _lot_ of coding, though. The more
>> > immediate-term solution that still makes the most sense to me is one
>> > where we let modules work straight from the data as it exists in the db,
>> > and define some logic for handling synchronizations that the deploy API
>> > can manage. But if all the systems are to be implemented...well, then it
>> > probably means a pluggable Deploy API that allows for different
>> > subsystems to handle different segments of the overall process.
>> >
>> > Sam
>
>

From victorkane at gmail.com  Mon Aug 11 21:36:08 2008
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 11 Aug 2008 18:36:08 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808111609.44411.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<200808111351.31349.drupal@samboyer.org>
	<ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
	<200808111609.44411.drupal@samboyer.org>
Message-ID: <ff176450808111436l182534fse5e2187e95b6d1fa@mail.gmail.com>

You make a lot of good points. I guess from here on in, this
discussion should move to the prototype arena, and working together
with Greg, Alex, and others to see what progress can be made.

Victor Kane

On Mon, Aug 11, 2008 at 6:09 PM, Sam Boyer <drupal at samboyer.org> wrote:
> On Monday 11 August 2008 14:38:27 Victor Kane wrote:
>> Your points are interestng, but I think there may be a lot to what
>> Greg Dunlap is recommending in terms of thinking in Drupal logic terms
>> and not database terms.
>>
>> The image I have in my mind is that the database is kind of a
>> two-dimensional projection of three dimensions; that is, there may be
>> many hidden relationships in the process side of things that have to
>> be taken into account for deployment, especially since the database is
>> usually considered in purely MySql terms, that is, with fully
>> transparent relationships between tables.
>>
>> But given concrete client driven circumstances, of course, in a given
>> instance with a given set of priorities, I can easily see how what you
>> are saying could make sense.
>>
>> Victor
>
> At this point then, I suspect we're talking past each other. First, are you
> referring only to the direct-database sync point that I made, or is that also
> in reference to the drupal-object exporting, git-managed system? If it's the
> latter as well as the former, then we've _really_ diverged.
>
> Just because I'm suggesting that there are direct-database syncing solutions
> possible does NOT mean that I'm not thinking in Drupal logic terms. Let me try
> a different, potentially clearer way:
>
> In your approach, it seems to me that the goal is to use existing drupal API
> functions - let's use nodes, so node_load() - to fully build a node object.
> That object is then exported to code, at which point we can do things with
> vcs, etc. During a deployment, we parse in that code and utilize the API
> counterpart to our data-getter function, so node_save(), to push the
> information into the database. Before node_save() is actually run, however,
> we can use something like a GUID system to change primary keys as necessary so
> that we've got the node from server A going into the right associated node on
> server B.
>
> As I said, I can see arguments for that, particularly if it utilizes a git
> backend. And only differs from what I'm proposing in a few ways.
>
> What I'm suggesting stems from Greg's original point about a GUID for every
> 'thing'. 'Things' being, to use your words:
>
> On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> ...
>> all entities, configurations, including exported views, content types,
>> panels, hopefully menues and module configurations and
>> exported variables
>> ...
>
> Because I agree completely that the _only_ way to arrive at a solution that
> works for drupal is to think in terms of the 'things' (I'm going to say
> 'items' from here on out) it makes - not to try to just grab bits of data from
> here and there and hope it all lines up on the other end. I've always thought
> that, and am pretty sure I always will.
>
> My proposal is for a deploy API that would let modules define what these items
> are, and then define a set of behaviors for managing the deployment of those
> items across a variety of different circumstances. For our concrete example, I
> suspect the _first_ thing I'd do in the synchro handler for nodes is to call
> node_load(), then follow it up with some internal logic that...I dunno, there
> are a lot of ways we could go from there. It could dynamically construct a
> delta from the last sync time with the remote server; it could just fire over
> the whole node object. If extension modules need to do something that the node
> module's deploy handler couldn't work out, no problem - those modules just
> need to register their interest in deploy transactions related to the GUID for
> that particular item. On the receiving end, the node module's deploy API
> implementation knows what to expect coming through the pipe and handles it
> accordingly - maybe through node_save(), maybe not.
>
> The advantage here, as I see it, is the potential to drill down _very_ quickly
> on exactly what should be checked during a given changeset. Very quickly as
> in, potentially, a single query. I can't picture the schema for the deploy
> items table, so it may take more, but it could be as simple as a single SELECT
> query that grabs all the items which have been changed/created since the last
> deploy txn, and that that particular deploy txn is interested in (again, a dev
> <=> qa txn != staging <=> live txn), and then it's a simple question of
> iterating through modules that have something to say about how each of the
> items is deployed.
>
> As I said, I can see ways that a git-driven system can probably provide
> similar speed when it comes to drilling down to what items need to be
> considered in a given txn; also, a git-driven system has the added benefit of
> being able to, even when your local system offline, still provide the entire
> version history on demand for _each server_ you've ever connected with on that
> project. Well, assuming your remote git branches are up to date.
>
> As far as I can tell, this is really the kind of thing you're talking about
> when you say:
>> ...the database is kind of a two-dimensional projection of three dimensions
>> that is, there may be many hidden relationships in the process side of
>> things that have to be taken into account for deployment...
>
> I can think of two very different ways of interpreting that metaphor, both of
> which are applicable to the topic at hand. I'm hoping, though, that this
> explanation finally does make clear that I'm _not_ thinking along the lines of
> 'how do we make an sqldump better?', but instead about methods for making
> deployment a process that's as smart about drupal data as drupal itself is.
>
> s
>
>>
>> On Mon, Aug 11, 2008 at 3:51 PM, Sam Boyer <drupal at samboyer.org> wrote:
>> > On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> >> The serialization and unserialization of data is included in my
>> >> approach to the problem for the purposes of the independent
>> >> transmission of nodes from one system to another, as in the case of
>> >> one Drupal site availing itself of a node.save service on another
>> >> Drupal site.
>> >>
>> >> It also has the purpose of guaranteeing insofar as is possible a text
>> >> version of all entities, configurations, including exported views,
>> >> content types, panels, hopefully menues and module configurations and
>> >> exported variables, for the purposes of continued version control and
>> >> hence deployment also (serialization to text, unserialization to
>> >> deployment objective).
>> >>
>> >> Here of course, serialization and unserialization is not meant in the
>> >> php function sense, and could include marshaling and unmarshaling to
>> >> and from XML, and is a cross-language concept.
>> >>
>> >> Victor Kane
>> >> http://awebfactory.com.ar
>> >
>> > So my initial reaction was that this was actually a disadvantage - it
>> > seemed to introduce an extra layer of unnecessary complexity, as it
>> > requires pulling the data out of the db, coming up with a new storage
>> > format, then transferring that format and reintegrating it into another
>> > db. The backup and project-level revisioning control implications are
>> > interesting - but that's a wholly different axis from the crux of the
>> > deployment paradigm, where there's _one_ version.
>> >
>> > However, on further reflection, I can see there being some strong
>> > arguments in either direction. Your approach, Victor, makes me drift back
>> > to the recent vcs thread on this list, as I can't imagine such a system
>> > being feasible and really scalable without the use  of something like
>> > (gasp!) git. Two basic reasons for that:
>> >
>> > 1. Data integrity assurance: there's nothing like a SHA1 hash to ensure
>> > that nothing gets corrupted in all the combining/recombining of data
>> > through and around various servers. And then there's the whole
>> > content-addressable filesystem bit - I'd conjecture that it would make
>> > git exceptionally proficient at handling either database dumps or tons of
>> > data structured from 'export' functionality, whichever the case may be. I
>> > imagine Kathleen might be able to speak more to that.
>> >
>> > 2. Security and logic (and speed): if run on a git backend, I'd speculate
>> > that we could use project-specific ssh keys to encrypt all the
>> > synchronizations (although that obviously brings up a host of other
>> > potential
>> > requirements/issues). On the logic end, we could build on top of git's
>> > system for organizing sets of commits to allow for different 'types' of
>> > syncs (i.e., you're working with different datasets when doing dev <=> qa
>> > vs. when you're working with live <=> staging). As for speed...well, I'll
>> > just call that a hunch =)
>> >
>> > This approach would require a _lot_ of coding, though. The more
>> > immediate-term solution that still makes the most sense to me is one
>> > where we let modules work straight from the data as it exists in the db,
>> > and define some logic for handling synchronizations that the deploy API
>> > can manage. But if all the systems are to be implemented...well, then it
>> > probably means a pluggable Deploy API that allows for different
>> > subsystems to handle different segments of the overall process.
>> >
>> > Sam
>
>

From victorkane at gmail.com  Mon Aug 11 21:40:14 2008
From: victorkane at gmail.com (victorkane at gmail.com)
Date: Mon, 11 Aug 2008 18:40:14 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808111609.44411.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<200808111351.31349.drupal@samboyer.org>
	<ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
	<200808111609.44411.drupal@samboyer.org>
Message-ID: <ff176450808111440ifcce3daw5cc261b8a8cb4fb2@mail.gmail.com>

You make a lot of good points. I guess from here on in, this discussion should move to the prototype arena, and working together with Greg, Alex, and others to see what progress can be made.



On Mon, Aug 11, 2008 at 6:09 PM, Sam Boyer <drupal at samboyer.org> wrote:
> On Monday 11 August 2008 14:38:27 Victor Kane wrote:
>> Your points are interestng, but I think there may be a lot to what
>> Greg Dunlap is recommending in terms of thinking in Drupal logic terms
>> and not database terms.
>>
>> The image I have in my mind is that the database is kind of a
>> two-dimensional projection of three dimensions; that is, there may be
>> many hidden relationships in the process side of things that have to
>> be taken into account for deployment, especially since the database is
>> usually considered in purely MySql terms, that is, with fully
>> transparent relationships between tables.
>>
>> But given concrete client driven circumstances, of course, in a given
>> instance with a given set of priorities, I can easily see how what you
>> are saying could make sense.
>>
>> Victor
>
> At this point then, I suspect we're talking past each other. First, are you
> referring only to the direct-database sync point that I made, or is that also
> in reference to the drupal-object exporting, git-managed system? If it's the
> latter as well as the former, then we've _really_ diverged.
>
> Just because I'm suggesting that there are direct-database syncing solutions
> possible does NOT mean that I'm not thinking in Drupal logic terms. Let me try
> a different, potentially clearer way:
>
> In your approach, it seems to me that the goal is to use existing drupal API
> functions - let's use nodes, so node_load() - to fully build a node object.
> That object is then exported to code, at which point we can do things with
> vcs, etc. During a deployment, we parse in that code and utilize the API
> counterpart to our data-getter function, so node_save(), to push the
> information into the database. Before node_save() is actually run, however,
> we can use something like a GUID system to change primary keys as necessary so
> that we've got the node from server A going into the right associated node on
> server B.
>
> As I said, I can see arguments for that, particularly if it utilizes a git
> backend. And only differs from what I'm proposing in a few ways.
>
> What I'm suggesting stems from Greg's original point about a GUID for every
> 'thing'. 'Things' being, to use your words:
>
> On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> ...
>> all entities, configurations, including exported views, content types,
>> panels, hopefully menues and module configurations and
>> exported variables
>> ...
>
> Because I agree completely that the _only_ way to arrive at a solution that
> works for drupal is to think in terms of the 'things' (I'm going to say
> 'items' from here on out) it makes - not to try to just grab bits of data from
> here and there and hope it all lines up on the other end. I've always thought
> that, and am pretty sure I always will.
>
> My proposal is for a deploy API that would let modules define what these items
> are, and then define a set of behaviors for managing the deployment of those
> items across a variety of different circumstances. For our concrete example, I
> suspect the _first_ thing I'd do in the synchro handler for nodes is to call
> node_load(), then follow it up with some internal logic that...I dunno, there
> are a lot of ways we could go from there. It could dynamically construct a
> delta from the last sync time with the remote server; it could just fire over
> the whole node object. If extension modules need to do something that the node
> module's deploy handler couldn't work out, no problem - those modules just
> need to register their interest in deploy transactions related to the GUID for
> that particular item. On the receiving end, the node module's deploy API
> implementation knows what to expect coming through the pipe and handles it
> accordingly - maybe through node_save(), maybe not.
>
> The advantage here, as I see it, is the potential to drill down _very_ quickly
> on exactly what should be checked during a given changeset. Very quickly as
> in, potentially, a single query. I can't picture the schema for the deploy
> items table, so it may take more, but it could be as simple as a single SELECT
> query that grabs all the items which have been changed/created since the last
> deploy txn, and that that particular deploy txn is interested in (again, a dev
> <=> qa txn != staging <=> live txn), and then it's a simple question of
> iterating through modules that have something to say about how each of the
> items is deployed.
>
> As I said, I can see ways that a git-driven system can probably provide
> similar speed when it comes to drilling down to what items need to be
> considered in a given txn; also, a git-driven system has the added benefit of
> being able to, even when your local system offline, still provide the entire
> version history on demand for _each server_ you've ever connected with on that
> project. Well, assuming your remote git branches are up to date.
>
> As far as I can tell, this is really the kind of thing you're talking about
> when you say:
>> ...the database is kind of a two-dimensional projection of three dimensions
>> that is, there may be many hidden relationships in the process side of
>> things that have to be taken into account for deployment...
>
> I can think of two very different ways of interpreting that metaphor, both of
> which are applicable to the topic at hand. I'm hoping, though, that this
> explanation finally does make clear that I'm _not_ thinking along the lines of
> 'how do we make an sqldump better?', but instead about methods for making
> deployment a process that's as smart about drupal data as drupal itself is.
>
> s
>
>>
>> On Mon, Aug 11, 2008 at 3:51 PM, Sam Boyer <drupal at samboyer.org> wrote:
>> > On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> >> The serialization and unserialization of data is included in my
>> >> approach to the problem for the purposes of the independent
>> >> transmission of nodes from one system to another, as in the case of
>> >> one Drupal site availing itself of a node.save service on another
>> >> Drupal site.
>> >>
>> >> It also has the purpose of guaranteeing insofar as is possible a text
>> >> version of all entities, configurations, including exported views,
>> >> content types, panels, hopefully menues and module configurations and
>> >> exported variables, for the purposes of continued version control and
>> >> hence deployment also (serialization to text, unserialization to
>> >> deployment objective).
>> >>
>> >> Here of course, serialization and unserialization is not meant in the
>> >> php function sense, and could include marshaling and unmarshaling to
>> >> and from XML, and is a cross-language concept.
>> >>
>> >> Victor Kane
>> >> http://awebfactory.com.ar
>> >
>> > So my initial reaction was that this was actually a disadvantage - it
>> > seemed to introduce an extra layer of unnecessary complexity, as it
>> > requires pulling the data out of the db, coming up with a new storage
>> > format, then transferring that format and reintegrating it into another
>> > db. The backup and project-level revisioning control implications are
>> > interesting - but that's a wholly different axis from the crux of the
>> > deployment paradigm, where there's _one_ version.
>> >
>> > However, on further reflection, I can see there being some strong
>> > arguments in either direction. Your approach, Victor, makes me drift back
>> > to the recent vcs thread on this list, as I can't imagine such a system
>> > being feasible and really scalable without the use  of something like
>> > (gasp!) git. Two basic reasons for that:
>> >
>> > 1. Data integrity assurance: there's nothing like a SHA1 hash to ensure
>> > that nothing gets corrupted in all the combining/recombining of data
>> > through and around various servers. And then there's the whole
>> > content-addressable filesystem bit - I'd conjecture that it would make
>> > git exceptionally proficient at handling either database dumps or tons of
>> > data structured from 'export' functionality, whichever the case may be. I
>> > imagine Kathleen might be able to speak more to that.
>> >
>> > 2. Security and logic (and speed): if run on a git backend, I'd speculate
>> > that we could use project-specific ssh keys to encrypt all the
>> > synchronizations (although that obviously brings up a host of other
>> > potential
>> > requirements/issues). On the logic end, we could build on top of git's
>> > system for organizing sets of commits to allow for different 'types' of
>> > syncs (i.e., you're working with different datasets when doing dev <=> qa
>> > vs. when you're working with live <=> staging). As for speed...well, I'll
>> > just call that a hunch =)
>> >
>> > This approach would require a _lot_ of coding, though. The more
>> > immediate-term solution that still makes the most sense to me is one
>> > where we let modules work straight from the data as it exists in the db,
>> > and define some logic for handling synchronizations that the deploy API
>> > can manage. But if all the systems are to be implemented...well, then it
>> > probably means a pluggable Deploy API that allows for different
>> > subsystems to handle different segments of the overall process.
>> >
>> > Sam
>
>


From victorkane at gmail.com  Mon Aug 11 22:18:27 2008
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 11 Aug 2008 19:18:27 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808111609.44411.drupal@samboyer.org>
References: <200808090758.01373.yuval@avramzon.net>
	<200808111351.31349.drupal@samboyer.org>
	<ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
	<200808111609.44411.drupal@samboyer.org>
Message-ID: <ff176450808111518j7afa80fco3cc3b9f53a52bda@mail.gmail.com>

You make a lot of good points. I guess from here on in, this
discussion should move to the prototype arena, and working together
with Greg, Alex, and others to see what progress can be made.



On Mon, Aug 11, 2008 at 6:09 PM, Sam Boyer <drupal at samboyer.org> wrote:
> On Monday 11 August 2008 14:38:27 Victor Kane wrote:
>> Your points are interestng, but I think there may be a lot to what
>> Greg Dunlap is recommending in terms of thinking in Drupal logic terms
>> and not database terms.
>>
>> The image I have in my mind is that the database is kind of a
>> two-dimensional projection of three dimensions; that is, there may be
>> many hidden relationships in the process side of things that have to
>> be taken into account for deployment, especially since the database is
>> usually considered in purely MySql terms, that is, with fully
>> transparent relationships between tables.
>>
>> But given concrete client driven circumstances, of course, in a given
>> instance with a given set of priorities, I can easily see how what you
>> are saying could make sense.
>>
>> Victor
>
> At this point then, I suspect we're talking past each other. First, are you
> referring only to the direct-database sync point that I made, or is that also
> in reference to the drupal-object exporting, git-managed system? If it's the
> latter as well as the former, then we've _really_ diverged.
>
> Just because I'm suggesting that there are direct-database syncing solutions
> possible does NOT mean that I'm not thinking in Drupal logic terms. Let me try
> a different, potentially clearer way:
>
> In your approach, it seems to me that the goal is to use existing drupal API
> functions - let's use nodes, so node_load() - to fully build a node object.
> That object is then exported to code, at which point we can do things with
> vcs, etc. During a deployment, we parse in that code and utilize the API
> counterpart to our data-getter function, so node_save(), to push the
> information into the database. Before node_save() is actually run, however,
> we can use something like a GUID system to change primary keys as necessary so
> that we've got the node from server A going into the right associated node on
> server B.
>
> As I said, I can see arguments for that, particularly if it utilizes a git
> backend. And only differs from what I'm proposing in a few ways.
>
> What I'm suggesting stems from Greg's original point about a GUID for every
> 'thing'. 'Things' being, to use your words:
>
> On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> ...
>> all entities, configurations, including exported views, content types,
>> panels, hopefully menues and module configurations and
>> exported variables
>> ...
>
> Because I agree completely that the _only_ way to arrive at a solution that
> works for drupal is to think in terms of the 'things' (I'm going to say
> 'items' from here on out) it makes - not to try to just grab bits of data from
> here and there and hope it all lines up on the other end. I've always thought
> that, and am pretty sure I always will.
>
> My proposal is for a deploy API that would let modules define what these items
> are, and then define a set of behaviors for managing the deployment of those
> items across a variety of different circumstances. For our concrete example, I
> suspect the _first_ thing I'd do in the synchro handler for nodes is to call
> node_load(), then follow it up with some internal logic that...I dunno, there
> are a lot of ways we could go from there. It could dynamically construct a
> delta from the last sync time with the remote server; it could just fire over
> the whole node object. If extension modules need to do something that the node
> module's deploy handler couldn't work out, no problem - those modules just
> need to register their interest in deploy transactions related to the GUID for
> that particular item. On the receiving end, the node module's deploy API
> implementation knows what to expect coming through the pipe and handles it
> accordingly - maybe through node_save(), maybe not.
>
> The advantage here, as I see it, is the potential to drill down _very_ quickly
> on exactly what should be checked during a given changeset. Very quickly as
> in, potentially, a single query. I can't picture the schema for the deploy
> items table, so it may take more, but it could be as simple as a single SELECT
> query that grabs all the items which have been changed/created since the last
> deploy txn, and that that particular deploy txn is interested in (again, a dev
> <=> qa txn != staging <=> live txn), and then it's a simple question of
> iterating through modules that have something to say about how each of the
> items is deployed.
>
> As I said, I can see ways that a git-driven system can probably provide
> similar speed when it comes to drilling down to what items need to be
> considered in a given txn; also, a git-driven system has the added benefit of
> being able to, even when your local system offline, still provide the entire
> version history on demand for _each server_ you've ever connected with on that
> project. Well, assuming your remote git branches are up to date.
>
> As far as I can tell, this is really the kind of thing you're talking about
> when you say:
>> ...the database is kind of a two-dimensional projection of three dimensions
>> that is, there may be many hidden relationships in the process side of
>> things that have to be taken into account for deployment...
>
> I can think of two very different ways of interpreting that metaphor, both of
> which are applicable to the topic at hand. I'm hoping, though, that this
> explanation finally does make clear that I'm _not_ thinking along the lines of
> 'how do we make an sqldump better?', but instead about methods for making
> deployment a process that's as smart about drupal data as drupal itself is.
>
> s
>
>>
>> On Mon, Aug 11, 2008 at 3:51 PM, Sam Boyer <drupal at samboyer.org> wrote:
>> > On Monday 11 August 2008 05:33:49 Victor Kane wrote:
>> >> The serialization and unserialization of data is included in my
>> >> approach to the problem for the purposes of the independent
>> >> transmission of nodes from one system to another, as in the case of
>> >> one Drupal site availing itself of a node.save service on another
>> >> Drupal site.
>> >>
>> >> It also has the purpose of guaranteeing insofar as is possible a text
>> >> version of all entities, configurations, including exported views,
>> >> content types, panels, hopefully menues and module configurations and
>> >> exported variables, for the purposes of continued version control and
>> >> hence deployment also (serialization to text, unserialization to
>> >> deployment objective).
>> >>
>> >> Here of course, serialization and unserialization is not meant in the
>> >> php function sense, and could include marshaling and unmarshaling to
>> >> and from XML, and is a cross-language concept.
>> >>
>> >> Victor Kane
>> >> http://awebfactory.com.ar
>> >
>> > So my initial reaction was that this was actually a disadvantage - it
>> > seemed to introduce an extra layer of unnecessary complexity, as it
>> > requires pulling the data out of the db, coming up with a new storage
>> > format, then transferring that format and reintegrating it into another
>> > db. The backup and project-level revisioning control implications are
>> > interesting - but that's a wholly different axis from the crux of the
>> > deployment paradigm, where there's _one_ version.
>> >
>> > However, on further reflection, I can see there being some strong
>> > arguments in either direction. Your approach, Victor, makes me drift back
>> > to the recent vcs thread on this list, as I can't imagine such a system
>> > being feasible and really scalable without the use  of something like
>> > (gasp!) git. Two basic reasons for that:
>> >
>> > 1. Data integrity assurance: there's nothing like a SHA1 hash to ensure
>> > that nothing gets corrupted in all the combining/recombining of data
>> > through and around various servers. And then there's the whole
>> > content-addressable filesystem bit - I'd conjecture that it would make
>> > git exceptionally proficient at handling either database dumps or tons of
>> > data structured from 'export' functionality, whichever the case may be. I
>> > imagine Kathleen might be able to speak more to that.
>> >
>> > 2. Security and logic (and speed): if run on a git backend, I'd speculate
>> > that we could use project-specific ssh keys to encrypt all the
>> > synchronizations (although that obviously brings up a host of other
>> > potential
>> > requirements/issues). On the logic end, we could build on top of git's
>> > system for organizing sets of commits to allow for different 'types' of
>> > syncs (i.e., you're working with different datasets when doing dev <=> qa
>> > vs. when you're working with live <=> staging). As for speed...well, I'll
>> > just call that a hunch =)
>> >
>> > This approach would require a _lot_ of coding, though. The more
>> > immediate-term solution that still makes the most sense to me is one
>> > where we let modules work straight from the data as it exists in the db,
>> > and define some logic for handling synchronizations that the deploy API
>> > can manage. But if all the systems are to be implemented...well, then it
>> > probably means a pluggable Deploy API that allows for different
>> > subsystems to handle different segments of the overall process.
>> >
>> > Sam
>
>

From adrian at bryght.com  Mon Aug 11 22:24:59 2008
From: adrian at bryght.com (Adrian Rossouw)
Date: Tue, 12 Aug 2008 00:24:59 +0200
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <7e4a3f280808111325n445a61f2gab9e348f086b617d@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
	<A8D34AEF-5D16-4EE6-8F52-79D17F2BB069@developmentseed.org>
	<aa0037c80808110812o58112ee8o959ca720ff02095a@mail.gmail.com>
	<3FE4A030-F0AD-4CD4-A442-3BBD9DEEB444@bryght.com>
	<da965fc60808111243r1781077fmb0101160b91cb01e@mail.gmail.com>
	<7e4a3f280808111325n445a61f2gab9e348f086b617d@mail.gmail.com>
Message-ID: <62EB9F73-9508-4A7F-A4B8-A03009F47025@bryght.com>


On 11 Aug 2008, at 10:25 PM, Greg Dunlap wrote:
> - Upgrading an existing site would be virtually impossible. Every id  
> would change, plus you would have to update every foreign key  
> reference to every id throughout core AND contrib.
Yes, we'd need foreign key support in schema api, but that is  
something I think we should end up doing anyway. (and no, not in a way  
that slows down the work in db api for 7).

> - For sites not running pathauto, every URL would change.
Sites not running pathauto would have aliases created for the existing  
urls.

> That's just a couple of the purely technical reasons. I would also  
> add that a conscious decision was made to move away from PHP- 
> generated IDs in Drupal 6, and it seems to me very unlikely that  
> this will be reversed. There are several issues around this in the  
> queues. It would offer us up some great functionality but I just  
> don't see it happening.
If it needs to stay in the db, it's possible to use mysql and pgsql  
functions to create a next value. That would of course cut us of from  
sqllite.

I'm not entirely wedded to the idea, and even if it's supported, i  
foresee it being an option and not the default mechanism for doing  
things, for at least a release or two,
but it could help us solve a few very interesting problems down the  
line, apart from just the import export problem.

I do however think we should look at extending D6's import/export  
functionality through contrib, as it will help us pick up issues in  
core that can be helped along with core
api changes, and makes the functionality available to site developers  
sooner rather than later. (ie: let's not boil the ocean)

From larry at garfieldtech.com  Tue Aug 12 01:15:41 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Mon, 11 Aug 2008 20:15:41 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<200808111351.31349.drupal@samboyer.org>
	<ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
Message-ID: <200808112015.42073.larry@garfieldtech.com>

On Monday 11 August 2008 2:38:27 pm Victor Kane wrote:
> Your points are interestng, but I think there may be a lot to what
> Greg Dunlap is recommending in terms of thinking in Drupal logic terms
> and not database terms.

One of the take-aways from the Data API Design Sprint back in February was 
that we need to move away from assuming that everything is in a single local 
SQL database.  That is simply far too limiting.  

Any import/export/deploy mechanism will absolutely need to operate at the 
entity level, not the database level, because there's no guarantee that there 
will always be a local SQL database in which these things are stored.

-- 
Larry Garfield
larry at garfieldtech.com

From senpai_san at mac.com  Tue Aug 12 05:13:27 2008
From: senpai_san at mac.com (Senpai)
Date: Mon, 11 Aug 2008 22:13:27 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<7B53263F-3A4D-4957-B122-E97925133E58@bryght.com>
	<ff176450808100606r668e2e40hfaf3a7c8aa0be083@mail.gmail.com>
	<7e4a3f280808100922u5e58030ajd347696d8e2c48b@mail.gmail.com>
Message-ID: <9E405880-4B8E-4238-B85C-833E26EBE73E@mac.com>

Yes Heyrocker, yes! I would love to see these issues being discussed  
out in the open on the g.d.o. change management group! Everybody to  
come over there!

Seriously though, the sheer amount of people who are striving for a  
solution to this problem have hit critical mass this year. The very  
email thread you are reading confirms it. It's not a problem that any  
one of us, nor any single shop will be able to adequately solve simply  
because of the sheer amount of use cases that seem to crop up every  
time a developer cries, Eureka!" or " I have a module in the works for  
that."

Let's begin discussions in earnest on the g.d.o. group or we will see  
six contrib modules hit the streets at about the same time that are  
all 90% cool. My thread on the proposed hook_configuration() is even  
starting to lean towards a change management scenario. It's time,  
people, it's time.
-- 
Joel Farris
"I'm not concerned about all hell breaking loose, but that a PART of  
hell will break loose... it'll be much harder to detect."
~ George Carlin




On Aug 10, 2008, at 9:22 AM, Greg Dunlap wrote:

> I'd love to see everyone discussing their problems in a more public  
> setting, not here but perhaps in the Change Management group on  
> g.d.o., so we can pool resources on problems when it makes sense.  
> For all that people seem to be struggling with these issues, that  
> group is oddly dead.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080811/4a6c481b/attachment.htm 

From r.crowther at zen.co.uk  Tue Aug 12 07:31:14 2008
From: r.crowther at zen.co.uk (robert crowther)
Date: Tue, 12 Aug 2008 08:31:14 +0100
Subject: [development] New module makes custom menus from taxonomy -
	experienced coder	wish to pick this up?
Message-ID: <1218526274.8160.26.camel@robert-desktop>

Sorry for the long title, but wanted to get the key facts in there.

I've also posted in the module development forum, which seems more
appropriate, but the module needs a little time from an experienced
coder, up to speed on Drupal 6.x, so I'm leaving a message here, too.

I've made a new module. It creates creates custom menus from the
taxonomy. It stands out from the other solutions (unless I've missed
something), like this,

 - It's a bigger module (two modules) than other cuter solutions
(Tax'o'menu, TinyTax, Taxonomy-strider, Taxonomy-context, Site-menu,
Menu-tree...)

 -  It's far more generalised. In short, you can index any part of your
taxonomy. The menus it produces update on the fly. They look like the
navigation menu or the book menu, because they use the same Drupal
systems. There are more details on my recent forum post.

If the Dutch play total football, this is total Drupal (bit of hype).

When researching, I found repeated requests in  forums and lists for
such a module, but nobody has made one, which leads to the question,
shouldn't I post my work?

Answer, no. I only started on Drupal a few months ago. I only started
coding in PHP just before the 6.x upgrade, so this module has lived
through that. What I have works very well for me. But if the community
would like it, the module needs someone experienced to look it over and
tidy it up.

Anyone want to help? Or point me in some useful directions where I can
get help? It's exciting coding, as it uses many of the new features in
Drupal 6.x. You don't even have to do the tricky stuff, as the general
approach is now worked - the module is up and running as a proof of
concept.

All you have to do is mail me back, and we can take it from there.


Robert


From victorkane at gmail.com  Tue Aug 12 07:48:09 2008
From: victorkane at gmail.com (Victor Kane)
Date: Tue, 12 Aug 2008 04:48:09 -0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808112015.42073.larry@garfieldtech.com>
References: <200808090758.01373.yuval@avramzon.net>
	<200808111351.31349.drupal@samboyer.org>
	<ff176450808111238j6ec9698dv6c83217587bc4bef@mail.gmail.com>
	<200808112015.42073.larry@garfieldtech.com>
Message-ID: <ff176450808120048n3ef7cd71p1f01b10bda018769@mail.gmail.com>

Excellent!

On Mon, Aug 11, 2008 at 10:15 PM, Larry Garfield <larry at garfieldtech.com> wrote:
> On Monday 11 August 2008 2:38:27 pm Victor Kane wrote:
>> Your points are interestng, but I think there may be a lot to what
>> Greg Dunlap is recommending in terms of thinking in Drupal logic terms
>> and not database terms.
>
> One of the take-aways from the Data API Design Sprint back in February was
> that we need to move away from assuming that everything is in a single local
> SQL database.  That is simply far too limiting.
>
> Any import/export/deploy mechanism will absolutely need to operate at the
> entity level, not the database level, because there's no guarantee that there
> will always be a local SQL database in which these things are stored.
>
> --
> Larry Garfield
> larry at garfieldtech.com
>

From adrinux at perlucida.com  Tue Aug 12 08:11:57 2008
From: adrinux at perlucida.com (Adrian Simmons)
Date: Tue, 12 Aug 2008 09:11:57 +0100
Subject: [development] New module makes custom menus from taxonomy
 -	experienced coder	wish to pick this up?
In-Reply-To: <1218526274.8160.26.camel@robert-desktop>
References: <1218526274.8160.26.camel@robert-desktop>
Message-ID: <48A145CD.7040607@perlucida.com>

robert crowther wrote:
> All you have to do is mail me back, and we can take it from there.
This is what Drupal's CVS contrib repository is for! :)

Seriously. Upload it to contrib, make a project and just have a development 
release, in the project description tell people about it and that you 
consider it alpha or beta quality. Say you're looking for a co-maintainer.

If people want to use it and find bugs, you'll get bug reports. If you're 
lucky you'll also get patches. You may even get someone interested enough to 
help maintain it.

But just posting to the dev list like this (is everybody that writes modules 
even subscribed to this list?) has more of an air of "I can't be bothered to 
maintain this, can someone do it for me?".

At worst it'll sit in contrib and nothing will happen, at best you may get 
patches that teach you better php coding :)

-- 
Adrian Simmons (aka adrinux) <http://perlucida.com>
e-mail <mailto:adrinux at perlucida.com>

From yuval at avramzon.net  Tue Aug 12 09:27:10 2008
From: yuval at avramzon.net (Yuval Hager)
Date: Tue, 12 Aug 2008 12:27:10 +0300
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
Message-ID: <200808121227.16487.yuval@avramzon.net>

On Sunday 10 August 2008, Greg Dunlap wrote:
> When I created Deploy I had a set of goals in mind that I felt a solution
> had to meet. I think (hope) that most people will agree that these goals
> represent the ideal of what any staging and deployment system should
> achieve. Some of this will repeat some of what has already been said
> insightfully and thoughtfully above, but I kind of wanted it all put
> together in one place.
>
> [snip]

I've been thinking a lot about this thread. It has developed to be a very 
informative and important discussion. I was not aware of the deploy module, 
and it definitely looks like a very big step in the right direction.

Taking this  a step further I could *not* imagine myself deploy-ing data onto 
a client's live production site, although I happily use 'svn export' on such 
a site for code. Making all sorts of changes to the DB in a bulk is very 
frightening to do on production, and something I will try to avoid as much as 
I can. 

Assuming I am not the only one with this thoughts, I tried to analyze the 
basis of that hesitation. SVN does version management. I trust the tool that 
if I had made a catastrophic change on production, I can always switch back 
to the old version and leave production in a stable state. I can also provide 
a log of changes and create a diff to know what has changed. In order to be 
able to use a deploy style solution on a production server, IMHO, it must 
provide a trackable, version control style of logging and rollbacks. Somebody 
in this thread mentioned another VCS that might be used - maybe this is what 
he meant.. I am not sure.

Have you considered this type of version control handling for deploy? Or maybe 
this is achieved through the serialization that was discussed elsewhere in 
this thread? 

--yuval
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080812/ddaa8318/attachment-0001.pgp 

From alex at developmentseed.org  Tue Aug 12 12:09:00 2008
From: alex at developmentseed.org (Alex Barth)
Date: Tue, 12 Aug 2008 08:09:00 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808121227.16487.yuval@avramzon.net>
References: <200808090758.01373.yuval@avramzon.net>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<200808121227.16487.yuval@avramzon.net>
Message-ID: <089AE725-6A8B-4720-B5C7-5EE29D184FD3@developmentseed.org>


On Aug 12, 2008, at 5:27 AM, Yuval Hager wrote:
> On Sunday 10 August 2008, Greg Dunlap wrote:
>> When I created Deploy I had a set of goals in mind that I felt a  
>> solution
>> had to meet. I think (hope) that most people will agree that these  
>> goals
>> represent the ideal of what any staging and deployment system should
>> achieve. Some of this will repeat some of what has already been said
>> insightfully and thoughtfully above, but I kind of wanted it all put
>> together in one place.
>>
>> [snip]
[...]
>
> Have you considered this type of version control handling for  
> deploy? Or maybe
> this is achieved through the serialization that was discussed  
> elsewhere in
> this thread?

I can't speak of deploy, but this is defintely one of the three major  
use cases I'm having in my mind when thinking of exporting/importing  
site structure:

- deployment
- install profiles (or module package configurations)
- version control

One additional thing I'm having in the back of my head is doing the  
same thing with content: Once we've figured out what's structure in  
our sites, the rest is content, right?

Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633





From ethan at acquia.com  Tue Aug 12 12:37:18 2008
From: ethan at acquia.com (Ethan Fremen)
Date: Tue, 12 Aug 2008 08:37:18 -0400
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <ff176450808110420i504b14aayd572271320af81fa@mail.gmail.com>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
	<6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>
	<2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>
	<ff176450808110420i504b14aayd572271320af81fa@mail.gmail.com>
Message-ID: <9653285E-9A7B-441B-A3E2-D84AF6E32315@acquia.com>

On Aug 11, 2008, at 7:20 AM, Victor Kane wrote:

> OK, but please all take into account that it is not necessarily the
> best thing to tie the creation of the UUID to the database at all.

100% agreed. Right now I'm most strongly in favor of using the OSSP  
UUID library (aka php5-uuid in debian/ubuntu), which is, btw, *much*  
faster than the DIY random-64-bit identifiers I tried.

~ethan fremen

From kathleen at ceardach.com  Tue Aug 12 13:50:50 2008
From: kathleen at ceardach.com (Kathleen Murtagh)
Date: Tue, 12 Aug 2008 09:50:50 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <089AE725-6A8B-4720-B5C7-5EE29D184FD3@developmentseed.org>
References: <200808090758.01373.yuval@avramzon.net>
	<AE0D7197-69A2-4AE0-8D57-E749219D01F1@bryght.com>
	<7e4a3f280808100018rd04ff1an2ba296dc6333a0c7@mail.gmail.com>
	<200808121227.16487.yuval@avramzon.net>
	<089AE725-6A8B-4720-B5C7-5EE29D184FD3@developmentseed.org>
Message-ID: <1d83e3e60808120650p5c3b85b0ud646e1f75b416e4c@mail.gmail.com>

On Tue, Aug 12, 2008 at 8:09 AM, Alex Barth <alex at developmentseed.org> wrote:
> One additional thing I'm having in the back of my head is doing the same
> thing with content: Once we've figured out what's structure in our sites,
> the rest is content, right?
>

I have classified four types of data:

  * Configuration (structure)
  * Content
  * User
  * Ignorable

Configuration are things like the variables, blocks, cck type and
field definitions, etc  (you can configure settings.php to have unique
variable settings on dev and prod). Content is nodes, taxonomy, menu,
path, etc.  User data is users, comments, search, statistics,
watchdog, etc.  Basically, anything that tracks what a user is doing
(this is also stuff you generally don't need to track in development).

Ignorable data is cache and sessions - neither of which are
drastically harmful if you lose.  You don't store the data, but you
also don't erase it.  It lives only in the live database, and if the
live database is lost, it's not so bad to have to regenerate that
data.

The other possible "ignorable" data is the search index - this is sort
of a personal preference, I think.   By default, I have it categorized
as user data, but I think it could be ignored if needed for
performance reasons.

In a data classification plan, I think it would be important to leave
it flexible for a user to choose their own classification.  The search
index is one example of personal preference.

---
Kathleen Murtagh

From darrel.opry at gmail.com  Tue Aug 12 14:13:16 2008
From: darrel.opry at gmail.com (Darrel O'Pry)
Date: Tue, 12 Aug 2008 10:13:16 -0400
Subject: [development] Unique/Random IDs and drupal
In-Reply-To: <9653285E-9A7B-441B-A3E2-D84AF6E32315@acquia.com>
References: <909D1503-D851-4EDC-8E6D-FFA0F7A81960@acquia.com>
	<200808101557.27583.larry@garfieldtech.com>
	<D2BDACA5-22F4-4379-95C8-019354F91F12@gmail.com>
	<6988040F-B76A-40DF-9CE6-A5790B7C490A@acquia.com>
	<2B72711E-0193-432C-9B28-6C03C4CE1898@robshouse.net>
	<ff176450808110420i504b14aayd572271320af81fa@mail.gmail.com>
	<9653285E-9A7B-441B-A3E2-D84AF6E32315@acquia.com>
Message-ID: <bfcbb6230808120713k73f001b4p93d0f9b80998c0c6@mail.gmail.com>

I'm all in favor of supporting 64bit ints in the database, whether we're
going for UUID's or not. I'm personally experimenting with 64bit timestamps
instead of using DateTime strings for storing dates. It is silly to not use
it because "Noone could concievably use that many ID's in the near future."
Platform native word length is a valid argument.

UUIDs are 128bit... so I don't see how 64bit values helps you implement
UUIDs either, If it's 64bits it's not a UUID per spec it's something else.
You probably need a char(36) and hexadecimal representation if you wish to
store UUIDs in a single column unless, or you have a plan for reducing the
significant data which needs to be stored in the index to 64bits, or you
plan to spread the UUID over two integer indexes?

I don't quite follow how the sharding is intended to be implemented. I'm
more curious about your plans for that. I've read up on how flickr does
their user centric sharding, but how do you see the concept being mapped to
Drupal?

On Tue, Aug 12, 2008 at 8:37 AM, Ethan Fremen <ethan at acquia.com> wrote:

> On Aug 11, 2008, at 7:20 AM, Victor Kane wrote:
>
>  OK, but please all take into account that it is not necessarily the
>> best thing to tie the creation of the UUID to the database at all.
>>
>
> 100% agreed. Right now I'm most strongly in favor of using the OSSP UUID
> library (aka php5-uuid in debian/ubuntu), which is, btw, *much* faster than
> the DIY random-64-bit identifiers I tried.
>
> ~ethan fremen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080812/9038ab92/attachment.htm 

From drupal at dave-cohen.com  Tue Aug 12 17:33:29 2008
From: drupal at dave-cohen.com (Dave Cohen)
Date: Tue, 12 Aug 2008 10:33:29 -0700
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <1d83e3e60808120650p5c3b85b0ud646e1f75b416e4c@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<089AE725-6A8B-4720-B5C7-5EE29D184FD3@developmentseed.org>
	<1d83e3e60808120650p5c3b85b0ud646e1f75b416e4c@mail.gmail.com>
Message-ID: <200808121033.30082.drupal@dave-cohen.com>

In your model taxonomy is "content" while variables are "configuration".  
Let's say on my site, one of my taxonomies is "privacy" with terms 
like "public", "administrator only", etc...  Further I configure one of the 
taxonomy access control modules to use my privacy terms.

In my mind those terms are part of "configuration" (while other terms might be 
considered "content").

While in your model as I understand it, I now have some variables 
(configuration, of the access control module) referring to my term ids 
(content).  So the line is crossed, I can't replicate the configuration 
unless I also replicate the content.  If I understand you correctly.

I say this trying to point out that we can't simply divide Drupal's database 
into "content" tables and "configuration" tables.  Unfortunately is will 
never be that simple.  There are many examples like this where the line 
between content and configuration is fuzzy.

While I'm pessimistic about that particular idea, I'm optimistic about the 
UUID idea being discussed in the "Unique/Random IDs and drupal" thread.  I 
think using UUIDs rather than sequential ids will solve a big huge chunk of 
the dev->staging->live problem.

-Dave


On Tuesday 12 August 2008, Kathleen Murtagh wrote:
> Configuration are things like the variables, blocks, cck type and
> field definitions, etc ?(you can configure settings.php to have unique
> variable settings on dev and prod). Content is nodes, taxonomy, menu,
> path, etc.



From kathleen at ceardach.com  Tue Aug 12 18:23:07 2008
From: kathleen at ceardach.com (Kathleen Murtagh)
Date: Tue, 12 Aug 2008 14:23:07 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808121033.30082.drupal@dave-cohen.com>
References: <200808090758.01373.yuval@avramzon.net>
	<089AE725-6A8B-4720-B5C7-5EE29D184FD3@developmentseed.org>
	<1d83e3e60808120650p5c3b85b0ud646e1f75b416e4c@mail.gmail.com>
	<200808121033.30082.drupal@dave-cohen.com>
Message-ID: <1d83e3e60808121123t7a365a72s9c594f6b0de15784@mail.gmail.com>

On Tue, Aug 12, 2008 at 1:33 PM, Dave Cohen <drupal at dave-cohen.com> wrote:
> <snip>
> While in your model as I understand it, I now have some variables
> (configuration, of the access control module) referring to my term ids
> (content).  So the line is crossed, I can't replicate the configuration
> unless I also replicate the content.  If I understand you correctly.
>
> I say this trying to point out that we can't simply divide Drupal's database
> into "content" tables and "configuration" tables.  Unfortunately is will
> never be that simple.  There are many examples like this where the line
> between content and configuration is fuzzy.

Dave, you are correct.  It is for this reason that I took the "merge"
approach.  I have been thinking very deeply about this topic for about
a year now, so I may not so quickly 'get' everything that is being
discussed as I'm likely in a rut in my thinking.  However, I feel then
my role may be best to at the very least provide what I have learned
for those who do 'get' the whole issue.

The way Drupal behaves, creating this fuzzy division between
configuration and content, makes this whole process difficult.  This
is the core of the problem, otherwise we could just copy tables back
and forth.  As I see it, UUID's would really only solve one problem of
the whole package - the sequences issue.  It's, of course, a great
problem to solve, however, there are other issues.

One of the things that likely needs to be supported in any system is
modifying content data in both development and production.  I think it
is a long ways off before this fuzzy division will go away.  In all of
the sites I have developed, I have in some way touched and modified
nodes during development of a site that has a live counterpart. Your
taxonomy example is great, as it can be both used for configuration
(access control) and content (free tagging) on one website.  Yikes.

If you allow modification of content data on both development and
production, then it opens a whole can of worms when merging that data.
The biggest issue is figuring out what is "new" content and what is
"deleted" content.  If I delete something in development, is that
deletion eliminated because it is considered "new" content from
production?  If I delete something in production, how do I push that
back to development without development inadvertently pushing it back
to production?  Then, ick, what if the same piece of content is
modified on both production and development (lets say the menus as the
most likely culprit)?

(please excuse me if this was a double post)

---
Kathleen Murtagh

From allie at pajunas.com  Tue Aug 12 18:41:21 2008
From: allie at pajunas.com (Allie Micka)
Date: Tue, 12 Aug 2008 13:41:21 -0500
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
Message-ID: <29AC6FDA-C3FD-4D6F-BF1C-CE45B89F7E32@pajunas.com>

I was about to suggest this, but Adrian got there first:


On Aug 9, 2008, at 8:09 PM, Adrian Rossouw wrote:

> One of the things I would like to see in deploy , or any system we  
> end up using,
> is the ability to generate a module with a .install file for the  
> configuration info
> in install and update_x hooks.
>
> This allows developers to version their code and configuration with  
> their version tracking
> system, and roll out new releases the same way they would normally.


So my contribution to this thread will be a most-helpful +1.  This is  
how we do pretty much everything around here, and I'd be disappointed  
in any solution that wasn't equally as useful.

Thanks!

Allie

From kathleen at ceardach.com  Tue Aug 12 20:52:22 2008
From: kathleen at ceardach.com (Kathleen Murtagh)
Date: Tue, 12 Aug 2008 16:52:22 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <29AC6FDA-C3FD-4D6F-BF1C-CE45B89F7E32@pajunas.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
	<29AC6FDA-C3FD-4D6F-BF1C-CE45B89F7E32@pajunas.com>
Message-ID: <1d83e3e60808121352q19381099v95edeb021eb2ce0c@mail.gmail.com>

On Tue, Aug 12, 2008 at 2:41 PM, Allie Micka <allie at pajunas.com> wrote:
> On Aug 9, 2008, at 8:09 PM, Adrian Rossouw wrote:
>> One of the things I would like to see in deploy , or any system we end up
>> using,
>> is the ability to generate a module with a .install file for the
>> configuration info
>> in install and update_x hooks.
>>
>> This allows developers to version their code and configuration with their
>> version tracking
>> system, and roll out new releases the same way they would normally.
>
>
> So my contribution to this thread will be a most-helpful +1.  This is how we
> do pretty much everything around here, and I'd be disappointed in any
> solution that wasn't equally as useful.

Another +1.  This is along the lines of what I meant when I said I am
dreaming of having automated database migrations for Drupal.

Something quick and easy where someone could say, "Ok, everything I
just did, export it".  Then the next developer can add importing those
changes as part of their update workflow.

Something where, a month along in development, someone could say, "You
know, that commit was bad" and remove that commit from the system,
including any database changes that were made.

---
Kathleen Murtagh

From rob at robshouse.net  Wed Aug 13 07:10:30 2008
From: rob at robshouse.net (Robert Douglass)
Date: Wed, 13 Aug 2008 09:10:30 +0200
Subject: [development] Please help fix db_rewrite_sql in search
Message-ID: <1D17731E-6A55-48AA-A3E9-4AD0406ECD8A@acquia.com>

Did you know that Drupal's search module doesn't properly use  
db_rewrite_sql? Surprised? Well, it's been in the issue queue since  
2006.

http://drupal.org/node/54622

There is also a patch that has been waiting for review ever since the  
Minnesota Search Sprint (May 10) that nobody has looked at.

I've marked the bug as "critical". As Drupal's standards get higher  
bugs like this aren't acceptable. Hopefully this mail will stir up  
some interest.

From catch56 at googlemail.com  Wed Aug 13 09:37:43 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 13 Aug 2008 10:37:43 +0100
Subject: [development] Please help fix db_rewrite_sql in search
In-Reply-To: <1D17731E-6A55-48AA-A3E9-4AD0406ECD8A@acquia.com>
References: <1D17731E-6A55-48AA-A3E9-4AD0406ECD8A@acquia.com>
Message-ID: <fa5724270808130237w2f1cdf79of3cdae21d564fee3@mail.gmail.com>

That patch has been marked as needs work since May 10th, not needs
review. No-one looks at those (unless they're critical).

On Wed, Aug 13, 2008 at 8:10 AM, Robert Douglass <rob at robshouse.net> wrote:
> Did you know that Drupal's search module doesn't properly use
> db_rewrite_sql? Surprised? Well, it's been in the issue queue since 2006.
>
> http://drupal.org/node/54622
>
> There is also a patch that has been waiting for review ever since the
> Minnesota Search Sprint (May 10) that nobody has looked at.
>
> I've marked the bug as "critical". As Drupal's standards get higher bugs
> like this aren't acceptable. Hopefully this mail will stir up some interest.
>

From rob at robshouse.net  Wed Aug 13 09:42:10 2008
From: rob at robshouse.net (Robert Douglass)
Date: Wed, 13 Aug 2008 11:42:10 +0200
Subject: [development] Please help fix db_rewrite_sql in search
In-Reply-To: <fa5724270808130237w2f1cdf79of3cdae21d564fee3@mail.gmail.com>
References: <1D17731E-6A55-48AA-A3E9-4AD0406ECD8A@acquia.com>
	<fa5724270808130237w2f1cdf79of3cdae21d564fee3@mail.gmail.com>
Message-ID: <3FBBD540-2D19-4768-BA08-1666F8A4A597@robshouse.net>

Fair enough. That's why I marked it critical =)
On Aug 13, 2008, at 11:37 AM, Nathaniel Catchpole wrote:

> That patch has been marked as needs work since May 10th, not needs
> review. No-one looks at those (unless they're critical).
>
> On Wed, Aug 13, 2008 at 8:10 AM, Robert Douglass <rob at robshouse.net>  
> wrote:
>> Did you know that Drupal's search module doesn't properly use
>> db_rewrite_sql? Surprised? Well, it's been in the issue queue since  
>> 2006.
>>
>> http://drupal.org/node/54622
>>
>> There is also a patch that has been waiting for review ever since the
>> Minnesota Search Sprint (May 10) that nobody has looked at.
>>
>> I've marked the bug as "critical". As Drupal's standards get higher  
>> bugs
>> like this aren't acceptable. Hopefully this mail will stir up some  
>> interest.
>>


From karoly at negyesi.net  Wed Aug 13 16:07:05 2008
From: karoly at negyesi.net (Karoly Negyesi)
Date: Wed, 13 Aug 2008 18:07:05 +0200
Subject: [development] What about reviewing patches?
Message-ID: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>

All this rant about this and that and noone reviews patches. Shame on you.

From catch56 at googlemail.com  Wed Aug 13 16:31:03 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 13 Aug 2008 17:31:03 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
Message-ID: <fa5724270808130931n7527f35am1a57a49b6771761b@mail.gmail.com>

On Wed, Aug 13, 2008 at 5:07 PM, Karoly Negyesi  wrote:
> All this rant about this and that and noone reviews patches. Shame on you.
>

chx is right, and the patch review queue gets longer and longer.

There's over 320 just waiting to be reviewed against D7 [1] and over
200 against D6 [2], and that's just for core.

http://drupal.org/patch/review has just had a big overhaul, so if
you've not done patch reviews before, start there, or jump into
#drupal on irc and find many, many people willing to help get you
started.


[1] http://drupal.org/project/issues?projects=3060&states=8&versions=156281
[2] http://drupal.org/project/issues?projects=3060&versions=97368,280583

From development at robuustdesign.nl  Wed Aug 13 16:37:44 2008
From: development at robuustdesign.nl (Stefan Nagtegaal)
Date: Wed, 13 Aug 2008 18:37:44 +0200
Subject: [development] What about reviewing patches?
In-Reply-To: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
Message-ID: <ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>

Op 13 aug 2008, om 18:07 heeft Karoly Negyesi het volgende geschreven:
> All this rant about this and that and noone reviews patches. Shame  
> on you.

Why?
Reviewing patches would be much more fun if things would be committed  
sooner.
Patches stay in their current mode for days/weeks and even months  
untill they got committed.

I was one of the people who extensively tested and reviewed patches in  
the past, but completely lost my interest because of this.

I'm sorry Karoly, this is not against you in person but that's how I  
and other people feel about it.



Stefan




From cwgordon7 at cwgordon.com  Wed Aug 13 17:46:56 2008
From: cwgordon7 at cwgordon.com (Charlie Gordon)
Date: Wed, 13 Aug 2008 13:46:56 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
Message-ID: <48A31E10.3060004@cwgordon.com>

Stefan Nagtegaal wrote:
> Reviewing patches would be much more fun if things would be committed 
> sooner.
> Patches stay in their current mode for days/weeks and even months 
> untill they got committed.
On that note, why is there still no Drupal 7 branch maintainer? 
http://drupal.org/node/254640 has been postponed for months now, with no 
further explanation/discussion. A Drupal 7 maintainer would help 
eliminate that bottleneck in the patch cycle.

From drupal at ryancross.com  Wed Aug 13 18:21:54 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Thu, 14 Aug 2008 04:21:54 +1000
Subject: [development] What about reviewing patches?
In-Reply-To: <ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
Message-ID: <4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>

> Why?
> Reviewing patches would be much more fun if things would be committed
> sooner.
> Patches stay in their current mode for days/weeks and even months untill
> they got committed.

This seems like its becoming even more of an issue as the project
keeps growing. Its obviously a very major bottleneck in the developer
workflow (some could argue its a partially intentional choice) but it
does seem like its some discussion about possible ways of improving
this situation would be helpful.

Maybe speed of commitments isn't the key problem, but avoiding loosing
tester's motivations is something to consider. Or tackle the
committers speed if that is the underlying problem. Ideas?

From mpartap at gmx.net  Wed Aug 13 19:01:16 2008
From: mpartap at gmx.net (Marcel Partap)
Date: Wed, 13 Aug 2008 21:01:16 +0200
Subject: [development] What about reviewing patches?
In-Reply-To: <4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
Message-ID: <48A32F7C.9080104@gmx.net>

Ryan Cross wrote:
> Maybe speed of commitments isn't the key problem, but avoiding loosing
> tester's motivations is something to consider. Or tackle the
> committers speed if that is the underlying problem. Ideas?
> 
Mhh.. what about (auto-)committing to a D7.x-next branch after two 
independent people have confirmed a patch as working? That would give the 
process of reviewing patches more resoluteness, also liberating the core 
CVS admins to decide what gets in and what not. Patches that don't proof as 
a problem in 7.x-next could then be cherry-picked to 7.x-dev... Of course 
this would make running the next-branch a risky business, but at least it 
helps getting out of the situation where perfectly good and simple patches 
are not applied for weeks and months because the concerning code is being 
completly rewritten on some other issue (module system revamp f.e.)...
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 revolution: http://hfopi.org/vote-future

From catch56 at googlemail.com  Wed Aug 13 19:13:48 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 13 Aug 2008 20:13:48 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <48A32F7C.9080104@gmx.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net>
Message-ID: <fa5724270808131213j6a2f5ac3o14bce0c92bcad9b3@mail.gmail.com>

>>
> Mhh.. what about (auto-)committing to a D7.x-next branch after two
> independent people have confirmed a patch as working? That would give the
> process of reviewing patches more resoluteness, also liberating the core CVS
> admins to decide what gets in and what not. Patches that don't proof as a
> problem in 7.x-next could then be cherry-picked to 7.x-dev...

No-one runs 7.x, it's fairly unstable and isn't supported for either
upgrades or security releases - and that's the case right up until
release candidate, so I'm not sure what you're suggesting here.

While commits are a bottleneck at the moment. Reviews are a bottleneck
/all the time/.

Nat

PS. 10/1 odds on that more people reply to this thread than review
patches over the next couple of days. I'd love to be wrong of course.

From drupal-devel at webchick.net  Wed Aug 13 19:15:30 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Wed, 13 Aug 2008 15:15:30 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <48A32F7C.9080104@gmx.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net>
Message-ID: <48A332D2.4060209@webchick.net>

Marcel Partap wrote:
> Ryan Cross wrote:
>> Maybe speed of commitments isn't the key problem, but avoiding loosing
>> tester's motivations is something to consider. Or tackle the
>> committers speed if that is the underlying problem. Ideas?
>>
> Mhh.. what about (auto-)committing to a D7.x-next branch after two 
> independent people have confirmed a patch as working? That would give 
> the process of reviewing patches more resoluteness, also liberating the 
> core CVS admins to decide what gets in and what not. Patches that don't 
> proof as a problem in 7.x-next could then be cherry-picked to 7.x-dev... 
> Of course this would make running the next-branch a risky business, but 
> at least it helps getting out of the situation where perfectly good and 
> simple patches are not applied for weeks and months because the 
> concerning code is being completly rewritten on some other issue (module 
> system revamp f.e.)...
> regards_marcel.

Dear sweet Lord, NO! :)

It's imperative that HEAD remain stable at all times, and that automated 
tests continue to pass. There are a lot of seemingly "simple" patches 
that have lots of subtle ways that they break things if you're not 
careful. If we get into the situation where HEAD is broken, development 
effectively stops until things are working again.

It also makes a BIG difference who those two people are. Follow catch's 
advice. Catch is wise. The best shot you have of getting patches that 
you want in core is to become one of those rare patch reviewing ninjas 
like him. Then your voice being one of those two voices may very well be 
enough.

-Angie

From mpartap at gmx.net  Wed Aug 13 19:36:01 2008
From: mpartap at gmx.net (Marcel Partap)
Date: Wed, 13 Aug 2008 21:36:01 +0200
Subject: [development] What about reviewing patches?
In-Reply-To: <48A332D2.4060209@webchick.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>
Message-ID: <48A337A1.3010605@gmx.net>

Angela Byron wrote:
> careful. If we get into the situation where HEAD is broken, development 
> effectively stops until things are working again.
Nooooooo, 'cause not HEAD ;X
- 'next' or 'experimental' branch!

> It also makes a BIG difference who those two people are. Follow catch's 
> advice. Catch is wise. The best shot you have of getting patches that 
> you want in core is to become one of those rare patch reviewing ninjas 
> like him. Then your voice being one of those two voices may very well be 
> enough.
i'd love too but my excuse (as so many others') shall be: no real spare 
time atm. Also, of course i mostly care about bugs i run into myself, and i 
rarely run into any. Some people seem to report bugs using really obscure 
setups plus outdated modules...


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

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

From catch56 at googlemail.com  Wed Aug 13 19:52:46 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 13 Aug 2008 20:52:46 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <48A337A1.3010605@gmx.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
Message-ID: <fa5724270808131252k26b855dcu32b7a54972e053ad@mail.gmail.com>

>>
>> careful. If we get into the situation where HEAD is broken, development
>> effectively stops until things are working again.
>
> Nooooooo, 'cause not HEAD ;X
> - 'next' or 'experimental' branch!
>

Drupal 7 is the 'next' or 'experimental' branch. It's also likely to
have anything up to 1,000 people working on it (and at least about 50
at any one time) - so when it breaks, those people can't work.

>> i'd love too but my excuse (as so many others') shall be: no real spare time atm.

Some patch reviews take less than 30 seconds, especially when the
issue queue is long and has lots of stale patches in it. You've
already spent more than 30 seconds replying to this thread ;)

>> Also, of course i mostly care about bugs i run into myself, and i rarely run into any.

If you review some patches, the next time you report a bug, it's
likely others will pay more attention to it.

Nat

From katherine at esquaredworkshops.com  Wed Aug 13 20:08:58 2008
From: katherine at esquaredworkshops.com (Katherine Senzee)
Date: Wed, 13 Aug 2008 13:08:58 -0700
Subject: [development] What about reviewing patches?
In-Reply-To: <fa5724270808131252k26b855dcu32b7a54972e053ad@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
	<fa5724270808131252k26b855dcu32b7a54972e053ad@mail.gmail.com>
Message-ID: <da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>

On Wed, Aug 13, 2008 at 12:52 PM, Nathaniel Catchpole
<catch56 at googlemail.com> wrote:
> Some patch reviews take less than 30 seconds, especially when the
> issue queue is long and has lots of stale patches in it.

I'm not sure I follow. I review patches when I get the time, but I
figure on at least 20 minutes -- read the issue, check out HEAD, apply
the patch, create a new database, install the test site,
download/install devel, generate stuff, see if the patch works as
advertised, post my review. If I have a recent enough HEAD install I
figure I can skip the database bit and just use my existing database,
but it's still a decent chunk of time. What am I doing wrong?

-- 
Katherine Senzee (ksenzee)
esquaredworkshops.com

From dmitrig01 at gmail.com  Wed Aug 13 20:38:40 2008
From: dmitrig01 at gmail.com (Dmitri G)
Date: Wed, 13 Aug 2008 13:38:40 -0700
Subject: [development] What about reviewing patches?
In-Reply-To: <48A337A1.3010605@gmx.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
Message-ID: <9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>

"No real spare time."

What an excuse.

Somehow, people have spare time for all these rants, but no time for
patch reviews?

This does not make much sense to me.

Does anyone care to explain?

Dmitri

On Wed, Aug 13, 2008 at 12:36 PM, Marcel Partap <mpartap at gmx.net> wrote:
> Angela Byron wrote:
>>
>> careful. If we get into the situation where HEAD is broken, development
>> effectively stops until things are working again.
>
> Nooooooo, 'cause not HEAD ;X
> - 'next' or 'experimental' branch!
>
>> It also makes a BIG difference who those two people are. Follow catch's
>> advice. Catch is wise. The best shot you have of getting patches that you
>> want in core is to become one of those rare patch reviewing ninjas like him.
>> Then your voice being one of those two voices may very well be enough.
>
> i'd love too but my excuse (as so many others') shall be: no real spare time
> atm. Also, of course i mostly care about bugs i run into myself, and i
> rarely run into any. Some people seem to report bugs using really obscure
> setups plus outdated modules...
>
>
> --
>  "Obstacles are those frightful things you see when you take
>  your eyes off your goal."         -- Henry Ford (1863-1947)
>
>  Change the world! Vote revolution: http://hfopi.org/vote-future
>

From catch56 at googlemail.com  Wed Aug 13 20:45:07 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Wed, 13 Aug 2008 21:45:07 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
	<fa5724270808131252k26b855dcu32b7a54972e053ad@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
Message-ID: <fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>

On Wed, Aug 13, 2008 at 9:08 PM, Katherine Senzee wrote:
> On Wed, Aug 13, 2008 at 12:52 PM, Nathaniel Catchpole
>  wrote:
>> Some patch reviews take less than 30 seconds, especially when the
>> issue queue is long and has lots of stale patches in it.
>
> I'm not sure I follow. I review patches when I get the time, but I
> figure on at least 20 minutes -- read the issue, check out HEAD, apply
> the patch, create a new database, install the test site,
> download/install devel, generate stuff, see if the patch works as
> advertised, post my review. If I have a recent enough HEAD install I
> figure I can skip the database bit and just use my existing database,
> but it's still a decent chunk of time. What am I doing wrong?

20 minutes is about right to do a proper review, but a lot of patches
don't even apply any more, including RTBC ones.

So if you already have HEAD installed (I pretty much only clean my
database before or after reviewing a patch with an upgrade path or
schema change), you can do this:

// clean your HEAD of old changes.
cvs -q diff | patch -p0 -R

wget http://drupal.org/files/issues/somepatch.patch

patch -p0 < somepatch.patch

1 out of 1 hunks failed etc.

Mark to code needs work with 'needs a re-roll'.

Maybe 45 seconds then, but not too much more than that.

Also simpletest is a much, much easier and more comprehensive way to
avoid regressions that installing devel, generating content and
clicking around. So that stage is reduced to: admin/build/modules
enable simpletest
admin/build/testing run all tests

Although you can go make a cup of tea while the tests run, there's
little effort involved running them. You should obviously test the
actual functionality of the patch on top of this, but that's a bit
less RSI inducing.

Nat

From kathleen at ceardach.com  Wed Aug 13 21:21:25 2008
From: kathleen at ceardach.com (Kathleen Murtagh)
Date: Wed, 13 Aug 2008 17:21:25 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
	<9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
Message-ID: <1d83e3e60808131421w35b8c3d8ufda0d7d616f5c262@mail.gmail.com>

On Wed, Aug 13, 2008 at 4:38 PM, Dmitri G <dmitrig01 at gmail.com> wrote:
> "No real spare time."
>
> What an excuse.
>
> Somehow, people have spare time for all these rants, but no time for
> patch reviews?
>
> This does not make much sense to me.
>
> Does anyone care to explain?
>
> Dmitri

In terms of time management, I've been thinking a lot about this issue
:)  It comes down to patterns, motivation and task switching.

Patterns help you do things swiftly, or unconsciously.  Responding to
a mailing list is an example of doing something that takes time
unconsciously because we were checking our email _anyway_, what's
writing one more?  On the other hand, not having an environment set
up, or a system in place for going over patches makes it difficult
because there are too many conscious steps to address.  There isn't a
pattern or workflow set up, so the person has to consciously think of
the next step and work to improve upon the process with their given
environment.  There isn't yet any swiftness to following a pattern,
and you're well aware of the time that it will take.

That segways nicely into motivation.  In reading an email, we can be
inspired or angered to reply - and besides, we were checking our email
anyway.  A person may not be inspired to move and do some patch
reviews.  And if they're not inspired, setting up and maintaining that
environment to do the testing will be burdensome.

Then is task switching.  I know this one well :)  Although the actual
task itself may take a short amount of time, there is a significant
amount of overhead when switching from one task to another.  I can
work on one project and put in a 12 hour productive day.  However, if
I were asked to do three projects, I would likely work on only two in
the day, leaving the other out cold with only 6 productive hours, and
6 totally wasted hours due to overhead.  I am, obviously, an extreme
example of this phenomena.  However, a "20 minute" patch review can
very easily turn into an hour including the overhead of task
switching.

---
Kathleen Murtagh

From yuval at avramzon.net  Wed Aug 13 21:55:37 2008
From: yuval at avramzon.net (Yuval Hager)
Date: Thu, 14 Aug 2008 00:55:37 +0300
Subject: [development] What about reviewing patches?
In-Reply-To: <fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
Message-ID: <200808140055.43824.yuval@avramzon.net>

On Wednesday 13 August 2008, Nathaniel Catchpole wrote:
> So if you already have HEAD installed (I pretty much only clean my
> database before or after reviewing a patch with an upgrade path or
> schema change), you can do this:
>
> // clean your HEAD of old changes.
> cvs -q diff | patch -p0 -R
>
> wget http://drupal.org/files/issues/somepatch.patch
>
> patch -p0 < somepatch.patch
>
> 1 out of 1 hunks failed etc.
>
> Mark to code needs work with 'needs a re-roll'.

Can't this process be automated? I think I remember something about a process 
that scans for stale patches - does it still exist?. The 
close-fixed-after-two-weeks bot seems to be doing a very nice work!

-- 
Yuval Hager
[@] yuval at avramzon.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080814/bb0933fc/attachment.pgp 

From drewish at katherinehouse.com  Wed Aug 13 22:48:59 2008
From: drewish at katherinehouse.com (andrew morton)
Date: Wed, 13 Aug 2008 15:48:59 -0700
Subject: [development] What about reviewing patches?
In-Reply-To: <9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
	<9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
Message-ID: <fab053ce0808131548h51bf8bafy4833c348d4eccedb@mail.gmail.com>

On Wed, Aug 13, 2008 at 1:38 PM, Dmitri G <dmitrig01 at gmail.com> wrote:
> "No real spare time."
>
> What an excuse.
>
> Somehow, people have spare time for all these rants, but no time for
> patch reviews?
>
> This does not make much sense to me.
>
> Does anyone care to explain?
>
> Dmitri

Well I haven't had time for either but since you asked... I've burned
out on reviewing because I'd get excited about a patch try to help it
along and then.... nothing... it just gets ignored and never committed
or commented on by a committer. Sort of hard to stay motivated to keep
throwing good time after bad.

andrew

From stella at stellapower.net  Wed Aug 13 22:35:14 2008
From: stella at stellapower.net (Stella Power)
Date: Wed, 13 Aug 2008 23:35:14 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <200808140055.43824.yuval@avramzon.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
Message-ID: <cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>

There's a patch against the coder module waiting to be reviewed (I know it's
not core), but this patch will add functionality to coder which will allow
you to run a code review on patches.  You can paste in the patch, or just
provide the URL to it.  It might help speed up the process slightly.

Cheers,
Stella

On Wed, Aug 13, 2008 at 10:55 PM, Yuval Hager <yuval at avramzon.net> wrote:

> On Wednesday 13 August 2008, Nathaniel Catchpole wrote:
> > So if you already have HEAD installed (I pretty much only clean my
> > database before or after reviewing a patch with an upgrade path or
> > schema change), you can do this:
> >
> > // clean your HEAD of old changes.
> > cvs -q diff | patch -p0 -R
> >
> > wget http://drupal.org/files/issues/somepatch.patch
> >
> > patch -p0 < somepatch.patch
> >
> > 1 out of 1 hunks failed etc.
> >
> > Mark to code needs work with 'needs a re-roll'.
>
> Can't this process be automated? I think I remember something about a
> process
> that scans for stale patches - does it still exist?. The
> close-fixed-after-two-weeks bot seems to be doing a very nice work!
>
> --
> Yuval Hager
> [@] yuval at avramzon.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080813/fafd35e8/attachment.htm 

From morbus at disobey.com  Wed Aug 13 23:06:45 2008
From: morbus at disobey.com (Morbus Iff)
Date: Wed, 13 Aug 2008 19:06:45 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>	<48A337A1.3010605@gmx.net>
	<9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
Message-ID: <48A36905.8000007@disobey.com>

> Somehow, people have spare time for all these rants, but no time for
> patch reviews? This does not make much sense to me.
> Does anyone care to explain?

I've never bought this line of reasoning. Drupal core would be worst off 
if the same amount of time to send a flippant email was spent on a patch 
review. It's like comparing firing a gun to cleaning a gun.

-- 
Morbus Iff ( god less america )
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 kb at 2bits.com  Thu Aug 14 00:56:32 2008
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Wed, 13 Aug 2008 20:56:32 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <200808140055.43824.yuval@avramzon.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
Message-ID: <4a9fdc630808131756q22526b50u58d694cf2b67e5e7@mail.gmail.com>

On Wed, Aug 13, 2008 at 5:55 PM, Yuval Hager <yuval at avramzon.net> wrote:

> On Wednesday 13 August 2008, Nathaniel Catchpole wrote:
> > So if you already have HEAD installed (I pretty much only clean my
> > database before or after reviewing a patch with an upgrade path or
> > schema change), you can do this:
> >
> > // clean your HEAD of old changes.
> > cvs -q diff | patch -p0 -R
> >
> > wget http://drupal.org/files/issues/somepatch.patch
> >
> > patch -p0 < somepatch.patch
> >
> > 1 out of 1 hunks failed etc.
> >
> > Mark to code needs work with 'needs a re-roll'.
>
> Can't this process be automated? I think I remember something about a
> process
> that scans for stale patches - does it still exist?. The
> close-fixed-after-two-weeks bot seems to be doing a very nice work!
>

This is supposed to go here at some point http://testing.drupal.org/
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080813/d379bdad/attachment.htm 

From mhaggerty-lists at trellon.com  Thu Aug 14 02:04:46 2008
From: mhaggerty-lists at trellon.com (Michael Haggerty)
Date: Wed, 13 Aug 2008 22:04:46 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <48A36905.8000007@disobey.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>	<48A337A1.3010605@gmx.net>
	<9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
	<48A36905.8000007@disobey.com>
Message-ID: <F81E6EA8-9E08-4C14-9670-2084C15E5F5C@trellon.com>

Not if you just approve everything Morbus.

M

On Aug 13, 2008, at 7:06 PM, Morbus Iff wrote:

>> Somehow, people have spare time for all these rants, but no time for
>> patch reviews? This does not make much sense to me.
>> Does anyone care to explain?
>
> I've never bought this line of reasoning. Drupal core would be worst  
> off if the same amount of time to send a flippant email was spent on  
> a patch review. It's like comparing firing a gun to cleaning a gun.
>
> -- 
> Morbus Iff ( god less america )
> 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 z.stolar at gmail.com  Thu Aug 14 06:35:56 2008
From: z.stolar at gmail.com (Zohar Stolar)
Date: Thu, 14 Aug 2008 09:35:56 +0300
Subject: [development] What about reviewing patches?
In-Reply-To: <48A332D2.4060209@webchick.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>
Message-ID: <48A3D24C.7020401@gmail.com>


Angela Byron wrote:

> Marcel Partap wrote:
>> Mhh.. what about (auto-)committing to a D7.x-next branch after two 
>> independent people have confirmed a patch as working? 
>
> Dear sweet Lord, NO! :)
>
It does'nt have to be auto-committed, but if 2-3 persons have reviewed 
and marked RTBC, the status can escalate into something like TRTBC 
(Thoroughly RTBC).
This may have a nice effect on both the committers, as they will be more 
focused, and on the rest of us, since the more we review, the faster 
things will probably be committed.


From fsteiner-mail1 at bio.ifi.lmu.de  Thu Aug 14 09:24:05 2008
From: fsteiner-mail1 at bio.ifi.lmu.de (Frank Steiner)
Date: Thu, 14 Aug 2008 11:24:05 +0200
Subject: [development] What about reviewing patches?
In-Reply-To: <fab053ce0808131548h51bf8bafy4833c348d4eccedb@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>	<48A337A1.3010605@gmx.net>	<9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
	<fab053ce0808131548h51bf8bafy4833c348d4eccedb@mail.gmail.com>
Message-ID: <48A3F9B5.6030205@bio.ifi.lmu.de>

andrew morton wrote

> Well I haven't had time for either but since you asked... I've burned
> out on reviewing because I'd get excited about a patch try to help it
> along and then.... nothing... it just gets ignored and never committed
> or commented on by a committer. Sort of hard to stay motivated to keep
> throwing good time after bad.

Although I haven't either submitted nor reviewed patches for drupal core,
I can acknowledge this point because I see this with modules. Many of
the modules I need for 6.x were still in beta or not even upgraded to
6.x, so I tried to write and patch a lot of stuff by myself. With some
modules, I got feedback quite fast and so I went on patching and improving
for those.
But when you spent two weeks full-time work to add a feature (like attaching 
files for comments to use that in forums) and then get nothing but silence
for weeks, not even a "I will look at or test this", then you definitely
lose motivation to do any other patch for this module. I'm not blaming
module maintainers for this, since they might just not have enough time
to care about all this or more important things (or "real life" :-)) to do 
or whatever.

Although this is the view from the other side, I'm sure this is the same 
reviewing. People just want feedback about work they did, otherwise they
are disappointed and stop contributing.

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

From yuval at avramzon.net  Thu Aug 14 09:43:28 2008
From: yuval at avramzon.net (Yuval Hager)
Date: Thu, 14 Aug 2008 12:43:28 +0300
Subject: [development] What about reviewing patches?
In-Reply-To: <48A3F9B5.6030205@bio.ifi.lmu.de>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<fab053ce0808131548h51bf8bafy4833c348d4eccedb@mail.gmail.com>
	<48A3F9B5.6030205@bio.ifi.lmu.de>
Message-ID: <200808141243.29302.yuval@avramzon.net>

On Thursday 14 August 2008, Frank Steiner wrote:
>  I'm not blaming
> module maintainers for this, since they might just not have enough time
> to care about all this or more important things (or "real life" :-)) to do
> or whatever.

Well, I do blame them. Responsible maintainers *should* respond within two 
weeks to *any* bug they have on the issue queue. Any polite response would be 
better than silence.

Only a handful of complicatedmodules can skip this rule, but we all know their 
maintainers are responsible anyway :)

My own experience of Drupal core patches was also demotivating, where patches 
were discussed to every minor detail, not always in a professional way, but 
sometimes in a personal way, not without inappropriate comments or innuendos 
here and there. I have not reviewed enough to claim this counts for 
statistics, but it was enough to keep me away from core for a long time.

-- 
Yuval Hager
[@] yuval at avramzon.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080814/7328ef9b/attachment.pgp 

From mail at webthatworks.it  Thu Aug 14 12:53:10 2008
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Thu, 14 Aug 2008 14:53:10 +0200
Subject: [development] best pratices, test environment,
 patch review: clues how to make easier to contribute
Message-ID: <20080814145310.4128e906@dawn.webthatworks.it>

There are a lot of good tools for helping coders and reviewer.
There should be a lot of experience in building up a dev environment
*and* a patch review environment spread in the community but
"hidden".

If I had to put up a dev/review environment now I would:
* install drupal HEAD
* install coder devel modules(?)
* fill drupal with some data using devel
* backup

* update from cvs
* restore db connection setting
* apply a patch
- check if any schema change
* test (benchmark?)
* report
* restore db

Still this look very naive and I think there are a lot of tools that
could help without getting into module frenziness  and a lot of
details that could streamline the process or setup that may hide
some problems.
There is not a compact knowledge base of several techniques that may
make more profitable for people that already maintain drupal sites
to contribute to core and contrib. I think that most developers are
still applying common wisdom and their own hand made recipes.

code coverage, deploy, drupal automated staging toolkit, drush,
simpletest and auto test???

If tests are already automatically made on submitted patches,
preparing a testing environment isn't so critical for a patch
reviewer, but it could come handy for a developer.

If I had to improve the above naive method I'd start from writing a
script that given a patch url:
* update from cvs
* restore db connection setting
* apply the patch

Second thing I'd do would be to replicate the simpletest environment
and start testing the patch.

Then I'd choose a set of "important modules" and see if patches or
HEAD breaks them.
I think this looks a bit more tricky and may require some rcs
wizardry especially if I've my modules to test too.
Another thing I'd like to learn to do better is how to maintain
modified drupal core, supposing I submitted patch waiting and I'd
like to check if they still works when I update to HEAD/review a
patch and mix svn (or any rcs of choice) with drupal cvs.
A DVCS could come handy here... but... that's not the point here.

The material about how to put up a dev/review environment is sparse.
Something that may be interesting and I would like to read more
about or see them grouped or add some glue so that it would be
possible to guide people to a more rationalised dev/review
environment:

Using CVS to maintain a Drupal website
http://drupal.org/node/93966

R. Keeping Your Local and Remote Sites Synchronized
http://drupal.org/node/120617

Drupal development server configuration
http://www.garfieldtech.com/blog/drupal-dev-server

K. Moving Entire Drupal Site with Databases
http://drupal.org/node/120627

Migrating Database Changes From Development to Live Websites
http://drupal.org/node/199771

Drupal Performance Measurement & Benchmarking
http://drupal.org/node/282862

Drupal with safe mode enabled and open basedir
http://drupal.org/node/82223

More than one Drupal site on one machine
http://drupal.org/node/274

Transforming a default table names installation into a prefix table
names installation
http://drupal.org/node/195758

How-To: Virtual Hosting with Drupal
http://drupal.org/node/80472

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


From earnie at users.sourceforge.net  Thu Aug 14 12:53:58 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 14 Aug 2008 08:53:58 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <48A3D24C.7020401@gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A3D24C.7020401@gmail.com>
Message-ID: <20080814085358.c0alp3mwxwcg0osw@mail.progw.org>

Quoting Zohar Stolar <z.stolar at gmail.com>:

>
> Angela Byron wrote:
>
>> Marcel Partap wrote:
>>> Mhh.. what about (auto-)committing to a D7.x-next branch after two 
>>> independent people have confirmed a patch as working?
>>
>> Dear sweet Lord, NO! :)
>>
> It does'nt have to be auto-committed, but if 2-3 persons have 
> reviewed and marked RTBC, the status can escalate into something like 
> TRTBC (Thoroughly RTBC).
> This may have a nice effect on both the committers, as they will be 
> more focused, and on the rest of us, since the more we review, the 
> faster things will probably be committed.
>
>

Won't help.  We have a large funnel and the end of the funnel is a 
committer.  There is no way for the committer to catch up with all 
commits.  We need more committers to resolve that issue.

It'd be interesting and bazaar to see another repository of Drupal core 
where all CVS account holders could commit patches after review.  I 
wonder just how broken its HEAD would be.
  Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/


From catch56 at googlemail.com  Thu Aug 14 13:00:45 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 14 Aug 2008 14:00:45 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <48A3D24C.7020401@gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A3D24C.7020401@gmail.com>
Message-ID: <fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>

On Thu, Aug 14, 2008 at 7:35 AM, Zohar Stolar  wrote:

>>
> It does'nt have to be auto-committed, but if 2-3 persons have reviewed and
> marked RTBC, the status can escalate into something like TRTBC (Thoroughly
> RTBC).

This is what RTBC is, adding an extra status called Really Really
Reviewed and Tested by the Community and Thoroughly Ready to be
Committed (RRTBCTRBC). Due to the shortage of reviewers though,
patches don't always get confirmed as RTBC by two or more people,  so
it's not as solid as it should be - but that's a problem of lack of
reviews, not patch statuses.

Nat

From hovercrafter at earthlink.net  Thu Aug 14 13:05:33 2008
From: hovercrafter at earthlink.net (Jamie Holly)
Date: Thu, 14 Aug 2008 09:05:33 -0400
Subject: [development] best pratices, test environment,
 patch review: clues how to make easier to contribute
In-Reply-To: <20080814145310.4128e906@dawn.webthatworks.it>
References: <20080814145310.4128e906@dawn.webthatworks.it>
Message-ID: <48A42D9D.4090402@earthlink.net>

Something I think should be included in patch review is also database 
load. Check any new/changed queries the patch might make and do an 
explain on it to see if that query is properly using indexes and not 
going to bring the database server to a crawl. I don't know if there is 
a doc page on this. If not, it might be worth adding one, giving a brief 
tutorial on using explain.

On the benchmarking/testing, something I have found to be a nice 
addition to the toolbox is Siege. You can create a list of urls to 
different pages in your installation so you get more of a real world 
test (instead of benching a single page). When developing a site, I keep 
a url.txt file for that site just for this purpose. That way I can 
quickly run a benchmark.

Siege - http://www.joedog.org/JoeDog/Siege

(Also - if anyone has any other suggestions for benchmarking, I would 
love to hear it. I am always looking for new tools to use)

Jamie Holly
http://www.intoxination.net 
Skype:intoxination        Phone: 1-513-252-2919



Ivan Sergio Borgonovo wrote:
> There are a lot of good tools for helping coders and reviewer.
> There should be a lot of experience in building up a dev environment
> *and* a patch review environment spread in the community but
> "hidden".
>
> If I had to put up a dev/review environment now I would:
> * install drupal HEAD
> * install coder devel modules(?)
> * fill drupal with some data using devel
> * backup
>
> * update from cvs
> * restore db connection setting
> * apply a patch
> - check if any schema change
> * test (benchmark?)
> * report
> * restore db
>
> Still this look very naive and I think there are a lot of tools that
> could help without getting into module frenziness  and a lot of
> details that could streamline the process or setup that may hide
> some problems.
> There is not a compact knowledge base of several techniques that may
> make more profitable for people that already maintain drupal sites
> to contribute to core and contrib. I think that most developers are
> still applying common wisdom and their own hand made recipes.
>
> code coverage, deploy, drupal automated staging toolkit, drush,
> simpletest and auto test???
>
> If tests are already automatically made on submitted patches,
> preparing a testing environment isn't so critical for a patch
> reviewer, but it could come handy for a developer.
>
> If I had to improve the above naive method I'd start from writing a
> script that given a patch url:
> * update from cvs
> * restore db connection setting
> * apply the patch
>
> Second thing I'd do would be to replicate the simpletest environment
> and start testing the patch.
>
> Then I'd choose a set of "important modules" and see if patches or
> HEAD breaks them.
> I think this looks a bit more tricky and may require some rcs
> wizardry especially if I've my modules to test too.
> Another thing I'd like to learn to do better is how to maintain
> modified drupal core, supposing I submitted patch waiting and I'd
> like to check if they still works when I update to HEAD/review a
> patch and mix svn (or any rcs of choice) with drupal cvs.
> A DVCS could come handy here... but... that's not the point here.
>
> The material about how to put up a dev/review environment is sparse.
> Something that may be interesting and I would like to read more
> about or see them grouped or add some glue so that it would be
> possible to guide people to a more rationalised dev/review
> environment:
>
> Using CVS to maintain a Drupal website
> http://drupal.org/node/93966
>
> R. Keeping Your Local and Remote Sites Synchronized
> http://drupal.org/node/120617
>
> Drupal development server configuration
> http://www.garfieldtech.com/blog/drupal-dev-server
>
> K. Moving Entire Drupal Site with Databases
> http://drupal.org/node/120627
>
> Migrating Database Changes From Development to Live Websites
> http://drupal.org/node/199771
>
> Drupal Performance Measurement & Benchmarking
> http://drupal.org/node/282862
>
> Drupal with safe mode enabled and open basedir
> http://drupal.org/node/82223
>
> More than one Drupal site on one machine
> http://drupal.org/node/274
>
> Transforming a default table names installation into a prefix table
> names installation
> http://drupal.org/node/195758
>
> How-To: Virtual Hosting with Drupal
> http://drupal.org/node/80472
>
>   

From cxjohnson at gmail.com  Thu Aug 14 13:09:49 2008
From: cxjohnson at gmail.com (Chris Johnson)
Date: Thu, 14 Aug 2008 08:09:49 -0500
Subject: [development] What about reviewing patches?
In-Reply-To: <da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
	<fa5724270808131252k26b855dcu32b7a54972e053ad@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
Message-ID: <9ea8d6030808140609la2ca925i7e5d3e6727cd47e5@mail.gmail.com>

You are doing nothing wrong, Katherine.

Everybody reads their email with an email client that's been optimized
with years and years of experience.  Virtually no one has a Drupal
development environment and tools which have been optimized to that
extent.  As you described, Katherine, it takes real time to install
and test patches.  I took about 2 minutes to write this, far less time
than it would even take to go find a patch I was interested in, read
the issue and download the patch, much less give it a thorough test
and then write a review of that test.

Folks who suggest you can do reviews in the time it takes to review or
write a quick comment in email are wrong, wrong, wrong for 99.9% of
the development community out there.

..chris

On Wed, Aug 13, 2008 at 3:08 PM, Katherine Senzee
<katherine at esquaredworkshops.com> wrote:
> On Wed, Aug 13, 2008 at 12:52 PM, Nathaniel Catchpole
> <catch56 at googlemail.com> wrote:
>> Some patch reviews take less than 30 seconds, especially when the
>> issue queue is long and has lots of stale patches in it.
>
> I'm not sure I follow. I review patches when I get the time, but I
> figure on at least 20 minutes -- read the issue, check out HEAD, apply
> the patch, create a new database, install the test site,
> download/install devel, generate stuff, see if the patch works as
> advertised, post my review. If I have a recent enough HEAD install I
> figure I can skip the database bit and just use my existing database,
> but it's still a decent chunk of time. What am I doing wrong?
>
> --
> Katherine Senzee (ksenzee)
> esquaredworkshops.com
>

From drupal at ryancross.com  Thu Aug 14 13:11:02 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Thu, 14 Aug 2008 23:11:02 +1000
Subject: [development] What about reviewing patches?
In-Reply-To: <20080814085358.c0alp3mwxwcg0osw@mail.progw.org>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A3D24C.7020401@gmail.com>
	<20080814085358.c0alp3mwxwcg0osw@mail.progw.org>
Message-ID: <4e983be00808140611x560d02b2lc371564fdf645c7d@mail.gmail.com>

>
> Won't help.  We have a large funnel and the end of the funnel is a
> committer.  There is no way for the committer to catch up with all commits.
>  We need more committers to resolve that issue.

Hard to argue with that. However - is there anyway we can make the
committers job easier? and related, is there a way we can get work
that in "the funnel" to keep moving farther to the end so that people
don't get discouraged being stuck on the sidelines.

>
> It'd be interesting and bazaar to see another repository of Drupal core
> where all CVS account holders could commit patches after review.  I wonder
> just how broken its HEAD would be.

I agree that a free-for-all could be pretty messy (especially without
a reasonable transition) but I would point out that there are lots of
projects that operate with more than 2-3 committers. I believe I've
seen references to projects like svn having ~150 "core" committers or
apache having 100+ committers.

From earnie at users.sourceforge.net  Thu Aug 14 13:11:02 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 14 Aug 2008 09:11:02 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
Message-ID: <20080814091102.lwpkj4gr3xko0soo@mail.progw.org>

Quoting Stella Power <stella at stellapower.net>:

> There's a patch against the coder module waiting to be reviewed (I know it's
> not core), but this patch will add functionality to coder which will allow
> you to run a code review on patches.  You can paste in the patch, or just
> provide the URL to it.  It might help speed up the process slightly.
>

Then a project infrastructure process could just automate a run of the 
patch against coder and give a report (or a flag) in the issue.

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


From catch56 at googlemail.com  Thu Aug 14 13:17:57 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 14 Aug 2008 14:17:57 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <20080814091102.lwpkj4gr3xko0soo@mail.progw.org>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>
Message-ID: <fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>

On Thu, Aug 14, 2008 at 2:11 PM, Earnie Boyd  wrote:
> Quoting Stella Power
>
>> There's a patch against the coder module waiting to be reviewed (I know
>> it's
>> not core), but this patch will add functionality to coder which will allow
>> you to run a code review on patches.  You can paste in the patch, or just
>> provide the URL to it.  It might help speed up the process slightly.
>>
>
> Then a project infrastructure process could just automate a run of the patch
> against coder and give a report (or a flag) in the issue.
>

This seems like a very reasonable thing to add into testing.drupal.org
once it's up and running.

From drupal at ryancross.com  Thu Aug 14 13:30:50 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Thu, 14 Aug 2008 23:30:50 +1000
Subject: [development] best pratices, test environment,
	patch review: clues how to make easier to contribute
In-Reply-To: <20080814145310.4128e906@dawn.webthatworks.it>
References: <20080814145310.4128e906@dawn.webthatworks.it>
Message-ID: <4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>

On Thu, Aug 14, 2008 at 10:53 PM, Ivan Sergio Borgonovo
<mail at webthatworks.it> wrote:

> There is not a compact knowledge base of several techniques that may
> make more profitable for people that already maintain drupal sites
> to contribute to core and contrib. I think that most developers are
> still applying common wisdom and their own hand made recipes.
>

Actually, there is....
http://drupal.org/patch/review

and in more general there is the entire contributors guide handbook about this.

>
> If tests are already automatically made on submitted patches,
> preparing a testing environment isn't so critical for a patch
> reviewer, but it could come handy for a developer.
>

One of the major reasons for push to get unit tests written is so that
this basic type of review can be automated within the issue queue. You
can already load these tests yourself and test them automatically.

> The material about how to put up a dev/review environment is sparse.

again not correct..... Setting up a test environment to review
patches: http://drupal.org/node/28245

However, I think that most of this problem is not really a lack of
documentation for doing these reviews. Anyone that is sufficiently
interested can find this stuff out or ask someone and learn very
easily. I think more of this issue is community and infrastructure
based.

-Ryan

From drupal-devel at webchick.net  Thu Aug 14 13:43:37 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Thu, 14 Aug 2008 09:43:37 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>	<48A3D24C.7020401@gmail.com>
	<fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>
Message-ID: <48A43689.5050602@webchick.net>

Nathaniel Catchpole wrote:
> On Thu, Aug 14, 2008 at 7:35 AM, Zohar Stolar  wrote:
> 
>> It does'nt have to be auto-committed, but if 2-3 persons have reviewed and
>> marked RTBC, the status can escalate into something like TRTBC (Thoroughly
>> RTBC).
> 
> This is what RTBC is, adding an extra status called Really Really
> Reviewed and Tested by the Community and Thoroughly Ready to be
> Committed (RRTBCTRBC). Due to the shortage of reviewers though,
> patches don't always get confirmed as RTBC by two or more people,  so
> it's not as solid as it should be - but that's a problem of lack of
> reviews, not patch statuses.

I agree.

The people complaining about the long RTBC queue are missing the point. 
The point is that there's a much, much longer "needs review" queue, and 
there always has been.

While some of those RTBC patches will eventually get committed, none of 
the "needs review" patches will unless we get some help.

-Angie


From alex at developmentseed.org  Thu Aug 14 13:47:04 2008
From: alex at developmentseed.org (Alex Barth)
Date: Thu, 14 Aug 2008 09:47:04 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <200808121033.30082.drupal@dave-cohen.com>
References: <200808090758.01373.yuval@avramzon.net>
	<089AE725-6A8B-4720-B5C7-5EE29D184FD3@developmentseed.org>
	<1d83e3e60808120650p5c3b85b0ud646e1f75b416e4c@mail.gmail.com>
	<200808121033.30082.drupal@dave-cohen.com>
Message-ID: <5D29CA7A-CDD0-45D4-9E1C-AF5278A4D7B8@developmentseed.org>


On Aug 12, 2008, at 1:33 PM, Dave Cohen wrote:
> In your model taxonomy is "content" while variables are  
> "configuration".
> Let's say on my site, one of my taxonomies is "privacy" with terms
> like "public", "administrator only", etc...  Further I configure one  
> of the
> taxonomy access control modules to use my privacy terms.
>
> In my mind those terms are part of "configuration" (while other  
> terms might be
> considered "content").

While really convenient, I'm starting to consider using taxonomy as  
configuration as bad practice.

In the long run, building effective import/export and migration tools  
will also mean having a clean distinction between what's content and  
what's configuration on the Drupal level...

>
>
> While in your model as I understand it, I now have some variables
> (configuration, of the access control module) referring to my term ids
> (content).  So the line is crossed, I can't replicate the  
> configuration
> unless I also replicate the content.  If I understand you correctly.
>
> I say this trying to point out that we can't simply divide Drupal's  
> database
> into "content" tables and "configuration" tables.  Unfortunately is  
> will
> never be that simple.  There are many examples like this where the  
> line
> between content and configuration is fuzzy.
>
> While I'm pessimistic about that particular idea, I'm optimistic  
> about the
> UUID idea being discussed in the "Unique/Random IDs and drupal"  
> thread.  I
> think using UUIDs rather than sequential ids will solve a big huge  
> chunk of
> the dev->staging->live problem.
>
> -Dave
>
>
> On Tuesday 12 August 2008, Kathleen Murtagh wrote:
>> Configuration are things like the variables, blocks, cck type and
>> field definitions, etc  (you can configure settings.php to have  
>> unique
>> variable settings on dev and prod). Content is nodes, taxonomy, menu,
>> path, etc.
>
>

Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633





From alex at developmentseed.org  Thu Aug 14 13:52:54 2008
From: alex at developmentseed.org (Alex Barth)
Date: Thu, 14 Aug 2008 09:52:54 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <1d83e3e60808121352q19381099v95edeb021eb2ce0c@mail.gmail.com>
References: <200808090758.01373.yuval@avramzon.net>
	<C511E0EA-D30B-480C-B782-6011EC345376@civicactions.com>
	<BD742448-D65E-4ADE-8B84-9CEF9F158B35@bryght.com>
	<200808091822.17895.drupal@samboyer.org>
	<A8DAC01C-27E9-44FE-893A-6E3BB88810D0@bryght.com>
	<29AC6FDA-C3FD-4D6F-BF1C-CE45B89F7E32@pajunas.com>
	<1d83e3e60808121352q19381099v95edeb021eb2ce0c@mail.gmail.com>
Message-ID: <7CFC4C0E-7E6A-4B65-A84C-76FF7158D8B4@developmentseed.org>


On Aug 12, 2008, at 4:52 PM, Kathleen Murtagh wrote:
> On Tue, Aug 12, 2008 at 2:41 PM, Allie Micka <allie at pajunas.com>  
> wrote:
>> On Aug 9, 2008, at 8:09 PM, Adrian Rossouw wrote:
>>> One of the things I would like to see in deploy , or any system we  
>>> end up
>>> using,
>>> is the ability to generate a module with a .install file for the
>>> configuration info
>>> in install and update_x hooks.
>>>
>>> This allows developers to version their code and configuration  
>>> with their
>>> version tracking
>>> system, and roll out new releases the same way they would normally.
>>
>>
>> So my contribution to this thread will be a most-helpful +1.  This  
>> is how we
>> do pretty much everything around here, and I'd be disappointed in any
>> solution that wasn't equally as useful.
>
> Another +1.  This is along the lines of what I meant when I said I am
> dreaming of having automated database migrations for Drupal.

I really urge you to take a look at
http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/alex_b/port/

and let me know what you're thinking.

I built port module with exactly that in mind: code in version  
control, generate install profiles, export/import functions for  
deployment modules. I got in touch with Boris on how to join forces  
over port and install profile api - because that's the module I see  
most overlap with.

>
>
> Something quick and easy where someone could say, "Ok, everything I
> just did, export it".  Then the next developer can add importing those
> changes as part of their update workflow.
>
> Something where, a month along in development, someone could say, "You
> know, that commit was bad" and remove that commit from the system,
> including any database changes that were made.
>
> ---
> Kathleen Murtagh

Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633





From cxjohnson at gmail.com  Thu Aug 14 13:56:00 2008
From: cxjohnson at gmail.com (Chris Johnson)
Date: Thu, 14 Aug 2008 08:56:00 -0500
Subject: [development] What about reviewing patches?
In-Reply-To: <1d83e3e60808131421w35b8c3d8ufda0d7d616f5c262@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
	<9d2095ce0808131338u5c4a5531lf64bdb171fd23441@mail.gmail.com>
	<1d83e3e60808131421w35b8c3d8ufda0d7d616f5c262@mail.gmail.com>
Message-ID: <9ea8d6030808140655t12f77060x95dad55edb2e7d78@mail.gmail.com>

On Wed, Aug 13, 2008 at 4:21 PM, Kathleen Murtagh <kathleen at ceardach.com> wrote:


> In terms of time management, I've been thinking a lot about this issue
> :)  It comes down to patterns, motivation and task switching.

Exactly.  And tooling.  The world of software development has been
standardizing and optimizing the email client for more years and far
more man-years than the "test patch files against CVS" environment.


> Then is task switching.  I know this one well :)  Although the actual

> 6 totally wasted hours due to overhead.  I am, obviously, an extreme
> example of this phenomena.  However, a "20 minute" patch review can

> Kathleen Murtagh

No, you're not an extreme case.  You're just far more observant and
informed about the issue than most.  In their classic book Peopleware
, Tom DeMarco and Tim Lister report on studies of programmers'
productivity relative to the characteristics of their work
environment.

"It is clear that interruptions are a major cause of low productivity
among programmers. Why? The problem is not the time needed to handle
the interruptions themselves, but the time needed to get back into the
programming problem. Everybody, no matter what they do, face a
reorientation time when they return to their work after an
interruption. When you are reading a magazine article and look up to
answer a question, it takes you longer to read the next paragraph than
if you had been reading continuously."
  -- from this article:
http://www.ibm.com/developerworks/library/it-nielsen4/?dwzone=ibm

From cxjohnson at gmail.com  Thu Aug 14 14:05:23 2008
From: cxjohnson at gmail.com (Chris Johnson)
Date: Thu, 14 Aug 2008 09:05:23 -0500
Subject: [development] What about reviewing patches?
In-Reply-To: <fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A337A1.3010605@gmx.net>
	<fa5724270808131252k26b855dcu32b7a54972e053ad@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
Message-ID: <9ea8d6030808140705y6132f805g3ea2536f73dd8912@mail.gmail.com>

On Wed, Aug 13, 2008 at 3:45 PM, Nathaniel Catchpole
<catch56 at googlemail.com> wrote:

> So if you already have HEAD installed (I pretty much only clean my
> database before or after reviewing a patch with an upgrade path or
> schema change), you can do this:
>
> // clean your HEAD of old changes.
> cvs -q diff | patch -p0 -R
>
> wget http://drupal.org/files/issues/somepatch.patch
>
> patch -p0 < somepatch.patch
>
> 1 out of 1 hunks failed etc.
>
> Mark to code needs work with 'needs a re-roll'.

> Also simpletest is a much, much easier and more comprehensive way to
> avoid regressions that installing devel, generating content and
> clicking around. So that stage is reduced to: admin/build/modules
> enable simpletest
> admin/build/testing run all tests

Brilliant.  We need more of this kind of cook-book, how to do
something quickly and efficiently sort of documentation.

I've been using cvs and patch for about 25 years, and I never thought
to combine them in "cvs -q diff | patch -p0 -R".  There's always
something new to learn.  (I think simply running "cvs update -C" gets
you the same end result.)

From sirkitree at gmail.com  Thu Aug 14 14:12:19 2008
From: sirkitree at gmail.com (Jerad Bitner)
Date: Thu, 14 Aug 2008 10:12:19 -0400
Subject: [development] Patch reviewing best practices [was] What about
	reviewing patches?
Message-ID: <215a89c90808140712y18757043ka6f1ce46e9c17f06@mail.gmail.com>

So I'd like to hear from those of you who do a lot of core patch reviews to
find out what is your workflow?

It was pointed out in the last thread that it's not a matter of it taking a
long time to actually review a patch, but to get everything in place in
order to review a patch and having a standard environment setup that is
conducive to reviewing patches. I'm sure there are many devs out there that
have a standard set of steps they go through to test out a d6 patch and
something similar for then testing out a d7 patch. I'm sure it would help
many people to hear some of these setups in order to replicate these
practices on their own machines and get some patch reviewing done. If
anything, comparing notes from different developers on how they approach
this could lead to some great standard set of practices and therefor,
handbook pages ;)

~Jerad
sirkitree.net
drupalmao.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080814/411295bf/attachment.htm 

From sirkitree at gmail.com  Thu Aug 14 14:17:29 2008
From: sirkitree at gmail.com (Jerad Bitner)
Date: Thu, 14 Aug 2008 10:17:29 -0400
Subject: [development] best pratices, test environment,
	patch review: clues how to make easier to contribute
In-Reply-To: <4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>
References: <20080814145310.4128e906@dawn.webthatworks.it>
	<4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>
Message-ID: <215a89c90808140717y1e40347cke1df74d4a676e565@mail.gmail.com>

Ryan, thanks!

I started another thread on this subject not knowing these pages exist.

~Jerad

On Thu, Aug 14, 2008 at 9:30 AM, Ryan Cross <drupal at ryancross.com> wrote:

> On Thu, Aug 14, 2008 at 10:53 PM, Ivan Sergio Borgonovo
> <mail at webthatworks.it> wrote:
>
> > There is not a compact knowledge base of several techniques that may
> > make more profitable for people that already maintain drupal sites
> > to contribute to core and contrib. I think that most developers are
> > still applying common wisdom and their own hand made recipes.
> >
>
> Actually, there is....
> http://drupal.org/patch/review
>
> and in more general there is the entire contributors guide handbook about
> this.
>
> >
> > If tests are already automatically made on submitted patches,
> > preparing a testing environment isn't so critical for a patch
> > reviewer, but it could come handy for a developer.
> >
>
> One of the major reasons for push to get unit tests written is so that
> this basic type of review can be automated within the issue queue. You
> can already load these tests yourself and test them automatically.
>
> > The material about how to put up a dev/review environment is sparse.
>
> again not correct..... Setting up a test environment to review
> patches: http://drupal.org/node/28245
>
> However, I think that most of this problem is not really a lack of
> documentation for doing these reviews. Anyone that is sufficiently
> interested can find this stuff out or ask someone and learn very
> easily. I think more of this issue is community and infrastructure
> based.
>
> -Ryan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080814/182a5de9/attachment.htm 

From drupal at rocktreesky.com  Thu Aug 14 14:18:17 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Thu, 14 Aug 2008 10:18:17 -0400
Subject: [development] best pratices, test environment,
	patch review: clues how to make easier to contribute
In-Reply-To: <4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>
References: <20080814145310.4128e906@dawn.webthatworks.it>
	<4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>
Message-ID: <2AF1A3E3-5C6F-4FB7-B1E5-BBDB4CA2296D@rocktreesky.com>

Ryan, has pointed out the main resources that we have for this that  
already exist. That isn't to say that things can't be improved. Catch  
*just* redid the patch/review page and PLEASE feel free to hop in and  
help fill out the issue for the new Testing section of the Getting  
Involved guide: http://drupal.org/node/240216. For more background on  
that book and where the Testing section will fit, read the front page  
post re: docs http://drupal.org/node/293455.

Thanks
Addi

On Aug 14, 2008, at 9:30 AM, Ryan Cross wrote:

> On Thu, Aug 14, 2008 at 10:53 PM, Ivan Sergio Borgonovo
> <mail at webthatworks.it> wrote:
>
>> There is not a compact knowledge base of several techniques that may
>> make more profitable for people that already maintain drupal sites
>> to contribute to core and contrib. I think that most developers are
>> still applying common wisdom and their own hand made recipes.
>>
>
> Actually, there is....
> http://drupal.org/patch/review
>
> and in more general there is the entire contributors guide handbook  
> about this.
>
>>
>> If tests are already automatically made on submitted patches,
>> preparing a testing environment isn't so critical for a patch
>> reviewer, but it could come handy for a developer.
>>
>
> One of the major reasons for push to get unit tests written is so that
> this basic type of review can be automated within the issue queue. You
> can already load these tests yourself and test them automatically.
>
>> The material about how to put up a dev/review environment is sparse.
>
> again not correct..... Setting up a test environment to review
> patches: http://drupal.org/node/28245
>
> However, I think that most of this problem is not really a lack of
> documentation for doing these reviews. Anyone that is sufficiently
> interested can find this stuff out or ask someone and learn very
> easily. I think more of this issue is community and infrastructure
> based.
>
> -Ryan


From weitzman at tejasa.com  Thu Aug 14 14:56:06 2008
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Thu, 14 Aug 2008 10:56:06 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <48A43689.5050602@webchick.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A3D24C.7020401@gmail.com>
	<fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>
	<48A43689.5050602@webchick.net>
Message-ID: <6117a7500808140756n4fb05266i51212209d714d32a@mail.gmail.com>

> The people complaining about the long RTBC queue are missing the point. The
> point is that there's a much, much longer "needs review" queue, and there
> always has been.

Perhaps they are missing *your* point. The RTBC queue is a big problem
as well. Many patches in RTBC represent a massive effort by several
people and it is a complete shame to let them sit there, silently.
Losing a baserunner on 3rd base is much more painful than losing one
at second base. We terribly need a branch maintainer or two for D7.
Lack of throughput at RTBC demotivates the 'needs review' queue, and
even before that - patch creation.

Examples of RTBC silence:
1. make drupal_set_title() use check_plain() by default. -
http://drupal.org/node/242873
2. No way to flush form errors during iterative programatic form
submission - http://drupal.org/node/180063
3. Node revisions test fails if admin has a personal timezone offset -
http://drupal.org/node/283246

From mail at webthatworks.it  Thu Aug 14 15:17:41 2008
From: mail at webthatworks.it (Ivan Sergio Borgonovo)
Date: Thu, 14 Aug 2008 17:17:41 +0200
Subject: [development] best pratices, test environment,
 patch review: clues how to make easier to contribute
In-Reply-To: <4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>
References: <20080814145310.4128e906@dawn.webthatworks.it>
	<4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>
Message-ID: <20080814171741.664e28a9@dawn.webthatworks.it>

On Thu, 14 Aug 2008 23:30:50 +1000
"Ryan Cross" <drupal at ryancross.com> wrote:

> On Thu, Aug 14, 2008 at 10:53 PM, Ivan Sergio Borgonovo
> <mail at webthatworks.it> wrote:
> 
> > There is not a compact knowledge base of several techniques that
> > may make more profitable for people that already maintain drupal
> > sites to contribute to core and contrib. I think that most
> > developers are still applying common wisdom and their own hand
> > made recipes.

> Actually, there is....
> http://drupal.org/patch/review

> again not correct..... Setting up a test environment to review
> patches: http://drupal.org/node/28245

The only major thing I see that differ from what I consider a naive
approach is to name "label" the copy with the issue #.

That setup is not going to test if everything keep working on a
multi-site setup or with some prefixed tables.

I'd consider interesting to include in the test some popular
modules... or include some modules that just "test" a set of core
API.

It would be nice to share some more wisdom like Larry did about
development environment.

I think teaching how people can manage and integrate their everyday
job and patch review/patch contribution could help a lot.
eg. there are patches that are still waiting to be applied but that
are required in certain environment + people maintaining their own
modules.

So the process to test a patch for some people may become:
* keep a set of internal patch to Drupal core.
* install Drupal along with some "interesting" modules as multisite
+ db prefix + some data produced by devel module

* get Drupal HEAD
* apply internal patches to core
* apply issue queue patch
* restore "clean" test db

Now I'll gain another bit of unpopularity.

If I use Drupal, I've to patch core, my patches are seldom committed
but I've no easy way to check if other patches play nice with
mine... I'd prefer the status quo. Reviewing doesn't look as an
interesting activity... my focus will be on "when do my patch get
into core" and "how do I handle next core/module update?".
If on the other side reviewing patches is part of my everyday job
(eg. I review changes from colleagues in my drupal shop already) a)
I'll see more patches approved including mine b) I won't suffer the
"task switch" effect Kathleen was mentioning c) I'll work in a
uniform environment when developing my modules/core patches and an
uniform environment similar to the one used by other developers
making communication easier.

I'm not saying someone has to be blamed. I just would like to see
more discussion, learn more etc...
I think there is still a lot of hidden wisdom about best practices
and coming up with some sort of standardisation may lower the
learning curve and provide a common dev environment that could make
testing, applying patches and communication among dev easier.

As Kathleen and Chris pointed out we miss a common pattern for "test
patch files" in a more complex development environment (think about
Drupal shops).
I'm not sure if this is lack of infrastructure as you pointed out
or lack of common best practices that are suited for more complex
environment than just a plain Drupal install and a patch at a time.

Or maybe I'm just too optimist and I believe that there should be a
way to make all this a bit easier. Maybe all this fuss will help me
to accept it's not going to be easy, accept that in certain
environment a patch review is going to cost more than 20min and
concentrate on work that can actually be done in spite of wasting
time trying to turn lead into gold.

I just would like to know what others think and how they manage
their patch/review env when it get more complex.

BTW I get an access denied here
http://drupal.org/node/283840

BTW2 among the list of interesting documents I forgot to add other
than /review there should be also Drupal coding standards.

thanks

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


From earnie at users.sourceforge.net  Thu Aug 14 15:23:23 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 14 Aug 2008 11:23:23 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <5D29CA7A-CDD0-45D4-9E1C-AF5278A4D7B8@developmentseed.org>
References: <200808090758.01373.yuval@avramzon.net>
	<089AE725-6A8B-4720-B5C7-5EE29D184FD3@developmentseed.org>
	<1d83e3e60808120650p5c3b85b0ud646e1f75b416e4c@mail.gmail.com>
	<200808121033.30082.drupal@dave-cohen.com>
	<5D29CA7A-CDD0-45D4-9E1C-AF5278A4D7B8@developmentseed.org>
Message-ID: <20080814112323.qsuvmowdng0swc48@mail.progw.org>

Quoting Alex Barth <alex at developmentseed.org>:

>
> While really convenient, I'm starting to consider using taxonomy as  
> configuration as bad practice.
>
> In the long run, building effective import/export and migration tools 
>  will also mean having a clean distinction between what's content and 
>  what's configuration on the Drupal level...
>

But you just need to know which vocabularies are configuration; so you 
design the tool to take it into account.

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


From catch56 at googlemail.com  Thu Aug 14 15:31:16 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 14 Aug 2008 16:31:16 +0100
Subject: [development] best pratices, test environment,
	patch review: clues how to make easier to contribute
In-Reply-To: <20080814171741.664e28a9@dawn.webthatworks.it>
References: <20080814145310.4128e906@dawn.webthatworks.it>
	<4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>
	<20080814171741.664e28a9@dawn.webthatworks.it>
Message-ID: <fa5724270808140831r4d6802efq43a50f7d9a6324b7@mail.gmail.com>

Ivan Sergio Borgonovo wrote:
>
> That setup is not going to test if everything keep working on a
> multi-site setup or with some prefixed tables.

SimpleTest uses prefixed tables, so that point is moot.

The number of patches which are likely to affect multisite installs
are very, very little, maybe 1/1000.

>
> I'd consider interesting to include in the test some popular
> modules... or include some modules that just "test" a set of core
> API.
>
Again, SimpleTest - have you actually downloaded Drupal 7 and tried it out?

As to popular modules, when you find a 7.x version of Views and CCK,
please let me know. If you fancy porting some modules to 7.x early and
often to help test new APIs I'm sure maintainers of those modules will
welcome patches.

> BTW I get an access denied here
> http://drupal.org/node/283840

That page is now  merged into http://drupal.org/patch/review

Nat

From drupal at ryancross.com  Thu Aug 14 15:32:27 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Fri, 15 Aug 2008 01:32:27 +1000
Subject: [development] best pratices, test environment,
	patch review: clues how to make easier to contribute
In-Reply-To: <20080814171741.664e28a9@dawn.webthatworks.it>
References: <20080814145310.4128e906@dawn.webthatworks.it>
	<4e983be00808140630o41a6593s3f487ced072ab686@mail.gmail.com>
	<20080814171741.664e28a9@dawn.webthatworks.it>
Message-ID: <4e983be00808140832p6c9c31ccje0362b38b2c045a3@mail.gmail.com>

> If I use Drupal, I've to patch core...

I think that is probably the root of most of your problems

>
> I just would like to know what others think and how they manage
> their patch/review env when it get more complex.
>

The key with reviewing patches is to *not* use a complex environment.
You have to test and review patches against HEAD. If you want to
further test them against your customized version of drupal, then that
is a separate task and isn't relevant to getting that patch into core.

-Ryan

From alex at developmentseed.org  Thu Aug 14 16:06:51 2008
From: alex at developmentseed.org (Alex Barth)
Date: Thu, 14 Aug 2008 12:06:51 -0400
Subject: [development] Solving the dev->staging->live problem
In-Reply-To: <20080814112323.qsuvmowdng0swc48@mail.progw.org>
References: <200808090758.01373.yuval@avramzon.net>
	<089AE725-6A8B-4720-B5C7-5EE29D184FD3@developmentseed.org>
	<1d83e3e60808120650p5c3b85b0ud646e1f75b416e4c@mail.gmail.com>
	<200808121033.30082.drupal@dave-cohen.com>
	<5D29CA7A-CDD0-45D4-9E1C-AF5278A4D7B8@developmentseed.org>
	<20080814112323.qsuvmowdng0swc48@mail.progw.org>
Message-ID: <A02C9E0A-3195-4A31-9E47-95CB1E3A7D04@developmentseed.org>


On Aug 14, 2008, at 11:23 AM, Earnie Boyd wrote:
> Quoting Alex Barth <alex at developmentseed.org>:
>
>>
>> While really convenient, I'm starting to consider using taxonomy  
>> as  configuration as bad practice.
>>
>> In the long run, building effective import/export and migration  
>> tools  will also mean having a clean distinction between what's  
>> content and  what's configuration on the Drupal level...
>>
>
> But you just need to know which vocabularies are configuration; so  
> you design the tool to take it into account.

sure - we have to face reality, right? :)

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

Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633





From earnie at users.sourceforge.net  Thu Aug 14 16:53:41 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 14 Aug 2008 12:53:41 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>
	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>
Message-ID: <20080814125341.bq8yqwr7097o8kks@mail.progw.org>

Quoting Nathaniel Catchpole <catch56 at googlemail.com>:

>
> This seems like a very reasonable thing to add into testing.drupal.org
> once it's up and running.
>

Cooler than a snowball on a hot tin roof!  How often does the cron job 
run?  Is the plan to submit the results to the issue where the patch 
resides?  Do you plan for a similar system for contrib modules?  At 
least we should get a link to http://testing.drupal.org/tests listed on 
the project issue page.

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


From catch56 at googlemail.com  Thu Aug 14 16:58:00 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 14 Aug 2008 17:58:00 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <20080814125341.bq8yqwr7097o8kks@mail.progw.org>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>
	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>
	<20080814125341.bq8yqwr7097o8kks@mail.progw.org>
Message-ID: <fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>

On Thu, Aug 14, 2008 at 5:53 PM, Earnie Boyd wrote:


>
> Cooler than a snowball on a hot tin roof!  How often does the cron job run?

It doesn't at the moment.

>  Is the plan to submit the results to the issue where the patch resides?
Yes. But the bot can't set status until http://drupal.org/node/271216
is resolved - if you (or anyone else) would like to see this actually
happen, pitch in there.

>  Do
> you plan for a similar system for contrib modules?
I don't know if the testbed is set up to handle contrib modules as
well. That would be a natural extension of it though (although it'd
have to be one module added at a time, and we don't have any contribs
on api.drupal.org yet either).

Nat

From drupal-devel at webchick.net  Thu Aug 14 17:29:05 2008
From: drupal-devel at webchick.net (Angela Byron)
Date: Thu, 14 Aug 2008 13:29:05 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <6117a7500808140756n4fb05266i51212209d714d32a@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>	<48A3D24C.7020401@gmail.com>	<fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>	<48A43689.5050602@webchick.net>
	<6117a7500808140756n4fb05266i51212209d714d32a@mail.gmail.com>
Message-ID: <48A46B61.9070000@webchick.net>

Moshe Weitzman wrote:
>> The people complaining about the long RTBC queue are missing the point. The
>> point is that there's a much, much longer "needs review" queue, and there
>> always has been.
> 
> Perhaps they are missing *your* point. The RTBC queue is a big problem
> as well. Many patches in RTBC represent a massive effort by several
> people and it is a complete shame to let them sit there, silently.
> Losing a baserunner on 3rd base is much more painful than losing one
> at second base. We terribly need a branch maintainer or two for D7.
> Lack of throughput at RTBC demotivates the 'needs review' queue, and
> even before that - patch creation.

True. But exactly *one* person can do something about the RTBC queue. 
2,000+ people can do something about the CNR queue.

Let's have a community outcry about the RTBC queue once the situation is 
reversed, and we have 325 patches waiting for core committers' blessing, 
and only 40 patches that need community review. Until then, we have work 
to do.

-Angie



From catch56 at googlemail.com  Thu Aug 14 18:00:42 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 14 Aug 2008 19:00:42 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <48A46B61.9070000@webchick.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A3D24C.7020401@gmail.com>
	<fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>
	<48A43689.5050602@webchick.net>
	<6117a7500808140756n4fb05266i51212209d714d32a@mail.gmail.com>
	<48A46B61.9070000@webchick.net>
Message-ID: <fa5724270808141100y17d2cd25gb98082988fc686f8@mail.gmail.com>

On Thu, Aug 14, 2008 at 6:29 PM, Angela Byron  wrote:
>
> True. But exactly *one* person can do something about the RTBC queue. 2,000+
> people can do something about the CNR queue.
>

I think the main issue /at the moment/ is that this is probably the
longest in several releases that there's only been one person able to
do anything about the RTBC queue. Drupal 5 was released on January
15th 2007 [1], Gabor was given commit access on April 17, 2007[2],
three months later. Drupal 6 was released on February 13, 2008 [3],
it's now 6 months later and there's no sign of a branch maintainer
yet. Additionally, the last core commit by Steven Wittens was July 26,
2007 [4], three weeks after code freeze [5] - so there's actually two
less people committing to HEAD than during the Drupal 6 code thaw, and
Gabor was employed full time working by Acquia just to work on core
commits from August [6] as well.

However, even with three core committers, or two and one person
employed full time, reviews have always been the primary bottleneck.

> Let's have a community outcry about the RTBC queue once the situation is
> reversed, and we have 325 patches waiting for core committers' blessing, and
> only 40 patches that need community review. Until then, we have work to do.
>
> -Angie

It's pretty easy to make a difference to the RTBC queue as well, at
least when it's as long as it is now, I just went through everything
that had been untouched for 5 weeks or more, bumped everything that
still applied, found 2-3 that needed re-rolling, and one that was in
entirely the wrong queue. Quite a few patches left would probably get
in easier if they had simpletests written for them too - so people
could find those and help them out if simpletests are missing. For
now, RTBC patches against D7 are down to ~ 30 from over twice that a
few days ago (there's been some commits as well recently, although 30
is still quite a lot considering many of them are heavily tested and
nearly all should be valid against HEAD). We'll see if it goes up or
down from here.

Like you said, a review queue of about 40 would be pretty good - as
long as the RTBC queue goes down by the same proportion (about 5-15).
Would be much, much less work nursing patches once the initial pain
was over with.

Nat

[1] http://drupal.org/node/109494
[2] http://buytaert.net/gabor-hojtsy
[3] http://drupal.org/node/221219
[4] http://drupal.org/cvs?commit=74849
[5] http://drupal.org/drupal-6.0-code-freeze
[6] http://hojtsy.hu/blog/2008-feb-15/drupal-6-maintainers-perspective

From drupal at dwwright.net  Thu Aug 14 18:15:47 2008
From: drupal at dwwright.net (Derek Wright)
Date: Thu, 14 Aug 2008 11:15:47 -0700
Subject: [development] What about reviewing patches?
In-Reply-To: <48A46B61.9070000@webchick.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>	<48A3D24C.7020401@gmail.com>	<fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>	<48A43689.5050602@webchick.net>
	<6117a7500808140756n4fb05266i51212209d714d32a@mail.gmail.com>
	<48A46B61.9070000@webchick.net>
Message-ID: <72BBBBB5-D024-4B65-8FD3-E8ECE66D302F@dwwright.net>


On Aug 14, 2008, at 10:29 AM, Angela Byron wrote:

> True. But exactly *one* person can do something about the RTBC  
> queue. 2,000+ people can do something about the CNR queue.
>
> Let's have a community outcry about the RTBC queue once the  
> situation is reversed, and we have 325 patches waiting for core  
> committers' blessing, and only 40 patches that need community  
> review. Until then, we have work to do.

As someone who's done an awful lot of core patch reviews over the  
years, I feel compelled to chime in here.

If we've got a single bottleneck on the RTBC queue, how is mustering  
the forces of 2000+ people to exacerbate that problem going to help  
anything?  Things sitting in RTBC are a *HUGE* waste of developer  
time.  The sheer volume of hours wasted by things having to be re- 
rolled since they were RTBC once but no one committed for months is  
mind boggling.  Not to mention the cascading effect of other patches  
that are constantly re-rolled when something finally does get in.

I'm certainly not motivated to work in the core issue queue much  
anymore, except out of necessity.  I've just wasted far too many  
hours re-rolling, re-wrangling reviews, etc, etc, trying to get  
something in.  So long as things sit in RTBC for weeks on end,  
there's very little motivation for me (and clearly many others) to  
try to get stuff from CNR to RTBC.

The point of patches and patch reviews are to improve Drupal.  That  
only happens once a patch *lands*.  So long as one person is the  
bottleneck for patches landing, there's no point in shaming,  
moralizing, or otherwise cajoling people to review more patches.

Given a single maintainer, I think the core development workflow  
should make more use of the patch spotlight[1] and be something like:

- Dries says the 1-5 patches he cares about and is willing to follow  
and comment on at any given time.
- People who want to help core work on those patches until they're  
*committed*.
- i++;

Just about anything else is a giant waste of time it seems.

Cheers,
-Derek (dww)

[1] http://drupal.org/patch/spotlight




From rob at robshouse.net  Thu Aug 14 18:22:42 2008
From: rob at robshouse.net (Robert Douglass)
Date: Thu, 14 Aug 2008 20:22:42 +0200
Subject: [development] What about reviewing patches?
In-Reply-To: <72BBBBB5-D024-4B65-8FD3-E8ECE66D302F@dwwright.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>	<48A32F7C.9080104@gmx.net>
	<48A332D2.4060209@webchick.net>	<48A3D24C.7020401@gmail.com>	<fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>	<48A43689.5050602@webchick.net>
	<6117a7500808140756n4fb05266i51212209d714d32a@mail.gmail.com>
	<48A46B61.9070000@webchick.net>
	<72BBBBB5-D024-4B65-8FD3-E8ECE66D302F@dwwright.net>
Message-ID: <7C8F7619-B849-4AAC-A656-B2BCA8753745@robshouse.net>


On Aug 14, 2008, at 8:15 PM, Derek Wright wrote:

>
> Given a single maintainer, I think the core development workflow  
> should make more use of the patch spotlight[1] and be something like:
>
> - Dries says the 1-5 patches he cares about and is willing to follow  
> and comment on at any given time.
> - People who want to help core work on those patches until they're  
> *committed*.
> - i++;
>
> Just about anything else is a giant waste of time it seems.

This is an excellent workflow. If you look at core commit messages, it  
isn't for lack of commits that things seem stalled.

In the time that people have been complaining here, our Chief  
Bottleneck has committed 14 patches. A bit above average, but take the  
time to scroll through the pages. You'll be impressed.

http://drupal.org/project/cvs/3060

From earnie at users.sourceforge.net  Thu Aug 14 19:20:33 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 14 Aug 2008 15:20:33 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>
	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>
	<20080814125341.bq8yqwr7097o8kks@mail.progw.org>
	<fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>
Message-ID: <20080814152033.xpjmwdlb0wpws844@mail.progw.org>

Quoting Nathaniel Catchpole <catch56 at googlemail.com>:

> On Thu, Aug 14, 2008 at 5:53 PM, Earnie Boyd wrote:
>
>
>>
>> Cooler than a snowball on a hot tin roof!  How often does the cron job run?
>
> It doesn't at the moment.
>

So is it being run by hand?  I set at http://testing.drupal.org/tests 
text like "1 hour 27 min ago" under the "Submitted" column.

>>  Is the plan to submit the results to the issue where the patch resides?
> Yes. But the bot can't set status until http://drupal.org/node/271216
> is resolved - if you (or anyone else) would like to see this actually
> happen, pitch in there.
>

I don't know how much I have left to pitch (at least for August) but 
I've bookmarked it.

>>  Do
>> you plan for a similar system for contrib modules?
> I don't know if the testbed is set up to handle contrib modules as
> well. That would be a natural extension of it though (although it'd
> have to be one module added at a time, and we don't have any contribs
> on api.drupal.org yet either).

Well, that would be another plus for contrib.  At least I have 
http://drupal.kollm.org/node/1 thanks to ax.

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


From cwgordon7 at cwgordon.com  Thu Aug 14 19:48:47 2008
From: cwgordon7 at cwgordon.com (Charlie Gordon)
Date: Thu, 14 Aug 2008 15:48:47 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <20080814152033.xpjmwdlb0wpws844@mail.progw.org>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>	<200808140055.43824.yuval@avramzon.net>	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>	<20080814125341.bq8yqwr7097o8kks@mail.progw.org>	<fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>
	<20080814152033.xpjmwdlb0wpws844@mail.progw.org>
Message-ID: <48A48C1F.8090705@cwgordon.com>

Earnie Boyd wrote:
> So is it being run by hand?  I set at http://testing.drupal.org/tests 
> text like "1 hour 27 min ago" under the "Submitted" column.

The status of testing.drupal.org is, at the moment, this: patches are 
applied, and marked "fail" if they don't apply properly. Tests are not 
actually run at the moment. But none of that matters, because nothing is 
posted back to the issue queue anyway.

> Well, that would be another plus for contrib.  At least I have 
> http://drupal.kollm.org/node/1 thanks to ax.

But, how many contributed modules actually have their own tests written? 
No more than 10-20, certainly, which is a very small percentage. The 
workflow here needs to be more thought out; in addition, it's not all 
that reasonable to have a server running automated tests for almost 3000 
contributed modules, not to mention different core versions, module 
dependencies, etc.

-Charlie

From rob at robshouse.net  Thu Aug 14 20:08:49 2008
From: rob at robshouse.net (Robert Douglass)
Date: Thu, 14 Aug 2008 22:08:49 +0200
Subject: [development] What about reviewing patches?
In-Reply-To: <48A48C1F.8090705@cwgordon.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>	<200808140055.43824.yuval@avramzon.net>	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>	<20080814125341.bq8yqwr7097o8kks@mail.progw.org>	<fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>
	<20080814152033.xpjmwdlb0wpws844@mail.progw.org>
	<48A48C1F.8090705@cwgordon.com>
Message-ID: <187C6013-F871-4FD1-BDD2-907A6DE5F986@robshouse.net>

On Aug 14, 2008, at 9:48 PM, Charlie Gordon wrote:

> Earnie Boyd wrote:
>> So is it being run by hand?  I set at http://testing.drupal.org/ 
>> tests text like "1 hour 27 min ago" under the "Submitted" column.
>
> But, how many contributed modules actually have their own tests  
> written? No more than 10-20, certainly, which is a very small  
> percentage. The workflow here needs to be more thought out; in  
> addition, it's not all that reasonable to have a server running  
> automated tests for almost 3000 contributed modules, not to mention  
> different core versions, module dependencies, etc.
>
> -Charlie

Yes. Chicken and egg. If the test results were being posted back to  
d.o. it would encourage people to write more tests, especially if  
projects with no tests got a big "Testing status: FAIL" all over them.

I think it is unreasonable NOT to have as many servers as are needed,  
running all tests for all module, all day, 24/7. We're no longer  
talking about an ecosystem financed by milk money. Getting iron isn't  
the problem.

Someone please write a proposal to the Drupal Association in time for  
the next board meeting that the complete testing infrastructure and  
development resources should be financed. Or, alternatively, some  
Drupal shop out there with the capacity to make this happen step  
forward.

We've invested a lot into testing, and it is clear that it can have a  
positive influence on the commit process (for core and contrib), so  
let's not settle for a single or a double. To hit a home run we need  
the testing infrastructure.


From kathleen at ceardach.com  Thu Aug 14 20:27:24 2008
From: kathleen at ceardach.com (Kathleen Murtagh)
Date: Thu, 14 Aug 2008 16:27:24 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <187C6013-F871-4FD1-BDD2-907A6DE5F986@robshouse.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>
	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>
	<20080814125341.bq8yqwr7097o8kks@mail.progw.org>
	<fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>
	<20080814152033.xpjmwdlb0wpws844@mail.progw.org>
	<48A48C1F.8090705@cwgordon.com>
	<187C6013-F871-4FD1-BDD2-907A6DE5F986@robshouse.net>
Message-ID: <1d83e3e60808141327pd9110fan25457835035e5f9d@mail.gmail.com>

On Thu, Aug 14, 2008 at 4:08 PM, Robert Douglass <rob at robshouse.net> wrote:
> Yes. Chicken and egg. If the test results were being posted back to d.o. it
> would encourage people to write more tests, especially if projects with no
> tests got a big "Testing status: FAIL" all over them.
>
> I think it is unreasonable NOT to have as many servers as are needed,
> running all tests for all module, all day, 24/7. We're no longer talking
> about an ecosystem financed by milk money. Getting iron isn't the problem.
>
> Someone please write a proposal to the Drupal Association in time for the
> next board meeting that the complete testing infrastructure and development
> resources should be financed. Or, alternatively, some Drupal shop out there
> with the capacity to make this happen step forward.
>
> We've invested a lot into testing, and it is clear that it can have a
> positive influence on the commit process (for core and contrib), so let's
> not settle for a single or a double. To hit a home run we need the testing
> infrastructure.

If you're seriously interested in having a drupal shop or other step
in to help handle this need, then we still need a proposal written to
detail what is needed.  Write up a proposal of needs and make it
public.

I'd love to help to help with hardware, bandwidth, etc.  In fact my
company has a bunch of old servers hanging around the office unused
(we moved to EC2).  However, I need to know what is needed and how to
implement it.

---
Kathleen Murtagh

From catch56 at googlemail.com  Thu Aug 14 21:04:34 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Thu, 14 Aug 2008 22:04:34 +0100
Subject: [development] What about reviewing patches?
In-Reply-To: <1d83e3e60808141327pd9110fan25457835035e5f9d@mail.gmail.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>
	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>
	<20080814125341.bq8yqwr7097o8kks@mail.progw.org>
	<fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>
	<20080814152033.xpjmwdlb0wpws844@mail.progw.org>
	<48A48C1F.8090705@cwgordon.com>
	<187C6013-F871-4FD1-BDD2-907A6DE5F986@robshouse.net>
	<1d83e3e60808141327pd9110fan25457835035e5f9d@mail.gmail.com>
Message-ID: <fa5724270808141404m5f8847bdu2b5315f87263ec27@mail.gmail.com>

On Thu, Aug 14, 2008 at 9:27 PM, Kathleen Murtagh wrote:

>
> If you're seriously interested in having a drupal shop or other step
> in to help handle this need, then we still need a proposal written to
> detail what is needed.  Write up a proposal of needs and make it
> public.
>
> I'd love to help to help with hardware, bandwidth, etc.  In fact my
> company has a bunch of old servers hanging around the office unused
> (we moved to EC2).  However, I need to know what is needed and how to
> implement it.
>
> ---
> Kathleen Murtagh
>

I've started a thread in the QA/Testing + Association groups to detail
the steps required to the extent I know them, and get a proposal
written up if that's needed - http://groups.drupal.org/node/13990

Nat

From saintsjd at gmail.com  Thu Aug 14 21:35:03 2008
From: saintsjd at gmail.com (Jon Saints)
Date: Thu, 14 Aug 2008 15:35:03 -0600
Subject: [development] $custom_theme when does it take effect... when does
	it not
Message-ID: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>

I notice a bug in D6.4 and CVS in the block module. This post,
however, is not to report the bug (i will use bug tracker for that).
This post is to ask a development question that will help me create a
patch for the issue.

On our website we use different themes for different sections of the
site.  As the user browses to different sections of the site, the
theme is changed automatically by changing $custom_theme global in
hook_init().

Bug background: The bug occurs when administering blocks.  For
example, if my current active theme is foo_theme and I click
admin/build/block/list/bar_theme a list of blocks for bar_theme is not
displayed.  Instead, a list of blocks for the active theme foo_theme
is displayed.  When the user clicks the link "Bar theme" they could
reasonably expect that a list of the blocks for bar_theme should
display.

The development question: I think the bug has something to do with the
code in the block module function block_admin_display(). In this
function the author of the code tries to display a list of blocks for
the theme the user selected by changing  the global variable
$custom_theme. The problem with this approach is that outside of
hook_init() I have found that changing $custom_theme variable has no
effect on changing the active theme.

Have others found this to be the case that changes to $custom_theme
variable have no effect on changing the active theme outside of
hook_init()?

If this is the case then we need to rethink how we are pulling the
list of blocks in the block module admin.

Thanks
Jon

From merlin at logrus.com  Thu Aug 14 22:21:12 2008
From: merlin at logrus.com (Earl Miles)
Date: Thu, 14 Aug 2008 15:21:12 -0700
Subject: [development] $custom_theme when does it take effect... when
 does	it not
In-Reply-To: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>
References: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>
Message-ID: <48A4AFD8.1070403@logrus.com>

Jon Saints wrote:
> I notice a bug in D6.4 and CVS in the block module. This post,
> however, is not to report the bug (i will use bug tracker for that).
> This post is to ask a development question that will help me create a
> patch for the issue.
> 
> On our website we use different themes for different sections of the
> site.  As the user browses to different sections of the site, the
> theme is changed automatically by changing $custom_theme global in
> hook_init().
> 
> Bug background: The bug occurs when administering blocks.  For
> example, if my current active theme is foo_theme and I click
> admin/build/block/list/bar_theme a list of blocks for bar_theme is not
> displayed.  Instead, a list of blocks for the active theme foo_theme
> is displayed.  When the user clicks the link "Bar theme" they could
> reasonably expect that a list of the blocks for bar_theme should
> display.
> 
> The development question: I think the bug has something to do with the
> code in the block module function block_admin_display(). In this
> function the author of the code tries to display a list of blocks for
> the theme the user selected by changing  the global variable
> $custom_theme. The problem with this approach is that outside of
> hook_init() I have found that changing $custom_theme variable has no
> effect on changing the active theme.
> 
> Have others found this to be the case that changes to $custom_theme
> variable have no effect on changing the active theme outside of
> hook_init()?
> 
> If this is the case then we need to rethink how we are pulling the
> list of blocks in the block module admin.
> 
> Thanks
> Jon

$custom_theme takes effect as soon as init_theme() is run. The later in 
the page that you set it, the more likely that init_theme() will already 
have run. That makes it definitely work best inside hook_init(), but 
often later is ok, as long as some module isn't calling theme(...) very 
early. Calling theme() functions in hook_init(), for example, could be 
very bad as it can destroy $custom_theme setting.

From news at unleashedmind.com  Thu Aug 14 22:26:15 2008
From: news at unleashedmind.com (Daniel F. Kudwien)
Date: Fri, 15 Aug 2008 00:26:15 +0200
Subject: [development] $custom_theme when does it take effect... when
	doesit not
In-Reply-To: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>
Message-ID: <0c3101c8fe5c$c4024ab0$0200a8c0@structworks.com>

> On our website we use different themes for different sections 
> of the site.  As the user browses to different sections of 
> the site, the theme is changed automatically by changing 
> $custom_theme global in hook_init().

If you're doing this in with custom code, you should give
http://drupal.org/project/sections a try.  The module has been thoroughly
tested and works AFAIK.  Similar, but different purpose is
http://drupal.org/project/switchtheme.

> The development question: I think the bug has something to do 
> with the code in the block module function 
> block_admin_display(). In this function the author of the 
> code tries to display a list of blocks for the theme the user 
> selected by changing  the global variable $custom_theme. The 
> problem with this approach is that outside of
> hook_init() I have found that changing $custom_theme variable 
> has no effect on changing the active theme.

You should not try to change the theme on block administration pages.  Above
mentioned modules implement exactly this exception.

Thanks,
Daniel


From saintsjd at gmail.com  Thu Aug 14 22:55:14 2008
From: saintsjd at gmail.com (Jon Saints)
Date: Thu, 14 Aug 2008 16:55:14 -0600
Subject: [development] $custom_theme when does it take effect... when
	doesit not
In-Reply-To: <0c3101c8fe5c$c4024ab0$0200a8c0@structworks.com>
References: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>
	<0c3101c8fe5c$c4024ab0$0200a8c0@structworks.com>
Message-ID: <8e779d5d0808141555l56cc78b1yd3b7e3443471ef99@mail.gmail.com>

> If you're doing this in with custom code, you should give
> http://drupal.org/project/sections a try.  The module has been thoroughly
> tested and works AFAIK.  Similar, but different purpose is
> http://drupal.org/project/switchtheme.

Thanks. I will check out these modules

> You should not try to change the theme on block administration pages.  Above
> mentioned modules implement exactly this exception.

As for the bug in the block module, I think there is actually a good
reason that the author of the block module in core is trying (but not
succeeding) to change the theme on block administration pages.  As you
to edit blocks for different themes in the block admin it helps to
have the active theme change accordingly so that a user can see where
on the page the block regions will be appearing. Different themes can
have different arrangements of regions.

The bug occurs when the block_admin_display() function changes
$custom_theme variable and calls init_theme().  The global variable
$theme has already been set by a previous init_theme() call somehwere
in drupal so init_theme() is essentially ignored in
block_admin_display(). The theme does not change. That is why we are
seeing the wrong list of blocks appear for any theme that is not the
active theme.

So... how best to deal with this?

Do we:
1) always show the current default theme when editing blocks for other
themes (even though region arrangements might differ theme to theme)
or
2) do we write a block_init() hook to change the theme each time a
user chooses to edit blocks for a specific theme in the block admin. I
wonder how this would affect users that choose to use the admin theme
setting.

Thoughts on this one?

Thanks
Jon

From drupal at dave-cohen.com  Thu Aug 14 23:06:39 2008
From: drupal at dave-cohen.com (Dave Cohen)
Date: Thu, 14 Aug 2008 16:06:39 -0700
Subject: [development]
	=?iso-8859-1?q?=24custom=5Ftheme_when_does_it_take_?=
	=?iso-8859-1?q?effect=2E=2E=2E_when_does=09it_not?=
In-Reply-To: <48A4AFD8.1070403@logrus.com>
References: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>
	<48A4AFD8.1070403@logrus.com>
Message-ID: <200808141606.39377.drupal@dave-cohen.com>

As Earl points out, $custom_theme only has effect before init_theme() is run.  
Afterward, it's too late.  So when you set $custom_theme you had better be 
sure no code has called theme(...) yet.  You can check with:

global $theme;
if (isset($theme)) {
  // too late to set $custom_theme.
}

And look out for modules that set $custom_theme without checking first whether 
some other module has set it.  (I won't name names, but initials are "og")  
So if you want to set the custom theme and make sure noone overrides it, call 
theme(...) right after you set $custom_theme.

-Dave

On Thursday 14 August 2008, Earl Miles wrote:
> $custom_theme takes effect as soon as init_theme() is run. 
> [snip] ... as long as some module isn't calling theme(...) ...



From drupal at dave-cohen.com  Thu Aug 14 23:11:16 2008
From: drupal at dave-cohen.com (Dave Cohen)
Date: Thu, 14 Aug 2008 16:11:16 -0700
Subject: [development] $custom_theme when does it take effect... when
	doesit not
In-Reply-To: <8e779d5d0808141555l56cc78b1yd3b7e3443471ef99@mail.gmail.com>
References: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>
	<0c3101c8fe5c$c4024ab0$0200a8c0@structworks.com>
	<8e779d5d0808141555l56cc78b1yd3b7e3443471ef99@mail.gmail.com>
Message-ID: <200808141611.16398.drupal@dave-cohen.com>

On Thursday 14 August 2008, Jon Saints wrote:
> So... how best to deal with this?

Put something like print_r(debug_backtrace()) in your init_theme(), 
temporarily.  Use that to determine what call is initializing the theme.  If 
possible, change that code so that the theme is not initialized so soon.



From pinglaura at gmail.com  Thu Aug 14 23:48:57 2008
From: pinglaura at gmail.com (Laura Scott)
Date: Thu, 14 Aug 2008 17:48:57 -0600
Subject: [development] What about reviewing patches?
In-Reply-To: <187C6013-F871-4FD1-BDD2-907A6DE5F986@robshouse.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>	<200808140055.43824.yuval@avramzon.net>	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>	<20080814125341.bq8yqwr7097o8kks@mail.progw.org>	<fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>
	<20080814152033.xpjmwdlb0wpws844@mail.progw.org>
	<48A48C1F.8090705@cwgordon.com>
	<187C6013-F871-4FD1-BDD2-907A6DE5F986@robshouse.net>
Message-ID: <37BE0F68-92ED-4854-9D08-049DAFB4FEAC@gmail.com>

On Aug 14, 2008, at 2:08 PM, Robert Douglass wrote:

> Someone please write a proposal to the Drupal Association in time  
> for the next board meeting that the complete testing infrastructure  
> and development resources should be financed.

And by the by the next Board meeting is next week, and then another  
one at Szeged. Yes there are many things on the agenda, but  
infrastructure is one area where a serious proposal might get some  
serious consideration, and normally the Board meets every 2 months or  
so.

Laura


From earnie at users.sourceforge.net  Thu Aug 14 23:59:52 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 14 Aug 2008 19:59:52 -0400
Subject: [development] What about reviewing patches?
In-Reply-To: <48A48C1F.8090705@cwgordon.com>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<da965fc60808131308v66ee3d64h65daf1597f867372@mail.gmail.com>
	<fa5724270808131345w7d019d7aqe40ab621dedbeefc@mail.gmail.com>
	<200808140055.43824.yuval@avramzon.net>
	<cdcea3940808131535s4c9a74b2r4ff33df281e4b928@mail.gmail.com>
	<20080814091102.lwpkj4gr3xko0soo@mail.progw.org>
	<fa5724270808140617g1d84aed0t54d88e52e83d51a3@mail.gmail.com>
	<20080814125341.bq8yqwr7097o8kks@mail.progw.org>
	<fa5724270808140958g47e7cba0q9c3ee029dddedea0@mail.gmail.com>
	<20080814152033.xpjmwdlb0wpws844@mail.progw.org>
	<48A48C1F.8090705@cwgordon.com>
Message-ID: <20080814195952.swn6sr4cmw0ggcc8@mail.progw.org>

Quoting Charlie Gordon <cwgordon7 at cwgordon.com>:

> Earnie Boyd wrote:
>> So is it being run by hand?  I set at 
>> http://testing.drupal.org/tests text like "1 hour 27 min ago" under 
>> the "Submitted" column.
>
> The status of testing.drupal.org is, at the moment, this: patches are 
> applied, and marked "fail" if they don't apply properly. Tests are 
> not actually run at the moment. But none of that matters, because 
> nothing is posted back to the issue queue anyway.
>

Even the fact that this is done would be a benefit if the developer 
could new he could depend on it being done within 5 or 10 minutes of 
posting the patch.  The developer could check testing.drupal.org/tests 
to see if his patch applied properly.

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


From merlin at logrus.com  Fri Aug 15 01:00:43 2008
From: merlin at logrus.com (Earl Miles)
Date: Thu, 14 Aug 2008 18:00:43 -0700
Subject: [development] $custom_theme when does it take effect... when
 doesit not
In-Reply-To: <8e779d5d0808141555l56cc78b1yd3b7e3443471ef99@mail.gmail.com>
References: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>	<0c3101c8fe5c$c4024ab0$0200a8c0@structworks.com>
	<8e779d5d0808141555l56cc78b1yd3b7e3443471ef99@mail.gmail.com>
Message-ID: <48A4D53B.8020005@logrus.com>

Jon Saints wrote:
>> If you're doing this in with custom code, you should give
>> http://drupal.org/project/sections a try.  The module has been thoroughly
>> tested and works AFAIK.  Similar, but different purpose is
>> http://drupal.org/project/switchtheme.
> 
> Thanks. I will check out these modules
> 
>> You should not try to change the theme on block administration pages.  Above
>> mentioned modules implement exactly this exception.
> 
> As for the bug in the block module, I think there is actually a good
> reason that the author of the block module in core is trying (but not
> succeeding) to change the theme on block administration pages.  As you
> to edit blocks for different themes in the block admin it helps to
> have the active theme change accordingly so that a user can see where
> on the page the block regions will be appearing. Different themes can
> have different arrangements of regions.
> 
> The bug occurs when the block_admin_display() function changes
> $custom_theme variable and calls init_theme().  The global variable
> $theme has already been set by a previous init_theme() call somehwere
> in drupal so init_theme() is essentially ignored in
> block_admin_display(). The theme does not change. That is why we are
> seeing the wrong list of blocks appear for any theme that is not the
> active theme.
> 
> So... how best to deal with this?

IMO this is not a bug in block module; it's a bug in whatever is calling 
theme() or init_theme() before block module has a chance to set 
custom_theme.

From saintsjd at gmail.com  Fri Aug 15 18:30:17 2008
From: saintsjd at gmail.com (Jon Saints)
Date: Fri, 15 Aug 2008 12:30:17 -0600
Subject: [development] $custom_theme when does it take effect... when
	doesit not
In-Reply-To: <48A4D53B.8020005@logrus.com>
References: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>
	<0c3101c8fe5c$c4024ab0$0200a8c0@structworks.com>
	<8e779d5d0808141555l56cc78b1yd3b7e3443471ef99@mail.gmail.com>
	<48A4D53B.8020005@logrus.com>
Message-ID: <8e779d5d0808151130g1ab1bb7atc65c97efaf50491b@mail.gmail.com>

> IMO this is not a bug in block module; it's a bug in whatever is calling
> theme() or init_theme() before block module has a chance to set
> custom_theme.

Interesting. I added

var_dump(debug_backtrace());
exit();

to init_theme() after the if(isset($theme)) section and found that the
first functiont that calls init_theme().  As best I can tell,
system_init() (system.module around line 700) is the first function to
call theme() function.  It is the reason that the block module cannot
change the theme later on.

backtrace looks like this:
init_theme() -> theme() -> system_init() -> call_user_func_array() ->
module_invoke_all() -> _drupal_bootstrap_full() -> _drupal_bootstrap()
-> drupal_bootstrap()

I am not sure the problem is with system_init().  Shouldn't the block
module just use a hook_init() instead?

Thanks
Jon

From merlin at logrus.com  Fri Aug 15 18:43:03 2008
From: merlin at logrus.com (Earl Miles)
Date: Fri, 15 Aug 2008 11:43:03 -0700
Subject: [development] $custom_theme when does it take effect... when
 doesit not
In-Reply-To: <8e779d5d0808151130g1ab1bb7atc65c97efaf50491b@mail.gmail.com>
References: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>	<0c3101c8fe5c$c4024ab0$0200a8c0@structworks.com>	<8e779d5d0808141555l56cc78b1yd3b7e3443471ef99@mail.gmail.com>	<48A4D53B.8020005@logrus.com>
	<8e779d5d0808151130g1ab1bb7atc65c97efaf50491b@mail.gmail.com>
Message-ID: <48A5CE37.5070405@logrus.com>

Jon Saints wrote:
>> IMO this is not a bug in block module; it's a bug in whatever is calling
>> theme() or init_theme() before block module has a chance to set
>> custom_theme.
> 
> Interesting. I added
> 
> var_dump(debug_backtrace());
> exit();
> 
> to init_theme() after the if(isset($theme)) section and found that the
> first functiont that calls init_theme().  As best I can tell,
> system_init() (system.module around line 700) is the first function to
> call theme() function.  It is the reason that the block module cannot
> change the theme later on.
> 
> backtrace looks like this:
> init_theme() -> theme() -> system_init() -> call_user_func_array() ->
> module_invoke_all() -> _drupal_bootstrap_full() -> _drupal_bootstrap()
> -> drupal_bootstrap()
> 
> I am not sure the problem is with system_init().  Shouldn't the block
> module just use a hook_init() instead?
> 
> Thanks
> Jon

Indeed, it appears that a theme() call was added in HEAD to init_theme().

To whomever added this: *THWAP* bad developer. No biscuit!

From saintsjd at gmail.com  Fri Aug 15 18:55:49 2008
From: saintsjd at gmail.com (Jon Saints)
Date: Fri, 15 Aug 2008 12:55:49 -0600
Subject: [development] $custom_theme when does it take effect... when
	doesit not
In-Reply-To: <48A5CE37.5070405@logrus.com>
References: <8e779d5d0808141435r1d76cf59qd099976d540381d6@mail.gmail.com>
	<0c3101c8fe5c$c4024ab0$0200a8c0@structworks.com>
	<8e779d5d0808141555l56cc78b1yd3b7e3443471ef99@mail.gmail.com>
	<48A4D53B.8020005@logrus.com>
	<8e779d5d0808151130g1ab1bb7atc65c97efaf50491b@mail.gmail.com>
	<48A5CE37.5070405@logrus.com>
Message-ID: <8e779d5d0808151155p670893bal7409350e451ea357@mail.gmail.com>

>
> Indeed, it appears that a theme() call was added in HEAD to init_theme().
>
> To whomever added this: *THWAP* bad developer. No biscuit!
>

Did you mean to say " Indeed, it appears that a theme() was added in
HEAD to system_init()"?  If so, what is the alternative to that
theme() call in system_init()?

These are the lines we need to change:

// Emit the META tag in the HTML HEAD section
theme('meta_generator_html', $version);

// Emit the HTTP Header too
theme('meta_generator_header', $version);

I can change it and submit a patch.

Thanks
Jon

From senpai_san at mac.com  Sat Aug 16 05:17:22 2008
From: senpai_san at mac.com (Senpai)
Date: Fri, 15 Aug 2008 22:17:22 -0700
Subject: [development] What about reviewing patches?
In-Reply-To: <48A46B61.9070000@webchick.net>
References: <7e270cea0808130907r6a6e49d6v4eb441e9bec15dd3@mail.gmail.com>
	<ABA84DC0-BBED-4972-B93B-77B987A6BEC1@robuustdesign.nl>
	<4e983be00808131121m29c5ee25v65ba0311c126e195@mail.gmail.com>
	<48A32F7C.9080104@gmx.net> <48A332D2.4060209@webchick.net>
	<48A3D24C.7020401@gmail.com>
	<fa5724270808140600h5a0e4354m7e36b1b4b87b0bad@mail.gmail.com>
	<48A43689.5050602@webchick.net>
	<6117a7500808140756n4fb05266i51212209d714d32a@mail.gmail.com>
	<48A46B61.9070000@webchick.net>
Message-ID: <848CB110-7C99-490F-9E15-32CEC5319BA3@mac.com>


On Aug 14, 2008, at 10:29 AM, Angela Byron wrote:

> Let's have a community outcry about the RTBC queue once the  
> situation is reversed, and we have 325 patches waiting for core  
> committers' blessing, and only 40 patches that need community  
> review. Until then, we have work to do.


@Angie:
Hear hear! And while I'm at it, let me just say that a patch review  
doesn't take 20 minutes. Unless the patch only has < 5 lines of  
changed code in it, it takes an hour~ to review it. This is how long  
it takes me to read the entire issue queue to figure out which version  
of the patch is the community approved one, identify the goals and  
desires of the patch and weed out the scope creep, download the patch,  
reset my testing sandbox from the last time I ran one of these,  
install the core or contrib that I'm about to test against, go forth  
and familiarize myself with the existing functionality that's about to  
be changed or altered by this patch, apply the patch against its  
intended destination, re-familiarize myself with the intended set of  
changes, actually test those changes to see if they work, methodically  
approach the targeted subset of functional code to see if I can think  
of a way to break it, break it, observe the results of that breakage,  
and then reliably report the results back to the issue queue n a way  
that can be understood by all parties involved. And that's not even  
including the Simpletests that pass/fail, of the lack of Simpletest(s)  
for certain areas of the code that should really be tested, and would  
therefore hold back an RTBC status from being bestowed upon the issue.

Just reading that last paragraph should make your head hurt. It did  
me, and I wrote it. The one thing that speeds up the testing process  
for me, and I mean greater than 50% is a clear set of testing  
instructions. If I can find an issue that has less than 12 replies,  
and an attached patch, I'll jump on it because it should be far easier  
to discern what the intent of the patch is and test accordingly.

On the other hand, once an issue reaches > 15 comments, or has more  
than two patches attached to it, I automatically assign it a "one  
precious hour of my personal time" sticker, and am far less motivated  
to tackle the thing. The only way that an issue can really force me to  
test it is if I see recent action on the part of the person who  
actually makes the commit, or a clearly defined two-sentence  
instructional on how to test this patch from the coder's mindset at  
the time they wrote it.

Which brings me to the end of this little diatribe, but because I  
strive to never point out a problem without also proffering a  
solution, I'd like to ask if we might be able to create a 5-line  
textarea for each issue in the queue that would store the Patch  
Testing Instructions. Old issues would not have any info in this  
field, but if a developer wished to receive some near-instant reviews  
from the community, they could write up a one-paragraph set of  
instructions on how to adequately test this patch so that it's  
committable.

We can place this field at the top of each issue as a collapsed div,  
and proffer an expand/collapse jQuerified link right below the
First unread comment
Most recent comment
Add new comment
[+]Patch review instructions

-- 
Senpai

From cjones at partialflow.com  Tue Aug 19 18:25:42 2008
From: cjones at partialflow.com (Christopher M. Jones)
Date: Tue, 19 Aug 2008 14:25:42 -0400
Subject: [development] [Fwd: [support] Staging]
Message-ID: <48AB1026.1090007@partialflow.com>

I have been looking for a clean solution to the problem of how to stage 
a drupal site, using the common dev->QA->production development cycle. I 
originally posted to [Support], but someone there suggested that I post 
my questions here, as well. My original message follows below.

-------- Original Message --------
Subject: [support] Staging
Date: Thu, 07 Aug 2008 15:22:54 -0400
From: Christopher M. Jones <cjones at partialflow.com>
Reply-To: support at drupal.org
To: support at drupal.org

I'm looking for a decent approach to staging a drupal site. The
production site will be a collaborative authoring project, with forums,
blogs, and lots of media. The client will have access to this site, and
will be maintaining some of the content. Other content will be
maintained by us.

The development company that hosts this project prefers to make all of
their changes, both to content and templates, in a testing environment.
Once their client has approved the changes, they like to 'push' them to
production.

However, while these changes are taking place, the client may be
administering forums and writing blog posts in the -production- version.

To further complicate things, my company wants a three-stage cycle. They
want a dev site, where they make changes for in-house review, which they
then push to testing for client review before everything is pushed to
production.

I'm unsure how to approach this. The site in question has always been
static html created in Dreamweaver. At some point they started adding
other things, so now there are two wordpress blogs, and two phpbb
forums. The forums and blogs presently are excepted from the development
cycle. They simply appear to be part of the site, because their
templates have been designed so. But that means that we've got to
propagate template changes across five templates. Things are breaking
constantly, and this is why I piped up to them about drupal.

I've seen a lot of discussion about this topic, but I really need some
hard answers. What should I do?

I've seen the Staging module for 6.x. Is it safe to use? If so, then we
could use that for the database. Templates could be pushed with rsync or
svn... whatever. But would this work two ways? Could we sync the dev /
testing sites to the production site, then sync the other way? Would we
need to?

Also, I envision using a multisite environment so that all sites share
the same modules, media, etc, but use different templates.

I desperately need the detailed advice of someone with experience, here.
-- 
[ Drupal support list | http://lists.drupal.org/ ]


From z.stolar at gmail.com  Tue Aug 19 19:31:49 2008
From: z.stolar at gmail.com (Zohar Stolar)
Date: Tue, 19 Aug 2008 22:31:49 +0300
Subject: [development] [Fwd: [support] Staging]
In-Reply-To: <48AB1026.1090007@partialflow.com>
References: <48AB1026.1090007@partialflow.com>
Message-ID: <48AB1FA5.20902@gmail.com>

I was too late :)
I advised you NOT to cross post the message again. Here's a quote from 
the support list:
"
Since you raised this issue, it has been extensively discussed on the 
development list (see threads: "Solving the dev->staging->live problem" 
and "Unique/Random IDs and drupal")
"


Read those threads and you'll understand how deep the problem is.



Christopher M. Jones wrote:

> I have been looking for a clean solution to the problem of how to 
> stage a drupal site, using the common dev->QA->production development 
> cycle. I originally posted to [Support], but someone there suggested 
> that I post my questions here, as well. My original message follows 
> below.
>
> -------- Original Message --------
> Subject: [support] Staging
> Date: Thu, 07 Aug 2008 15:22:54 -0400
> From: Christopher M. Jones <cjones at partialflow.com>
> Reply-To: support at drupal.org
> To: support at drupal.org
>
> I'm looking for a decent approach to staging a drupal site. The
> production site will be a collaborative authoring project, with forums,
> blogs, and lots of media. The client will have access to this site, and
> will be maintaining some of the content. Other content will be
> maintained by us.
>
> The development company that hosts this project prefers to make all of
> their changes, both to content and templates, in a testing environment.
> Once their client has approved the changes, they like to 'push' them to
> production.
>
> However, while these changes are taking place, the client may be
> administering forums and writing blog posts in the -production- version.
>
> To further complicate things, my company wants a three-stage cycle. They
> want a dev site, where they make changes for in-house review, which they
> then push to testing for client review before everything is pushed to
> production.
>
> I'm unsure how to approach this. The site in question has always been
> static html created in Dreamweaver. At some point they started adding
> other things, so now there are two wordpress blogs, and two phpbb
> forums. The forums and blogs presently are excepted from the development
> cycle. They simply appear to be part of the site, because their
> templates have been designed so. But that means that we've got to
> propagate template changes across five templates. Things are breaking
> constantly, and this is why I piped up to them about drupal.
>
> I've seen a lot of discussion about this topic, but I really need some
> hard answers. What should I do?
>
> I've seen the Staging module for 6.x. Is it safe to use? If so, then we
> could use that for the database. Templates could be pushed with rsync or
> svn... whatever. But would this work two ways? Could we sync the dev /
> testing sites to the production site, then sync the other way? Would we
> need to?
>
> Also, I envision using a multisite environment so that all sites share
> the same modules, media, etc, but use different templates.
>
> I desperately need the detailed advice of someone with experience, here.

-- 
Zohar Stolar   |   ??? ?????
z.stolar at gmail.com <mailto:z.stolar at gmail.com>
Tel. +972-(0)77-5345-704
Cel. +972-(0)52-8348-278
Fax. +972-(0)72-2500-882
SkypeID: zstolar


From drupal at dave-cohen.com  Wed Aug 20 22:09:26 2008
From: drupal at dave-cohen.com (Dave Cohen)
Date: Wed, 20 Aug 2008 15:09:26 -0700
Subject: [development] form_set_value and multistep
Message-ID: <200808201509.27322.drupal@dave-cohen.com>

Hi,

I've written a form element for drupal 5.x which, in it's #validate callback, 
converts a comma-seperated string into an array of ids.  It uses the 
form_set_value() function to change the string value to an array.

My element fails in multistep forms.  The reason being that first the form is 
processed, then the $form_values which my call to form_set_value() affected 
is discarded (at the end of drupal_process_form()) then 
drupal_retrieve_form() is called again, this time passing in $_POST (this 
happens in drupal_get_form()).  Because my call to form_set_value() affects 
$form_values and not $_POST, my changes are lost.

I've noticed that if I also change the $_POST after I call form_set_value(), I 
can work around the problem:


  // Here's the call usually make:
  form_set_value($element, $items);

  // Here's the workaround that modifies $_POST:
  _form_set_value($_POST, $element, $element['#parents'], $items);


For a number of reasons, I feel that call to _form_set_value() is hacky and 
does not belong in my code.  However, it might be a reasonable addition to 
form_set_value().  If I were to submit that as a patch, any chance it would 
be committed?

I'm not the only one who's had problems with form_set_value().  Most people 
find workarounds usually avoiding it entirely, but I have yet to find one for 
my case.  For example, http://drupal.org/node/264743.

Thanks,

-Dave

From caleb.gilbert at gmail.com  Thu Aug 21 00:01:06 2008
From: caleb.gilbert at gmail.com (Caleb Gilbert)
Date: Wed, 20 Aug 2008 17:01:06 -0700
Subject: [development]  form_set_value and multistep
Message-ID: <38ad0b0a0808201701x276d9091uea152a4a456f7573@mail.gmail.com>

This link starts off the most helpful thread/thing I've seen about
form_set_value() - might be worth a look before filing an issue:

http://drupal.org/node/160160#comment-820709

- Caleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080820/71599398/attachment.htm 

From rleigh at northcountry.com  Thu Aug 21 00:41:30 2008
From: rleigh at northcountry.com (Roger Leigh)
Date: Wed, 20 Aug 2008 17:41:30 -0700
Subject: [development] autocomplete.js and http error 0
Message-ID: <48ACB9BA.2050805@northcountry.com>

I'm working with an autocomplete text field in a module, and some users 
were getting an alert error, "An HTTP error 0 occured".

I was finally able to reproduce this error, not only on my form but on a 
standard CCK form as well; if you click the form submit button while the 
autocomplete is retrieving entries (the 'blue wheel' is present), it 
triggers the error. Surprisingly, I couldn't find a lot of info on a 
drupal search, though I did see some related reports in other projects.

Looking at the autocomplete.js file, I see the alert at line 285. 
Obviously I can change it here, but always hate to hack the core.

Any ideas?

Regards,

Roger

From enboig at gmail.com  Thu Aug 21 10:16:49 2008
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Thu, 21 Aug 2008 12:16:49 +0200
Subject: [development] delete menu not appearing
Message-ID: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>

I have developed several node types for an application, and in one of
them "delete" menu doesn't appear when viewing it; first I thought it
could be a permission problem, so I wrote:
function hook_access($op, $node) {
 return true; //debug
...
}

but nothing happend; then I tried with user 1 and it is the same (I
cleared all cache tables using phpmyadmin).
besides hook_delete and hook_access is there anything else necessary
for the menu to appear? From the administrative interface I can delete
the node without problems.

thanks

-- 
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*La felicitat ha de ser compatible, compartible i cooperativa.
*Envellim quan els records superen les il?lusions.
*Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From victorkane at gmail.com  Thu Aug 21 11:00:09 2008
From: victorkane at gmail.com (Victor Kane)
Date: Thu, 21 Aug 2008 08:00:09 -0300
Subject: [development] delete menu not appearing
In-Reply-To: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
Message-ID: <ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>

If you are using Drupal 6, then there are now separate permissions for
creating, editing and deleting... check your permissions if this is
the case

On Thu, Aug 21, 2008 at 7:16 AM, Llu?s <enboig at gmail.com> wrote:
> I have developed several node types for an application, and in one of
> them "delete" menu doesn't appear when viewing it; first I thought it
> could be a permission problem, so I wrote:
> function hook_access($op, $node) {
>  return true; //debug
> ...
> }
>
> but nothing happend; then I tried with user 1 and it is the same (I
> cleared all cache tables using phpmyadmin).
> besides hook_delete and hook_access is there anything else necessary
> for the menu to appear? From the administrative interface I can delete
> the node without problems.
>
> thanks
>
> --
> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
> nom?s una vegada.
> *La felicitat ha de ser compatible, compartible i cooperativa.
> *Envellim quan els records superen les il?lusions.
> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>

From enboig at gmail.com  Thu Aug 21 11:05:21 2008
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Thu, 21 Aug 2008 13:05:21 +0200
Subject: [development] delete menu not appearing
In-Reply-To: <ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
	<ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
Message-ID: <45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>

I am using drupal 5; I just updated the core to be sure I didn't
change anything there, but the problem continues. It afect other
node-types also. As I can delete nodes using the administrative
interface, may it be a menu problem?

On Thu, Aug 21, 2008 at 1:00 PM, Victor Kane <victorkane at gmail.com> wrote:
> If you are using Drupal 6, then there are now separate permissions for
> creating, editing and deleting... check your permissions if this is
> the case
>
> On Thu, Aug 21, 2008 at 7:16 AM, Llu?s <enboig at gmail.com> wrote:
>> I have developed several node types for an application, and in one of
>> them "delete" menu doesn't appear when viewing it; first I thought it
>> could be a permission problem, so I wrote:
>> function hook_access($op, $node) {
>>  return true; //debug
>> ...
>> }
>>
>> but nothing happend; then I tried with user 1 and it is the same (I
>> cleared all cache tables using phpmyadmin).
>> besides hook_delete and hook_access is there anything else necessary
>> for the menu to appear? From the administrative interface I can delete
>> the node without problems.
>>
>> thanks
>>
>> --
>> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>> nom?s una vegada.
>> *La felicitat ha de ser compatible, compartible i cooperativa.
>> *Envellim quan els records superen les il?lusions.
>> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
>> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>>
>



-- 
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*La felicitat ha de ser compatible, compartible i cooperativa.
*Envellim quan els records superen les il?lusions.
*Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From victorkane at gmail.com  Thu Aug 21 11:10:14 2008
From: victorkane at gmail.com (Victor Kane)
Date: Thu, 21 Aug 2008 08:10:14 -0300
Subject: [development] delete menu not appearing
In-Reply-To: <45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
	<ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
	<45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>
Message-ID: <ff176450808210410o236367r556d3e5676cb8a72@mail.gmail.com>

Sometimes the permissions get very complicated in terms of filters,
ownership, edit own, edit, etc.

One thing I sometimes do is make a backup of the database, then give
the non-admin user all node, filter, etc. permissions, and then start
taking off these permissions one by one to see what's going on.

Another source of problems is if you have been using any kind of
access module which you have then disabled, then you will want to go
to Administer > Content management > Post settings and hit the rebuild
permissions button.

Victor Kane
http://awebfactory.com.ar

On Thu, Aug 21, 2008 at 8:05 AM, Llu?s <enboig at gmail.com> wrote:
> I am using drupal 5; I just updated the core to be sure I didn't
> change anything there, but the problem continues. It afect other
> node-types also. As I can delete nodes using the administrative
> interface, may it be a menu problem?
>
> On Thu, Aug 21, 2008 at 1:00 PM, Victor Kane <victorkane at gmail.com> wrote:
>> If you are using Drupal 6, then there are now separate permissions for
>> creating, editing and deleting... check your permissions if this is
>> the case
>>
>> On Thu, Aug 21, 2008 at 7:16 AM, Llu?s <enboig at gmail.com> wrote:
>>> I have developed several node types for an application, and in one of
>>> them "delete" menu doesn't appear when viewing it; first I thought it
>>> could be a permission problem, so I wrote:
>>> function hook_access($op, $node) {
>>>  return true; //debug
>>> ...
>>> }
>>>
>>> but nothing happend; then I tried with user 1 and it is the same (I
>>> cleared all cache tables using phpmyadmin).
>>> besides hook_delete and hook_access is there anything else necessary
>>> for the menu to appear? From the administrative interface I can delete
>>> the node without problems.
>>>
>>> thanks
>>>
>>> --
>>> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>>> nom?s una vegada.
>>> *La felicitat ha de ser compatible, compartible i cooperativa.
>>> *Envellim quan els records superen les il?lusions.
>>> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
>>> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>>>
>>
>
>
>
> --
> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
> nom?s una vegada.
> *La felicitat ha de ser compatible, compartible i cooperativa.
> *Envellim quan els records superen les il?lusions.
> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>

From enboig at gmail.com  Thu Aug 21 11:23:12 2008
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Thu, 21 Aug 2008 13:23:12 +0200
Subject: [development] delete menu not appearing
In-Reply-To: <ff176450808210410o236367r556d3e5676cb8a72@mail.gmail.com>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
	<ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
	<45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>
	<ff176450808210410o236367r556d3e5676cb8a72@mail.gmail.com>
Message-ID: <45a29f450808210423j379234c7xde16a00d9e41d615@mail.gmail.com>

I have programed my own premission system; but it shouldn't be the
issue here, when de user goes to 'node/2175'
appear 'view' and 'edit' not 'delete', but user can go manually to
'node/2175/delete' and delete the node with no problems.


On Thu, Aug 21, 2008 at 1:10 PM, Victor Kane <victorkane at gmail.com> wrote:
> Sometimes the permissions get very complicated in terms of filters,
> ownership, edit own, edit, etc.
>
> One thing I sometimes do is make a backup of the database, then give
> the non-admin user all node, filter, etc. permissions, and then start
> taking off these permissions one by one to see what's going on.
>
> Another source of problems is if you have been using any kind of
> access module which you have then disabled, then you will want to go
> to Administer > Content management > Post settings and hit the rebuild
> permissions button.
>
> Victor Kane
> http://awebfactory.com.ar
>
> On Thu, Aug 21, 2008 at 8:05 AM, Llu?s <enboig at gmail.com> wrote:
>> I am using drupal 5; I just updated the core to be sure I didn't
>> change anything there, but the problem continues. It afect other
>> node-types also. As I can delete nodes using the administrative
>> interface, may it be a menu problem?
>>
>> On Thu, Aug 21, 2008 at 1:00 PM, Victor Kane <victorkane at gmail.com> wrote:
>>> If you are using Drupal 6, then there are now separate permissions for
>>> creating, editing and deleting... check your permissions if this is
>>> the case
>>>
>>> On Thu, Aug 21, 2008 at 7:16 AM, Llu?s <enboig at gmail.com> wrote:
>>>> I have developed several node types for an application, and in one of
>>>> them "delete" menu doesn't appear when viewing it; first I thought it
>>>> could be a permission problem, so I wrote:
>>>> function hook_access($op, $node) {
>>>>  return true; //debug
>>>> ...
>>>> }
>>>>
>>>> but nothing happend; then I tried with user 1 and it is the same (I
>>>> cleared all cache tables using phpmyadmin).
>>>> besides hook_delete and hook_access is there anything else necessary
>>>> for the menu to appear? From the administrative interface I can delete
>>>> the node without problems.
>>>>
>>>> thanks
>>>>
>>>> --
>>>> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>>>> nom?s una vegada.
>>>> *La felicitat ha de ser compatible, compartible i cooperativa.
>>>> *Envellim quan els records superen les il?lusions.
>>>> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
>>>> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>>>>
>>>
>>
>>
>>
>> --
>> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>> nom?s una vegada.
>> *La felicitat ha de ser compatible, compartible i cooperativa.
>> *Envellim quan els records superen les il?lusions.
>> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
>> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>>
>



-- 
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*La felicitat ha de ser compatible, compartible i cooperativa.
*Envellim quan els records superen les il?lusions.
*Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From enboig at gmail.com  Thu Aug 21 11:28:19 2008
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Thu, 21 Aug 2008 13:28:19 +0200
Subject: [development] delete menu not appearing
In-Reply-To: <45a29f450808210423j379234c7xde16a00d9e41d615@mail.gmail.com>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
	<ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
	<45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>
	<ff176450808210410o236367r556d3e5676cb8a72@mail.gmail.com>
	<45a29f450808210423j379234c7xde16a00d9e41d615@mail.gmail.com>
Message-ID: <45a29f450808210428q7e28ffc6xce8902269a32afe6@mail.gmail.com>

I forgot to say I added some "extra menu" to make me easy to customize
the menus like:

........
    $items[] = array('path' => 'comptacau/projectes/'. arg(2) .'/delete',
                     'title' => t('Delete'),
                     'callback' => 'drupal_get_form',
                     'callback arguments' =>
array('node_delete_confirm', $node),
                     'access' => node_access('delete', $node),
                     'weight' => 1,
                     'type' => MENU_LOCAL_TASK);
........

I checked for a concrete "projecte" node type, and going though
'comptacau/projectes/_nid_' (my menu) shows "delete" option, but not
through 'node/_nid_'

Can this affect menu system in any way? Some node types have this
custom menus, and some not; but all of the have delete option hidden.

On Thu, Aug 21, 2008 at 1:23 PM, Llu?s <enboig at gmail.com> wrote:
> I have programed my own premission system; but it shouldn't be the
> issue here, when de user goes to 'node/2175'
> appear 'view' and 'edit' not 'delete', but user can go manually to
> 'node/2175/delete' and delete the node with no problems.
>
>
> On Thu, Aug 21, 2008 at 1:10 PM, Victor Kane <victorkane at gmail.com> wrote:
>> Sometimes the permissions get very complicated in terms of filters,
>> ownership, edit own, edit, etc.
>>
>> One thing I sometimes do is make a backup of the database, then give
>> the non-admin user all node, filter, etc. permissions, and then start
>> taking off these permissions one by one to see what's going on.
>>
>> Another source of problems is if you have been using any kind of
>> access module which you have then disabled, then you will want to go
>> to Administer > Content management > Post settings and hit the rebuild
>> permissions button.
>>
>> Victor Kane
>> http://awebfactory.com.ar
>>
>> On Thu, Aug 21, 2008 at 8:05 AM, Llu?s <enboig at gmail.com> wrote:
>>> I am using drupal 5; I just updated the core to be sure I didn't
>>> change anything there, but the problem continues. It afect other
>>> node-types also. As I can delete nodes using the administrative
>>> interface, may it be a menu problem?
>>>
>>> On Thu, Aug 21, 2008 at 1:00 PM, Victor Kane <victorkane at gmail.com> wrote:
>>>> If you are using Drupal 6, then there are now separate permissions for
>>>> creating, editing and deleting... check your permissions if this is
>>>> the case
>>>>
>>>> On Thu, Aug 21, 2008 at 7:16 AM, Llu?s <enboig at gmail.com> wrote:
>>>>> I have developed several node types for an application, and in one of
>>>>> them "delete" menu doesn't appear when viewing it; first I thought it
>>>>> could be a permission problem, so I wrote:
>>>>> function hook_access($op, $node) {
>>>>>  return true; //debug
>>>>> ...
>>>>> }
>>>>>
>>>>> but nothing happend; then I tried with user 1 and it is the same (I
>>>>> cleared all cache tables using phpmyadmin).
>>>>> besides hook_delete and hook_access is there anything else necessary
>>>>> for the menu to appear? From the administrative interface I can delete
>>>>> the node without problems.
>>>>>
>>>>> thanks
>>>>>
>>>>> --
>>>>> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>>>>> nom?s una vegada.
>>>>> *La felicitat ha de ser compatible, compartible i cooperativa.
>>>>> *Envellim quan els records superen les il?lusions.
>>>>> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
>>>>> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
>>> nom?s una vegada.
>>> *La felicitat ha de ser compatible, compartible i cooperativa.
>>> *Envellim quan els records superen les il?lusions.
>>> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
>>> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>>>
>>
>
>
>
> --
> *La vida ?s com una moneda, la pots gastar en el que vulguis per?
> nom?s una vegada.
> *La felicitat ha de ser compatible, compartible i cooperativa.
> *Envellim quan els records superen les il?lusions.
> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
> *Abans d'imprimir aquest missatge, pensa en el medi ambient.
>



-- 
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*La felicitat ha de ser compatible, compartible i cooperativa.
*Envellim quan els records superen les il?lusions.
*Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From earnie at users.sourceforge.net  Thu Aug 21 11:32:06 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 21 Aug 2008 07:32:06 -0400
Subject: [development] autocomplete.js and http error 0
In-Reply-To: <48ACB9BA.2050805@northcountry.com>
References: <48ACB9BA.2050805@northcountry.com>
Message-ID: <20080821073206.l51yb0k4fq1c8g0s@mail.progw.org>

Quoting Roger Leigh <rleigh at northcountry.com>:

>
> Any ideas?
>

File an issue and supply a patch file for the fix.

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


From earnie at users.sourceforge.net  Thu Aug 21 14:00:09 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Thu, 21 Aug 2008 10:00:09 -0400
Subject: [development] delete menu not appearing
In-Reply-To: <45a29f450808210428q7e28ffc6xce8902269a32afe6@mail.gmail.com>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
	<ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
	<45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>
	<ff176450808210410o236367r556d3e5676cb8a72@mail.gmail.com>
	<45a29f450808210423j379234c7xde16a00d9e41d615@mail.gmail.com>
	<45a29f450808210428q7e28ffc6xce8902269a32afe6@mail.gmail.com>
Message-ID: <20080821100009.w2tran8iihq8wkgk@mail.progw.org>

Quoting Llu?s <enboig at gmail.com>:

> I forgot to say I added some "extra menu" to make me easy to customize
> the menus like:
>
> ........
>    $items[] = array('path' => 'comptacau/projectes/'. arg(2) .'/delete',
>                     'title' => t('Delete'),
>                     'callback' => 'drupal_get_form',
>                     'callback arguments' =>
> array('node_delete_confirm', $node),
>                     'access' => node_access('delete', $node),
>                     'weight' => 1,
>                     'type' => MENU_LOCAL_TASK);
> ........
>
> I checked for a concrete "projecte" node type, and going though
> 'comptacau/projectes/_nid_' (my menu) shows "delete" option, but not
> through 'node/_nid_'
>
> Can this affect menu system in any way? Some node types have this
> custom menus, and some not; but all of the have delete option hidden.
>

In your module add a MENU_LOCAL_TASK item for 'node/' . arg(2) . 
'/delete'.  The delete function currently is part of the edit page but 
there is no reason you can't added a MENU_LOCAL_TASK for it.

> On Thu, Aug 21, 2008 at 1:23 PM, Llu?s <enboig at gmail.com> wrote:
>> I have programed my own premission system; but it shouldn't be the
>> issue here, when de user goes to 'node/2175'
>> appear 'view' and 'edit' not 'delete', but user can go manually to
>> 'node/2175/delete' and delete the node with no problems.
>>

The manual path works because there is a MENU_CALLBACK item for it to 
make the Delete button on the edit page work.

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


From enboig at gmail.com  Thu Aug 21 14:27:16 2008
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Thu, 21 Aug 2008 16:27:16 +0200
Subject: [development] delete menu not appearing
In-Reply-To: <20080821100009.w2tran8iihq8wkgk@mail.progw.org>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
	<ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
	<45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>
	<ff176450808210410o236367r556d3e5676cb8a72@mail.gmail.com>
	<45a29f450808210423j379234c7xde16a00d9e41d615@mail.gmail.com>
	<45a29f450808210428q7e28ffc6xce8902269a32afe6@mail.gmail.com>
	<20080821100009.w2tran8iihq8wkgk@mail.progw.org>
Message-ID: <45a29f450808210727u49bfa256y60bd708c199663a7@mail.gmail.com>

My fault, I was confused after working so long with my own modules; I
didn't remember by default drupal just allow to delete nodes from the
"edit" page; I thought there used to be a "delete" option when viewing
the node. I added this option because while developing it is easier to
delete test nodes.

Thanks to everybody.

On Thu, Aug 21, 2008 at 4:00 PM, Earnie Boyd
<earnie at users.sourceforge.net> wrote:
> Quoting Llu?s <enboig at gmail.com>:
>
>> I forgot to say I added some "extra menu" to make me easy to customize
>> the menus like:
>>
>> ........
>>   $items[] = array('path' => 'comptacau/projectes/'. arg(2) .'/delete',
>>                    'title' => t('Delete'),
>>                    'callback' => 'drupal_get_form',
>>                    'callback arguments' =>
>> array('node_delete_confirm', $node),
>>                    'access' => node_access('delete', $node),
>>                    'weight' => 1,
>>                    'type' => MENU_LOCAL_TASK);
>> ........
>>
>> I checked for a concrete "projecte" node type, and going though
>> 'comptacau/projectes/_nid_' (my menu) shows "delete" option, but not
>> through 'node/_nid_'
>>
>> Can this affect menu system in any way? Some node types have this
>> custom menus, and some not; but all of the have delete option hidden.
>>
>
> In your module add a MENU_LOCAL_TASK item for 'node/' . arg(2) . '/delete'.
>  The delete function currently is part of the edit page but there is no
> reason you can't added a MENU_LOCAL_TASK for it.
>
>> On Thu, Aug 21, 2008 at 1:23 PM, Llu?s <enboig at gmail.com> wrote:
>>>
>>> I have programed my own premission system; but it shouldn't be the
>>> issue here, when de user goes to 'node/2175'
>>> appear 'view' and 'edit' not 'delete', but user can go manually to
>>> 'node/2175/delete' and delete the node with no problems.
>>>
>
> The manual path works because there is a MENU_CALLBACK item for it to make
> the Delete button on the edit page work.
>
> Earnie -- http://for-my-kids.com/
> -- http://give-me-an-offer.com/
>
>



-- 
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*La felicitat ha de ser compatible, compartible i cooperativa.
*Envellim quan els records superen les il?lusions.
*Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From kb at 2bits.com  Thu Aug 21 14:30:15 2008
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Thu, 21 Aug 2008 10:30:15 -0400
Subject: [development] delete menu not appearing
In-Reply-To: <45a29f450808210428q7e28ffc6xce8902269a32afe6@mail.gmail.com>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
	<ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
	<45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>
	<ff176450808210410o236367r556d3e5676cb8a72@mail.gmail.com>
	<45a29f450808210423j379234c7xde16a00d9e41d615@mail.gmail.com>
	<45a29f450808210428q7e28ffc6xce8902269a32afe6@mail.gmail.com>
Message-ID: <4a9fdc630808210730w588415e4ia1ad27e61e1a0605@mail.gmail.com>

On Thu, Aug 21, 2008 at 7:28 AM, Llu?s <enboig at gmail.com> wrote:

> I forgot to say I added some "extra menu" to make me easy to customize
> the menus like:
>
> ........
>    $items[] = array('path' => 'comptacau/projectes/'. arg(2) .'/delete',
>                     'title' => t('Delete'),
>                     'callback' => 'drupal_get_form',
>                     'callback arguments' =>
> array('node_delete_confirm', $node),
>                     'access' => node_access('delete', $node),
>                     'weight' => 1,
>                     'type' => MENU_LOCAL_TASK);
> ........
>

node_access() expects a $node object to be passed in. You have not pasted
the entire hook_menu function from your module, but I if you do want to
check node_access(), you have to make sure you do node_load() beforehand, on
that path so node_access has something to check.


-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080821/7e06db46/attachment.htm 

From enboig at gmail.com  Thu Aug 21 14:33:48 2008
From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=)
Date: Thu, 21 Aug 2008 16:33:48 +0200
Subject: [development] delete menu not appearing
In-Reply-To: <4a9fdc630808210730w588415e4ia1ad27e61e1a0605@mail.gmail.com>
References: <45a29f450808210316ue01035cib9cf5c5d9f5da037@mail.gmail.com>
	<ff176450808210400u2ca79cd9p52f065db3d4892df@mail.gmail.com>
	<45a29f450808210405o57b91d45y4467925269db3219@mail.gmail.com>
	<ff176450808210410o236367r556d3e5676cb8a72@mail.gmail.com>
	<45a29f450808210423j379234c7xde16a00d9e41d615@mail.gmail.com>
	<45a29f450808210428q7e28ffc6xce8902269a32afe6@mail.gmail.com>
	<4a9fdc630808210730w588415e4ia1ad27e61e1a0605@mail.gmail.com>
Message-ID: <45a29f450808210733q1a48aaa4pf71cb32a77b5abbc@mail.gmail.com>

I already do node_load() earlier in the hook_menu(), thanks.

Now everythink works ok

On Thu, Aug 21, 2008 at 4:30 PM, Khalid Baheyeldin <kb at 2bits.com> wrote:
> On Thu, Aug 21, 2008 at 7:28 AM, Llu?s <enboig at gmail.com> wrote:
>>
>> I forgot to say I added some "extra menu" to make me easy to customize
>> the menus like:
>>
>> ........
>>    $items[] = array('path' => 'comptacau/projectes/'. arg(2) .'/delete',
>>                     'title' => t('Delete'),
>>                     'callback' => 'drupal_get_form',
>>                     'callback arguments' =>
>> array('node_delete_confirm', $node),
>>                     'access' => node_access('delete', $node),
>>                     'weight' => 1,
>>                     'type' => MENU_LOCAL_TASK);
>> ........
>
> node_access() expects a $node object to be passed in. You have not pasted
> the entire hook_menu function from your module, but I if you do want to
> check node_access(), you have to make sure you do node_load() beforehand, on
> that path so node_access has something to check.
>
>
> --
> Khalid M. Baheyeldin
> 2bits.com, Inc.
> http://2bits.com
> Drupal optimization, development, customization and consulting.
>



-- 
*La vida ?s com una moneda, la pots gastar en el que vulguis per?
nom?s una vegada.
*La felicitat ha de ser compatible, compartible i cooperativa.
*Envellim quan els records superen les il?lusions.
*Als llocs desconeguts nom?s s'hi arriba per camins desconeguts.
*Abans d'imprimir aquest missatge, pensa en el medi ambient.

From cwgordon7 at cwgordon.com  Thu Aug 21 14:44:08 2008
From: cwgordon7 at cwgordon.com (Charlie Gordon)
Date: Thu, 21 Aug 2008 10:44:08 -0400
Subject: [development] autocomplete.js and http error 0
In-Reply-To: <48ACB9BA.2050805@northcountry.com>
References: <48ACB9BA.2050805@northcountry.com>
Message-ID: <48AD7F38.8070009@cwgordon.com>

Roger Leigh wrote:
> Any ideas?

Perhaps try figuring out why an "http error 0" occurred, rather than 
suppressing the message in autocomplete.js. E.g. go to the autocomplete 
path specified - do you get the proper headers and json?

-Charlie

From drupal_development at dropcube.com  Thu Aug 21 17:12:22 2008
From: drupal_development at dropcube.com (Dropcube)
Date: Thu, 21 Aug 2008 12:12:22 -0500
Subject: [development] autocomplete.js and http error 0
In-Reply-To: <48AD7F38.8070009@cwgordon.com>
References: <48ACB9BA.2050805@northcountry.com> <48AD7F38.8070009@cwgordon.com>
Message-ID: <48ADA1F6.7050108@dropcube.com>

Firebug can help you to debug, you can see the headers and output of the 
Ajax requests.
http://getfirebug.com/

Charlie Gordon wrote:
> Roger Leigh wrote:
>> Any ideas?
>
> Perhaps try figuring out why an "http error 0" occurred, rather than 
> suppressing the message in autocomplete.js. E.g. go to the 
> autocomplete path specified - do you get the proper headers and json?
>
> -Charlie


From rleigh at northcountry.com  Thu Aug 21 19:45:16 2008
From: rleigh at northcountry.com (Roger Leigh)
Date: Thu, 21 Aug 2008 12:45:16 -0700
Subject: [development] autocomplete.js and http error 0
In-Reply-To: <48ADA1F6.7050108@dropcube.com>
References: <48ACB9BA.2050805@northcountry.com>
	<48AD7F38.8070009@cwgordon.com> <48ADA1F6.7050108@dropcube.com>
Message-ID: <48ADC5CC.6020107@northcountry.com>

The problem is not with the autocomplete php routine. The error is 
occurring in the javascript; it happens when the submit button is 
selected before the ajax routine is finished. You can repeat it by 
starting the autocomplete process (seeing the blue circle) and 
submitting immediately. Normally, it happens so fast that the process 
completes before the form is submitted, but I think this is a 
combination of bad server response, slow connection and large number of 
data entries to process.

I use firebug all the time, but I've never been much of a Javascript 
expert. It has something to do with code in jquery.js, and I can 
certainly look to that with an unpacked version, but I just hoped 
someone had encountered this already.

the error occurs on line 285 in the autocomplete.js, at the error alert:

    // Ajax GET request for autocompletion

    $.ajax({

      type: "GET",

      url: db.uri +'/'+ Drupal.encodeURIComponent(searchString),

      success: function (data) {

        // Parse back result

        var matches = Drupal.parseJson(data);

        if (typeof matches['status'] == 'undefined' || matches['status'] != 0) {

          db.cache[searchString] = matches;

          // Verify if these are still the matches the user wants to see

          if (db.searchString == searchString) {

            db.owner.found(matches);

          }

          db.owner.setStatus('found');

        }

      },

      error: function (xmlhttp) {

        alert('An HTTP error '+ xmlhttp.status +' occured.\n'+ db.uri);

      }

-Roger


Dropcube wrote:
> Firebug can help you to debug, you can see the headers and output of 
> the Ajax requests.
> http://getfirebug.com/
>
> Charlie Gordon wrote:
>> Roger Leigh wrote:
>>> Any ideas?
>>
>> Perhaps try figuring out why an "http error 0" occurred, rather than 
>> suppressing the message in autocomplete.js. E.g. go to the 
>> autocomplete path specified - do you get the proper headers and json?
>>
>> -Charlie
>

From caleb.gilbert at gmail.com  Thu Aug 21 19:57:08 2008
From: caleb.gilbert at gmail.com (Caleb Gilbert)
Date: Thu, 21 Aug 2008 12:57:08 -0700
Subject: [development] Drupal and acceptance testing
Message-ID: <38ad0b0a0808211257y7a901bb1rc3fc5f2ef7d0e9de@mail.gmail.com>

So far all documentation and comments I can find on Drupal.org seem to give
the impression that the Drupal project/community-at-large is taking the
stance that simpletest should be used for acceptance testing (please correct
me if I'm wrong). This, however, would be counter to simpletest's own
documentation which suggests to look at other solutions for acceptance
testing: http://simpletest.org/api/ (bottom of page)

In the interest interest of stimulating solutions/attention/discussion to
these subjects I've posted an article which contains information and links
to other Drupal.org resources about this:
http://highervisibilitywebsites.com/researching-drupal-and-acceptance-testing-or-where-simpletest-seems-fall-short

Cheers!
Caleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080821/96c12ed6/attachment.htm 

From cwgordon7 at cwgordon.com  Thu Aug 21 20:52:12 2008
From: cwgordon7 at cwgordon.com (Charlie Gordon)
Date: Thu, 21 Aug 2008 16:52:12 -0400
Subject: [development] Drupal and acceptance testing
In-Reply-To: <38ad0b0a0808211257y7a901bb1rc3fc5f2ef7d0e9de@mail.gmail.com>
References: <38ad0b0a0808211257y7a901bb1rc3fc5f2ef7d0e9de@mail.gmail.com>
Message-ID: <48ADD57C.5020606@cwgordon.com>

Caleb Gilbert wrote:
> So far all documentation and comments I can find on Drupal.org seem to 
> give the impression that the Drupal project/community-at-large is 
> taking the stance that simpletest should be used for acceptance 
> testing (please correct me if I'm wrong). This, however, would be 
> counter to simpletest's own documentation which suggests to look at 
> other solutions for acceptance testing: http://simpletest.org/api/ 
> (bottom of page)

The Drupal SimpleTest module has progressed far beyond the original 
SimpleTest we started with - we now have a more powerful, although 
Drupal-specific testing framework which still retains the somewhat 
misleading name "SimpleTest" (there's an issue somewhere to rename 
SimpleTest to testing). We currently do have both functional and unit 
tests working under the current framework - although javascript tests 
currently remain impossible, although there are several issues 
addressing that point (feel free to help!).

But basically, our Drupal-specific extension of SimpleTest meets our 
needs for functional testing and unit testing so well, I don't think 
there's really any point to looking into other harder-to-install 
automated testing tools - they'll never be used by a sizable percentage 
of the Drupal community, whereas the SimpleTest module for Drupal 
requires very little in order to function properly. The current 
framework covers the vast majority of our testing needs; the tests are 
lagging far behind the testing framework here. We don't really need to 
rethink our framework or consider other frameworks until we've reached 
the limit of what the current framework can do. JavaScript tests would 
certainly be nice, but should we really worry ourselves with them when 
much important core php code remains entirely untested?

-Charlie

From r.crowther at zen.co.uk  Thu Aug 21 21:29:59 2008
From: r.crowther at zen.co.uk (robert crowther)
Date: Thu, 21 Aug 2008 22:29:59 +0100
Subject: [development] New module makes custom menus from
	taxonomy	-	experienced coder	wish to pick this up?
In-Reply-To: <48A145CD.7040607@perlucida.com>
References: <1218526274.8160.26.camel@robert-desktop>
	<48A145CD.7040607@perlucida.com>
Message-ID: <1219354199.21273.4.camel@robert-desktop>

Hello Adrian,

It's taken me a few days to reply, apologies.

First up, thank you for taking the time to mail back explaining what I
should do. No need for people to do that, but lists and forums would be
better for the effort.

See, I didn't think it was releasable, so I didn't follow any links on
Drupal contributions. I don't even have that much culture. I've never
used a content versioning system, let alone know where to find the
Drupal one. So I may take this route up.

Any project has a curve of learning plotted against achievement. I have
learned about not one but two Drupal menu systems, taught myself PHP,
and written the modules. In a few weeks. This is the obvious place for
me to stop. But given that there is an evident low level interest in
such a module, I wondered if it should go out work somewhere.

I was aware of  
"I can't be bothered to maintain this, can someone do it for me?"
Hope the above explains.

I'm also aware of the strangeness of posting to the dev list. But the
module reads like a core module in places. It needs that quality of
input to make it solid.

Yes, maybe I wouldn't subscribe to a dev list normally, but I would
always trawl the dev list archives on any project. Wouldn't anybody? I
like to know what can be known before I set my compass.

Thanks again for the information,

Robert


On Tue, 2008-08-12 at 09:11 +0100, Adrian Simmons wrote:
> robert crowther wrote:
> > All you have to do is mail me back, and we can take it from there.
> This is what Drupal's CVS contrib repository is for! :)
> 
> Seriously. Upload it to contrib, make a project and just have a development 
> release, in the project description tell people about it and that you 
> consider it alpha or beta quality. Say you're looking for a co-maintainer.
> 
> If people want to use it and find bugs, you'll get bug reports. If you're 
> lucky you'll also get patches. You may even get someone interested enough to 
> help maintain it.
> 
> But just posting to the dev list like this (is everybody that writes modules 
> even subscribed to this list?) has more of an air of "I can't be bothered to 
> maintain this, can someone do it for me?".
> 
> At worst it'll sit in contrib and nothing will happen, at best you may get 
> patches that teach you better php coding :)
> 


From caleb.gilbert at gmail.com  Thu Aug 21 22:35:01 2008
From: caleb.gilbert at gmail.com (Caleb Gilbert)
Date: Thu, 21 Aug 2008 15:35:01 -0700
Subject: [development]  Drupal and acceptance testing
Message-ID: <38ad0b0a0808211535i6340a2ddvbedab9d93d024016@mail.gmail.com>

The Drupal SimpleTest module has progressed far beyond the original
SimpleTest we started with - we now have a more powerful, although
Drupal-specific testing framework which still retains the somewhat
misleading name "SimpleTest" (there's an issue somewhere to rename
SimpleTest to testing). We currently do have both functional and unit
tests working under the current framework - although javascript tests
currently remain impossible, although there are several issues
addressing that point (feel free to help!).

I think what you're saying confirms that while 'far-beyond the original
simpletest'  - the current testing framework in Drupal still has this in
common with the standard version of Simpletest -- it's primarily focused on
unit/functional testing - not acceptance testing, which is a whole different
focus. ( http://en.wikipedia.org/wiki/Acceptance_testing )

To help make what I'm talking about more understandable, here's a list of
what selenium (for instance) offers that simpletest (and the Drupal
implementation) does not:
a) a top-rated browser plugin which offers an interface for scripting,
exporting, and running tests specifically aimed at the browser-based aspect
of a web application (again *not* unit/functional testing) (screenshots and
explanation http://www.spreadfirefox.com/node/980 )
b) an additional tool, Selenium RC, which includes functionlity to
automatically launch a variety of browsers and step through the tests in
each browser - as an end-user would do
c) testing of ajax/js ui elements


But basically, our Drupal-specific extension of SimpleTest meets our
needs for functional testing and unit testing so well, I don't think
there's really any point to looking into other harder-to-install
automated testing tools - they'll never be used by a sizable percentage
of the Drupal community, whereas the SimpleTest module for Drupal
requires very little in order to function properly. The current
framework covers the vast majority of our testing needs; the tests are
lagging far behind the testing framework here. We don't really need to
rethink our framework or consider other frameworks until we've reached
the limit of what the current framework can do. JavaScript tests would
certainly be nice, but should we really worry ourselves with them when
much important core php code remains entirely untested?

Again, acceptance testing/selenium does not just = adding-javascript support
to unit tests - it equals a whole other kind of testing - one I believe that
a very sizable percentage of the Drupal community is interested in I'm sure
- testing from the end-user/client perspective. So this would not be a
matter of rethinking the existing framework - it's would be adding on to it
and/or getting a way to more easily get selenium working with Drupal so that
Drupal developers can include accetance test within their workflow.

For anyone who doesn't have the bandwidth or the interest to work on finding
solutions to better acceptance testing within Drupal I can understand - but
I just wanted to point out the difference between what is in Drupal now and
what I'm talking about. They are different and it's not just about what's in
Drupal 'missing javascript support'.

- Caleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080821/ac60c3ca/attachment.htm 

From caleb.gilbert at gmail.com  Thu Aug 21 22:43:48 2008
From: caleb.gilbert at gmail.com (Caleb Gilbert)
Date: Thu, 21 Aug 2008 15:43:48 -0700
Subject: [development]  Drupal and acceptance testing
In-Reply-To: <38ad0b0a0808211535i6340a2ddvbedab9d93d024016@mail.gmail.com>
References: <38ad0b0a0808211535i6340a2ddvbedab9d93d024016@mail.gmail.com>
Message-ID: <38ad0b0a0808211543k259bcda0k18a2a997e2b4d30d@mail.gmail.com>

(Reposted because mailserve stripped blockquotes making things
unreadable - apologies)

> The Drupal SimpleTest module has progressed far beyond the original
> SimpleTest we started with - we now have a more powerful, although
> Drupal-specific testing framework which still retains the somewhat
> misleading name "SimpleTest" (there's an issue somewhere to rename
> SimpleTest to testing). We currently do have both functional and unit
> tests working under the current framework - although javascript tests
> currently remain impossible, although there are several issues
> addressing that point (feel free to help!).

I think what you're saying confirms that while 'far-beyond the original
simpletest'  - the current testing framework in Drupal still has this in
common with the standard version of Simpletest -- it's primarily focused on
unit/functional testing - not acceptance testing, which is a whole different
focus. ( http://en.wikipedia.org/wiki/Acceptance_testing )

To help make what I'm talking about more understandable, here's a list of
what selenium (for instance) offers that simpletest (and the Drupal
implementation) does not:
       a) a top-rated browser plugin which offers an interface for
scripting, exporting, and running tests
           specifically aimed at the browser-based aspect of a web
application (again *not* unit/functional
           testing) (screenshots and explanation
http://www.spreadfirefox.com/node/980 )
       b) an additional tool, Selenium RC, which includes functionlity to
automatically launch a variety
           of browsers and step through the tests in each browser - as an
end-user would do
      c) testing of ajax/js ui elements


> The Drupal SimpleTest module has progressed far beyond the original
> SimpleTest we started with - we now have a more powerful, although
> Drupal-specific testing framework which still retains the somewhat
> misleading name "SimpleTest" (there's an issue somewhere to rename
> SimpleTest to testing). We currently do have both functional and unit
> tests working under the current framework - although javascript tests
> currently remain impossible, although there are several issues
> addressing that point (feel free to help!).

Again, acceptance testing/selenium does not just = adding-javascript support
to unit tests - it equals a whole other kind of testing - one I believe that
a very sizable percentage of the Drupal community is interested in I'm sure
- testing from the end-user/client perspective. So this would not be a
matter of rethinking the existing framework - it's would be adding on to it
and/or getting a way to more easily get selenium working with Drupal so that
Drupal developers can include accetance test within their workflow.

For anyone who doesn't have the bandwidth or the interest to work on finding
solutions to better acceptance testing within Drupal I can understand - but
I just wanted to point out the difference between what is in Drupal now and
what I'm talking about. They are different and it's not just about what's in
Drupal 'missing javascript support'.

- Caleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080821/cba904da/attachment.htm 

From catch56 at googlemail.com  Thu Aug 21 23:11:04 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Fri, 22 Aug 2008 00:11:04 +0100
Subject: [development] Drupal and acceptance testing
In-Reply-To: <38ad0b0a0808211543k259bcda0k18a2a997e2b4d30d@mail.gmail.com>
References: <38ad0b0a0808211535i6340a2ddvbedab9d93d024016@mail.gmail.com>
	<38ad0b0a0808211543k259bcda0k18a2a997e2b4d30d@mail.gmail.com>
Message-ID: <fa5724270808211611p57494219r8a648c831cc0572a@mail.gmail.com>

I suggested an automated javascript testing framework for gsoc, was thinking
watir rather than selenium based on a few discussions about both, but it
didn't go anywhere:http://groups.drupal.org/node/9511,

While I'd love to see testing with Selenium or Watir or some other browser
remote control that can handle stuff that simpletest or straight up
javascript unit testing can't, like cwgordon said, it's a matter of effort
and returns.

The testing framework we have in core has the advantage that anyone can
download and run tests without needing to install other software, tests can
be written in PHP, and we're getting close to the tipping point where our
coverage is high enough to start finding regressions before they're
committed.

On the other hand, and  unfortunately, at the moment we don't have that many
jQuery intensive patches - yes, it's really annoying trying to get
cross-browser tests when a new jQuery is released, but that's once every few
months - so in terms of saving click around time SimpleTest is giving higher
returns at the moment. While it might appear to be a lack of interest at the
moment, it's more a case of 1. a lack of resources (the 'testing brigade' is
still pretty small) 2. a need to get the testing framework we actually have
up to a point where it begins to actually save some work - it'll only do
this when we're closer to 100% test coverage and tests are being run on
patches automatically via testing.drupal.org

That said - it's very clear that the core testing framework can't cover
everything, so extending it would be the natural next step - and given the
amount of time and work it's taken to get to where we are now, starting
early surely wouldn't hurt.

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

From cxjohnson at gmail.com  Fri Aug 22 03:21:37 2008
From: cxjohnson at gmail.com (Chris Johnson)
Date: Thu, 21 Aug 2008 21:21:37 -0600
Subject: [development] External database handling
Message-ID: <9ea8d6030808212021j9413faer874258476dc736e3@mail.gmail.com>

Is it generally desirable that contributed modules use the Drupal
database abstraction whenever possible when accessing external
databases?  That is, is it generally preferable to use db_query() and
friends, instead of mysql_connect(), mysql_query(), etc. whenever
possible?

I personally think so at the moment, but would certainly like to hear
any arguments to the contrary.  An argument that it doesn't really
matter is an argument against generally using Drupal's DB layer.

If one agrees it is generally better to use the Drupal DB layer, there
is a significant problem to doing so.  The code which supports
multiple databases (of which I admit to being partially the author),
such as db_set_active(), requires the additional databases to be
listed in an array version of the global $db_url variable (up to and
including Drupal 6) and $databases (Drupal 7).  This array is set in
the settings.php file.

When using the Drupal 6 installer, this file can be written for the
user doing the install.  One can assume that most installations will
thus likely not involve someone hand editing that file.  Yet, except
for some ugly kludges involving overwriting the $db_url or $databases
variable (a scalar by default) with an array form including the extra
external database(s), the only way to add an external database is to
hand edit that file.

If one wants to write a contrib module which has all the ease of
installation which D6 and D7 core have, and which uses an external
database, one is rather stuck.  One can either (1) kludge up the
$db_url or $databases variable by overwriting it, (2) require the user
to expertly hand-edit the settings.php file or (3) not use the Drupal
DB abstraction layer.

Or so it seems.  The contrib modules I've looked at so far mostly
resort to #3, not using the DB abstraction.

I'd especially like to chat with the folks working on the DB layer for
D7.  It would be nice to provide an interface to allow adding an
additional DB programmatically from the contrib module.

..chris

From metzlerd at metzlerd.com  Fri Aug 22 04:50:53 2008
From: metzlerd at metzlerd.com (David Metzler)
Date: Thu, 21 Aug 2008 21:50:53 -0700
Subject: [development] External database handling
In-Reply-To: <9ea8d6030808212021j9413faer874258476dc736e3@mail.gmail.com>
References: <9ea8d6030808212021j9413faer874258476dc736e3@mail.gmail.com>
Message-ID: <29892E39-028D-4839-8FE2-56D11430BDB5@metzlerd.com>

When  writing integration modules that are connecting to external  
data sources in non-supported drupal db languages (MSSQL, orcale,  
etc) , I have generally used a separate database abstraction layer,  
such as ADODB or PEARDB.

Or better yet, implement an xmlrpc or restxml layer between your app  
and the external database, so that the External DB doesn't even need  
to be hosted on the same box as the drupal code tree.

I wouldn't call these anointed best practices, but it certainly is  
the approach that has kept the integration code the cleanest for me.

Dave
On Aug 21, 2008, at 8:21 PM, Chris Johnson wrote:

> Is it generally desirable that contributed modules use the Drupal
> database abstraction whenever possible when accessing external
> databases?  That is, is it generally preferable to use db_query() and
> friends, instead of mysql_connect(), mysql_query(), etc. whenever
> possible?
>
> I personally think so at the moment, but would certainly like to hear
> any arguments to the contrary.  An argument that it doesn't really
> matter is an argument against generally using Drupal's DB layer.
>
> If one agrees it is generally better to use the Drupal DB layer, there
> is a significant problem to doing so.  The code which supports
> multiple databases (of which I admit to being partially the author),
> such as db_set_active(), requires the additional databases to be
> listed in an array version of the global $db_url variable (up to and
> including Drupal 6) and $databases (Drupal 7).  This array is set in
> the settings.php file.
>
> When using the Drupal 6 installer, this file can be written for the
> user doing the install.  One can assume that most installations will
> thus likely not involve someone hand editing that file.  Yet, except
> for some ugly kludges involving overwriting the $db_url or $databases
> variable (a scalar by default) with an array form including the extra
> external database(s), the only way to add an external database is to
> hand edit that file.
>
> If one wants to write a contrib module which has all the ease of
> installation which D6 and D7 core have, and which uses an external
> database, one is rather stuck.  One can either (1) kludge up the
> $db_url or $databases variable by overwriting it, (2) require the user
> to expertly hand-edit the settings.php file or (3) not use the Drupal
> DB abstraction layer.
>
> Or so it seems.  The contrib modules I've looked at so far mostly
> resort to #3, not using the DB abstraction.
>
> I'd especially like to chat with the folks working on the DB layer for
> D7.  It would be nice to provide an interface to allow adding an
> additional DB programmatically from the contrib module.
>
> ..chris


From larry at garfieldtech.com  Fri Aug 22 05:24:12 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Fri, 22 Aug 2008 00:24:12 -0500
Subject: [development] External database handling
In-Reply-To: <9ea8d6030808212021j9413faer874258476dc736e3@mail.gmail.com>
References: <9ea8d6030808212021j9413faer874258476dc736e3@mail.gmail.com>
Message-ID: <200808220024.12674.larry@garfieldtech.com>

On Thursday 21 August 2008 10:21:37 pm Chris Johnson wrote:
> Is it generally desirable that contributed modules use the Drupal
> database abstraction whenever possible when accessing external
> databases?  That is, is it generally preferable to use db_query() and
> friends, instead of mysql_connect(), mysql_query(), etc. whenever
> possible?

Yes, very much so.  All of the security system is built into the abstraction 
layer; using mysql_query() directly means you're totally on your own for 
security.

> I'd especially like to chat with the folks working on the DB layer for
> D7.  It would be nice to provide an interface to allow adding an
> additional DB programmatically from the contrib module.
>
> ..chris

Well hi there! :-)

What you describe was absolutely an issue in the D6 and earlier DB layer.  The 
new DB layer is still not perfect, but has improved on it in two ways:

1) The $databases value is always an array.  It can be a flattened array, as 
some layers are optional, but since the installer populates it in the first 
place it will in almost every case already be an array.  

2) You can actually instantiate a connection object directly.  I wouldn't 
recommend it as then the core system can't switch to it, but it's 
possible. :-)

3) (Nobody expects the Spanish Inquisition!)  The db_*() functions are all 
dumb wrappers.  You can grab a database connection with 
Database::getConnection($key) and then do everything after that with method 
calls; $db->query(), $db->insert(), $db->select(), etc.  So if you want to 
use a given database connection and just pull yourself out of the 
Drupal "active database" definition entirely, you can do so.

It's still not perfect, though, I agree.  If you have a suggestion for how to 
make the connection management more flexible without hurting performance (it 
is along the critical path, so we have to be careful) please post an issue.  
Just because the mega-patch landed doesn't mean we're done changing things 
yet. :-)

-- 
Larry Garfield
larry at garfieldtech.com

From csillagasz at gmail.com  Fri Aug 22 10:15:42 2008
From: csillagasz at gmail.com (Balazs Dianiska)
Date: Fri, 22 Aug 2008 11:15:42 +0100
Subject: [development] access module
Message-ID: <372ed1ba0808220315t1b9e821bk260fd58be0921762@mail.gmail.com>

Hi all,

for work I am thinking on implementing an access logging module, but
before I would start head on I would like to ask your opinion on the
subject. Drupal core provides a logging module (the access module),
which effectively logs on hook_exit. The problem I have with this
approach is that this
a) as far I know will get ignored for aggressive caching,
b) it gets triggered for page load from any source.

I thought about using a JavaScript snippet placed into the page (maybe
with token so it couldn't be misused, but then a cached page is not
trivial) as most bots cant run the JS. Is there any way a callback
like this could be validated for a cache stored page? What do you
think of the approach?

Would appreciate any feedback,
Balazs

From earnie at users.sourceforge.net  Fri Aug 22 12:43:58 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Fri, 22 Aug 2008 08:43:58 -0400
Subject: [development] access module
In-Reply-To: <372ed1ba0808220315t1b9e821bk260fd58be0921762@mail.gmail.com>
References: <372ed1ba0808220315t1b9e821bk260fd58be0921762@mail.gmail.com>
Message-ID: <20080822084358.tiubffm13fsos8cg@mail.progw.org>

Quoting Balazs Dianiska <csillagasz at gmail.com>:

> Hi all,
>
> for work I am thinking on implementing an access logging module, but
> before I would start head on I would like to ask your opinion on the
> subject. Drupal core provides a logging module (the access module),
> which effectively logs on hook_exit. The problem I have with this
> approach is that this
> a) as far I know will get ignored for aggressive caching,
> b) it gets triggered for page load from any source.
>
> I thought about using a JavaScript snippet placed into the page (maybe
> with token so it couldn't be misused, but then a cached page is not
> trivial) as most bots cant run the JS. Is there any way a callback
> like this could be validated for a cache stored page? What do you
> think of the approach?
>

Have you researched existing solutions?  
http://www.google.com/search?q=access+log+site%3Adrupal.org%2Fproject

Are you looking for a method to log each form access?

Create a module foo.

<?php
function foo_form_alter ($form_id, &$form) {
  global $user;
  watchdog ('form access', t('@uid accessed @form_id', array('@uid' => 
$user->uid, '#form_id' => $form_id)));
}
?>

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


From ernst.pluess at gmail.com  Fri Aug 22 13:19:00 2008
From: ernst.pluess at gmail.com (=?ISO-8859-1?Q?Ernst_Pl=FCss?=)
Date: Fri, 22 Aug 2008 15:19:00 +0200
Subject: [development] External database handling
In-Reply-To: <200808220024.12674.larry@garfieldtech.com>
References: <9ea8d6030808212021j9413faer874258476dc736e3@mail.gmail.com>
	<200808220024.12674.larry@garfieldtech.com>
Message-ID: <27c534c90808220619h1ad06993o9b181053f23de784@mail.gmail.com>

I'm just in the process of writing a osCommerce api for Drupal. I started my
work by using db_set_active(). Unfortunaltey this only works as long there
are now problems in the code. (Which of course shouldn't be the case for
production).

Let's make an example:

db_set_active('oscommerce');
// read oscommerce data
db_set_active();

If an error occurs during the oscommer data access the drupal DB is not
found any more. You'll get error messeage telling you that table watchdog
couldn't be found.
I thing we should use the db_* methods because of security, but replacing
the active DB isn't fail proof.

Best Regards
Ernst


2008/8/22 Larry Garfield <larry at garfieldtech.com>

> On Thursday 21 August 2008 10:21:37 pm Chris Johnson wrote:
> > Is it generally desirable that contributed modules use the Drupal
> > database abstraction whenever possible when accessing external
> > databases?  That is, is it generally preferable to use db_query() and
> > friends, instead of mysql_connect(), mysql_query(), etc. whenever
> > possible?
>
> Yes, very much so.  All of the security system is built into the
> abstraction
> layer; using mysql_query() directly means you're totally on your own for
> security.
>
> > I'd especially like to chat with the folks working on the DB layer for
> > D7.  It would be nice to provide an interface to allow adding an
> > additional DB programmatically from the contrib module.
> >
> > ..chris
>
> Well hi there! :-)
>
> What you describe was absolutely an issue in the D6 and earlier DB layer.
>  The
> new DB layer is still not perfect, but has improved on it in two ways:
>
> 1) The $databases value is always an array.  It can be a flattened array,
> as
> some layers are optional, but since the installer populates it in the first
> place it will in almost every case already be an array.
>
> 2) You can actually instantiate a connection object directly.  I wouldn't
> recommend it as then the core system can't switch to it, but it's
> possible. :-)
>
> 3) (Nobody expects the Spanish Inquisition!)  The db_*() functions are all
> dumb wrappers.  You can grab a database connection with
> Database::getConnection($key) and then do everything after that with method
> calls; $db->query(), $db->insert(), $db->select(), etc.  So if you want to
> use a given database connection and just pull yourself out of the
> Drupal "active database" definition entirely, you can do so.
>
> It's still not perfect, though, I agree.  If you have a suggestion for how
> to
> make the connection management more flexible without hurting performance
> (it
> is along the critical path, so we have to be careful) please post an issue.
> Just because the mega-patch landed doesn't mean we're done changing things
> yet. :-)
>
> --
> Larry Garfield
> larry at garfieldtech.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080822/3215e40c/attachment.htm 

From cwgordon7 at cwgordon.com  Fri Aug 22 14:20:53 2008
From: cwgordon7 at cwgordon.com (Charlie Gordon)
Date: Fri, 22 Aug 2008 10:20:53 -0400
Subject: [development] access module
In-Reply-To: <372ed1ba0808220315t1b9e821bk260fd58be0921762@mail.gmail.com>
References: <372ed1ba0808220315t1b9e821bk260fd58be0921762@mail.gmail.com>
Message-ID: <48AECB45.5050900@cwgordon.com>

Balazs Dianiska wrote:
> I thought about using a JavaScript snippet placed into the page (maybe
> with token so it couldn't be misused, but then a cached page is not
> trivial) as most bots cant run the JS. Is there any way a callback
> like this could be validated for a cache stored page? What do you
> think of the approach?

I wouldn't worry too much about misuse, since people could just visit 
the page hundreds of times anyway to achieve the same result - just make 
a post request to a javascript menu callback, and log from there.

-Charlie

From larry at garfieldtech.com  Fri Aug 22 15:43:08 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Fri, 22 Aug 2008 10:43:08 -0500
Subject: [development] External database handling
In-Reply-To: <27c534c90808220619h1ad06993o9b181053f23de784@mail.gmail.com>
References: <27c534c90808220619h1ad06993o9b181053f23de784@mail.gmail.com>
Message-ID: <23071fa58f8bdb387298b52eead32a83@localhost>


I may not have been clear below.  Using $db->query() is just as secure as using db_query().  The security handling happens much further down in the system.  db_query() is now basically a dumb convenience wrapper that has really only one line of value in it (once the BC layer is removed).

--Larry Garfield

On Fri, 22 Aug 2008 15:19:00 +0200, "Ernst Pl?ss" <ernst.pluess at gmail.com> wrote:
> I'm just in the process of writing a osCommerce api for Drupal. I started
> my
> work by using db_set_active(). Unfortunaltey this only works as long there
> are now problems in the code. (Which of course shouldn't be the case for
> production).
> 
> Let's make an example:
> 
> db_set_active('oscommerce');
> // read oscommerce data
> db_set_active();
> 
> If an error occurs during the oscommer data access the drupal DB is not
> found any more. You'll get error messeage telling you that table watchdog
> couldn't be found.
> I thing we should use the db_* methods because of security, but replacing
> the active DB isn't fail proof.
> 
> Best Regards
> Ernst
> 
> 
> 2008/8/22 Larry Garfield <larry at garfieldtech.com>
> 
>> On Thursday 21 August 2008 10:21:37 pm Chris Johnson wrote:
>> > Is it generally desirable that contributed modules use the Drupal
>> > database abstraction whenever possible when accessing external
>> > databases?  That is, is it generally preferable to use db_query() and
>> > friends, instead of mysql_connect(), mysql_query(), etc. whenever
>> > possible?
>>
>> Yes, very much so.  All of the security system is built into the
>> abstraction
>> layer; using mysql_query() directly means you're totally on your own for
>> security.
>>
>> > I'd especially like to chat with the folks working on the DB layer for
>> > D7.  It would be nice to provide an interface to allow adding an
>> > additional DB programmatically from the contrib module.
>> >
>> > ..chris
>>
>> Well hi there! :-)
>>
>> What you describe was absolutely an issue in the D6 and earlier DB
> layer.
>>  The
>> new DB layer is still not perfect, but has improved on it in two ways:
>>
>> 1) The $databases value is always an array.  It can be a flattened
> array,
>> as
>> some layers are optional, but since the installer populates it in the
> first
>> place it will in almost every case already be an array.
>>
>> 2) You can actually instantiate a connection object directly.  I
> wouldn't
>> recommend it as then the core system can't switch to it, but it's
>> possible. :-)
>>
>> 3) (Nobody expects the Spanish Inquisition!)  The db_*() functions are
> all
>> dumb wrappers.  You can grab a database connection with
>> Database::getConnection($key) and then do everything after that with
> method
>> calls; $db->query(), $db->insert(), $db->select(), etc.  So if you want
> to
>> use a given database connection and just pull yourself out of the
>> Drupal "active database" definition entirely, you can do so.
>>
>> It's still not perfect, though, I agree.  If you have a suggestion for
> how
>> to
>> make the connection management more flexible without hurting performance
>> (it
>> is along the critical path, so we have to be careful) please post an
> issue.
>> Just because the mega-patch landed doesn't mean we're done changing
> things
>> yet. :-)
>>
>> --
>> Larry Garfield
>> larry at garfieldtech.com
>>
> 
> 


From csillagasz at gmail.com  Fri Aug 22 15:55:54 2008
From: csillagasz at gmail.com (Balazs Dianiska)
Date: Fri, 22 Aug 2008 16:55:54 +0100
Subject: [development] access module
In-Reply-To: <48AECB45.5050900@cwgordon.com>
References: <372ed1ba0808220315t1b9e821bk260fd58be0921762@mail.gmail.com>
	<48AECB45.5050900@cwgordon.com>
Message-ID: <372ed1ba0808220855j7bd785abu8452699a5152f205@mail.gmail.com>

> I wouldn't worry too much about misuse, since people could just visit the
> page hundreds of times anyway to achieve the same result - just make a post
> request to a javascript menu callback, and log from there.

I was concerned about that one could fabricate a post call and do it
programmaticaly. Having validation at least requires semi-real visits
from a JS capable browser and some automatization, which hopefully is
a little bit more difficult to do on large scale than the fabrication.

However it just dawned on me that I could just check for a session in
the callback code, which should prevent most fabrications to work.

Earnie: yes I looked at other alternatives, but none of them seems to
give me the simple output of the standard access module, just more
accurately (-bots).

Thanks for the feedback,
Balazs

From dmitrig01 at gmail.com  Fri Aug 22 16:46:43 2008
From: dmitrig01 at gmail.com (Dmitri G)
Date: Fri, 22 Aug 2008 09:46:43 -0700
Subject: [development] access module
In-Reply-To: <372ed1ba0808220855j7bd785abu8452699a5152f205@mail.gmail.com>
References: <372ed1ba0808220315t1b9e821bk260fd58be0921762@mail.gmail.com>
	<48AECB45.5050900@cwgordon.com>
	<372ed1ba0808220855j7bd785abu8452699a5152f205@mail.gmail.com>
Message-ID: <9d2095ce0808220946h2c14d4bes3835c88a97237ad7@mail.gmail.com>

I disagree with the fact that you turn to JavaScript as an access
logging solution.

Access logging needs to log *everything*, but what if a user has
JavaScript turned off, as many do?
Oh well. They won't be logged.

Why don't you use hook_boot, which is new in Drupal 6, and runs for
*every* page, even ones that are cached aggressively. That way, you
don't run into problems of generating tokens (which you would have to
do per-page-load) and such.

Dmitri

On Fri, Aug 22, 2008 at 8:55 AM, Balazs Dianiska <csillagasz at gmail.com> wrote:
>> I wouldn't worry too much about misuse, since people could just visit the
>> page hundreds of times anyway to achieve the same result - just make a post
>> request to a javascript menu callback, and log from there.
>
> I was concerned about that one could fabricate a post call and do it
> programmaticaly. Having validation at least requires semi-real visits
> from a JS capable browser and some automatization, which hopefully is
> a little bit more difficult to do on large scale than the fabrication.
>
> However it just dawned on me that I could just check for a session in
> the callback code, which should prevent most fabrications to work.
>
> Earnie: yes I looked at other alternatives, but none of them seems to
> give me the simple output of the standard access module, just more
> accurately (-bots).
>
> Thanks for the feedback,
> Balazs
>

From mfburdett at gmail.com  Fri Aug 22 17:31:26 2008
From: mfburdett at gmail.com (mark burdett)
Date: Fri, 22 Aug 2008 10:31:26 -0700
Subject: [development] access module
In-Reply-To: <9d2095ce0808220946h2c14d4bes3835c88a97237ad7@mail.gmail.com>
References: <372ed1ba0808220315t1b9e821bk260fd58be0921762@mail.gmail.com>
	<48AECB45.5050900@cwgordon.com>
	<372ed1ba0808220855j7bd785abu8452699a5152f205@mail.gmail.com>
	<9d2095ce0808220946h2c14d4bes3835c88a97237ad7@mail.gmail.com>
Message-ID: <e1bd5b380808221031p21d5f5a8naf6084e831c2841d@mail.gmail.com>

Hi, if you do decide on client-side analytics you might look at piwik:
http://piwik.org It loads via javascript or a <noscript> img tag.
There's a drupal module that integrates with piwik (haven't used it
myself): http://drupal.org/project/piwik

--mark

On Fri, Aug 22, 2008 at 9:46 AM, Dmitri G <dmitrig01 at gmail.com> wrote:
> I disagree with the fact that you turn to JavaScript as an access
> logging solution.
>
> Access logging needs to log *everything*, but what if a user has
> JavaScript turned off, as many do?
> Oh well. They won't be logged.
>
> Why don't you use hook_boot, which is new in Drupal 6, and runs for
> *every* page, even ones that are cached aggressively. That way, you
> don't run into problems of generating tokens (which you would have to
> do per-page-load) and such.
>
> Dmitri
>
> On Fri, Aug 22, 2008 at 8:55 AM, Balazs Dianiska <csillagasz at gmail.com> wrote:
>>> I wouldn't worry too much about misuse, since people could just visit the
>>> page hundreds of times anyway to achieve the same result - just make a post
>>> request to a javascript menu callback, and log from there.
>>
>> I was concerned about that one could fabricate a post call and do it
>> programmaticaly. Having validation at least requires semi-real visits
>> from a JS capable browser and some automatization, which hopefully is
>> a little bit more difficult to do on large scale than the fabrication.
>>
>> However it just dawned on me that I could just check for a session in
>> the callback code, which should prevent most fabrications to work.
>>
>> Earnie: yes I looked at other alternatives, but none of them seems to
>> give me the simple output of the standard access module, just more
>> accurately (-bots).
>>
>> Thanks for the feedback,
>> Balazs
>>
>

From weitzman at tejasa.com  Fri Aug 22 17:46:48 2008
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Fri, 22 Aug 2008 13:46:48 -0400
Subject: [development] how to restore devel.module query log in HEAD
Message-ID: <6117a7500808221046s6ffe7ca0mca5cbfbe2c5507a@mail.gmail.com>

I'd appreciate suggestions on how to implement the query log for
devel.module now that the new DB layer has landed. I've already
submitted a patch to add timing info: http://drupal.org/node/298669

But, it seems that PDO will not show us the SQL that was executed for
any given prepared statement. We have access to the statement with
placeholders, but that can be verbose as sin, and can't be copy/pasted
into a console. Here is a statement for cache_set():

INSERT INTO {cache_registry} (serialized, created, expire, headers,
DATA, cid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1,
:db_insert_placeholder_2, :db_insert_placeholder_3,
:db_insert_placeholder_4, :db_insert_placeholder_5) ON DUPLICATE KEY
UPDATE serialized=:db_update_placeholder_0,
created=:db_update_placeholder_1, expire=:db_update_placeholder_2,
headers=:db_update_placeholder_3, DATA=:db_update_placeholder_4

Not so readable, eh?

So, should we grab the executed SQL from the DB itself? I had some
success with mysql SHOW PROFILES command -
http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html.
In order to fully implement that, I need a hook before and after the
query is executed so i can start and stop profiling. The profiler will
only log 100 queries at a time and our pages require more than that.
Other DB backends would need a different approach.

From gerhard at killesreiter.de  Fri Aug 22 17:51:28 2008
From: gerhard at killesreiter.de (Gerhard Killesreiter)
Date: Fri, 22 Aug 2008 19:51:28 +0200
Subject: [development] how to restore devel.module query log in HEAD
In-Reply-To: <6117a7500808221046s6ffe7ca0mca5cbfbe2c5507a@mail.gmail.com>
References: <6117a7500808221046s6ffe7ca0mca5cbfbe2c5507a@mail.gmail.com>
Message-ID: <48AEFCA0.8080803@killesreiter.de>

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

Moshe Weitzman schrieb:
> I'd appreciate suggestions on how to implement the query log for
> devel.module now that the new DB layer has landed. I've already
> submitted a patch to add timing info: http://drupal.org/node/298669
> 
> But, it seems that PDO will not show us the SQL that was executed for
> any given prepared statement. We have access to the statement with
> placeholders, but that can be verbose as sin, and can't be copy/pasted
> into a console. Here is a statement for cache_set():
> 
> INSERT INTO {cache_registry} (serialized, created, expire, headers,
> DATA, cid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1,
> :db_insert_placeholder_2, :db_insert_placeholder_3,
> :db_insert_placeholder_4, :db_insert_placeholder_5) ON DUPLICATE KEY
> UPDATE serialized=:db_update_placeholder_0,
> created=:db_update_placeholder_1, expire=:db_update_placeholder_2,
> headers=:db_update_placeholder_3, DATA=:db_update_placeholder_4
> 
> Not so readable, eh?


If you just replace db_update_placeholder by something shorter, it
wouldn't be a problem, I think.

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

iD8DBQFIrvyffg6TFvELooQRAqBJAJ9nCCW04gAfgFExBAjzC9yB5/O+qQCfWMRC
sEPoBQkhK2BqocOW7vhmVmU=
=9Ymo
-----END PGP SIGNATURE-----

From larry at garfieldtech.com  Fri Aug 22 19:16:41 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Fri, 22 Aug 2008 14:16:41 -0500
Subject: [development] how to restore devel.module query log in HEAD
In-Reply-To: <48AEFCA0.8080803@killesreiter.de>
References: <48AEFCA0.8080803@killesreiter.de>
Message-ID: <c726043147bdfe6635df8373867a4e9c@localhost>


On Fri, 22 Aug 2008 19:51:28 +0200, Gerhard Killesreiter <gerhard at killesreiter.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Moshe Weitzman schrieb:
>> I'd appreciate suggestions on how to implement the query log for
>> devel.module now that the new DB layer has landed. I've already
>> submitted a patch to add timing info: http://drupal.org/node/298669
>>
>> But, it seems that PDO will not show us the SQL that was executed for
>> any given prepared statement. We have access to the statement with
>> placeholders, but that can be verbose as sin, and can't be copy/pasted
>> into a console. Here is a statement for cache_set():
>>
>> INSERT INTO {cache_registry} (serialized, created, expire, headers,
>> DATA, cid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1,
>> :db_insert_placeholder_2, :db_insert_placeholder_3,
>> :db_insert_placeholder_4, :db_insert_placeholder_5) ON DUPLICATE KEY
>> UPDATE serialized=:db_update_placeholder_0,
>> created=:db_update_placeholder_1, expire=:db_update_placeholder_2,
>> headers=:db_update_placeholder_3, DATA=:db_update_placeholder_4
>>
>> Not so readable, eh?
> 
> 
> If you just replace db_update_placeholder by something shorter, it
> wouldn't be a problem, I think.
> 
> Cheers,
> 	Gerhard

I don't know that using a shorter string would be much help, especially when the above is a generated query.  For static queries you run into the same issue.

However, if someone is using named parameters instead of ? placeholders then perhaps we can simply do a strtr()?  Hm, that wouldn't handle quoting/escaping, though.  That may be a better way to go.  (Store the query and the args separately, then merge them back together on rendering.)

--Larry Garfield


From weitzman at tejasa.com  Sat Aug 23 01:05:06 2008
From: weitzman at tejasa.com (Moshe Weitzman)
Date: Fri, 22 Aug 2008 21:05:06 -0400
Subject: [development] how to restore devel.module query log in HEAD
In-Reply-To: <c726043147bdfe6635df8373867a4e9c@localhost>
References: <48AEFCA0.8080803@killesreiter.de>
	<c726043147bdfe6635df8373867a4e9c@localhost>
Message-ID: <6117a7500808221805o3338ca3fwc6fc3489b64dbfa@mail.gmail.com>

>
> However, if someone is using named parameters instead of ? placeholders then perhaps we can simply do a strtr()?  Hm, that wouldn't handle quoting/escaping, though.  That may be a better way to go.  (Store the query and the args separately, then merge them back together on rendering.)
>

Right. Seems like devel can ask for quoting via PDO::quote and then
strtr(). See http://www.phpbuilder.com/manual/en/function.pdo-quote.php.

From winborn at advomatic.com  Sat Aug 23 13:50:07 2008
From: winborn at advomatic.com (Aaron Winborn)
Date: Sat, 23 Aug 2008 09:50:07 -0400
Subject: [development] Preprocess flaw
Message-ID: <48B0158F.6030205@advomatic.com>

I raised an issue at http://drupal.org/node/297951 originally for the 
Filefield module, and then at http://drupal.org/node/297952 for the 
Drupal core theme preprocess hook architecture. The second issue was 
marked 'by design', but I believe the design is flawed, and that this 
needs to be addressed.

As the preprocess theme hook has only been opened for developers in 
Drupal 6, this wasn't much of an issue before, and the flaw has only now 
become apparent. Without any documentation I can find, the $file 
variable is reserved, meaning that theme developers may not expose a 
variable named $file to a template file when inserting a preprocess 
hook, as outlined at http://drupal.org/node/223430.

The $file variable is well established in Drupal, and often used in 
contributed module theme functions. Now that it's relatively easy for 
themers to override theme files with their own template files, this 
issue will begin to crop up.

The current work-around is that if the theme function you wish to 
override uses a $file variable, then you have to copy that variable in 
your preprocess hook to another variable, such as $original_file. This 
is unwieldy, unfortunate, and currently undocumented (as far as I can tell).

I have a feeling we'll see this problem become more prevalent as 
developers move to Drupal 6. In core, $file appears only 22 times, and 
not in any core theme functions (that I'm aware of). However, that is 
misleading, as core Drupal currently does a poor to middling job of file 
handling (which will hopefully be remedied soon).

In the contributed DRUPAL-6--1/modules branch, $file appears 265 times, 
and 1186 times in the contributions/modules branch. There are several 
contributed modules using $file in theme functions, such as the 
aforementioned Filefield, Imagefield, Media Mover, and File Framework. 
(I'm sure there are others, those are just from a quick grep). And I 
suspect that at the very least, Imagefield and Filefield will warrant 
relatively frequent theme overrides for individual sites.

Assuming hook_file (http://drupal.org/node/142995) makes it into Drupal 
7, I suspect we'll see even more use of the $file variable in themes, 
particularly as more developers jump into file asset management.

Here are some options available to us. There are probably other options 
as well:
1) Do nothing. Let themers struggle when they try to override a theme 
$file variable using a preprocess hook.
2) Document the flaw, so at least developers know the difficulties 
involved in doing this.
3) Declare $file a restricted variable, forbidden in theme functions.
4) Encourage developers to find all instances of $file in contributed 
module themes and rename them.
5) Use another magic variable name for use in theme_render_template, 
such as $file__ or $template_file, and declare it restricted.
6) ???

I believe we are doing a disservice to developers if we tell them to use 
a flawed preprocess system. I strongly suggest we implement option 5 
before this problem becomes more severe, ideally for Drupal 6, as many 
developers are migrating there as we speak.

Thanks,
Aaron Winborn

-- 
Aaron Winborn

Advomatic, LLC
http://advomatic.com/

Drupal Multimedia available in September!
http://www.packtpub.com/create-multimedia-website-with-drupal/book

My blog:
http://aaronwinborn.com/


From drupal at oadaeh.net  Sun Aug 24 22:12:14 2008
From: drupal at oadaeh.net (Jason Flatt)
Date: Sun, 24 Aug 2008 15:12:14 -0700
Subject: [development] Handling multiple e-mail log in IDs and passwords . .
	.
Message-ID: <200808241512.14809.drupal@oadaeh.net>

I'm in a bit of a quandary and I'm seeking ideas, opinions, insights, whatever 
to help me move forward.

I am, for the third time, building or modifying a module that has as one of 
its requirements the collecting of user data for logging into an e-mail 
account, i.e.: the user ID and password. For the previous two modules, I 
simply gave the administrator the option of specifying whether to use the 
account id and password from the users' account or to add additional fields in 
the users' registration and edit forms for collecting that information.

During the process of, basically, doing the same thing, it occurred to me that 
some folks might not want to use the Drupal account information, but they 
also might not want to have two or three or more areas to put in, quite 
possibly, the same information.

So, the question is, how to approach this? Do I go into every possible module 
that collects e-mail information, see where and how they store it and make it 
available for the users of my module(s). That seems like an effort in 
futility. Is there a module that already handles this and related situations? 
I didn't see any that looked like they did. How about API calls? That would 
be the ideal way, but, again, I didn't see any that looked like they did what 
I'm looking for. (That's not to say that neither module nor API call exists, 
just that I didn't see any that I thought addressed my needs.)

Does anyone have any ideas or suggestions on where to go, or do I just stick 
with the old stand by methods and end up with what I've been doing all along?


-- 
Jason Flatt
http://www.oadaeh.net/
Father of Six:  http://www.flattfamily.com/ (Joseph, 15; Cramer, 13; Travis, 
11; Angela; Harry, 8; and William, 2)
Linux User:     http://www.kubuntu.org/
Drupal Fanatic: http://drupal.org/

From mvgrootel at gmail.com  Mon Aug 25 11:39:11 2008
From: mvgrootel at gmail.com (Maarten van Grootel)
Date: Mon, 25 Aug 2008 13:39:11 +0200
Subject: [development] DrupalWebTestCase and changing permissions of
	authenticate user role
Message-ID: <9f8bbf980808250439p3cb22dacs8636b3f102bf33da@mail.gmail.com>

Hello all,

I'm currently in the process of writing a 7.x patch to create the 'edit own
comments' permission, to give admins the option to prohibit editing of
comments. The functionality is working, but I would like to write a testcase
for it, just to be complete. Here I found either a limitation of my
understanding of the drupal testing framework, or a limitation of the
framework itself.

Because the 'edit own comments' permission is on by default, (the
'authenticated user' role has the permission checked by default), any user
created with drupalCreateUser($roles) will inherit the right to edit their
own comment. Therefore, I can't make a test that checks that a person gets a
403 when trying to edit their post without the right permissions, because I
can't disable the permission in the testing environment.

What I need, and can not find, is a function that will change the
role_permission values for the 'authenticated user'-role, something like
DrupalWebTestCase->drupalSetPermissions($role-id, $permissions).

Am I right to conclude that this can't be done with the current state of the
Drupal WebTestCase? If so, do you have an idea how to solve this in an other
way, or should I just leave the testcase out of the patch?

Thanks,
Maarten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080825/691a3a6f/attachment.htm 

From earnie at users.sourceforge.net  Mon Aug 25 11:42:07 2008
From: earnie at users.sourceforge.net (Earnie Boyd)
Date: Mon, 25 Aug 2008 07:42:07 -0400
Subject: [development] Handling multiple e-mail log in IDs and	passwords
	. . .
In-Reply-To: <200808241512.14809.drupal@oadaeh.net>
References: <200808241512.14809.drupal@oadaeh.net>
Message-ID: <20080825074207.3kjcc4kfpnlwos80@mail.progw.org>

Quoting Jason Flatt <drupal at oadaeh.net>:

>
> Does anyone have any ideas or suggestions on where to go, or do I just stick
> with the old stand by methods and end up with what I've been doing all along?
>

I would welcome patches for advuser for this.  I haven't had the time 
yet for D6 but do plan to get there.

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


From catch56 at googlemail.com  Mon Aug 25 12:46:01 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Mon, 25 Aug 2008 13:46:01 +0100
Subject: [development] DrupalWebTestCase and changing permissions of
	authenticate user role
In-Reply-To: <9f8bbf980808250439p3cb22dacs8636b3f102bf33da@mail.gmail.com>
References: <9f8bbf980808250439p3cb22dacs8636b3f102bf33da@mail.gmail.com>
Message-ID: <fa5724270808250546t114fc402q105b996dc4ca4969@mail.gmail.com>

If you pass an array of permissions to drupalCreateUser() then it'll get
those permissions, rather than the default ones for authenticated user. See
the documentation here: http://drupal.org/node/265762

Nat

On Mon, Aug 25, 2008 at 12:39 PM, Maarten van Grootel
<mvgrootel at gmail.com>wrote:

> Hello all,
>
> I'm currently in the process of writing a 7.x patch to create the 'edit own
> comments' permission, to give admins the option to prohibit editing of
> comments. The functionality is working, but I would like to write a testcase
> for it, just to be complete. Here I found either a limitation of my
> understanding of the drupal testing framework, or a limitation of the
> framework itself.
>
> Because the 'edit own comments' permission is on by default, (the
> 'authenticated user' role has the permission checked by default), any user
> created with drupalCreateUser($roles) will inherit the right to edit their
> own comment. Therefore, I can't make a test that checks that a person gets a
> 403 when trying to edit their post without the right permissions, because I
> can't disable the permission in the testing environment.
>
> What I need, and can not find, is a function that will change the
> role_permission values for the 'authenticated user'-role, something like
> DrupalWebTestCase->drupalSetPermissions($role-id, $permissions).
>
> Am I right to conclude that this can't be done with the current state of
> the Drupal WebTestCase? If so, do you have an idea how to solve this in an
> other way, or should I just leave the testcase out of the patch?
>
> Thanks,
> Maarten
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080825/b9822890/attachment.htm 

From mvgrootel at gmail.com  Mon Aug 25 14:20:21 2008
From: mvgrootel at gmail.com (Maarten van Grootel)
Date: Mon, 25 Aug 2008 16:20:21 +0200
Subject: [development] DrupalWebTestCase and changing permissions of
	authenticate user role
In-Reply-To: <fa5724270808250546t114fc402q105b996dc4ca4969@mail.gmail.com>
References: <9f8bbf980808250439p3cb22dacs8636b3f102bf33da@mail.gmail.com>
	<fa5724270808250546t114fc402q105b996dc4ca4969@mail.gmail.com>
Message-ID: <9f8bbf980808250720h23e31dd0x1daf1245e0dcf141@mail.gmail.com>

Hi Nat,

That's not what it says, or at least not what's happening. It says that if
null, it receives the default permissions stated in _drupalCreateRole()
(which is array('access comments', 'access content', 'post comments', 'post
comments without approval') according to
http://api.drupal.org/api/file/modules/simpletest/drupal_web_test_case.php/7/source).
But, this does not influence the permissions every user receives by the hard
coded Authenticated User role. Not directly, but by association/inheritance.

This behavior is expected, because it's the Drupal way of permission
inheritance. But to test the behavior I still need to find a way to alter
the permissions not my newly created user+role, but of the global
Authenticated User Role. You can try it by removing 'post comments' from row
27 of comment.test. You'd expect al sorts of failures, because you just made
web_user not able to create comments, but everything passes effortlessly.

So if anybody has a way to change permissions of the 2 default roles from
within the testsuite, or has some other tips, it would be greatly
appreciated.

Maarten

This is contrary to what you expect when you create a user with only 'access
content' permissions.
On Mon, Aug 25, 2008 at 2:46 PM, Nathaniel Catchpole <catch56 at googlemail.com
> wrote:

> If you pass an array of permissions to drupalCreateUser() then it'll get
> those permissions, rather than the default ones for authenticated user. See
> the documentation here: http://drupal.org/node/265762
>
> Nat
>
>
> On Mon, Aug 25, 2008 at 12:39 PM, Maarten van Grootel <mvgrootel at gmail.com
> > wrote:
>
>> Hello all,
>>
>> I'm currently in the process of writing a 7.x patch to create the 'edit
>> own comments' permission, to give admins the option to prohibit editing of
>> comments. The functionality is working, but I would like to write a testcase
>> for it, just to be complete. Here I found either a limitation of my
>> understanding of the drupal testing framework, or a limitation of the
>> framework itself.
>>
>> Because the 'edit own comments' permission is on by default, (the
>> 'authenticated user' role has the permission checked by default), any user
>> created with drupalCreateUser($roles) will inherit the right to edit their
>> own comment. Therefore, I can't make a test that checks that a person gets a
>> 403 when trying to edit their post without the right permissions, because I
>> can't disable the permission in the testing environment.
>>
>> What I need, and can not find, is a function that will change the
>> role_permission values for the 'authenticated user'-role, something like
>> DrupalWebTestCase->drupalSetPermissions($role-id, $permissions).
>>
>> Am I right to conclude that this can't be done with the current state of
>> the Drupal WebTestCase? If so, do you have an idea how to solve this in an
>> other way, or should I just leave the testcase out of the patch?
>>
>> Thanks,
>> Maarten
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080825/e70d4738/attachment.htm 

From roberto at robertobermejo.es  Mon Aug 25 14:22:09 2008
From: roberto at robertobermejo.es (Roberto Bermejo Martinez)
Date: Mon, 25 Aug 2008 16:22:09 +0200
Subject: [development] Questions about views
Message-ID: <48B2C011.7070501@robertobermejo.es>

Hello
I'm working with the version of drupal 6 with the modules and views cck
2. I need some way of creating a block to me shows a tree with links to
the documents as the publication date. I make a page, but can not block.
It would enable the block to obtain the arguments of the page?

Sorry for my English.

Thank you very much.

From victorkane at gmail.com  Mon Aug 25 15:15:28 2008
From: victorkane at gmail.com (Victor Kane)
Date: Mon, 25 Aug 2008 12:15:28 -0300
Subject: [development] Questions about views
In-Reply-To: <48B2C011.7070501@robertobermejo.es>
References: <48B2C011.7070501@robertobermejo.es>
Message-ID: <ff176450808250815r7b90eda5vab24ba8e7ae83ee1@mail.gmail.com>

You must Add a display. Select "block" and hit the Add a display
button. Default settings will be used, but they can be overriden for
the block.

On Mon, Aug 25, 2008 at 11:22 AM, Roberto Bermejo Martinez
<roberto at robertobermejo.es> wrote:
> Hello
> I'm working with the version of drupal 6 with the modules and views cck
> 2. I need some way of creating a block to me shows a tree with links to
> the documents as the publication date. I make a page, but can not block.
> It would enable the block to obtain the arguments of the page?
>
> Sorry for my English.
>
> Thank you very much.
>

From catch56 at googlemail.com  Mon Aug 25 14:45:16 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Mon, 25 Aug 2008 15:45:16 +0100
Subject: [development] DrupalWebTestCase and changing permissions of
	authenticate user role
In-Reply-To: <9f8bbf980808250720h23e31dd0x1daf1245e0dcf141@mail.gmail.com>
References: <9f8bbf980808250439p3cb22dacs8636b3f102bf33da@mail.gmail.com>
	<fa5724270808250546t114fc402q105b996dc4ca4969@mail.gmail.com>
	<9f8bbf980808250720h23e31dd0x1daf1245e0dcf141@mail.gmail.com>
Message-ID: <fa5724270808250745q75fe5076wdae4a37e8333ca2a@mail.gmail.com>

Hmm. I think you're probably right.

There's nothing stopping you from changing the permissions as part of your
test though, you can visit admin/user/permissions and save the form with
different values, or just delete the row from the permissions table directly
with db_query().

That said, I'm not sure how much this is by design, or an omission in
drupal_web_test_case,

Nat

On Mon, Aug 25, 2008 at 3:20 PM, Maarten van Grootel wrote:

> Hi Nat,
>
> That's not what it says, or at least not what's happening. It says that if
> null, it receives the default permissions stated in _drupalCreateRole()
> (which is array('access comments', 'access content', 'post comments', 'post
> comments without approval') according to
> http://api.drupal.org/api/file/modules/simpletest/drupal_web_test_case.php/7/source).
> But, this does not influence the permissions every user receives by the hard
> coded Authenticated User role. Not directly, but by association/inheritance.
>
> This behavior is expected, because it's the Drupal way of permission
> inheritance. But to test the behavior I still need to find a way to alter
> the permissions not my newly created user+role, but of the global
> Authenticated User Role. You can try it by removing 'post comments' from row
> 27 of comment.test. You'd expect al sorts of failures, because you just made
> web_user not able to create comments, but everything passes effortlessly.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080825/73a08766/attachment.htm 

From caleb.gilbert at gmail.com  Mon Aug 25 18:43:56 2008
From: caleb.gilbert at gmail.com (Caleb Gilbert)
Date: Mon, 25 Aug 2008 11:43:56 -0700
Subject: [development]  Drupal and acceptance testing
Message-ID: <38ad0b0a0808251143l58bfb650p1ad274d9dfae1fc5@mail.gmail.com>

Thanks for the reply, Catch - good stuff. I'm going to take a look at what
it would take to get Selenium RC to work with simpletest instead of PHPunit
(the unit testing framework the Selenium RC docs refer to).

An interesting note about Selenium's ties to Drupal - the new AutoPilot 2.0
beta - which was just released in time for Drupalicon -
http://twitter.com/workhabit  heavily relies on  selenium (e.g., selenium's
macro recorder/playback is being used in this case for handling change
management [pushing changes from dev to staging to production], so
apparently it is not just for acceptance testing!).

- Caleb


I suggested an automated javascript testing framework for gsoc, was thinking
watir rather than selenium based on a few discussions about both, but it
didn't go anywhere:http://groups.drupal.org/node/9511,

While I'd love to see testing with Selenium or Watir or some other browser
remote control that can handle stuff that simpletest or straight up
javascript unit testing can't, like cwgordon said, it's a matter of effort
and returns.

The testing framework we have in core has the advantage that anyone can
download and run tests without needing to install other software, tests can
be written in PHP, and we're getting close to the tipping point where our
coverage is high enough to start finding regressions before they're
committed.

On the other hand, and  unfortunately, at the moment we don't have that many
jQuery intensive patches - yes, it's really annoying trying to get
cross-browser tests when a new jQuery is released, but that's once every few
months - so in terms of saving click around time SimpleTest is giving higher
returns at the moment. While it might appear to be a lack of interest at the
moment, it's more a case of 1. a lack of resources (the 'testing brigade' is
still pretty small) 2. a need to get the testing framework we actually have
up to a point where it begins to actually save some work - it'll only do
this when we're closer to 100% test coverage and tests are being run on
patches automatically via testing.drupal.org

That said - it's very clear that the core testing framework can't cover
everything, so extending it would be the natural next step - and given the
amount of time and work it's taken to get to where we are now, starting
early surely wouldn't hurt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080825/ea46f2eb/attachment.htm 

From mvgrootel at gmail.com  Mon Aug 25 21:08:51 2008
From: mvgrootel at gmail.com (Maarten van Grootel)
Date: Mon, 25 Aug 2008 23:08:51 +0200
Subject: [development] DrupalWebTestCase and changing permissions of
	authenticate user role
In-Reply-To: <fa5724270808250745q75fe5076wdae4a37e8333ca2a@mail.gmail.com>
References: <9f8bbf980808250439p3cb22dacs8636b3f102bf33da@mail.gmail.com>
	<fa5724270808250546t114fc402q105b996dc4ca4969@mail.gmail.com>
	<9f8bbf980808250720h23e31dd0x1daf1245e0dcf141@mail.gmail.com>
	<fa5724270808250745q75fe5076wdae4a37e8333ca2a@mail.gmail.com>
Message-ID: <9f8bbf980808251408m2f886822w8f6975f52b268555@mail.gmail.com>

You're right, I can just work around it. I have to admit that I didn't think
of 'visiting' admin/user/permissions, but that's what this mailinglist is
for. :)

Thanks for your input,
Maarten

On Mon, Aug 25, 2008 at 4:45 PM, Nathaniel Catchpole <catch56 at googlemail.com
> wrote:

> Hmm. I think you're probably right.
>
> There's nothing stopping you from changing the permissions as part of your
> test though, you can visit admin/user/permissions and save the form with
> different values, or just delete the row from the permissions table directly
> with db_query().
>
> That said, I'm not sure how much this is by design, or an omission in
> drupal_web_test_case,
>
> Nat
>
> On Mon, Aug 25, 2008 at 3:20 PM, Maarten van Grootel wrote:
>
>> Hi Nat,
>>
>> That's not what it says, or at least not what's happening. It says that if
>> null, it receives the default permissions stated in _drupalCreateRole()
>> (which is array('access comments', 'access content', 'post comments', 'post
>> comments without approval') according to
>> http://api.drupal.org/api/file/modules/simpletest/drupal_web_test_case.php/7/source).
>> But, this does not influence the permissions every user receives by the hard
>> coded Authenticated User role. Not directly, but by association/inheritance.
>>
>> This behavior is expected, because it's the Drupal way of permission
>> inheritance. But to test the behavior I still need to find a way to alter
>> the permissions not my newly created user+role, but of the global
>> Authenticated User Role. You can try it by removing 'post comments' from row
>> 27 of comment.test. You'd expect al sorts of failures, because you just made
>> web_user not able to create comments, but everything passes effortlessly.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080825/574a2d45/attachment.htm 

From roberto at robertobermejo.es  Tue Aug 26 06:41:58 2008
From: roberto at robertobermejo.es (Roberto Bermejo Martinez)
Date: Tue, 26 Aug 2008 08:41:58 +0200
Subject: [development] Questions about views
In-Reply-To: <ff176450808250815r7b90eda5vab24ba8e7ae83ee1@mail.gmail.com>
References: <48B2C011.7070501@robertobermejo.es>
	<ff176450808250815r7b90eda5vab24ba8e7ae83ee1@mail.gmail.com>
Message-ID: <48B3A5B6.8060903@robertobermejo.es>

Ok.
This is my view:

|$view = new view;
$view->name = 'Prueba_01';
$view->description = '';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view
disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('fields', array(
  'title' => array(
    'label' => 'T?tulo',
    'link_to_node' => 1,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
));
$handler->override_option('arguments', array(
  'created_year' => array(
    'id' => 'created_year',
    'table' => 'node',
    'field' => 'created_year',
    'validate_type' => 'none',
    'validate_fail' => 'not found',
    'default_argument_type' => 'fixed',
    'relationship' => 'none',
    'title' => '%1',
    'default_action' => 'summary desc',
    'wildcard' => 'all values',
    'wildcard_substitution' => 'Todos',
    'default_options_div_prefix' => '',
    'default_argument_user' => 0,
    'default_argument_fixed' => '',
    'default_argument_php' => '',
    'validate_argument_node_type' => array(
      'page' => 0,
      'story' => 0,
    ),
    'validate_argument_node_access' => 0,
    'validate_argument_nid_type' => 'nid',
    'validate_argument_vocabulary' => array(),
    'validate_argument_type' => 'tid',
    'validate_argument_php' => '',
    'style_options' => array(
      'count' => 1,
      'override' => 0,
      'items_per_page' => '25',
    ),
    'style_plugin' => 'default_summary',
  ),
  'created_month' => array(
    'id' => 'created_month',
    'table' => 'node',
    'field' => 'created_month',
    'validate_type' => 'none',
    'validate_fail' => 'not found',
    'default_argument_type' => 'fixed',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
    'title' => '',
    'default_action' => 'summary desc',
    'wildcard' => '',
    'wildcard_substitution' => '',
    'default_options_div_prefix' => '',
    'default_argument_user' => 0,
    'default_argument_fixed' => '',
    'default_argument_php' => '',
    'validate_argument_node_type' => array(
      'page' => 0,
      'story' => 0,
    ),
    'validate_argument_node_access' => 0,
    'validate_argument_nid_type' => 'nid',
    'validate_argument_vocabulary' => array(),
    'validate_argument_type' => 'tid',
    'validate_argument_php' => '',
    'style_options' => array(
      'count' => 1,
      'override' => 0,
      'items_per_page' => '25',
    ),
    'style_plugin' => 'default_summary',
  ),
));
$handler->override_option('access', array(
  'type' => 'role',
  'role' => array(
    '1' => 1,
    '2' => 2,
  ),
  'perm' => 'view advanced help topic',
));
$handler->override_option('style_plugin', 'list');
$handler->override_option('style_options', array(
  'type' => 'ul',
));
$handler->override_option('row_plugin', 'node');
$handler->override_option('row_options', array(
  'teaser' => 0,
  'links' => 1,
));
$handler = $view->new_display('page', 'P?gina', 'page_1');
$handler->override_option('path', 'prueba_01');
$handler->override_option('menu', array(
  'type' => 'none',
  'title' => '',
  'weight' => 0,
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'weight' => 0,
));
$handler = $view->new_display('block', 'Bloque', 'block_1');
$handler->override_option('arguments', array(
  'created_year' => array(
    'id' => 'created_year',
    'table' => 'node',
    'field' => 'created_year',
    'validate_type' => 'none',
    'validate_fail' => 'not found',
    'default_argument_type' => 'fixed',
    'relationship' => 'none',
    'title' => '%1',
    'default_action' => 'summary desc',
    'wildcard' => 'all values',
    'wildcard_substitution' => 'Todos',
    'default_options_div_prefix' => '',
    'default_argument_user' => 0,
    'default_argument_fixed' => '',
    'default_argument_php' => '',
    'validate_argument_node_type' => array(
      'page' => 0,
      'story' => 0,
    ),
    'validate_argument_node_access' => 0,
    'validate_argument_nid_type' => 'nid',
    'validate_argument_vocabulary' => array(),
    'validate_argument_type' => 'tid',
    'validate_argument_php' => '',
    'style_options' => array(
      'count' => 1,
      'override' => 0,
      'items_per_page' => '25',
    ),
    'style_plugin' => 'default_summary',
  ),
  'created_month' => array(
    'id' => 'created_month',
    'table' => 'node',
    'field' => 'created_month',
    'validate_type' => 'none',
    'validate_fail' => 'not found',
    'default_argument_type' => 'php',
    'override' => array(
      'button' => 'Use default',
    ),
    'relationship' => 'none',
    'title' => '%2',
    'default_action' => 'summary desc',
    'wildcard' => 'all values',
    'wildcard_substitution' => 'Todos',
    'default_options_div_prefix' => '',
    'default_argument_user' => 0,
    'default_argument_fixed' => '',
    'default_argument_php' => 'return arg(2)',
    'validate_argument_node_type' => array(
      'page' => 0,
      'story' => 0,
    ),
    'validate_argument_node_access' => 0,
    'validate_argument_nid_type' => 'nid',
    'validate_argument_vocabulary' => array(),
    'validate_argument_type' => 'tid',
    'validate_argument_php' => '',
    'style_options' => array(
      'count' => 1,
      'override' => 0,
      'items_per_page' => '25',
    ),
    'style_plugin' => 'default_summary',
  ),
));
$handler->override_option('block_description', 'Prueba_01');


This is the output code:

    <ul>
      <li><a href="/prueba_01/2008">2008</a>
              (2)
          </li>
      <li><a href="/prueba_01/2007">2007</a>
              (1)
          </li>
    </ul>


And this is the output which I want to get:

<ul>
      <li><a href="/prueba_01/2008">2008</a>
              (2)
          <ul>
             <li><a href="||/prueba_01/2008/08||">August</a>(1)</li>
||             <li><a href="||/prueba_01/2008/07||">July</a>(1)</li>|
|          </ul>
      </li>
      <li><a href="/prueba_01/2007">2007</a>
              (1)
          ||<ul>||
||             <li><a href="||/prueba_01/2007/07||">July</a>(1)</li>|
|          </ul>|
|      </li>
    </ul>


|Victor Kane escribi?:
> You must Add a display. Select "block" and hit the Add a display
> button. Default settings will be used, but they can be overriden for
> the block.
>
> On Mon, Aug 25, 2008 at 11:22 AM, Roberto Bermejo Martinez
> <roberto at robertobermejo.es> wrote:
>   
>> Hello
>> I'm working with the version of drupal 6 with the modules and views cck
>> 2. I need some way of creating a block to me shows a tree with links to
>> the documents as the publication date. I make a page, but can not block.
>> It would enable the block to obtain the arguments of the page?
>>
>> Sorry for my English.
>>
>> Thank you very much.
>>
>>     


From larry at garfieldtech.com  Mon Aug 25 19:05:37 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Mon, 25 Aug 2008 14:05:37 -0500
Subject: [development] Module needs good home
Message-ID: <200808251405.37266.larry@garfieldtech.com>

So I've been trying to put this off thinking I'd find time for it, but it's 
become very clear to me that I won't.

NodeReview (http://drupal.org/project/nodereview) is in need of a new 
maintainer.  I simply do not have the time or, honestly, interest to maintain 
it, as evidenced by the lack of activity by me in its issue queue.  There is 
currently one other committer but he hasn't really done much with it either.

Judging by the issue queue there's a fair number of people who really dig this 
module, and judging by the number of times I've gotten direct contacts asking 
to pay for upgrades and enhancements to it I'd say it definitely has a future 
with the right maintainer.  NodeReview was also my very first released Drupal 
module (despite the fact that I have never used it in production, ironically) 
so it has a special place for me.  I am hoping for a maintainer that can 
treat it well and give it the good home it deserves.

Interested parties, please contact me directly.  Be sure to include why you'd 
be a good maintainer for it; as I said, this module has a following and is a 
module I care about (just not enough to actually make time to work on it).

-- 
Larry Garfield
larry at garfieldtech.com

From cxjohnson at gmail.com  Tue Aug 26 12:41:03 2008
From: cxjohnson at gmail.com (Chris Johnson)
Date: Tue, 26 Aug 2008 07:41:03 -0500
Subject: [development] External database handling
In-Reply-To: <200808220024.12674.larry@garfieldtech.com>
References: <9ea8d6030808212021j9413faer874258476dc736e3@mail.gmail.com>
	<200808220024.12674.larry@garfieldtech.com>
Message-ID: <9ea8d6030808260541w3217a5b8ndc45f3ebabc5b88e@mail.gmail.com>

On Fri, Aug 22, 2008 at 12:24 AM, Larry Garfield <larry at garfieldtech.com> wrote:
> On Thursday 21 August 2008 10:21:37 pm Chris Johnson wrote:

>> I'd especially like to chat with the folks working on the DB layer for
>> D7.  It would be nice to provide an interface to allow adding an
>> additional DB programmatically from the contrib module.
>>
>> ..chris
>
> Well hi there! :-)

Heh.  I know who those are on the short list -- just didn't want to
drag anyone into the game involuntarily.  :-)


> What you describe was absolutely an issue in the D6 and earlier DB layer.  The
> new DB layer is still not perfect, but has improved on it in two ways:
>
> 1) The $databases value is always an array.  It can be a flattened array, as
> some layers are optional, but since the installer populates it in the first
> place it will in almost every case already be an array.

This might solve most of the problem.  I haven't used the new D7 layer
yet, so I only made a cursory review of the code.  I didn't notice
that $databases is always an array.  As long as a contrib module can
always say something like $databases['mydatabase'] = ... without
causing errors, I think we may be ok.  It's essentially pushing
another database onto the stack of known databases, and if that will
work without core changes, contrib modules should be able to use the
DB abstraction without resorting to strange code.


> It's still not perfect, though, I agree.  If you have a suggestion for how to
> make the connection management more flexible without hurting performance (it
> is along the critical path, so we have to be careful) please post an issue.
> Just because the mega-patch landed doesn't mean we're done changing things
> yet. :-)

If I see anything else, I'll let you know.  :-)


Regarding Ernst Pl?ss's comment about watchdog DB logging errors
occurring while other, non-Drupal databases are active:  I could have
sworn I fixed that very problem in a patch to 4.7 core a very long
time ago.  In fact, I'm 99.99% sure I did.  It appears there may be a
regression, although I'm not sure which version of core of Ernst is
referring to here.

Thanks much for the reply, Larry.

..chris

From neetu at valiantica.com  Tue Aug 26 22:23:21 2008
From: neetu at valiantica.com (Neetu)
Date: Tue, 26 Aug 2008 15:23:21 -0700
Subject: [development] Job Opening for- Sr. Drupal Developer / Contract for
	6m / Palo Alto, CA
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAOwdFxCBdjpMoIDe1DF0AAfCgAAAEAAAALGAx3jyJ0RGta7d2L0lyqUBAAAAAA==@valiantica.com>

Contact me if you are interested in following job.

 

Title: Sr. Drupal Developer

Location: Palo Alto, CA

Duration: Contract -to-Perm

Responsibilities: 
The Sr. Drupal Developer will be responsible for defining and leading the
development of a high performance, highly available multi-language web
property. As a Sr. Developer, you will be engaged from all prospective
development levels and play a critical role in driving VAM to its next
level. 

You must possess excellent technical and leadership skills, be highly
organized and able to manage the full project lifecycle from requirements to
deployment. You will use your technical knowledge and creative thinking to
provide the most innovative solutions. You must be able to lead and motivate
the junior developers to meet aggressive deadlines in a rapid application
development environment. 

Requirements: 
. Minimum 5 years experience developing web applications 
. Previous experience working with a team of technical developers with
successful delivery of web-based applications 
. Extensive knowledge of LAMP (Linux-Apache-MySQL-PhP) based development 
. Experience working with Web Services (XMLRPC, SOAP) in a highly scalable,
highly available environment 
. Experience integrating application pages into WCM, SFA's, and Tracking /
Marketing systems 
. Strong fundamental understanding of web application technology 
. Strong understanding of basic web skills (D/HTML, CSS and Jscript) 
. Strong programming skills with the LAMP Stack - PHP5 and Drupal CMS
Framework as well as exposure to Ajax and interaction with front-end
technologies 
. Working knowledge of Web servers (Apache, Lighttpd, IIS) 
. Good communications skills and organization skills 
. Working knowledge of relational databases (Oracle and SQL) 
. Ability and desire to learn new applications/processes/environments 

Education: 
. B.S./M.S. in Computer Science/Engineering or equivalent in work experience

 

 

Thank you for your time.

 

Neetu

-----------------------

Valiantica, Inc.

408-693-3145

Skype: Valiantica

IM: neetuvaliantica

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080826/799892e0/attachment.htm 

From ernst.pluess at gmail.com  Wed Aug 27 18:09:08 2008
From: ernst.pluess at gmail.com (=?ISO-8859-1?Q?Ernst_Pl=FCss?=)
Date: Wed, 27 Aug 2008 20:09:08 +0200
Subject: [development] External database handling
In-Reply-To: <9ea8d6030808260541w3217a5b8ndc45f3ebabc5b88e@mail.gmail.com>
References: <9ea8d6030808212021j9413faer874258476dc736e3@mail.gmail.com>
	<200808220024.12674.larry@garfieldtech.com>
	<9ea8d6030808260541w3217a5b8ndc45f3ebabc5b88e@mail.gmail.com>
Message-ID: <27c534c90808271109h1b3bd2damb973be3e4242e19a@mail.gmail.com>

The problem occurs in D5.


2008/8/26 Chris Johnson <cxjohnson at gmail.com>

>
> Regarding Ernst Pl?ss's comment about watchdog DB logging errors
> occurring while other, non-Drupal databases are active:  I could have
> sworn I fixed that very problem in a patch to 4.7 core a very long
> time ago.  In fact, I'm 99.99% sure I did.  It appears there may be a
> regression, although I'm not sure which version of core of Ernst is
> referring to here.
>
> Thanks much for the reply, Larry.
>
> ..chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080827/fb4c5b3b/attachment.htm 

From michael at favias.org  Wed Aug 27 19:18:17 2008
From: michael at favias.org (Michael Favia)
Date: Wed, 27 Aug 2008 14:18:17 -0500
Subject: [development] Job Opening for- Sr. Drupal Developer / Contract
 for	6m / Palo Alto, CA
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAOwdFxCBdjpMoIDe1DF0AAfCgAAAEAAAALGAx3jyJ0RGta7d2L0lyqUBAAAAAA==@valiantica.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAAOwdFxCBdjpMoIDe1DF0AAfCgAAAEAAAALGAx3jyJ0RGta7d2L0lyqUBAAAAAA==@valiantica.com>
Message-ID: <48B5A879.3020906@favias.org>

Neetu wrote:
>
> Contact me if you are interested in following job.
>
While effective, this unfortunately this isnt the appropriate place for 
such a message. Please be considerate of our time. Drupal provides 
alternative avenues for such requests.

-- 
Michael Favia                   michael at favias.org
tel. 512.585.5650            http://www.favias.org


From pwgdarchive at gmail.com  Thu Aug 28 12:57:13 2008
From: pwgdarchive at gmail.com (=?ISO-8859-1?Q?Benjamin_Melan=E7on?=)
Date: Thu, 28 Aug 2008 08:57:13 -0400
Subject: [development] New module makes custom menus from taxonomy -
	experienced coder wish to pick this up?
In-Reply-To: <1219354199.21273.4.camel@robert-desktop>
References: <1218526274.8160.26.camel@robert-desktop>
	<48A145CD.7040607@perlucida.com>
	<1219354199.21273.4.camel@robert-desktop>
Message-ID: <1406bb8f0808280557u79ae57fk4c4c7150c17f15d8@mail.gmail.com>

Hi Robert,

There's a Taxonomy code sprint coming up in Chicago next month-
http://sprint.eol.org/

The organizers have their own agenda, but it might make sense to get
it released before then when a lot of taxonomy stuff is going to be
kicked around.

You could do that simply by posting a link to the files at the
taxonomy group, http://groups.drupal.org/taxonomy

best,

benjamin

Agaric Design Collective
Open Source Free Software Web Development
http://agaricdesign.com/



On Thu, Aug 21, 2008 at 5:29 PM, robert crowther <r.crowther at zen.co.uk> wrote:
> Hello Adrian,
>
> It's taken me a few days to reply, apologies.
>
> First up, thank you for taking the time to mail back explaining what I
> should do. No need for people to do that, but lists and forums would be
> better for the effort.
>
> See, I didn't think it was releasable, so I didn't follow any links on
> Drupal contributions. I don't even have that much culture. I've never
> used a content versioning system, let alone know where to find the
> Drupal one. So I may take this route up.
>
> Any project has a curve of learning plotted against achievement. I have
> learned about not one but two Drupal menu systems, taught myself PHP,
> and written the modules. In a few weeks. This is the obvious place for
> me to stop. But given that there is an evident low level interest in
> such a module, I wondered if it should go out work somewhere.
>
> I was aware of
> "I can't be bothered to maintain this, can someone do it for me?"
> Hope the above explains.
>
> I'm also aware of the strangeness of posting to the dev list. But the
> module reads like a core module in places. It needs that quality of
> input to make it solid.
>
> Yes, maybe I wouldn't subscribe to a dev list normally, but I would
> always trawl the dev list archives on any project. Wouldn't anybody? I
> like to know what can be known before I set my compass.
>
> Thanks again for the information,
>
> Robert
>
>
> On Tue, 2008-08-12 at 09:11 +0100, Adrian Simmons wrote:
>> robert crowther wrote:
>> > All you have to do is mail me back, and we can take it from there.
>> This is what Drupal's CVS contrib repository is for! :)
>>
>> Seriously. Upload it to contrib, make a project and just have a development
>> release, in the project description tell people about it and that you
>> consider it alpha or beta quality. Say you're looking for a co-maintainer.
>>
>> If people want to use it and find bugs, you'll get bug reports. If you're
>> lucky you'll also get patches. You may even get someone interested enough to
>> help maintain it.
>>
>> But just posting to the dev list like this (is everybody that writes modules
>> even subscribed to this list?) has more of an air of "I can't be bothered to
>> maintain this, can someone do it for me?".
>>
>> At worst it'll sit in contrib and nothing will happen, at best you may get
>> patches that teach you better php coding :)
>>
>
>

From dan at drob.org  Fri Aug 29 00:10:12 2008
From: dan at drob.org (Dan Robinson)
Date: Thu, 28 Aug 2008 17:10:12 -0700
Subject: [development] Value of submit button on insert
Message-ID: <48B73E64.70802@drob.org>

Folks,

I've written a module and used hook_form to create a form.  I want the
"Save" button to read "Print Registration Form", not "Save".  If I put
my own button in:

    $form['#submit'] = array('mymodule_process_registration');
    $form['#arg'] = $node;
    $form['#redirect'] = 'registration/complete';
   
    $form['submit'] = array(
        '#type' => 'submit',
        '#value' => t('Print Registration Form'),
        '#weight' => -2,
    )

Then the node won't get inserted because the 'op' is set to 'Print
Registration Form' instead of 'Save'.  I've looked at using
hook_validate and hook_nodeapi but no joy there.  Any suggestions?

Thanks,

Dan

From dan at drob.org  Fri Aug 29 15:48:07 2008
From: dan at drob.org (Dan Robinson)
Date: Fri, 29 Aug 2008 08:48:07 -0700
Subject: [development] Value of submit button on insert
In-Reply-To: <48B73E64.70802@drob.org>
References: <48B73E64.70802@drob.org>
Message-ID: <48B81A37.5020900@drob.org>

"ridenour" on irc helped me with this one. The trick was to modify the
"#value" in form_alter.  I assume it sets the #value and then on form
submit it gets set back to "Save".

Dan
> Folks,
>
> I've written a module and used hook_form to create a form.  I want the
> "Save" button to read "Print Registration Form", not "Save".  If I put
> my own button in:
>
>     $form['#submit'] = array('mymodule_process_registration');
>     $form['#arg'] = $node;
>     $form['#redirect'] = 'registration/complete';
>    
>     $form['submit'] = array(
>         '#type' => 'submit',
>         '#value' => t('Print Registration Form'),
>         '#weight' => -2,
>     )
>
> Then the node won't get inserted because the 'op' is set to 'Print
> Registration Form' instead of 'Save'.  I've looked at using
> hook_validate and hook_nodeapi but no joy there.  Any suggestions?
>
> Thanks,
>
> Dan
>
>   


From dries at buytaert.net  Sat Aug 30 09:21:37 2008
From: dries at buytaert.net (Dries Buytaert)
Date: Sat, 30 Aug 2008 11:21:37 +0200
Subject: [development] Drupal 7 branch maintainer
Message-ID: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>

Hello all,

during my keynote presentation at DrupalCon Szeged this week, I
announced that Angela "webchick" Byron will be my Drupal 7
co-maintainer. For the duration of one release cycle, she will help me
coordinate Drupal 7 development.  Additional detail at
http://buytaert.net/angela-webchick-byron.

Kind regards,

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

From pavan.k.murthy at gmail.com  Sat Aug 30 09:31:05 2008
From: pavan.k.murthy at gmail.com (Pavan Keshavamurthy)
Date: Sat, 30 Aug 2008 15:01:05 +0530
Subject: [development] Drupal 7 branch maintainer
In-Reply-To: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
References: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
Message-ID: <46b9cfab0808300231m4c814f12kc904612898a27981@mail.gmail.com>

Congratulations, Webchick!

2008/8/30 Dries Buytaert <dries at buytaert.net>

> Hello all,
>
> during my keynote presentation at DrupalCon Szeged this week, I
> announced that Angela "webchick" Byron will be my Drupal 7
> co-maintainer. For the duration of one release cycle, she will help me
> coordinate Drupal 7 development.  Additional detail at
> http://buytaert.net/angela-webchick-byron.
>
> Kind regards,
>
> --
> Dries Buytaert :: http://buytaert.net/
>



-- 
_PK
Skype: pavankeshavamurthy
http://grahana.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080830/25685d4d/attachment.htm 

From z.stolar at gmail.com  Sat Aug 30 09:39:48 2008
From: z.stolar at gmail.com (Zohar Stolar)
Date: Sat, 30 Aug 2008 12:39:48 +0300
Subject: [development] Drupal 7 branch maintainer
In-Reply-To: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
References: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
Message-ID: <b7cd92d40808300239j2c8f8aa2o688f740c8610e537@mail.gmail.com>

Hey Angie,

You've just earned a free Drupalager! Make sure you claim it... you're gonna
need it ;-)

Congratulations!
Zohar

On Sat, Aug 30, 2008 at 12:21 PM, Dries Buytaert <dries at buytaert.net> wrote:

> Hello all,
>
> during my keynote presentation at DrupalCon Szeged this week, I
> announced that Angela "webchick" Byron will be my Drupal 7
> co-maintainer. For the duration of one release cycle, she will help me
> coordinate Drupal 7 development.  Additional detail at
> http://buytaert.net/angela-webchick-byron.
>
> Kind regards,
>
> --
> Dries Buytaert :: http://buytaert.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080830/6222a4c8/attachment.htm 

From mvgrootel at gmail.com  Sat Aug 30 09:44:00 2008
From: mvgrootel at gmail.com (Maarten van Grootel)
Date: Sat, 30 Aug 2008 11:44:00 +0200
Subject: [development] Drupal 7 branch maintainer
In-Reply-To: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
References: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
Message-ID: <9f8bbf980808300244x2fad94e2k47b34d8fdd911313@mail.gmail.com>

Great news and great choice! Now D7 will definitely be the best release :)


On Sat, Aug 30, 2008 at 11:21 AM, Dries Buytaert <dries at buytaert.net> wrote:

> Hello all,
>
> during my keynote presentation at DrupalCon Szeged this week, I
> announced that Angela "webchick" Byron will be my Drupal 7
> co-maintainer. For the duration of one release cycle, she will help me
> coordinate Drupal 7 development.  Additional detail at
> http://buytaert.net/angela-webchick-byron.
>
> Kind regards,
>
> --
> Dries Buytaert :: http://buytaert.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080830/4ff4ef3c/attachment.htm 

From darrel.opry at gmail.com  Sun Aug 31 11:22:48 2008
From: darrel.opry at gmail.com (Darrel O'Pry)
Date: Sun, 31 Aug 2008 07:22:48 -0400
Subject: [development] Drupal 7 branch maintainer
In-Reply-To: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
References: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
Message-ID: <bfcbb6230808310422g1a0f5dd8w2817389523372bf6@mail.gmail.com>

poor angie.... :)

On Sat, Aug 30, 2008 at 5:21 AM, Dries Buytaert <dries at buytaert.net> wrote:

> Hello all,
>
> during my keynote presentation at DrupalCon Szeged this week, I
> announced that Angela "webchick" Byron will be my Drupal 7
> co-maintainer. For the duration of one release cycle, she will help me
> coordinate Drupal 7 development.  Additional detail at
> http://buytaert.net/angela-webchick-byron.
>
> Kind regards,
>
> --
> Dries Buytaert :: http://buytaert.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080831/900c7e23/attachment-0001.htm 

From kb at 2bits.com  Sun Aug 31 15:13:36 2008
From: kb at 2bits.com (Khalid Baheyeldin)
Date: Sun, 31 Aug 2008 11:13:36 -0400
Subject: [development] Drupal 7 branch maintainer
In-Reply-To: <bfcbb6230808310422g1a0f5dd8w2817389523372bf6@mail.gmail.com>
References: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
	<bfcbb6230808310422g1a0f5dd8w2817389523372bf6@mail.gmail.com>
Message-ID: <4a9fdc630808310813p19856dd8t9916108f01817ad8@mail.gmail.com>

Yes, proof once again that no good deed goes unpunished ;-)

On Sun, Aug 31, 2008 at 7:22 AM, Darrel O'Pry <darrel.opry at gmail.com> wrote:

> poor angie.... :)
>
>
> On Sat, Aug 30, 2008 at 5:21 AM, Dries Buytaert <dries at buytaert.net>wrote:
>
>> Hello all,
>>
>> during my keynote presentation at DrupalCon Szeged this week, I
>> announced that Angela "webchick" Byron will be my Drupal 7
>> co-maintainer. For the duration of one release cycle, she will help me
>> coordinate Drupal 7 development.  Additional detail at
>> http://buytaert.net/angela-webchick-byron.
>>
>> Kind regards,
>>
>> --
>> Dries Buytaert :: http://buytaert.net/
>>
>
>


-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080831/11ece4d9/attachment.htm 

From arancaytar.ilyaran at gmail.com  Sun Aug 31 17:10:04 2008
From: arancaytar.ilyaran at gmail.com (Arancaytar Ilyaran)
Date: Sun, 31 Aug 2008 19:10:04 +0200
Subject: [development] Drupal 7 branch maintainer
In-Reply-To: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
References: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
Message-ID: <48BAD06C.8070406@gmail.com>

Dries Buytaert wrote:
> Hello all,
> 
> during my keynote presentation at DrupalCon Szeged this week, I
> announced that Angela "webchick" Byron will be my Drupal 7
> co-maintainer. For the duration of one release cycle, she will help me
> coordinate Drupal 7 development.  Additional detail at
> http://buytaert.net/angela-webchick-byron.
> 
> Kind regards,
> 

Webchick is really raking in the honors this year - congratulations! =D

-- 
Aran

From larry at garfieldtech.com  Sun Aug 31 22:37:08 2008
From: larry at garfieldtech.com (Larry Garfield)
Date: Sun, 31 Aug 2008 17:37:08 -0500
Subject: [development] Drupal 7 branch maintainer
In-Reply-To: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
References: <61bca48a0808300221x8986623paf96e79eb4979c38@mail.gmail.com>
Message-ID: <200808311737.08386.larry@garfieldtech.com>

On Saturday 30 August 2008 4:21:37 am Dries Buytaert wrote:
> Hello all,
>
> during my keynote presentation at DrupalCon Szeged this week, I
> announced that Angela "webchick" Byron will be my Drupal 7
> co-maintainer. For the duration of one release cycle, she will help me
> coordinate Drupal 7 development.  Additional detail at
> http://buytaert.net/angela-webchick-byron.
>
> Kind regards,

And there has been much rejoicing all week. :-)

There are also many photographs and even a 6 minute video of her making her 
first core commit.  (It was, appropriately, 1000+ lines of database unit 
tests.)

-- 
Larry Garfield
larry at garfieldtech.com