qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Modularizing Qpid
Date Wed, 10 Apr 2013 15:40:22 GMT
+1 on this.
Having the flexibility to have individual release cycles for each component
will be huge advantage for us.
However as Justin mentioned, we shouldn't rule out a Qpid wide release
perhaps once a year or so.
>From a users perspective this is a great thing to have, bcos all the
components bundled under that release will be guaranteed to work well
together.

Rajith

On Wed, Apr 10, 2013 at 10:46 AM, Rob Godfrey <rob.j.godfrey@gmail.com>wrote:

> I'm +1 this... Obviously we need to understand better the amount of work to
> achieve the separation of the components... but if this were in place then
> we wouldn't be facing the sort of issues we are currently experiencing with
> the 0.22 release which would strongly benefit from not having the release
> cycles of all components tied together.
>
> -- Rob
>
>
> On 10 April 2013 15:55, Justin Ross <jross@apache.org> wrote:
>
> > Hi, everyone.  We've recently been discussing the components of our
> > project in a couple different contexts.  This is a proposal to take
> > the outcomes of those discussion and apply them to how Qpid is
> > organized.
> >
> > Thanks for taking a look,
> > Justin
> >
> > ## Related discussions
> >
> >  -
> >
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> >  - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
> >
> > ## The problem
> >
> > For a long time, Qpid was in many respects treated as one thing, with
> > one release cycle.  Its parts were divided at the top level by
> > language, not function.
> >
> > The division by language provides little incentive to factor out
> > dependencies into clean interfaces, and it has tended to mean that
> > developers often work in just one language silo.
> >
> > It has also meant that our source modules have only a weak
> > correspondence to the user-focused release artifacts that we produce.
> >
> > With Proton, we've broken the mold, and the overall picture of Qpid is
> > inconsistent and confusing, to the Qpid developers and users.
> >
> > ## The proposed approach
> >
> >  - Qpid the project embraces a functional division of components
> >
> >  - Each source component is self-contained and independent, with a
> >    focused purpose; among components, there are well defined
> >    dependencies
> >
> >  - The source components should correspond closely to the pieces our
> >    users want to use independently; nonetheless, there would in some
> >    cases be multiple release artifacts from a component
> >
> >  - Each component has its own set of branches, supporting independent
> >    releases
> >
> >  - Each component should be neither too large nor too small; large
> >    enough to ease development and release management; small enough to
> >    represent a focused functional unit and to clarify dependencies
> >
> >  - API components would in some cases also contain code shared by APIs
> >    and servers; the server would in that case depend on the API code
> >    base
> >
> > ## Proposed source components
> >
> >  - Proton (this one already exists)
> >    - /qpid/proton/trunk/
> >
> >  - JMS
> >    - /qpid/jms/trunk/
> >    - Depends on Proton
> >
> >  - Java broker
> >    - /qpid/java-broker/trunk/
> >    - Depends on JMS (?)
> >
> >  - Messaging API
> >    - /qpid/messaging-api/trunk/
> >    - Both the C++ (and bindings) and python implementations would
> >      move here
> >    - Depends on Proton
> >
> >  - C++ broker
> >    - /qpid/cpp-broker/trunk/
> >    - Depends on Messaging-API
> >
> > Note that this matches the download page of the new website pretty
> > nicely.
> >
> >  - http://people.apache.org/~jross/transom/head/download.html
> >
> > There's some debate about the right names for these things.  Don't
> > take my suggestions seriously.  I just had to put something down to
> > illustrate.  If I had my druthers, we'd give the two brokers names
> > that didn't include a programming language.
> >
> > ## First steps
> >
> > This change can't happen all at once.  We propose to start with these:
> >
> >  - Isolate JMS from the existing qpid/trunk/qpid tree
> >  - Isolate the Messaging API from the existing qpid/trunk/qpid tree
> >
> > If this is agreed, the idea is to bite off this much during the 0.24
> > cycle.
> >
> > ## Developer infrastructure
> >
> > This change calls for some work to support developers using multiple
> > components in one development environment.  This needs more
> > investigation.
> >
> > ## JIRA instances
> >
> > We propose *not* to create new jira instances for each component.  We
> > can do that later on if necessary.  For now we can overload the
> > version field in the qpid jira instance to include a component name.
> >
> > ## A Qpid "distribution" of source component releases
> >
> > While this scheme supports independent releases of each source
> > component, it doesn't rule out a Qpid-wide release.  There may be
> > reason for Qpid as a whole to share a release cadence and
> > produce a new "distribution" of components each cycle.  It would all
> > be more flexible, however.  A component might want to produce three
> > revisions in the space of a standard Qpid-wide four-month cycle, or a
> > component might produce no new revisions.
> >
> > To me the advantage of producing a periodic distribution is (a)
> > coordinated testing and (b) a known distribution set for users to
> > deploy together.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message