Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D4801200BE0 for ; Sat, 17 Dec 2016 07:43:12 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id D2996160B28; Sat, 17 Dec 2016 06:43:12 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id CDC23160B16 for ; Sat, 17 Dec 2016 07:43:11 +0100 (CET) Received: (qmail 78651 invoked by uid 500); 17 Dec 2016 06:43:06 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 78635 invoked by uid 99); 17 Dec 2016 06:43:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Dec 2016 06:43:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id A293CC74A1 for ; Sat, 17 Dec 2016 06:43:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.498 X-Spam-Level: ** X-Spam-Status: No, score=2.498 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=rowe-clan-net.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 5ufXMz96ll3x for ; Sat, 17 Dec 2016 06:43:04 +0000 (UTC) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 22C625F251 for ; Sat, 17 Dec 2016 06:43:04 +0000 (UTC) Received: by mail-io0-f171.google.com with SMTP id h30so115216388iod.2 for ; Fri, 16 Dec 2016 22:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowe-clan-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=AnBfkmjVjvHCJcnmxt3eUaiTecq7dxyCQhKrXXbjqOU=; b=r+YcCQol6jMV7WQ4TOoprsj8HaaBTbV6vk+Jb5nXZPD6KmoW1Ayg+HZU4rgL1FgQmz tXH5D2kHJHEf8WccwlcO0PBxpl9/Zc6V0v29ZExCpyNvEu6MSS/oLxYj66pmkoBkx2f4 aru+7j2FVGfaq6tTQRn3VPTvJQOzb+wETXhiefyzWhSmigqGG8peoczo3U6NfDSDdLvR LJFXea23WaghIC2wgH4+oi/QJEdaiJhH3OxKf9s7YJCFRVPuQvkJ7gPCrISmAwqLrom0 HAg8MEQK3XtkVmJqwdj4pue8XikKlCnH6Qs4vawB+G1IsHeDu6HN3sGz8N2gWt6iM+FR kRog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AnBfkmjVjvHCJcnmxt3eUaiTecq7dxyCQhKrXXbjqOU=; b=bYxYLckOyAfg0Z+UHvd/ZS9GL/6j2ixP/R0qG8rr9J3T8/RtHVO6HIs0wwjSXbIWMl VQcIbuJh3n/hH1DAH32s+3594WT/J3bLBXkoj0WVdjipsmxfr5c6Mv7rVoFZGgswcE9r ocHXqGx64Ru0qUrDBR/juPZlOqvKwZxdt8DKkYVxmBfCH0clYIxuOcd4WMzlSr1WsGFl oIrK3D1qOJk4x+pLxII2XCxTm2fKycPbWiUCyLtNQF7/a9u+ZDtckjSzUX5s9rh+wmUp ffuUqTub3ST/wsFAzhy9U85qheZLd6IiaQheeoQzIUKnd16MqxtmMEwKfDX5qIjqV8Jq eX1Q== X-Gm-Message-State: AKaTC00w9rk0YQFy8q+XTdtc4PKqj4EzPjo0uVksU+trFoWEpbs73suPEtlHor5SLYIy24Ds4uEhBOLkk9XEe8ZS X-Received: by 10.107.158.4 with SMTP id h4mr6021592ioe.43.1481956968103; Fri, 16 Dec 2016 22:42:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.34.197 with HTTP; Fri, 16 Dec 2016 22:42:47 -0800 (PST) In-Reply-To: <20161216184850.886393A0026@svn01-us-west.apache.org> References: <20161216184850.886393A0026@svn01-us-west.apache.org> From: William A Rowe Jr Date: Sat, 17 Dec 2016 00:42:47 -0600 Message-ID: Subject: Re: svn commit: r1774650 - /httpd/httpd/branches/2.4.x/modules/cache/mod_socache_memcache.mak To: httpd Content-Type: multipart/alternative; boundary=001a1140e9aca8308f0543d4fe8c archived-at: Sat, 17 Dec 2016 06:43:13 -0000 --001a1140e9aca8308f0543d4fe8c Content-Type: text/plain; charset=UTF-8 I'm torn whether this is a showstopper or not. In all fairness, feature/enhancement crap modified 2.4.x branch as of; Modified *Tue Dec 13 13:57:02 2016 UTC* (3 days, 16 hours ago) by *jim* So the question is, is it fair to other platform maintainers to deal with enhancements requiring build structure refactoring less than 3 days prior to T&R? (And if you presume me a win32 platform maintainer, you would be mistaken. I resuscitated my win32 environments as of 4pm today across all my VMs, after some brutal force-update- reboot crap by M$ after I configured it never to do that again. and again. and...) I'll leave this question for the RM to decide. Right now I can offer no vote for or against. We have another thread on how to fix this long term. I haven't used the packaged .mak/.dep files in a decade, since I forked the APR core build from the httpd build, and that isn't reflected in our httpd distro. At this point, I'm not looking back, the CMake solution on trunk seems like the one and only one correct solution, and some proposal to scuttle .dsp from that tree will be arriving once I have a reasonable solution to CMake's 'f' you, it is a fixed root' nightmare. If this were an enhancement release, I would shrug my shoulders and say 'feh, small bug, patch this.' Since this release is overloaded with 10 months of security fixes, I'd suggest an entirely correct tarball is to everyone's' benefit. That's why I can't +1 this otherwise satisfactory tag. I won't vote against this release, the sources are as best as we can accomplish, correct, build issues notwithstanding. On Fri, Dec 16, 2016 at 12:48 PM, wrote: > Author: wrowe > Date: Fri Dec 16 18:48:49 2016 > New Revision: 1774650 > > URL: http://svn.apache.org/viewvc?rev=1774650&view=rev > Log: > Fix exported .mak output of mod_socache_memcache for '../generators' > dependency > > Modified: > httpd/httpd/branches/2.4.x/modules/cache/mod_socache_memcache.mak > > Modified: httpd/httpd/branches/2.4.x/modules/cache/mod_socache_ > memcache.mak > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/ > modules/cache/mod_socache_memcache.mak?rev=1774650&r1= > 1774649&r2=1774650&view=diff > ============================================================ > ================== > --- httpd/httpd/branches/2.4.x/modules/cache/mod_socache_memcache.mak > (original) > +++ httpd/httpd/branches/2.4.x/modules/cache/mod_socache_memcache.mak Fri > Dec 16 18:48:49 2016 > @@ -62,7 +62,7 @@ CLEAN : > if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)" > > CPP=cl.exe > -CPP_PROJ=/nologo /MD /W3 /Zi /O2 /Oy- /I "../../srclib/apr-util/include" > /I "../../srclib/apr/include" /I "../../include" /D "NDEBUG" /D "WIN32" /D > "_WINDOWS" /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_socache_memcache_src" /FD /c > +CPP_PROJ=/nologo /MD /W3 /Zi /O2 /Oy- /I "../../srclib/apr-util/include" > /I "../../srclib/apr/include" /I "../../include" /I "../generators" /D > "NDEBUG" /D "WIN32" /D "_WINDOWS" /Fo"$(INTDIR)\\" > /Fd"$(INTDIR)\mod_socache_memcache_src" /FD /c > > .c{$(INTDIR)}.obj:: > $(CPP) @<< > @@ -166,7 +166,7 @@ CLEAN : > if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)" > > CPP=cl.exe > -CPP_PROJ=/nologo /MDd /W3 /Zi /Od /I "../../srclib/apr-util/include" /I > "../../srclib/apr/include" /I "../../include" /D "_DEBUG" /D "WIN32" /D > "_WINDOWS" /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_socache_memcache_src" /FD > /EHsc /c > +CPP_PROJ=/nologo /MDd /W3 /Zi /Od /I "../../srclib/apr-util/include" /I > "../../srclib/apr/include" /I "../../include" /I "../generators" /D > "_DEBUG" /D "WIN32" /D "_WINDOWS" /Fo"$(INTDIR)\\" > /Fd"$(INTDIR)\mod_socache_memcache_src" /FD /EHsc /c > > .c{$(INTDIR)}.obj:: > $(CPP) @<< > > > --001a1140e9aca8308f0543d4fe8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm torn whether this is a showstopper or not.
In all fairness, feature/enhancement crap modified 2.4.x branch= as of;

