Appologies: httpd/httpd/vendor/ SNAFU

2007-11-26 Thread Philip M. Gollucci

Hi All,

I accidentally committed an upgrade to httpd/httpd/vendor/pcre/current
to 7.4.  I apparently had a commit bit there because I'm on the PMC from 
past apreq work.


I immediately asked what to do over on #infra on freenode and jerenkrantz 
agreed I should back it out so I did.


It was committed in r598339 and removed in r598343.
I was following th README there and did not execute the svn cp after 
actually seing the ci complete. I was expecting it to fail. 
httpd/httpd/{branches,trunk} were not affected.


If I need to do anything else to undo it let me know.

I shall be more careful in the future.

On another note, the reasoning behind this is FreeBSD ports supposed 
WITH_PCRE_FROM_PORTS option in www/apache22 et al. Which works flawlessly 
so I thought it might be a good idea; however, I definetely wanted it 
reviewed on this list first.


Again, my appologies.



 -- 


Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708
Senior System Admin - Riderway, Inc. http://riderway.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB  B89E 1324 9B4F EC88 A0BF

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.



Re: Appologies: httpd/httpd/vendor/ SNAFU

2007-11-26 Thread Roy T. Fielding

On Nov 26, 2007, at 6:59 AM, Philip M. Gollucci wrote:

I accidentally committed an upgrade to httpd/httpd/vendor/pcre/current
to 7.4.  I apparently had a commit bit there because I'm on the PMC  
from past apreq work.


I immediately asked what to do over on #infra on freenode and  
jerenkrantz agreed I should back it out so I did.


Generally speaking, if someone tells you to do something in IRC
then it is almost certainly the wrong thing to do -- just like
decisions made in boring meetings.

The right thing to do, assuming you actually want this change to
be done at some point in the near future, is just to apologize for
the accident and *ask* if anyone objects to the change *here*.

I can't think of any reason not to update the vendor branch with
the latest vendor version, particularly after receiving the 37
commit logs associated with it.  My opinion won't change, even
though the revert means an additional 59 commit notices will be
sent for no good reason.  The only thing better than that would
be to remove the vendor branch entirely, unless the svn log is
insufficient to capture what changes have been made since the
last time the vendor branch was synced with trunk.

In any case, if you have the itch to update trunk to the latest
version of PCRE in workable form, then by all means go for it.
That is, assuming you have time to test it with httpd first and
make sure that it works on your system before committing.

Roy


Re: Appologies: httpd/httpd/vendor/ SNAFU

2007-11-26 Thread Justin Erenkrantz
On Nov 26, 2007 4:28 PM, Roy T. Fielding [EMAIL PROTECTED] wrote:
 Generally speaking, if someone tells you to do something in IRC
 then it is almost certainly the wrong thing to do -- just like
 decisions made in boring meetings.

Philip said he never intended to commit it.

 The right thing to do, assuming you actually want this change to
 be done at some point in the near future, is just to apologize for
 the accident and *ask* if anyone objects to the change *here*.

I did indicate sending the email to [EMAIL PROTECTED] was the priority.  *shrug*

 In any case, if you have the itch to update trunk to the latest
 version of PCRE in workable form, then by all means go for it.
 That is, assuming you have time to test it with httpd first and
 make sure that it works on your system before committing.

Once we switched our code to supporting external PCREs, in my opinion,
we should have just dropped the whole vendor branch concept as it
serves no legitimate purpose any more.  If the PCRE guys are doing
releases now (it seems someone is home now), then we should just get
our changes merged upstream and stop having private copies of it.  --
justin


Re: Appologies: httpd/httpd/vendor/ SNAFU

2007-11-26 Thread William A. Rowe, Jr.

Justin Erenkrantz wrote:


Once we switched our code to supporting external PCREs, in my opinion,
we should have just dropped the whole vendor branch concept as it
serves no legitimate purpose any more.  If the PCRE guys are doing
releases now (it seems someone is home now), then we should just get
our changes merged upstream and stop having private copies of it.  --


To Trunk (/future release)?  ++1



Re: Appologies: httpd/httpd/vendor/ SNAFU

2007-11-26 Thread Justin Erenkrantz
On Nov 26, 2007 8:01 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
 Justin Erenkrantz wrote:
 
  Once we switched our code to supporting external PCREs, in my opinion,
  we should have just dropped the whole vendor branch concept as it
  serves no legitimate purpose any more.  If the PCRE guys are doing
  releases now (it seems someone is home now), then we should just get
  our changes merged upstream and stop having private copies of it.  --

 To Trunk (/future release)?  ++1

Yup, we should unbundle PCRE for trunk/2.4/3.0/whatever-comes-next.

Obviously, we need to keep bundling it for 2.2 and prior; but going
forward?  Eh.  We only had a PCRE in-tree because we were diverging
from upstream and no one on the PCRE side was home for years.  So, if
someone is maintaining PCRE these days, then we don't need to and just
get our folks to download and install PCRE separately.  -- justin


Re: Appologies: httpd/httpd/vendor/ SNAFU

2007-11-26 Thread Roy T. Fielding

On Nov 26, 2007, at 8:20 PM, Justin Erenkrantz wrote:

On Nov 26, 2007 8:01 PM, William A. Rowe, Jr. [EMAIL PROTECTED]  
wrote:

Justin Erenkrantz wrote:


Once we switched our code to supporting external PCREs, in my  
opinion,

we should have just dropped the whole vendor branch concept as it
serves no legitimate purpose any more.  If the PCRE guys are doing
releases now (it seems someone is home now), then we should just get
our changes merged upstream and stop having private copies of  
it.  --


To Trunk (/future release)?  ++1


Yup, we should unbundle PCRE for trunk/2.4/3.0/whatever-comes-next.

Obviously, we need to keep bundling it for 2.2 and prior; but going
forward?  Eh.  We only had a PCRE in-tree because we were diverging
from upstream and no one on the PCRE side was home for years.  So, if
someone is maintaining PCRE these days, then we don't need to and just
get our folks to download and install PCRE separately.  -- justin


Okay with me.  All we need now is a volunteer to figure out what
(if any) changes are needed to use a separately installed PCRE.

Roy


Re: Appologies: httpd/httpd/vendor/ SNAFU

2007-11-26 Thread Justin Erenkrantz
On Nov 26, 2007 8:46 PM, Roy T. Fielding [EMAIL PROTECTED] wrote:
 Okay with me.  All we need now is a volunteer to figure out what
 (if any) changes are needed to use a separately installed PCRE.

All hail Guido's time machine than has been hijacked by Joe.  =)  -- justin

% ./configure --help | grep pcre
  --with-pcre=PATHUse external PCRE library


r153400 | jorton | 2005-02-11 06:08:24 -0800 (Fri, 11 Feb 2005) | 12 lines

Support use of an external copy of the PCRE library:

* configure.in: Set abs_{builddir,srcdir} higher.  Add --with-pcre
flag; build against external PCRE library if used.

* Makefile.in (install-include): Don't install pcre headers any more.

* srclib/Makefile.in (SUBDIRS): Remove.

PR: 27550 (part two)
Submitted by: Andres Salomon dilinger voxel.net, Joe Orton