On 23 January 2013 19:09, Rafael Schloming <r...@alum.mit.edu> wrote:
> 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 would be helpful if you could enumerate requirements which you believe to be missing and add the to the existing wiki page. I don't think anyone is suggesting that the make install step should be broken in the source tarball, so it's a little unclear to me the problem you are trying to highlight above. > 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. > > So, I think we probably need to consider what sort of tests are required, and which languages it is appropriate to write any particular type of test in. For me tests in Java have some advantages over Python tests. Firstly they allow interop tests between the two implementations within the same process and secondly they will also be able to be used against any future pure JavaScript Proton implementation (something we have planned to do but not yet embarked upon). A third issue for me is that when we start to attempt more granular testing of things such as error handling, I will want to ensure that the user experience is identical between the pure Java and JNI binding implementations of the Java Proton API... if the tests are being run through a second translation into the Python API then this is not easily verifiable. As a final aside, on the standard development environment many of us have to work with, the installed version on Python is too old to support the current Python client (lack of UUID, etc). Personally I think the more tests we have the better, and it's more important to encourage people to write tests than to force the use of a particular language to write them in. I'd also suggest that we should be writing at least some tests for each of the idiomatic bindings. -- Rob --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 > > > > > >
