>> 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