Modified=C2=A0Tue Dec 13 13:57:02 2016 UT= C=C2=A0(3 days, 16 hours ago) by=C2=A0jim=C2=A0
<= br>
So the question is, is it fair to = other platform maintainers to deal with
enh= ancements requiring build structure refactoring less than 3 days
prior to T&R? (And if you presume me a win32 plat= form maintainer,
you would be mistaken. I r= esuscitated my win32 environments=C2=A0
as = of 4pm today across all my VMs, after some brutal force-update-
reboot crap by M$ after I configured it never to do th= at again. and=C2=A0
again. and...)

I'll leave= this question for the RM to decide. Right now I can offer no
vote for or against.
We have another thread on how to fix this= long term. I haven't used
the packaged= .mak/.dep files in a decade, since I forked the APR
core build from the httpd build, and that isn't reflected in = our httpd
distro. At this point, I'm no= t looking back, the CMake solution on
trunk= seems like the one and only one correct solution, and some
proposal to scuttle .dsp from that tree will be arriving o= nce I have
a reasonable solution to CMake&#= 39;s 'f' you, it is a fixed root' nightmare.

If this were an enhancem= ent release, I would shrug my shoulders
and= say 'feh, small bug, patch this.' Since this release is overloaded=
with 10 months of security fixes, I'd = suggest an entirely correct
tarball is to e= veryone's' benefit. That's why I can't +1 this otherwise
satisfactory tag.

