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
>

Reply via email to