No, Community process. I am going to beg to restore sanity for all our developers, not relying on any one person, and we are going to strive at a community decision before 2.next GA, whether my suggestions carry, or not.
One of those suggestions is that win32 do nothing that the unix build schema refused to. For 18 years we faithfully delivered a LICENSE and later a NOTICE to the build result tree. I've raised this repeatedly and the vast majority of the PMC does not care. Until unix builds bother, it is time to drop this maintenance headache of depositing the Apache License and NOTICE, nevermind appending third party artifacts in the win32 schema. On the topic of splitting the many-other-ways to build win32, I'm not only supportive of your efforts to maintain this, but am willing to participate now that I'm in sync again with modern MSVC/Studio. I'll share pointers once my testing is complete of baby+bathwater solution to all the prerequisite components. All I suggest is that it can sit in parallel and be fixed both before and after release, instead of burning rev no's on nearly every candidate. Thanks for your efforts and enthusiasm Gregg, I'm not about to start ignoring your input, Cheers Bill On Feb 25, 2018 14:17, "Gregg Smith" <g...@gknw.net> wrote: On 2/23/2018 10:24 AM, William A Rowe Jr wrote: > On Fri, Feb 23, 2018 at 12:01 PM, Steffen <i...@apachelounge.com> wrote: > >> >> Op 18 feb. 2018 om 17:57 heeft Eric Covener <cove...@gmail.com> het >>> volgende geschreven: >>> >>> On Sun, Feb 18, 2018 at 11:53 AM, Steffen <i...@apachelounge.com> wrote: >>>> >>>> On Sunday 18/02/2018 at 17:39, Eric Covener wrote: >>>> >>>> -- not sure, mod_md; should curl and jansson be added to notice/license >>>> files ? >>>> >>>> >>>> I don't think either is contained in mod_md, so I don't think they >>>> should be referenced in the NOTICES: >>>> >>>> http://www.apache.org/dev/licensing-howto.html#mod-notice >>>> ``` >>>> Dependencies which are not included in the distribution MUST NOT be >>>> added to LICENSE and NOTICE. As far as LICENSE and NOTICE are >>>> concerned, only bundled bits matter. >>>> ``` >>>> On Win the curl and jansson dependencies are included in the binary >>>> distribution. >>>> >>>> >>>> We can't reflect what might be added in a third-party binary >>>> distribution to the NOTICES file in httpd SVN. I think the obligation >>>> is on whoever creates the binary distribution to enumerate what's in >>>> it. That's what the ASF policy (same page) would be, at least. >>>> >>>> Till now Makefile.win in SVN contains the text,for example see below. >>>> >>>> >>>> >>>> !IF EXIST("srclib\nghttp2") >>>> type << >> "$(INSTDIR)\NOTICE.txt" >>>> >>>> This binary distribution of mod_http2.so includes nghttp2 C library >>>> written >>>> by Tatsuhiro Tsujikawa. For complete information, visit nghttp2's web >>>> site >>>> at https://nghttp2.org/ >>>> << >>>> -awk -f <<script.awk < "srclib\nghttp2\COPYING" >> >>>> "$(INSTDIR)\LICENSE.txt" >>>> BEGIN { >>>> print ""; >>>> print "For the mod_http2 component:"; >>>> print ""; >>>> while ( getline > 0 ) { >>>> print $$0; >>>> } >>>> exit 0; >>>> } >>>> << >>>> !ENDIF >>>> >>>> >>> Are you asking if it would be appropriate to do the same thing for the >>> other dependencies? If they're built the same way it would seem >>> reasonable. I do not personally think it's necessary (showstopper) >>> for a release. It looks like a convenience for someone who already >>> copied prereqs into srclib/. Maybe others feel differently? >>> >> >> Bill and others, what do you think ? >> > > I am getting to snapshot testing in about an hour here on Windows, > I'm just finishing up my review of 2.4.30 on Linux. I'll have more to > offer, then. > > I think to be in line with other deps (like brotli, http2...) we should >> add it to makefile.win, which copies to notice/license. >> > > These are all legacies of having a command line build schema > for httpd-project distributed windows binaries, which handled the > vast amount of target tree preparation by presuming each of these > components exist within srcdir/. That's an extremely inflexible > mechanism that must be cleaned up in trunk. > So basically what your saying is that if I put any time into getting trunk building again (have already done with exception of apreq & now proxy_uwsgi), it's all for not and just a waste of my time because you're going to toss it all out in the end. Am I understanding this correctly? > I'm unclear of your build process, whether you are using the SLN > schema of Makefile.win? Or using the GUI results and then just > using the nmake install step of Makefile.win? > InstallBin is just nmake _install, so there's no difference. # PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache24" SHORT=R LONG=Release _install" And since nmake _install has a dependency to nmake _build(r/d) (like InstallBin to BuildBin), it would just builds everything again if you used nmake install(r/d) after building with the GUI. > In any case, for those components which the Makefile.win does > physically copy into the target tree, it ought to also be appending > the NOTICE. Where it does not take responsibility to move the > third party lib, it should not extend the NOTICE. Does that seem > rational? > > We (httpd source tree maintainers) should be out of the business > of handling 'make install' steps for third party packages. As a > distributor, I'm sure you and others appreciate the current > convenience, but it involves generally knowing which rev level > each third party package is at, and distributors can and will > disagree on which components and versions should be linked > into their own build of httpd for their purposes. > > I'm happy to > collaborate on such helpful scripts and utilities but > they belong out of the /httpd/httpd/branches/rev/ tree so that they > don't interfere with the release cycle of the primary source project. > >