I won't vote against this rel= ease, the sources are as best as we
can acc= omplish, correct, build issues notwithstanding.




On = Fri, Dec 16, 2016 at 12:48 PM, <wrowe@apache.org> wrote:
=
Author: wrowe
Date: Fri Dec 16 18:48:49 2016
New Revision: 1774650

URL: http://svn.apache.org/viewvc?rev= =3D1774650&view=3Drev
Log:
Fix exported .mak output of mod_socache_memcache for '../generators'= ; dependency

Modified:
=C2=A0 =C2=A0 httpd/httpd/branches/2.4.x/modules/cache/mod_socache_memcache.mak

Modified: httpd/httpd/branches/2.4.x/modules/cache/mod_socache_me= mcache.mak
URL: http://svn= .apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/cache/mod_s= ocache_memcache.mak?rev=3D1774650&r1=3D1774649&r2=3D17746= 50&view=3Ddiff
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
--- httpd/httpd/branches/2.4.x/modules/cache/mod_socache_memcache= .mak (original)
+++ httpd/httpd/branches/2.4.x/modules/cache/mod_socache_memcache= .mak Fri Dec 16 18:48:49 2016
@@ -62,7 +62,7 @@ CLEAN :
=C2=A0 =C2=A0 =C2=A0if not exist "$(OUTDIR)/$(NULL)" mkdir "= $(OUTDIR)"

=C2=A0CPP=3Dcl.exe
-CPP_PROJ=3D/nologo /MD /W3 /Zi /O2 /Oy- /I "../../srclib/apr-util/include" /I "../../srclib/apr/include" /I "../../incl= ude" /D "NDEBUG" /D "WIN32" /D "_WINDOWS"= ; /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_socache_memcache_s= rc" /FD /c
+CPP_PROJ=3D/nologo /MD /W3 /Zi /O2 /Oy- /I "../../srclib/apr-util/include" /I "../../srclib/apr/include" /I "../../incl= ude" /I "../generators" /D "NDEBUG" /D "WIN32= " /D "_WINDOWS" /Fo"$(INTDIR)\\" /Fd"$(INTDIR= )\mod_socache_memcache_src" /FD /c

=C2=A0.c{$(INTDIR)}.obj::
=C2=A0 =C2=A0 $(CPP) @<<
@@ -166,7 +166,7 @@ CLEAN :
=C2=A0 =C2=A0 =C2=A0if not exist "$(OUTDIR)/$(NULL)" mkdir "= $(OUTDIR)"

=C2=A0CPP=3Dcl.exe
-CPP_PROJ=3D/nologo /MDd /W3 /Zi /Od /I "../../srclib/apr-util/in= clude" /I "../../srclib/apr/include" /I "../../include&= quot; /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /F= o"$(INTDIR)\\" /Fd"$(INTDIR)\mod_socache_memcache_src&q= uot; /FD /EHsc /c
+CPP_PROJ=3D/nologo /MDd /W3 /Zi /Od /I "../../srclib/apr-util/in= clude" /I "../../srclib/apr/include" /I "../../include&= quot; /I "../generators" /D "_DEBUG" /D "WIN32&quo= t; /D "_WINDOWS" /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mo= d_socache_memcache_src" /FD /EHsc /c

=C2=A0.c{$(INTDIR)}.obj::
=C2=A0 =C2=A0 $(CPP) @<<



--001a1140e9aca8308f0543d4fe8c--