I've added another wiki page that documents the proton release steps as best I can remember. I'll updated it more during the 0.4 release: https://cwiki.apache.org/confluence/display/qpid/Proton+Release+Steps
I think it's important to understand the overall release and testing process as it is a significant and perhaps underrepresented factor against which to measure any proposals. I believe the build system requirements documented below are inherently incomplete as they don't recognize the fact that the C build system is not just a developer productivity tool, it is also the installer for our end users. And before anyone says our end users will just use yum or equivalents, all those packaging tools *also* depend on our build system both directly, and because we can't even supply a release for packagers to consume without a reasonable amount of direct install testing. To a good extent a standard looking C source tarball is pretty much the equivalent of a jar or jar + pom file in the Java world, it's really the only platform independent means of distribution we have. It's also probably worth noting that perhaps the biggest issue with system tests in Java is not so much imposing maven on proton-c developers, but the fact that Java may not be available on all the platforms that proton-c needs to be tested on. My primary concern here would be iOS. I'm not an expert, but my brief googling seems to suggest there would be significant issues. --Rafael On Wed, Jan 23, 2013 at 12:45 PM, Phil Harvey <p...@philharveyonline.com>wrote: > In case anyone has missed it, note that Gordon has added some relevant > comments directly on the wiki pages: > > > https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+requirements > > https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+proposals > > Phil > > > On 23 January 2013 13:01, Keith W <keith.w...@gmail.com> wrote: > > > >> What are people's views on the relative priority of these > requirements? > > >> Are there any I've missed? I think answering these questions is a > > >> prerequisite for agreeing the technical solution. > > > > With the aim of stimulating discussion regarding our requirements and > > to reach a consensus, I've classified each of the proposed > > requirements into whether I believe each is essential, neutral or > > detrimental to the smooth development of Proton. > > > > (proposed requirement numbers from > > > > > https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+requirements > > ) > > > > Essential > > > > 3. To change proton-api, all that is required is to edit a Java file. > > - Developer productivity > > > > 4. To switch to a particular SVN revision, simple SVN commands are run > > (e.g. svn switch or svn update) > > - Developer productivity > > > > 5. proton-c can be built, excluding its JNI binding, without requiring > > non-standard tools* > > 6. proton-c can be built, excluding its JNI binding, from a standalone > > checkout of the proton-c directory > > - Developer productivity / tool familiarity > > > > Neutral > > > > 1. A "tarball" source release of proton-c can be built by a user > > without an external dependency on any other part of proton, e.g. > > proton-api. > > 2. The aforementioned proton-c tarball release can be produced by > > performing a simple "svn export" of proton-c. > > - If I were building proton-c for my platform for tarball, I would > > also want to run the tests to be sure proton-c functions correctly. > > For this reason I question the usefulness of a proton-c tarball. I > > would want a tarball that included the whole tree including the tests. > > > > 7. Proton-c can be built without requiring non-standard tools* > > 9. Proton-c can be tested without requiring non-standard tools* > > - If we can achieve this without introducing too much complexity, > > reinventing too many wheels and the result is portable across all > > target platforms. > > > > Detrimental > > > > 8. proton-c can be built from a standalone checkout of the proton-c > > directory > > - I think that all proton developers who are changing either the C or > > Java implementations should be running the system tests before each > > commit. If they are changing system tests then they need to run > > against both implementations before each commit. > > > > On 22 January 2013 17:09, Rafael Schloming <r...@alum.mit.edu> wrote: > > > Thanks for posting this, I think it's a very useful step. I'd suggest > > > adding another Stakeholder -- someone testing a release artifact. Rob > > makes > > > a good point that the release manager is a distinct view, but I think > the > > > desire to minimize deltas between the svn tree and the release > artifacts > > is > > > most directly motivated by my experience *testing* release artifacts. I > > > remember going through qpid releases in the old days and having the > very > > > unpleasant experience of trying to remember from 8 or 10 months ago how > > > exactly stuff worked in the release artifact as compared to the build > > tree. > > > I very much like the fact that with a simple export I can be highly > > > confident that my experience of stuff working in my checkout translates > > > well to the release artifacts and testing them is a very familiar, > quick, > > > and easy process. > > > > > > Strictly speaking I think the requirement from a release management > > > perspective is purely that we can produce releases at the rate we need, > > so > > > it has to be quick and easy and robust to different environments, but I > > > wouldn't say the export thing is a requirement of the release manager > > > per/se. As many have pointed out we already use a script for this and > it > > > can remap things quite easily. > > > > > > I have more thoughts on the release process, especially as it is > somewhat > > > expanded now to produce java binaries and will need to expand more to > > > include windows stuff, however I need to run an errand at the moment. > > I'll > > > post and/or comment on the page later though. > > > > > > --Rafael > > > > > > I very much like the fact that our current release artifacts are > trivial > > > > > > On Tue, Jan 22, 2013 at 11:43 AM, Phil Harvey < > p...@philharveyonline.com > > >wrote: > > > > > >> It sounds like we're still a little way away from reaching a > consensus. > > As > > >> a step towards this, I would like to clarify the relative priority of > > the > > >> various requirements that have come up. I've therefore created a page > > on > > >> the wiki that lists them, with a child page briefly describing the > > various > > >> proposals. > > >> > > >> > > >> > > > https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+requirements > > >> > > >> What are people's views on the relative priority of these > requirements? > > >> Are there any I've missed? I think answering these questions is a > > >> prerequisite for agreeing the technical solution. > > >> > > >> Phil > > >