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


On 22 January 2013 13:34, Rob Godfrey <rob.j.godf...@gmail.com> wrote:

> On 22 January 2013 13:47, Rafael Schloming <r...@alum.mit.edu> wrote:
>
> > On Tue, Jan 22, 2013 at 4:22 AM, Rob Godfrey <rob.j.godf...@gmail.com
> > >wrote:
> >
> > > On 21 January 2013 18:05, Rafael Schloming <r...@alum.mit.edu> wrote:
> > >
> > > > On Mon, Jan 21, 2013 at 9:33 AM, Rob Godfrey <
> rob.j.godf...@gmail.com
> > > > >wrote:
> > > >
> > > > > Ummm... it's a dependency... you're familiar with those, yeah?
> > > > >
> > > > > The same way that the Qpid JMS clients depend on a JMS API jar, for
> > > which
> > > > > the source is readily available from another source. The JNI
> binding
> > > > would
> > > > > build if the dependency was installed.  The same way I believe the
> > SSL
> > > > code
> > > > > in the core of proton-c builds if the dependency for it is
> installed.
> > > > >
> > > >
> > > > That's not really a proper analogy. Again the JMS interfaces are
> > defined
> > > > outside of qpid. We don't release them, and we depend only on a well
> > > > defined version of them, we don't share a release cycle with them. If
> > the
> > > > JMS API was something that we developed/defined right alongside the
> > impl
> > > > and was part of the same release process, we would certainly not be
> > > allowed
> > > > to release without the source.
> > > >
> > > >
> > > This "releasing without the source" is a complete red herring and you
> > know
> > > it.  The source is released in whichever scheme we settle upon.
> > >
> > > If you want an example of dependencies within the qpid project, how did
> > the
> > > AMQP 1.0 work on the C++ broker get released for 0.20?  Did all the
> > proton
> > > source get released with the C++ Broker / client?  In the future are
> you
> > > expecting every part of the Qpid project which depends on proton to
> > include
> > > its full source?  If yes then how is the source tree going to work - is
> > > everything to be a subdirectory of proton-c?
> > >
> >
> > Again that's not really the same. If the Java API where on a separate
> > (staggered) release cycle and the dependency was on a specific version,
> > then that would be the same, but for what we're discussing, it really
> > isn't. Proton and the cpp broker live under different trunks and
> > branch/release separately, as far as I know this is not what you're
> > proposing for the Java API, it is to live under the same trunk and
> > branch/release together.
> >
> >
> The point was that the source code doesn't need to be in the same tarball
> let alone the same subdirectory in source control. If one considers that
> the Java API is a dependency then whether it is released concurrently or
> not with the JNI binding is moot.
>
> I've already said that it is preferable to have the source within the same
> tarball for the source release, but if needs be then I can live with the
> strict dependency view of things.
>
>
> >
> > >
> > > I agree that having the source for the version of the Java API included
> > in
> > > the source release bundle is advantageous. But if the collective
> decision
> > > is that we have taken a religious position that the source tarballs can
> > > only be svn exports of subdirectories of our source tree, then my
> > > preference would be to use separated dependencies over duplication in
> the
> > > repository.  Personally I would think that having a more flexible
> policy
> > on
> > > constructing the release source tarballs would make a lot more sense.
> > >
> >
> > You can call it religious if you like, but I don't think there is
> anything
> > invalid about wanting to keep a simple mapping between release artifacts
> > and proton developer environment. In the past we have had quite direct
> > experience of exactly this factor contributing to very poor out of the
> box
> > experience for users. Correct me if I'm wrong, but I believe you yourself
> > have actually advocated (or at least agreed with) this position in the
> > past.
> >
> > That said, I don't think I'm asking for us to be entirely inflexible in
> > that regard. There really are two opposing concerns here, one being the
> > user experience for our release artifacts, and the other being the
> > convenience of the development process for proton developers.
>
>
> I actually think there are three perspectives here.  The user experience of
> our release artefacts, the committer experience of working on the
> checkedout codebase, and the release manager view of preparing the release
> aretfacts from the source control.
>
>
> > All I'm
> > asking is that we recognize that there is a real tradeoff and be willing
> to
> > explore options that might preserve user experience albeit at a hopefully
> > minor cost to developer convenience.
>
>
> I think the issue here is that if you take a rigid view of how the release
> artefacts correspond to the source repo directories then you impose
> different trade-offs compared to not imposing those constraints.
>
> I'd be very happy with a solution that provided source tarballs with
> exactly what the users need to build, and having the source tree having
> everything in exactly once, if the cost was that the release process had a
> little more processing in it.  Frankly if the source tarballs were
> constructed by taking a cut at the top level of proton (rather than at -j
> or -c) and irrelevant parts were simply pruned, then I don't (personally)
> see a big issue.
>
>
> > For any other aspect of software
> > engineering this would be a no-brainer, you start from the user
> > requirements/user experience and work your way backwards to the simplest
> > solution that achieves this, however this proposal and the related
> > requirements JIRA make zero mention of any *user* requirements merely
> > developer requirements. This may be ok for Java where all your users will
> > get stuff via jars and the source tarball is mostly a formality, but for
> C
> > the situation is different.
> >
> >
> The proposed solution in the JIRA implies that in order to build the JNI
> binding then the builder would need to "install" the Java API (in the same
> way that they would need to "install" Java, Python, etc).  This is a
> slightly greater burden on the end user who is building the binding, and
> one which I would wish to avoid. However the fact of having a dependency
> for a certain part of the build does not seem out of line with the rest of
> the process which a user would have to go through.  If the Java API were
> not present then the JNI binding would simply be skipped in the build.
>
> As above, I personally prefer having the API code available in the source
> tarball, but if the only way to do this would be to have two copies of the
> source code checked in (even if there were some scripts to try to keep the
> copies in sync), I would choose to omit the source from the tar and go with
> the strict dependency.
>
> -- Rob
>
>
> > --Rafael
> >
>

Reply via email to