On Saturday, April 21, 2001, at 12:52 PM, Jim Jagielski wrote:
> Chuck Murcko wrote:
>>
>> So did the discussion then stall on the best tool(s)?
>>
>
> Yeah, and implementation and how to handle it and repository
> locations, etc... :)
>
> Back then we weren't that clear, IIRC, on how to do things like
> subprojects, etc.
>
Makes sense. The requirement to deal with subprojects sounds like it
wasn't as clear cut then. Hell, subprojects themselves weren't as well
defined as they have grown lately. Now that we have them (or are about
to), we probably want to define both a (rollup) build staging and a
distribution area for each subproject (say, proxy). Both of these are
outside the repository.
The distribution area is under (as at least Brian, Greg Stein, and Bill
Rowe have suggested) /dist/proxy or /dist/httpd/proxy or somesuch.
Then the latest tested release is there, tagged with same tag as
httpd-2.0blah in this case for easy fetching from cvs with httpd for
packaging. In a subdirectory like httpd-2.0blah, as well. Thus
/dist/httpd/proxy/httpd-2_0_16-beta in the case of the last release. And
/dist/httpd/proxy/apache_1.3.19, since we're a special case of carrying
a rather largish patch along with the core code there.
Symlink to -latest as well in each subdirectory; this will help
automated tools too.
Now, for build staging for a rollup release. That seems simpler, if the
project (httpd) and subprojects tag with the same tagname for a given
release. This is something we don't do for the other packages httpd
uses, but I assume httpd will stage into the build area complete already
(since it has to do so for its own release). Subprojects get dropped
into place in the httpd source tree, and we build the rollup source and
binary builds out of there. Subprojects should "just be built in" to a
casual test using a normal config-make-make install set of commands on
the rollup build directory, please no stinking build release notes and
changes here, you can't whine to a script.
I would expect subprojects to grow a little cruft, like release notes,
CHANGES, and stuff in, say, modules/proxy or wherever the subproject
sits in httpd.
Does this sound OK? It's easier than I am used to because we don't go to
build-per-platform except at the compile stage, which for distribution
gets offloaded to the build volunteers.
Of course the underlying assumption in all this is that subprojects
cleanly drop into a httpd source release.
>> I must apologize for being out of the loop then.
> We don't need no stinkin' apologies :)
>
Alrighty then. You can never say I didn't offer you one, once. 8^)
Chuck Murcko
Topsail Group
http://www.topsail.org/
