You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Justin Ross <jr...@apache.org> on 2013/01/21 18:17:43 UTC
Proposal to adjust our source tree layout
Qpid has undergone some important changes in the last year. "What
Qpid is" has shifted. In particular, the introduction of Proton is
important because it means that Qpid is not just (mainly) the stuff
under repos/asf/qpid/trunk/qpid anymore.
One point of confusion (and certainly not the only! more emails to
follow) is the source tree. Here's what we have now:
jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/
branches/
doap_qpid.rdf
proton/
site/
tags/
trunk/
Some of those things are alike, and some are not. Since the
introduction of "proton" and "site" at this level, we've begun to mix
the long-existing qpid/$language model with the new one that has
distinct and independently releasable modules.
The first step I propose to clean things up is pretty simple. Take
qpid/{branches,tags,trunk} and move them under a name, just as proton
is organized.
In other words, move to this:
qpid/
doap_qpid.rdf
site/
proton/
trunk/
branches/
tags/
trident/ - qpid as we have known it
trunk/
branches/
tags/
Queue naming debate, ;). I chose "trident" for my illustration
because I like how it sounds. I would also take this opportunity
eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
After that step, I see it evolving over time as in the following example:
qpid/
doap_qpid.rdf
site/
proton/
triton/
---
jms/ - a new jms implementation powered by proton
janet/ - a new home for the java tree, migrated from triton/trunk/java
casper/ - a new home for the cpp tree, migrated from triton/trunk/cpp
This is merely an illustration of what I would consider correct under
this new scheme. I've included the last two to show how I think we
might begin to move things out of triton (which is more or less the
old qpid model as is) and into new top-level modules.
The names under qpid/ should not in my opinion be brands unto
themselves; "Qpid" is our brand, and Qpid has named components. They
are simply distinct modules with defined interfaces and dependencies.
They *can* be released independently, and in some cases we would have
reason to do so, but in general I think creating one release
distribution is preferable.
Thanks!
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal to adjust our source tree layout
Posted by Rob Godfrey <ro...@gmail.com>.
On 22 January 2013 14:11, Justin Ross <ju...@gmail.com> wrote:
> This isn't even a first draft, but to show good faith, I am working on
> this:
>
> http://people.apache.org/~jross/transom/output/
>
> I'll have a better draft and a more proper introduction later, with an
> outline of what Qpid's components are and how they fit together.
>
>
Thanks Justin - much appreciated! I think we should probably try to come
up with some blurb on AMQP as well as simply pointing to the AMQP site.
To me Apache Qpid should be all about AMQP (in particular about AMQP 1.0).
> In my opinion, we are underestimating the significance of things such
> as source tree layout, mailing list names, and such. They are not
> merely internal details. When I go to understand a project, those are
> precisely the things I look at. I think leaving Qpid in a confused
> state, such as the state it is in right now, is not really worth
> tolerating.
>
>
I agree they are important, just that the cost vs. benefit of trying to
change the directory structure of the existing components right now does
not add up for me. For all new components then I think we should have a
template of how those are added and agreement on what a sensible source
code directory structure looks like / what our requirements of such are.
I'm also open to the idea of trying to migrate our existing components into
such a structure, however my knowledge of the Java build is such that I
wouldn't expect any such work to be quick or easy... Simply moving the
entire java build tree up to be a peer of the proton component doesn't seem
like it would help our users any more than our current structure.
Personally as a user, if there are clearly available source / binary
tarballs for downloading with good documentation as to what they contain,
then I would choose those over checking out the repo.
There's probably a stronger case for changing the mailing lists in that the
cost of change is probably low. I just feel its potentially getting a bit
bike-sheddy when our main problem is that the content is not there (i.e.
the problem is not that the question about "what is proton vs. qpid" was
asked on different lists, it's that the answer isn't clear from the
website).
In other words, that confusion has a significant opportunity cost.
> Facing confusion, many people will turn away. Sometimes opportunity
> costs are hard to measure. My sense (and I admit this is intuition)
> is that in this case, the cost is more than you might think.
>
>
Agreed - personally my feeling is that if we have cycles which we can use
to improve the "stickiness" of Qpid, then those cycles should be spent on
generating content for the website and keeping the website up to date.
Further it would be nice if we actually had things like a roadmap that
were clearly visible to people interested in the project. Again such
things need to be kept up to date by the project team.
In an ideal world I think the directory structure in your head and in my
head are probably pretty much the same - but (at least on the Java side) it
would take a lot of pain to get there, and I think our limited energies
would be better spent on producing AMQP 1.0 libraries and services and
updating our website so that people know about our good work and can then
download it :)
-- Rob
> Justin
>
> On Tue, Jan 22, 2013 at 5:57 AM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> > I dont really see the proposed end state outlined as being full of
> > equivalent things. Site gets a top level dir because its effectively a
> sub
> > project, and burying it within any other sub folder would seem a little
> > strange. Proton gets a top level dir because it is a sub-project with its
> > own release cycle. The same isnt true of the other pre-existing bits, and
> > until we decide that thigns like jms clients and caspers have their own
> > indepenant release cycles I dont think I would structure the repository
> in
> > such a way that so strictly segregated their development in the way that
> > having independant trunks for each component does.
> >
> > Having a look around, there are other projects with structures somewhat
> > similar to our own, where the main project has the trunk etc at the top
> > level along with any sub-projects and their site. Of the others, one
> > example would be the Maven project whereby they have maven1, maven2, and
> > maven3 dirs (with trunk, branches, etc) directly under the maven parent
> dir
> > plus site and other dirs as their peers. If we wanted a sub-dir, then in
> > similar fashion qpid/qpid would actually the most obvious choice for me.
> >
> > Personally, I'd leave it the way it is now and concentrate on larger
> issues
> > such as things causing user confusion, e.g improving the website and
> > communicating about things like what Proton is and where its going.
> >
> > Robbie
> >
> > On 21 January 2013 19:20, Justin Ross <ju...@gmail.com> wrote:
> >
> >> My main goal is to populate the top level with equivalent things. If
> >> we don't, then I think the source tree itself forces you to think
> >> about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.},
> >> and Qpid is qpid/{proton,$futuremodule,etc.}.
> >>
> >> The funny name is not required. The trouble is I can't think of a
> >> better approach. Can you think of a functional name that works in
> >> this role? I'm open to almost anything except qpid/qpid.
> >>
> >> Justin
> >>
> >> On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
> >> <ro...@gmail.com> wrote:
> >> > If we were going to move them down a level then I wouldnt pick what
> seems
> >> > like a fairly random new name for the folder, especially if the
> >> motiviation
> >> > is to make things clearer. Thats definitely not where names like
> >> > trident/triton take me, and I have no idea where it would take someone
> >> new
> >> > coming along looking for all the existing stuff that is as far as they
> >> are
> >> > concerned just now, what Qpid is.
> >> >
> >> > I dont have anything to suggest myself right now, but the end state
> >> example
> >> > doesnt particularly inspire me as easier to work with either,
> requiring
> >> > lots of different chekouts to stay out to date on the different
> >> components,
> >> > or alternatively a massive amount of playing with svn folder depths on
> >> > checkouts (which im not sure play nice with git-svn anyway).
> >> >
> >> > Regarding the existing extra 'inner qpid folder', we have discussed
> >> > removing it in the past and decided not to simply because it had been
> >> that
> >> > way for so long, isnt really doing any harm , and doesnt seem worth
> the
> >> > hassle for merges, breaking peoples existing checkouts etc. Its
> presence
> >> > doesnt particularly bother me either FWIW, its easy enough to ignore
> >> > (though I actually dont, I checkout 'trunk')
> >> >
> >> > Robbie
> >> >
> >> > On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
> >> >
> >> >> Qpid has undergone some important changes in the last year. "What
> >> >> Qpid is" has shifted. In particular, the introduction of Proton is
> >> >> important because it means that Qpid is not just (mainly) the stuff
> >> >> under repos/asf/qpid/trunk/qpid anymore.
> >> >>
> >> >> One point of confusion (and certainly not the only! more emails to
> >> >> follow) is the source tree. Here's what we have now:
> >> >>
> >> >> jross@localhost qpid$ svn ls
> https://svn.apache.org/repos/asf/qpid/
> >> >> branches/
> >> >> doap_qpid.rdf
> >> >> proton/
> >> >> site/
> >> >> tags/
> >> >> trunk/
> >> >>
> >> >> Some of those things are alike, and some are not. Since the
> >> >> introduction of "proton" and "site" at this level, we've begun to mix
> >> >> the long-existing qpid/$language model with the new one that has
> >> >> distinct and independently releasable modules.
> >> >>
> >> >> The first step I propose to clean things up is pretty simple. Take
> >> >> qpid/{branches,tags,trunk} and move them under a name, just as proton
> >> >> is organized.
> >> >>
> >> >> In other words, move to this:
> >> >>
> >> >> qpid/
> >> >> doap_qpid.rdf
> >> >> site/
> >> >> proton/
> >> >> trunk/
> >> >> branches/
> >> >> tags/
> >> >> trident/ - qpid as we have known it
> >> >> trunk/
> >> >> branches/
> >> >> tags/
> >> >>
> >> >> Queue naming debate, ;). I chose "trident" for my illustration
> >> >> because I like how it sounds. I would also take this opportunity
> >> >> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
> >> >>
> >> >> After that step, I see it evolving over time as in the following
> >> example:
> >> >>
> >> >> qpid/
> >> >> doap_qpid.rdf
> >> >> site/
> >> >> proton/
> >> >> triton/
> >> >> ---
> >> >> jms/ - a new jms implementation powered by proton
> >> >> janet/ - a new home for the java tree, migrated from
> >> triton/trunk/java
> >> >> casper/ - a new home for the cpp tree, migrated from
> >> triton/trunk/cpp
> >> >>
> >> >> This is merely an illustration of what I would consider correct under
> >> >> this new scheme. I've included the last two to show how I think we
> >> >> might begin to move things out of triton (which is more or less the
> >> >> old qpid model as is) and into new top-level modules.
> >> >>
> >> >> The names under qpid/ should not in my opinion be brands unto
> >> >> themselves; "Qpid" is our brand, and Qpid has named components. They
> >> >> are simply distinct modules with defined interfaces and dependencies.
> >> >> They *can* be released independently, and in some cases we would have
> >> >> reason to do so, but in general I think creating one release
> >> >> distribution is preferable.
> >> >>
> >> >> Thanks!
> >> >> Justin
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Proposal to adjust our source tree layout
Posted by Rob Godfrey <ro...@gmail.com>.
So, I'm not really sold on the benefits of moving the java and cpp trees to
the top level to be peers of proton. From a cost benefit perspective, the
cost is probably fairly low... but I'm not sure if there is any real
benefit.
As far as I can see the only positive is that we no longer have a
sub-project of Qpid in a directory called "qpid"... but now we have a
couple of sub-projects that have no logical cohesion, but do some level of
interdependency, and a history of releasing as a unit. My view is that this
simply takes us from having one messed up top level sub-project, to having
two (which actually probably still want to stick to a joint release cycle
anyway).
Rather than putting "java" at the top level, if we were wanting to do a
quick-ish and dirty-ish change in the short-ish term, then I would prefer
to move the JMS client, and Java Broker to be separate top level
components. I would suggest that the Java Broker have a dependency on the
Java Client, and the Java "Common" code live in the client (ideally I'd
want to move the shared transport code into a proper library, but that
would probably be a bigger ask).
Having said all of the above, I'd be prioritising work on the website and
work on proton above re-orging the components for the moment. On the java
side I would proably suggest altering the directory structure when we start
looking to build the new JMS client based on Proton, and integrating Proton
code into the Java Broker.
-- Rob
On 22 January 2013 21:58, Justin Ross <ju...@gmail.com> wrote:
> I think this is productive discussion! Just to be clear, I'm not bent
> out of shape about any of this. I want more and more people to get
> engaged solving it.
>
> On Tue, Jan 22, 2013 at 2:08 PM, Alan Conway <ac...@redhat.com> wrote:
> >> I think the general idea of having other libraries and services at the
> same
> >> level as proton makes a lot of sense... however given the way that the
> Java
> >> tree is constructed (I can't speak for the C++), it'd be a little hard
> to
> >> arrange right now and having a top level entry corresponding to "java"
> >> probably wouldn't help with the silo-ing which you describe below
> (moreover
> >> it really doesn't make much sense from a user perspective either).
> >>
> >> So a directory structure which had top level entries something more like
> >>
> >> ** proton
> >> ** Java broker
> >> ** C++ broker
> >> ** JMS client
> >> ** Messaging API client(s)
> >> ** AMQP proxy
> >> ** AMQP router
> >> ** Management Console
>
> I like this very much. But when I was looking at this I took a
> pragmatic turn: extricating the common dependencies is hard, so why
> not just leave the cpp and java trees as is (albeit moved up to the
> level of proton)? They're already quite independent, and there is a
> lot of "integration" invested in them as they are.
>
> So I thought, we could keep them as they are, maintain them, and
> refocus our energy on things like a new independent JMS client (on
> proton) and AMQP routers (on proton). On balance, it seems like the
> neatest way to make a break, balancing our desire to not break stuff
> with our desire to press forward with a new model.
>
> I understand the argument in favor of zero disruption. To me that's
> about timing; it's something you do only rarely. But I happen to
> think this year is the right time to set down a new pattern and come
> out with a splash.
>
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Proposal to adjust our source tree layout
Posted by Justin Ross <ju...@gmail.com>.
I think this is productive discussion! Just to be clear, I'm not bent
out of shape about any of this. I want more and more people to get
engaged solving it.
On Tue, Jan 22, 2013 at 2:08 PM, Alan Conway <ac...@redhat.com> wrote:
>> I think the general idea of having other libraries and services at the same
>> level as proton makes a lot of sense... however given the way that the Java
>> tree is constructed (I can't speak for the C++), it'd be a little hard to
>> arrange right now and having a top level entry corresponding to "java"
>> probably wouldn't help with the silo-ing which you describe below (moreover
>> it really doesn't make much sense from a user perspective either).
>>
>> So a directory structure which had top level entries something more like
>>
>> ** proton
>> ** Java broker
>> ** C++ broker
>> ** JMS client
>> ** Messaging API client(s)
>> ** AMQP proxy
>> ** AMQP router
>> ** Management Console
I like this very much. But when I was looking at this I took a
pragmatic turn: extricating the common dependencies is hard, so why
not just leave the cpp and java trees as is (albeit moved up to the
level of proton)? They're already quite independent, and there is a
lot of "integration" invested in them as they are.
So I thought, we could keep them as they are, maintain them, and
refocus our energy on things like a new independent JMS client (on
proton) and AMQP routers (on proton). On balance, it seems like the
neatest way to make a break, balancing our desire to not break stuff
with our desire to press forward with a new model.
I understand the argument in favor of zero disruption. To me that's
about timing; it's something you do only rarely. But I happen to
think this year is the right time to set down a new pattern and come
out with a splash.
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal to adjust our source tree layout
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2013-01-22 at 17:31 +0100, Rob Godfrey wrote:
> On 22 January 2013 17:12, Rafael Schloming <rh...@alum.mit.edu> wrote:
>
> > I have directly experienced some of the opportunity cost that Justin speaks
> > of. I once observed someone (a director level decision maker) being very
> > surprised to be informed that qpid is actually *two* brokers. He had ruled
> > it out as an option entirely until he found out that we actualy have a Java
> > broker that speaks multiple versions of the protocol.
>
>
>
> Yes - this is the sort of thing that I think we need to make clear from the
> starting point of the website. What components we have, what the can be
> used for, and what components we are looking to build.
>
> I think the general idea of having other libraries and services at the same
> level as proton makes a lot of sense... however given the way that the Java
> tree is constructed (I can't speak for the C++), it'd be a little hard to
> arrange right now and having a top level entry corresponding to "java"
> probably wouldn't help with the silo-ing which you describe below (moreover
> it really doesn't make much sense from a user perspective either).
>
> So a directory structure which had top level entries something more like
>
> ** proton
> ** Java broker
> ** C++ broker
> ** JMS client
> ** Messaging API client(s)
> ** AMQP proxy
> ** AMQP router
> ** Management Console
If we do the split that way (which seems reasonable) then we have to
think about where to put libraries used by more than one component. e.g.
for C++ we have libqpidcommon and libqpidtypes that are used by both the
broker and the C++ messaging API.
I can think of 2 ways to do this:
1. create extra top level directories for the common stuff.
2. Put common stuff in the "lighter" component and have the "heavier"
component depend on it (e.g. C++ broker depends on C++ messaging API).
3. duplicate the code
I'm happy with 1 or 2, not 3.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal to adjust our source tree layout
Posted by Rob Godfrey <ro...@gmail.com>.
On 22 January 2013 17:12, Rafael Schloming <rh...@alum.mit.edu> wrote:
> I have directly experienced some of the opportunity cost that Justin speaks
> of. I once observed someone (a director level decision maker) being very
> surprised to be informed that qpid is actually *two* brokers. He had ruled
> it out as an option entirely until he found out that we actualy have a Java
> broker that speaks multiple versions of the protocol.
Yes - this is the sort of thing that I think we need to make clear from the
starting point of the website. What components we have, what the can be
used for, and what components we are looking to build.
I think the general idea of having other libraries and services at the same
level as proton makes a lot of sense... however given the way that the Java
tree is constructed (I can't speak for the C++), it'd be a little hard to
arrange right now and having a top level entry corresponding to "java"
probably wouldn't help with the silo-ing which you describe below (moreover
it really doesn't make much sense from a user perspective either).
So a directory structure which had top level entries something more like
** proton
** Java broker
** C++ broker
** JMS client
** Messaging API client(s)
** AMQP proxy
** AMQP router
** Management Console
Would definitely make sense (note some entries above may not currently
exist, may not end up as distinct components, etc).
In order to get the Java side to that sort of state we'd probably first
need to sort out the "common" code which is shared between the Java (0.x)
client and the broker. Ideally we'd probably want to turn the
0-8/0-9/0-9-1 and 0-10 protocol layers into components (though they'll not
be getting much love going forward). that would still leave a fair amount
of cruft which is shared but not really AMQP protocol related. Altogether,
it would be a fair amount of work, and not something I'd necessarily want
to prioritize.
> Now while I agree
> that the source tree layout is likely not a serious impediment for
> developers, I do think it may have an impact in promoting the silo effect
> which can obviously propagate beyond developers to our detriment.
>
>
Agreed. One thing I am very keen to avoid is the categorization by language
that our current build tree suggests. Top level components should be
defined in terms of function rather than language (IMHO), though for some
(e.g. a JMS client) language may be implied. (And where a component has
multiple languages used, developers in that component should endeavour to
be familiar with the build and test process for each such language).
-- Rob
> That said, I agree the first step is to get the web site sorted and ensure
> we have a shared model of what the structure should be. I think with this
> in place and well understood, the case to change the layout to something
> more sensible will be compelling. FWIW, I think the proposed layout is
> probably very close to where we should end up, the total number of top
> level components notwithstanding.
>
> --Rafael
>
> On Tue, Jan 22, 2013 at 9:49 AM, Robbie Gemmell <robbie.gemmell@gmail.com
> >wrote:
>
> > On 22 January 2013 13:11, Justin Ross <ju...@gmail.com> wrote:
> >
> > > This isn't even a first draft, but to show good faith, I am working on
> > > this:
> > >
> > > http://people.apache.org/~jross/transom/output/
> > >
> > > I'll have a better draft and a more proper introduction later, with an
> > > outline of what Qpid's components are and how they fit together.
> > >
> > >
> > If you are looking into a new website design, now would probably be a
> good
> > time to look at the branding requirements:
> >
> > http://www.apache.org/foundation/marks/pmcs
> >
> > In my opinion, we are underestimating the significance of things such
> > > as source tree layout, mailing list names, and such. They are not
> > > merely internal details. When I go to understand a project, those are
> > > precisely the things I look at. I think leaving Qpid in a confused
> > > state, such as the state it is in right now, is not really worth
> > > tolerating.
> > >
> > >
> > As with Rob, for me it is a balance between the time taken to get
> existing
> > stuff to any new structure and what improvement that would bring versus
> > spending all that time on different things that could have a bigger
> payoff.
> >
> > Whilst I might not pick what we have now as a new starting point, the
> > layout of our source doesnt seem all that confusing to me. Qpid was the
> > first 'real project' I ever worked on, and it wasn't a problem figuring
> out
> > where stuff was. I dont recall seeing many questions on the subject
> either,
> > whereas the website and documentation (or lack therof) gather/cause many
> > and so would be more deliver more rewarding for any effort in my mind.
> >
> >
> > > In other words, that confusion has a significant opportunity cost.
> > > Facing confusion, many people will turn away. Sometimes opportunity
> > > costs are hard to measure. My sense (and I admit this is intuition)
> > > is that in this case, the cost is more than you might think.
> > >
> > > Justin
> > >
> > > On Tue, Jan 22, 2013 at 5:57 AM, Robbie Gemmell
> > > <ro...@gmail.com> wrote:
> > > > I dont really see the proposed end state outlined as being full of
> > > > equivalent things. Site gets a top level dir because its effectively
> a
> > > sub
> > > > project, and burying it within any other sub folder would seem a
> little
> > > > strange. Proton gets a top level dir because it is a sub-project with
> > its
> > > > own release cycle. The same isnt true of the other pre-existing bits,
> > and
> > > > until we decide that thigns like jms clients and caspers have their
> own
> > > > indepenant release cycles I dont think I would structure the
> repository
> > > in
> > > > such a way that so strictly segregated their development in the way
> > that
> > > > having independant trunks for each component does.
> > > >
> > > > Having a look around, there are other projects with structures
> somewhat
> > > > similar to our own, where the main project has the trunk etc at the
> top
> > > > level along with any sub-projects and their site. Of the others, one
> > > > example would be the Maven project whereby they have maven1, maven2,
> > and
> > > > maven3 dirs (with trunk, branches, etc) directly under the maven
> parent
> > > dir
> > > > plus site and other dirs as their peers. If we wanted a sub-dir, then
> > in
> > > > similar fashion qpid/qpid would actually the most obvious choice for
> > me.
> > > >
> > > > Personally, I'd leave it the way it is now and concentrate on larger
> > > issues
> > > > such as things causing user confusion, e.g improving the website and
> > > > communicating about things like what Proton is and where its going.
> > > >
> > > > Robbie
> > > >
> > > > On 21 January 2013 19:20, Justin Ross <ju...@gmail.com> wrote:
> > > >
> > > >> My main goal is to populate the top level with equivalent things.
> If
> > > >> we don't, then I think the source tree itself forces you to think
> > > >> about Qpid with two conflicting frames: Qpid is
> qpid/{cpp,java,etc.},
> > > >> and Qpid is qpid/{proton,$futuremodule,etc.}.
> > > >>
> > > >> The funny name is not required. The trouble is I can't think of a
> > > >> better approach. Can you think of a functional name that works in
> > > >> this role? I'm open to almost anything except qpid/qpid.
> > > >>
> > > >> Justin
> > > >>
> > > >> On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
> > > >> <ro...@gmail.com> wrote:
> > > >> > If we were going to move them down a level then I wouldnt pick
> what
> > > seems
> > > >> > like a fairly random new name for the folder, especially if the
> > > >> motiviation
> > > >> > is to make things clearer. Thats definitely not where names like
> > > >> > trident/triton take me, and I have no idea where it would take
> > someone
> > > >> new
> > > >> > coming along looking for all the existing stuff that is as far as
> > they
> > > >> are
> > > >> > concerned just now, what Qpid is.
> > > >> >
> > > >> > I dont have anything to suggest myself right now, but the end
> state
> > > >> example
> > > >> > doesnt particularly inspire me as easier to work with either,
> > > requiring
> > > >> > lots of different chekouts to stay out to date on the different
> > > >> components,
> > > >> > or alternatively a massive amount of playing with svn folder
> depths
> > on
> > > >> > checkouts (which im not sure play nice with git-svn anyway).
> > > >> >
> > > >> > Regarding the existing extra 'inner qpid folder', we have
> discussed
> > > >> > removing it in the past and decided not to simply because it had
> > been
> > > >> that
> > > >> > way for so long, isnt really doing any harm , and doesnt seem
> worth
> > > the
> > > >> > hassle for merges, breaking peoples existing checkouts etc. Its
> > > presence
> > > >> > doesnt particularly bother me either FWIW, its easy enough to
> ignore
> > > >> > (though I actually dont, I checkout 'trunk')
> > > >> >
> > > >> > Robbie
> > > >> >
> > > >> > On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
> > > >> >
> > > >> >> Qpid has undergone some important changes in the last year.
> "What
> > > >> >> Qpid is" has shifted. In particular, the introduction of Proton
> is
> > > >> >> important because it means that Qpid is not just (mainly) the
> stuff
> > > >> >> under repos/asf/qpid/trunk/qpid anymore.
> > > >> >>
> > > >> >> One point of confusion (and certainly not the only! more emails
> to
> > > >> >> follow) is the source tree. Here's what we have now:
> > > >> >>
> > > >> >> jross@localhost qpid$ svn ls
> > > https://svn.apache.org/repos/asf/qpid/
> > > >> >> branches/
> > > >> >> doap_qpid.rdf
> > > >> >> proton/
> > > >> >> site/
> > > >> >> tags/
> > > >> >> trunk/
> > > >> >>
> > > >> >> Some of those things are alike, and some are not. Since the
> > > >> >> introduction of "proton" and "site" at this level, we've begun to
> > mix
> > > >> >> the long-existing qpid/$language model with the new one that has
> > > >> >> distinct and independently releasable modules.
> > > >> >>
> > > >> >> The first step I propose to clean things up is pretty simple.
> Take
> > > >> >> qpid/{branches,tags,trunk} and move them under a name, just as
> > proton
> > > >> >> is organized.
> > > >> >>
> > > >> >> In other words, move to this:
> > > >> >>
> > > >> >> qpid/
> > > >> >> doap_qpid.rdf
> > > >> >> site/
> > > >> >> proton/
> > > >> >> trunk/
> > > >> >> branches/
> > > >> >> tags/
> > > >> >> trident/ - qpid as we have known it
> > > >> >> trunk/
> > > >> >> branches/
> > > >> >> tags/
> > > >> >>
> > > >> >> Queue naming debate, ;). I chose "trident" for my illustration
> > > >> >> because I like how it sounds. I would also take this opportunity
> > > >> >> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
> > > >> >>
> > > >> >> After that step, I see it evolving over time as in the following
> > > >> example:
> > > >> >>
> > > >> >> qpid/
> > > >> >> doap_qpid.rdf
> > > >> >> site/
> > > >> >> proton/
> > > >> >> triton/
> > > >> >> ---
> > > >> >> jms/ - a new jms implementation powered by proton
> > > >> >> janet/ - a new home for the java tree, migrated from
> > > >> triton/trunk/java
> > > >> >> casper/ - a new home for the cpp tree, migrated from
> > > >> triton/trunk/cpp
> > > >> >>
> > > >> >> This is merely an illustration of what I would consider correct
> > under
> > > >> >> this new scheme. I've included the last two to show how I think
> we
> > > >> >> might begin to move things out of triton (which is more or less
> the
> > > >> >> old qpid model as is) and into new top-level modules.
> > > >> >>
> > > >> >> The names under qpid/ should not in my opinion be brands unto
> > > >> >> themselves; "Qpid" is our brand, and Qpid has named components.
> > They
> > > >> >> are simply distinct modules with defined interfaces and
> > dependencies.
> > > >> >> They *can* be released independently, and in some cases we would
> > have
> > > >> >> reason to do so, but in general I think creating one release
> > > >> >> distribution is preferable.
> > > >> >>
> > > >> >> Thanks!
> > > >> >> Justin
> > > >> >>
> > > >> >>
> > ---------------------------------------------------------------------
> > > >> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > > >> >> For additional commands, e-mail: dev-help@qpid.apache.org
> > > >> >>
> > > >> >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > > >> For additional commands, e-mail: dev-help@qpid.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: dev-help@qpid.apache.org
> > >
> > >
> >
>
Re: Proposal to adjust our source tree layout
Posted by Rafael Schloming <rh...@alum.mit.edu>.
I have directly experienced some of the opportunity cost that Justin speaks
of. I once observed someone (a director level decision maker) being very
surprised to be informed that qpid is actually *two* brokers. He had ruled
it out as an option entirely until he found out that we actualy have a Java
broker that speaks multiple versions of the protocol. Now while I agree
that the source tree layout is likely not a serious impediment for
developers, I do think it may have an impact in promoting the silo effect
which can obviously propagate beyond developers to our detriment.
That said, I agree the first step is to get the web site sorted and ensure
we have a shared model of what the structure should be. I think with this
in place and well understood, the case to change the layout to something
more sensible will be compelling. FWIW, I think the proposed layout is
probably very close to where we should end up, the total number of top
level components notwithstanding.
--Rafael
On Tue, Jan 22, 2013 at 9:49 AM, Robbie Gemmell <ro...@gmail.com>wrote:
> On 22 January 2013 13:11, Justin Ross <ju...@gmail.com> wrote:
>
> > This isn't even a first draft, but to show good faith, I am working on
> > this:
> >
> > http://people.apache.org/~jross/transom/output/
> >
> > I'll have a better draft and a more proper introduction later, with an
> > outline of what Qpid's components are and how they fit together.
> >
> >
> If you are looking into a new website design, now would probably be a good
> time to look at the branding requirements:
>
> http://www.apache.org/foundation/marks/pmcs
>
> In my opinion, we are underestimating the significance of things such
> > as source tree layout, mailing list names, and such. They are not
> > merely internal details. When I go to understand a project, those are
> > precisely the things I look at. I think leaving Qpid in a confused
> > state, such as the state it is in right now, is not really worth
> > tolerating.
> >
> >
> As with Rob, for me it is a balance between the time taken to get existing
> stuff to any new structure and what improvement that would bring versus
> spending all that time on different things that could have a bigger payoff.
>
> Whilst I might not pick what we have now as a new starting point, the
> layout of our source doesnt seem all that confusing to me. Qpid was the
> first 'real project' I ever worked on, and it wasn't a problem figuring out
> where stuff was. I dont recall seeing many questions on the subject either,
> whereas the website and documentation (or lack therof) gather/cause many
> and so would be more deliver more rewarding for any effort in my mind.
>
>
> > In other words, that confusion has a significant opportunity cost.
> > Facing confusion, many people will turn away. Sometimes opportunity
> > costs are hard to measure. My sense (and I admit this is intuition)
> > is that in this case, the cost is more than you might think.
> >
> > Justin
> >
> > On Tue, Jan 22, 2013 at 5:57 AM, Robbie Gemmell
> > <ro...@gmail.com> wrote:
> > > I dont really see the proposed end state outlined as being full of
> > > equivalent things. Site gets a top level dir because its effectively a
> > sub
> > > project, and burying it within any other sub folder would seem a little
> > > strange. Proton gets a top level dir because it is a sub-project with
> its
> > > own release cycle. The same isnt true of the other pre-existing bits,
> and
> > > until we decide that thigns like jms clients and caspers have their own
> > > indepenant release cycles I dont think I would structure the repository
> > in
> > > such a way that so strictly segregated their development in the way
> that
> > > having independant trunks for each component does.
> > >
> > > Having a look around, there are other projects with structures somewhat
> > > similar to our own, where the main project has the trunk etc at the top
> > > level along with any sub-projects and their site. Of the others, one
> > > example would be the Maven project whereby they have maven1, maven2,
> and
> > > maven3 dirs (with trunk, branches, etc) directly under the maven parent
> > dir
> > > plus site and other dirs as their peers. If we wanted a sub-dir, then
> in
> > > similar fashion qpid/qpid would actually the most obvious choice for
> me.
> > >
> > > Personally, I'd leave it the way it is now and concentrate on larger
> > issues
> > > such as things causing user confusion, e.g improving the website and
> > > communicating about things like what Proton is and where its going.
> > >
> > > Robbie
> > >
> > > On 21 January 2013 19:20, Justin Ross <ju...@gmail.com> wrote:
> > >
> > >> My main goal is to populate the top level with equivalent things. If
> > >> we don't, then I think the source tree itself forces you to think
> > >> about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.},
> > >> and Qpid is qpid/{proton,$futuremodule,etc.}.
> > >>
> > >> The funny name is not required. The trouble is I can't think of a
> > >> better approach. Can you think of a functional name that works in
> > >> this role? I'm open to almost anything except qpid/qpid.
> > >>
> > >> Justin
> > >>
> > >> On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
> > >> <ro...@gmail.com> wrote:
> > >> > If we were going to move them down a level then I wouldnt pick what
> > seems
> > >> > like a fairly random new name for the folder, especially if the
> > >> motiviation
> > >> > is to make things clearer. Thats definitely not where names like
> > >> > trident/triton take me, and I have no idea where it would take
> someone
> > >> new
> > >> > coming along looking for all the existing stuff that is as far as
> they
> > >> are
> > >> > concerned just now, what Qpid is.
> > >> >
> > >> > I dont have anything to suggest myself right now, but the end state
> > >> example
> > >> > doesnt particularly inspire me as easier to work with either,
> > requiring
> > >> > lots of different chekouts to stay out to date on the different
> > >> components,
> > >> > or alternatively a massive amount of playing with svn folder depths
> on
> > >> > checkouts (which im not sure play nice with git-svn anyway).
> > >> >
> > >> > Regarding the existing extra 'inner qpid folder', we have discussed
> > >> > removing it in the past and decided not to simply because it had
> been
> > >> that
> > >> > way for so long, isnt really doing any harm , and doesnt seem worth
> > the
> > >> > hassle for merges, breaking peoples existing checkouts etc. Its
> > presence
> > >> > doesnt particularly bother me either FWIW, its easy enough to ignore
> > >> > (though I actually dont, I checkout 'trunk')
> > >> >
> > >> > Robbie
> > >> >
> > >> > On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
> > >> >
> > >> >> Qpid has undergone some important changes in the last year. "What
> > >> >> Qpid is" has shifted. In particular, the introduction of Proton is
> > >> >> important because it means that Qpid is not just (mainly) the stuff
> > >> >> under repos/asf/qpid/trunk/qpid anymore.
> > >> >>
> > >> >> One point of confusion (and certainly not the only! more emails to
> > >> >> follow) is the source tree. Here's what we have now:
> > >> >>
> > >> >> jross@localhost qpid$ svn ls
> > https://svn.apache.org/repos/asf/qpid/
> > >> >> branches/
> > >> >> doap_qpid.rdf
> > >> >> proton/
> > >> >> site/
> > >> >> tags/
> > >> >> trunk/
> > >> >>
> > >> >> Some of those things are alike, and some are not. Since the
> > >> >> introduction of "proton" and "site" at this level, we've begun to
> mix
> > >> >> the long-existing qpid/$language model with the new one that has
> > >> >> distinct and independently releasable modules.
> > >> >>
> > >> >> The first step I propose to clean things up is pretty simple. Take
> > >> >> qpid/{branches,tags,trunk} and move them under a name, just as
> proton
> > >> >> is organized.
> > >> >>
> > >> >> In other words, move to this:
> > >> >>
> > >> >> qpid/
> > >> >> doap_qpid.rdf
> > >> >> site/
> > >> >> proton/
> > >> >> trunk/
> > >> >> branches/
> > >> >> tags/
> > >> >> trident/ - qpid as we have known it
> > >> >> trunk/
> > >> >> branches/
> > >> >> tags/
> > >> >>
> > >> >> Queue naming debate, ;). I chose "trident" for my illustration
> > >> >> because I like how it sounds. I would also take this opportunity
> > >> >> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
> > >> >>
> > >> >> After that step, I see it evolving over time as in the following
> > >> example:
> > >> >>
> > >> >> qpid/
> > >> >> doap_qpid.rdf
> > >> >> site/
> > >> >> proton/
> > >> >> triton/
> > >> >> ---
> > >> >> jms/ - a new jms implementation powered by proton
> > >> >> janet/ - a new home for the java tree, migrated from
> > >> triton/trunk/java
> > >> >> casper/ - a new home for the cpp tree, migrated from
> > >> triton/trunk/cpp
> > >> >>
> > >> >> This is merely an illustration of what I would consider correct
> under
> > >> >> this new scheme. I've included the last two to show how I think we
> > >> >> might begin to move things out of triton (which is more or less the
> > >> >> old qpid model as is) and into new top-level modules.
> > >> >>
> > >> >> The names under qpid/ should not in my opinion be brands unto
> > >> >> themselves; "Qpid" is our brand, and Qpid has named components.
> They
> > >> >> are simply distinct modules with defined interfaces and
> dependencies.
> > >> >> They *can* be released independently, and in some cases we would
> have
> > >> >> reason to do so, but in general I think creating one release
> > >> >> distribution is preferable.
> > >> >>
> > >> >> Thanks!
> > >> >> Justin
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > >> >> For additional commands, e-mail: dev-help@qpid.apache.org
> > >> >>
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > >> For additional commands, e-mail: dev-help@qpid.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
Re: Proposal to adjust our source tree layout
Posted by Robbie Gemmell <ro...@gmail.com>.
On 22 January 2013 13:11, Justin Ross <ju...@gmail.com> wrote:
> This isn't even a first draft, but to show good faith, I am working on
> this:
>
> http://people.apache.org/~jross/transom/output/
>
> I'll have a better draft and a more proper introduction later, with an
> outline of what Qpid's components are and how they fit together.
>
>
If you are looking into a new website design, now would probably be a good
time to look at the branding requirements:
http://www.apache.org/foundation/marks/pmcs
In my opinion, we are underestimating the significance of things such
> as source tree layout, mailing list names, and such. They are not
> merely internal details. When I go to understand a project, those are
> precisely the things I look at. I think leaving Qpid in a confused
> state, such as the state it is in right now, is not really worth
> tolerating.
>
>
As with Rob, for me it is a balance between the time taken to get existing
stuff to any new structure and what improvement that would bring versus
spending all that time on different things that could have a bigger payoff.
Whilst I might not pick what we have now as a new starting point, the
layout of our source doesnt seem all that confusing to me. Qpid was the
first 'real project' I ever worked on, and it wasn't a problem figuring out
where stuff was. I dont recall seeing many questions on the subject either,
whereas the website and documentation (or lack therof) gather/cause many
and so would be more deliver more rewarding for any effort in my mind.
> In other words, that confusion has a significant opportunity cost.
> Facing confusion, many people will turn away. Sometimes opportunity
> costs are hard to measure. My sense (and I admit this is intuition)
> is that in this case, the cost is more than you might think.
>
> Justin
>
> On Tue, Jan 22, 2013 at 5:57 AM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> > I dont really see the proposed end state outlined as being full of
> > equivalent things. Site gets a top level dir because its effectively a
> sub
> > project, and burying it within any other sub folder would seem a little
> > strange. Proton gets a top level dir because it is a sub-project with its
> > own release cycle. The same isnt true of the other pre-existing bits, and
> > until we decide that thigns like jms clients and caspers have their own
> > indepenant release cycles I dont think I would structure the repository
> in
> > such a way that so strictly segregated their development in the way that
> > having independant trunks for each component does.
> >
> > Having a look around, there are other projects with structures somewhat
> > similar to our own, where the main project has the trunk etc at the top
> > level along with any sub-projects and their site. Of the others, one
> > example would be the Maven project whereby they have maven1, maven2, and
> > maven3 dirs (with trunk, branches, etc) directly under the maven parent
> dir
> > plus site and other dirs as their peers. If we wanted a sub-dir, then in
> > similar fashion qpid/qpid would actually the most obvious choice for me.
> >
> > Personally, I'd leave it the way it is now and concentrate on larger
> issues
> > such as things causing user confusion, e.g improving the website and
> > communicating about things like what Proton is and where its going.
> >
> > Robbie
> >
> > On 21 January 2013 19:20, Justin Ross <ju...@gmail.com> wrote:
> >
> >> My main goal is to populate the top level with equivalent things. If
> >> we don't, then I think the source tree itself forces you to think
> >> about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.},
> >> and Qpid is qpid/{proton,$futuremodule,etc.}.
> >>
> >> The funny name is not required. The trouble is I can't think of a
> >> better approach. Can you think of a functional name that works in
> >> this role? I'm open to almost anything except qpid/qpid.
> >>
> >> Justin
> >>
> >> On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
> >> <ro...@gmail.com> wrote:
> >> > If we were going to move them down a level then I wouldnt pick what
> seems
> >> > like a fairly random new name for the folder, especially if the
> >> motiviation
> >> > is to make things clearer. Thats definitely not where names like
> >> > trident/triton take me, and I have no idea where it would take someone
> >> new
> >> > coming along looking for all the existing stuff that is as far as they
> >> are
> >> > concerned just now, what Qpid is.
> >> >
> >> > I dont have anything to suggest myself right now, but the end state
> >> example
> >> > doesnt particularly inspire me as easier to work with either,
> requiring
> >> > lots of different chekouts to stay out to date on the different
> >> components,
> >> > or alternatively a massive amount of playing with svn folder depths on
> >> > checkouts (which im not sure play nice with git-svn anyway).
> >> >
> >> > Regarding the existing extra 'inner qpid folder', we have discussed
> >> > removing it in the past and decided not to simply because it had been
> >> that
> >> > way for so long, isnt really doing any harm , and doesnt seem worth
> the
> >> > hassle for merges, breaking peoples existing checkouts etc. Its
> presence
> >> > doesnt particularly bother me either FWIW, its easy enough to ignore
> >> > (though I actually dont, I checkout 'trunk')
> >> >
> >> > Robbie
> >> >
> >> > On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
> >> >
> >> >> Qpid has undergone some important changes in the last year. "What
> >> >> Qpid is" has shifted. In particular, the introduction of Proton is
> >> >> important because it means that Qpid is not just (mainly) the stuff
> >> >> under repos/asf/qpid/trunk/qpid anymore.
> >> >>
> >> >> One point of confusion (and certainly not the only! more emails to
> >> >> follow) is the source tree. Here's what we have now:
> >> >>
> >> >> jross@localhost qpid$ svn ls
> https://svn.apache.org/repos/asf/qpid/
> >> >> branches/
> >> >> doap_qpid.rdf
> >> >> proton/
> >> >> site/
> >> >> tags/
> >> >> trunk/
> >> >>
> >> >> Some of those things are alike, and some are not. Since the
> >> >> introduction of "proton" and "site" at this level, we've begun to mix
> >> >> the long-existing qpid/$language model with the new one that has
> >> >> distinct and independently releasable modules.
> >> >>
> >> >> The first step I propose to clean things up is pretty simple. Take
> >> >> qpid/{branches,tags,trunk} and move them under a name, just as proton
> >> >> is organized.
> >> >>
> >> >> In other words, move to this:
> >> >>
> >> >> qpid/
> >> >> doap_qpid.rdf
> >> >> site/
> >> >> proton/
> >> >> trunk/
> >> >> branches/
> >> >> tags/
> >> >> trident/ - qpid as we have known it
> >> >> trunk/
> >> >> branches/
> >> >> tags/
> >> >>
> >> >> Queue naming debate, ;). I chose "trident" for my illustration
> >> >> because I like how it sounds. I would also take this opportunity
> >> >> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
> >> >>
> >> >> After that step, I see it evolving over time as in the following
> >> example:
> >> >>
> >> >> qpid/
> >> >> doap_qpid.rdf
> >> >> site/
> >> >> proton/
> >> >> triton/
> >> >> ---
> >> >> jms/ - a new jms implementation powered by proton
> >> >> janet/ - a new home for the java tree, migrated from
> >> triton/trunk/java
> >> >> casper/ - a new home for the cpp tree, migrated from
> >> triton/trunk/cpp
> >> >>
> >> >> This is merely an illustration of what I would consider correct under
> >> >> this new scheme. I've included the last two to show how I think we
> >> >> might begin to move things out of triton (which is more or less the
> >> >> old qpid model as is) and into new top-level modules.
> >> >>
> >> >> The names under qpid/ should not in my opinion be brands unto
> >> >> themselves; "Qpid" is our brand, and Qpid has named components. They
> >> >> are simply distinct modules with defined interfaces and dependencies.
> >> >> They *can* be released independently, and in some cases we would have
> >> >> reason to do so, but in general I think creating one release
> >> >> distribution is preferable.
> >> >>
> >> >> Thanks!
> >> >> Justin
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Proposal to adjust our source tree layout
Posted by Justin Ross <ju...@gmail.com>.
This isn't even a first draft, but to show good faith, I am working on this:
http://people.apache.org/~jross/transom/output/
I'll have a better draft and a more proper introduction later, with an
outline of what Qpid's components are and how they fit together.
In my opinion, we are underestimating the significance of things such
as source tree layout, mailing list names, and such. They are not
merely internal details. When I go to understand a project, those are
precisely the things I look at. I think leaving Qpid in a confused
state, such as the state it is in right now, is not really worth
tolerating.
In other words, that confusion has a significant opportunity cost.
Facing confusion, many people will turn away. Sometimes opportunity
costs are hard to measure. My sense (and I admit this is intuition)
is that in this case, the cost is more than you might think.
Justin
On Tue, Jan 22, 2013 at 5:57 AM, Robbie Gemmell
<ro...@gmail.com> wrote:
> I dont really see the proposed end state outlined as being full of
> equivalent things. Site gets a top level dir because its effectively a sub
> project, and burying it within any other sub folder would seem a little
> strange. Proton gets a top level dir because it is a sub-project with its
> own release cycle. The same isnt true of the other pre-existing bits, and
> until we decide that thigns like jms clients and caspers have their own
> indepenant release cycles I dont think I would structure the repository in
> such a way that so strictly segregated their development in the way that
> having independant trunks for each component does.
>
> Having a look around, there are other projects with structures somewhat
> similar to our own, where the main project has the trunk etc at the top
> level along with any sub-projects and their site. Of the others, one
> example would be the Maven project whereby they have maven1, maven2, and
> maven3 dirs (with trunk, branches, etc) directly under the maven parent dir
> plus site and other dirs as their peers. If we wanted a sub-dir, then in
> similar fashion qpid/qpid would actually the most obvious choice for me.
>
> Personally, I'd leave it the way it is now and concentrate on larger issues
> such as things causing user confusion, e.g improving the website and
> communicating about things like what Proton is and where its going.
>
> Robbie
>
> On 21 January 2013 19:20, Justin Ross <ju...@gmail.com> wrote:
>
>> My main goal is to populate the top level with equivalent things. If
>> we don't, then I think the source tree itself forces you to think
>> about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.},
>> and Qpid is qpid/{proton,$futuremodule,etc.}.
>>
>> The funny name is not required. The trouble is I can't think of a
>> better approach. Can you think of a functional name that works in
>> this role? I'm open to almost anything except qpid/qpid.
>>
>> Justin
>>
>> On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
>> <ro...@gmail.com> wrote:
>> > If we were going to move them down a level then I wouldnt pick what seems
>> > like a fairly random new name for the folder, especially if the
>> motiviation
>> > is to make things clearer. Thats definitely not where names like
>> > trident/triton take me, and I have no idea where it would take someone
>> new
>> > coming along looking for all the existing stuff that is as far as they
>> are
>> > concerned just now, what Qpid is.
>> >
>> > I dont have anything to suggest myself right now, but the end state
>> example
>> > doesnt particularly inspire me as easier to work with either, requiring
>> > lots of different chekouts to stay out to date on the different
>> components,
>> > or alternatively a massive amount of playing with svn folder depths on
>> > checkouts (which im not sure play nice with git-svn anyway).
>> >
>> > Regarding the existing extra 'inner qpid folder', we have discussed
>> > removing it in the past and decided not to simply because it had been
>> that
>> > way for so long, isnt really doing any harm , and doesnt seem worth the
>> > hassle for merges, breaking peoples existing checkouts etc. Its presence
>> > doesnt particularly bother me either FWIW, its easy enough to ignore
>> > (though I actually dont, I checkout 'trunk')
>> >
>> > Robbie
>> >
>> > On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
>> >
>> >> Qpid has undergone some important changes in the last year. "What
>> >> Qpid is" has shifted. In particular, the introduction of Proton is
>> >> important because it means that Qpid is not just (mainly) the stuff
>> >> under repos/asf/qpid/trunk/qpid anymore.
>> >>
>> >> One point of confusion (and certainly not the only! more emails to
>> >> follow) is the source tree. Here's what we have now:
>> >>
>> >> jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/
>> >> branches/
>> >> doap_qpid.rdf
>> >> proton/
>> >> site/
>> >> tags/
>> >> trunk/
>> >>
>> >> Some of those things are alike, and some are not. Since the
>> >> introduction of "proton" and "site" at this level, we've begun to mix
>> >> the long-existing qpid/$language model with the new one that has
>> >> distinct and independently releasable modules.
>> >>
>> >> The first step I propose to clean things up is pretty simple. Take
>> >> qpid/{branches,tags,trunk} and move them under a name, just as proton
>> >> is organized.
>> >>
>> >> In other words, move to this:
>> >>
>> >> qpid/
>> >> doap_qpid.rdf
>> >> site/
>> >> proton/
>> >> trunk/
>> >> branches/
>> >> tags/
>> >> trident/ - qpid as we have known it
>> >> trunk/
>> >> branches/
>> >> tags/
>> >>
>> >> Queue naming debate, ;). I chose "trident" for my illustration
>> >> because I like how it sounds. I would also take this opportunity
>> >> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
>> >>
>> >> After that step, I see it evolving over time as in the following
>> example:
>> >>
>> >> qpid/
>> >> doap_qpid.rdf
>> >> site/
>> >> proton/
>> >> triton/
>> >> ---
>> >> jms/ - a new jms implementation powered by proton
>> >> janet/ - a new home for the java tree, migrated from
>> triton/trunk/java
>> >> casper/ - a new home for the cpp tree, migrated from
>> triton/trunk/cpp
>> >>
>> >> This is merely an illustration of what I would consider correct under
>> >> this new scheme. I've included the last two to show how I think we
>> >> might begin to move things out of triton (which is more or less the
>> >> old qpid model as is) and into new top-level modules.
>> >>
>> >> The names under qpid/ should not in my opinion be brands unto
>> >> themselves; "Qpid" is our brand, and Qpid has named components. They
>> >> are simply distinct modules with defined interfaces and dependencies.
>> >> They *can* be released independently, and in some cases we would have
>> >> reason to do so, but in general I think creating one release
>> >> distribution is preferable.
>> >>
>> >> Thanks!
>> >> Justin
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: dev-help@qpid.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal to adjust our source tree layout
Posted by Robbie Gemmell <ro...@gmail.com>.
I dont really see the proposed end state outlined as being full of
equivalent things. Site gets a top level dir because its effectively a sub
project, and burying it within any other sub folder would seem a little
strange. Proton gets a top level dir because it is a sub-project with its
own release cycle. The same isnt true of the other pre-existing bits, and
until we decide that thigns like jms clients and caspers have their own
indepenant release cycles I dont think I would structure the repository in
such a way that so strictly segregated their development in the way that
having independant trunks for each component does.
Having a look around, there are other projects with structures somewhat
similar to our own, where the main project has the trunk etc at the top
level along with any sub-projects and their site. Of the others, one
example would be the Maven project whereby they have maven1, maven2, and
maven3 dirs (with trunk, branches, etc) directly under the maven parent dir
plus site and other dirs as their peers. If we wanted a sub-dir, then in
similar fashion qpid/qpid would actually the most obvious choice for me.
Personally, I'd leave it the way it is now and concentrate on larger issues
such as things causing user confusion, e.g improving the website and
communicating about things like what Proton is and where its going.
Robbie
On 21 January 2013 19:20, Justin Ross <ju...@gmail.com> wrote:
> My main goal is to populate the top level with equivalent things. If
> we don't, then I think the source tree itself forces you to think
> about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.},
> and Qpid is qpid/{proton,$futuremodule,etc.}.
>
> The funny name is not required. The trouble is I can't think of a
> better approach. Can you think of a functional name that works in
> this role? I'm open to almost anything except qpid/qpid.
>
> Justin
>
> On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> > If we were going to move them down a level then I wouldnt pick what seems
> > like a fairly random new name for the folder, especially if the
> motiviation
> > is to make things clearer. Thats definitely not where names like
> > trident/triton take me, and I have no idea where it would take someone
> new
> > coming along looking for all the existing stuff that is as far as they
> are
> > concerned just now, what Qpid is.
> >
> > I dont have anything to suggest myself right now, but the end state
> example
> > doesnt particularly inspire me as easier to work with either, requiring
> > lots of different chekouts to stay out to date on the different
> components,
> > or alternatively a massive amount of playing with svn folder depths on
> > checkouts (which im not sure play nice with git-svn anyway).
> >
> > Regarding the existing extra 'inner qpid folder', we have discussed
> > removing it in the past and decided not to simply because it had been
> that
> > way for so long, isnt really doing any harm , and doesnt seem worth the
> > hassle for merges, breaking peoples existing checkouts etc. Its presence
> > doesnt particularly bother me either FWIW, its easy enough to ignore
> > (though I actually dont, I checkout 'trunk')
> >
> > Robbie
> >
> > On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
> >
> >> Qpid has undergone some important changes in the last year. "What
> >> Qpid is" has shifted. In particular, the introduction of Proton is
> >> important because it means that Qpid is not just (mainly) the stuff
> >> under repos/asf/qpid/trunk/qpid anymore.
> >>
> >> One point of confusion (and certainly not the only! more emails to
> >> follow) is the source tree. Here's what we have now:
> >>
> >> jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/
> >> branches/
> >> doap_qpid.rdf
> >> proton/
> >> site/
> >> tags/
> >> trunk/
> >>
> >> Some of those things are alike, and some are not. Since the
> >> introduction of "proton" and "site" at this level, we've begun to mix
> >> the long-existing qpid/$language model with the new one that has
> >> distinct and independently releasable modules.
> >>
> >> The first step I propose to clean things up is pretty simple. Take
> >> qpid/{branches,tags,trunk} and move them under a name, just as proton
> >> is organized.
> >>
> >> In other words, move to this:
> >>
> >> qpid/
> >> doap_qpid.rdf
> >> site/
> >> proton/
> >> trunk/
> >> branches/
> >> tags/
> >> trident/ - qpid as we have known it
> >> trunk/
> >> branches/
> >> tags/
> >>
> >> Queue naming debate, ;). I chose "trident" for my illustration
> >> because I like how it sounds. I would also take this opportunity
> >> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
> >>
> >> After that step, I see it evolving over time as in the following
> example:
> >>
> >> qpid/
> >> doap_qpid.rdf
> >> site/
> >> proton/
> >> triton/
> >> ---
> >> jms/ - a new jms implementation powered by proton
> >> janet/ - a new home for the java tree, migrated from
> triton/trunk/java
> >> casper/ - a new home for the cpp tree, migrated from
> triton/trunk/cpp
> >>
> >> This is merely an illustration of what I would consider correct under
> >> this new scheme. I've included the last two to show how I think we
> >> might begin to move things out of triton (which is more or less the
> >> old qpid model as is) and into new top-level modules.
> >>
> >> The names under qpid/ should not in my opinion be brands unto
> >> themselves; "Qpid" is our brand, and Qpid has named components. They
> >> are simply distinct modules with defined interfaces and dependencies.
> >> They *can* be released independently, and in some cases we would have
> >> reason to do so, but in general I think creating one release
> >> distribution is preferable.
> >>
> >> Thanks!
> >> Justin
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Proposal to adjust our source tree layout
Posted by Phil Harvey <ph...@philharveyonline.com>.
On 22 January 2013 09:55, Rob Godfrey <ro...@gmail.com> wrote:
> On 21 January 2013 20:20, Justin Ross <ju...@gmail.com> wrote:
>
> > My main goal is to populate the top level with equivalent things. If
> > we don't, then I think the source tree itself forces you to think
> > about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.},
> > and Qpid is qpid/{proton,$futuremodule,etc.}.
> >
> > The funny name is not required. The trouble is I can't think of a
> > better approach. Can you think of a functional name that works in
> > this role? I'm open to almost anything except qpid/qpid.
> >
> >
>
> While I think we could probably spend some time thinking about the desired
> end-state of our source tree (and should think about how we can move things
> such as the Java and C++ Brokers to become peers of Proton in said tree),
> I'm not sure changing these will fundamentally solve the communication
> issues around how the components of the project fit together. I think it
> more important to review our website and our release artefacts.
>
> While the source tree is undoubtedly a mess, it will mostly affect
> ourselves as developers on Qpid. Hopefully we should be aware of the fact
> that Proton is a sub-project of Qpid, and the fact that the other
> "sub-projects" currently have a really poor directory structure is just an
> accident of history.
>
> In order to communicate better how Proton and other components make up the
> Qpid project I think we need to take a good hard look at how we present
> ourselves through the website, our documentation, and in our mailing lists.
>
> If we are to be discussing source code directory structure I would like us
> to actually agree (and document) what our fundamental requirements are,
> particularly given the ongoing discussion [1] on the proton mailing list on
> how we cope with interdependency between different (cross language)
> sub-components within proton itself. Other points of view / suggestions in
> that discussion would be most welcome.
>
Regarding that thread, I've just created a wiki page listing some of the
build system / directory layout requirements that have been mooted:
https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+requirements
These potential requirements may apply to the broader Qpid project, so any
opinions would be very welcome.
Phil
> -- Rob
>
> [1]
> http://mail-archives.apache.org/mod_mbox/qpid-proton/201301.mbox/browser
>
>
> > Justin
> >
> > On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
> > <ro...@gmail.com> wrote:
> > > If we were going to move them down a level then I wouldnt pick what
> seems
> > > like a fairly random new name for the folder, especially if the
> > motiviation
> > > is to make things clearer. Thats definitely not where names like
> > > trident/triton take me, and I have no idea where it would take someone
> > new
> > > coming along looking for all the existing stuff that is as far as they
> > are
> > > concerned just now, what Qpid is.
> > >
> > > I dont have anything to suggest myself right now, but the end state
> > example
> > > doesnt particularly inspire me as easier to work with either, requiring
> > > lots of different chekouts to stay out to date on the different
> > components,
> > > or alternatively a massive amount of playing with svn folder depths on
> > > checkouts (which im not sure play nice with git-svn anyway).
> > >
> > > Regarding the existing extra 'inner qpid folder', we have discussed
> > > removing it in the past and decided not to simply because it had been
> > that
> > > way for so long, isnt really doing any harm , and doesnt seem worth the
> > > hassle for merges, breaking peoples existing checkouts etc. Its
> presence
> > > doesnt particularly bother me either FWIW, its easy enough to ignore
> > > (though I actually dont, I checkout 'trunk')
> > >
> > > Robbie
> > >
> > > On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
> > >
> > >> Qpid has undergone some important changes in the last year. "What
> > >> Qpid is" has shifted. In particular, the introduction of Proton is
> > >> important because it means that Qpid is not just (mainly) the stuff
> > >> under repos/asf/qpid/trunk/qpid anymore.
> > >>
> > >> One point of confusion (and certainly not the only! more emails to
> > >> follow) is the source tree. Here's what we have now:
> > >>
> > >> jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/
> > >> branches/
> > >> doap_qpid.rdf
> > >> proton/
> > >> site/
> > >> tags/
> > >> trunk/
> > >>
> > >> Some of those things are alike, and some are not. Since the
> > >> introduction of "proton" and "site" at this level, we've begun to mix
> > >> the long-existing qpid/$language model with the new one that has
> > >> distinct and independently releasable modules.
> > >>
> > >> The first step I propose to clean things up is pretty simple. Take
> > >> qpid/{branches,tags,trunk} and move them under a name, just as proton
> > >> is organized.
> > >>
> > >> In other words, move to this:
> > >>
> > >> qpid/
> > >> doap_qpid.rdf
> > >> site/
> > >> proton/
> > >> trunk/
> > >> branches/
> > >> tags/
> > >> trident/ - qpid as we have known it
> > >> trunk/
> > >> branches/
> > >> tags/
> > >>
> > >> Queue naming debate, ;). I chose "trident" for my illustration
> > >> because I like how it sounds. I would also take this opportunity
> > >> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
> > >>
> > >> After that step, I see it evolving over time as in the following
> > example:
> > >>
> > >> qpid/
> > >> doap_qpid.rdf
> > >> site/
> > >> proton/
> > >> triton/
> > >> ---
> > >> jms/ - a new jms implementation powered by proton
> > >> janet/ - a new home for the java tree, migrated from
> > triton/trunk/java
> > >> casper/ - a new home for the cpp tree, migrated from
> > triton/trunk/cpp
> > >>
> > >> This is merely an illustration of what I would consider correct under
> > >> this new scheme. I've included the last two to show how I think we
> > >> might begin to move things out of triton (which is more or less the
> > >> old qpid model as is) and into new top-level modules.
> > >>
> > >> The names under qpid/ should not in my opinion be brands unto
> > >> themselves; "Qpid" is our brand, and Qpid has named components. They
> > >> are simply distinct modules with defined interfaces and dependencies.
> > >> They *can* be released independently, and in some cases we would have
> > >> reason to do so, but in general I think creating one release
> > >> distribution is preferable.
> > >>
> > >> Thanks!
> > >> Justin
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > >> For additional commands, e-mail: dev-help@qpid.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
Re: Proposal to adjust our source tree layout
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jan 22, 2013 at 4:55 AM, Rob Godfrey <ro...@gmail.com> wrote:
> In order to communicate better how Proton and other components make up the
> Qpid project I think we need to take a good hard look at how we present
> ourselves through the website, our documentation, and in our mailing lists.
I don't have any opinion yet on the source tree.
However I very much agree with what Rob has mentioned above.
But even before we look at the above, IMO we need to figure out where
we want to be as a project.
My biggest gripe is, that we don't seem to be on the same page about
what Qpid should look like.
An evolving protocol has made it somewhat difficult. But with AMQP 1.0
we have an opportunity to make that right.
As I have mentioned several time before, I'm of the opinion we need to
have a discussion about, agree and then document what our goals and
what we want to provide as a project.
Once we figure that out.
1. It will be clear (hopefully) what our products/releases should look like.
2. We can build our website around our product strategy.
3. Mailing lists, documentation, source tree etc would be more clear
when we figure out #1.
On the hand I'm glad that people are making an effort to conduct a
discussion in an open and transparent manner.
I believe this is the way forward.
Regards,
Rajith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal to adjust our source tree layout
Posted by Gordon Sim <gs...@redhat.com>.
On 01/22/2013 09:55 AM, Rob Godfrey wrote:
> I think it more important to review our website and our release
> artefacts.
I very much agree with that emphasis.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal to adjust our source tree layout
Posted by Rob Godfrey <ro...@gmail.com>.
On 21 January 2013 20:20, Justin Ross <ju...@gmail.com> wrote:
> My main goal is to populate the top level with equivalent things. If
> we don't, then I think the source tree itself forces you to think
> about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.},
> and Qpid is qpid/{proton,$futuremodule,etc.}.
>
> The funny name is not required. The trouble is I can't think of a
> better approach. Can you think of a functional name that works in
> this role? I'm open to almost anything except qpid/qpid.
>
>
While I think we could probably spend some time thinking about the desired
end-state of our source tree (and should think about how we can move things
such as the Java and C++ Brokers to become peers of Proton in said tree),
I'm not sure changing these will fundamentally solve the communication
issues around how the components of the project fit together. I think it
more important to review our website and our release artefacts.
While the source tree is undoubtedly a mess, it will mostly affect
ourselves as developers on Qpid. Hopefully we should be aware of the fact
that Proton is a sub-project of Qpid, and the fact that the other
"sub-projects" currently have a really poor directory structure is just an
accident of history.
In order to communicate better how Proton and other components make up the
Qpid project I think we need to take a good hard look at how we present
ourselves through the website, our documentation, and in our mailing lists.
If we are to be discussing source code directory structure I would like us
to actually agree (and document) what our fundamental requirements are,
particularly given the ongoing discussion [1] on the proton mailing list on
how we cope with interdependency between different (cross language)
sub-components within proton itself. Other points of view / suggestions in
that discussion would be most welcome.
-- Rob
[1] http://mail-archives.apache.org/mod_mbox/qpid-proton/201301.mbox/browser
> Justin
>
> On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> > If we were going to move them down a level then I wouldnt pick what seems
> > like a fairly random new name for the folder, especially if the
> motiviation
> > is to make things clearer. Thats definitely not where names like
> > trident/triton take me, and I have no idea where it would take someone
> new
> > coming along looking for all the existing stuff that is as far as they
> are
> > concerned just now, what Qpid is.
> >
> > I dont have anything to suggest myself right now, but the end state
> example
> > doesnt particularly inspire me as easier to work with either, requiring
> > lots of different chekouts to stay out to date on the different
> components,
> > or alternatively a massive amount of playing with svn folder depths on
> > checkouts (which im not sure play nice with git-svn anyway).
> >
> > Regarding the existing extra 'inner qpid folder', we have discussed
> > removing it in the past and decided not to simply because it had been
> that
> > way for so long, isnt really doing any harm , and doesnt seem worth the
> > hassle for merges, breaking peoples existing checkouts etc. Its presence
> > doesnt particularly bother me either FWIW, its easy enough to ignore
> > (though I actually dont, I checkout 'trunk')
> >
> > Robbie
> >
> > On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
> >
> >> Qpid has undergone some important changes in the last year. "What
> >> Qpid is" has shifted. In particular, the introduction of Proton is
> >> important because it means that Qpid is not just (mainly) the stuff
> >> under repos/asf/qpid/trunk/qpid anymore.
> >>
> >> One point of confusion (and certainly not the only! more emails to
> >> follow) is the source tree. Here's what we have now:
> >>
> >> jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/
> >> branches/
> >> doap_qpid.rdf
> >> proton/
> >> site/
> >> tags/
> >> trunk/
> >>
> >> Some of those things are alike, and some are not. Since the
> >> introduction of "proton" and "site" at this level, we've begun to mix
> >> the long-existing qpid/$language model with the new one that has
> >> distinct and independently releasable modules.
> >>
> >> The first step I propose to clean things up is pretty simple. Take
> >> qpid/{branches,tags,trunk} and move them under a name, just as proton
> >> is organized.
> >>
> >> In other words, move to this:
> >>
> >> qpid/
> >> doap_qpid.rdf
> >> site/
> >> proton/
> >> trunk/
> >> branches/
> >> tags/
> >> trident/ - qpid as we have known it
> >> trunk/
> >> branches/
> >> tags/
> >>
> >> Queue naming debate, ;). I chose "trident" for my illustration
> >> because I like how it sounds. I would also take this opportunity
> >> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
> >>
> >> After that step, I see it evolving over time as in the following
> example:
> >>
> >> qpid/
> >> doap_qpid.rdf
> >> site/
> >> proton/
> >> triton/
> >> ---
> >> jms/ - a new jms implementation powered by proton
> >> janet/ - a new home for the java tree, migrated from
> triton/trunk/java
> >> casper/ - a new home for the cpp tree, migrated from
> triton/trunk/cpp
> >>
> >> This is merely an illustration of what I would consider correct under
> >> this new scheme. I've included the last two to show how I think we
> >> might begin to move things out of triton (which is more or less the
> >> old qpid model as is) and into new top-level modules.
> >>
> >> The names under qpid/ should not in my opinion be brands unto
> >> themselves; "Qpid" is our brand, and Qpid has named components. They
> >> are simply distinct modules with defined interfaces and dependencies.
> >> They *can* be released independently, and in some cases we would have
> >> reason to do so, but in general I think creating one release
> >> distribution is preferable.
> >>
> >> Thanks!
> >> Justin
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Proposal to adjust our source tree layout
Posted by Justin Ross <ju...@gmail.com>.
My main goal is to populate the top level with equivalent things. If
we don't, then I think the source tree itself forces you to think
about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.},
and Qpid is qpid/{proton,$futuremodule,etc.}.
The funny name is not required. The trouble is I can't think of a
better approach. Can you think of a functional name that works in
this role? I'm open to almost anything except qpid/qpid.
Justin
On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> If we were going to move them down a level then I wouldnt pick what seems
> like a fairly random new name for the folder, especially if the motiviation
> is to make things clearer. Thats definitely not where names like
> trident/triton take me, and I have no idea where it would take someone new
> coming along looking for all the existing stuff that is as far as they are
> concerned just now, what Qpid is.
>
> I dont have anything to suggest myself right now, but the end state example
> doesnt particularly inspire me as easier to work with either, requiring
> lots of different chekouts to stay out to date on the different components,
> or alternatively a massive amount of playing with svn folder depths on
> checkouts (which im not sure play nice with git-svn anyway).
>
> Regarding the existing extra 'inner qpid folder', we have discussed
> removing it in the past and decided not to simply because it had been that
> way for so long, isnt really doing any harm , and doesnt seem worth the
> hassle for merges, breaking peoples existing checkouts etc. Its presence
> doesnt particularly bother me either FWIW, its easy enough to ignore
> (though I actually dont, I checkout 'trunk')
>
> Robbie
>
> On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
>
>> Qpid has undergone some important changes in the last year. "What
>> Qpid is" has shifted. In particular, the introduction of Proton is
>> important because it means that Qpid is not just (mainly) the stuff
>> under repos/asf/qpid/trunk/qpid anymore.
>>
>> One point of confusion (and certainly not the only! more emails to
>> follow) is the source tree. Here's what we have now:
>>
>> jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/
>> branches/
>> doap_qpid.rdf
>> proton/
>> site/
>> tags/
>> trunk/
>>
>> Some of those things are alike, and some are not. Since the
>> introduction of "proton" and "site" at this level, we've begun to mix
>> the long-existing qpid/$language model with the new one that has
>> distinct and independently releasable modules.
>>
>> The first step I propose to clean things up is pretty simple. Take
>> qpid/{branches,tags,trunk} and move them under a name, just as proton
>> is organized.
>>
>> In other words, move to this:
>>
>> qpid/
>> doap_qpid.rdf
>> site/
>> proton/
>> trunk/
>> branches/
>> tags/
>> trident/ - qpid as we have known it
>> trunk/
>> branches/
>> tags/
>>
>> Queue naming debate, ;). I chose "trident" for my illustration
>> because I like how it sounds. I would also take this opportunity
>> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
>>
>> After that step, I see it evolving over time as in the following example:
>>
>> qpid/
>> doap_qpid.rdf
>> site/
>> proton/
>> triton/
>> ---
>> jms/ - a new jms implementation powered by proton
>> janet/ - a new home for the java tree, migrated from triton/trunk/java
>> casper/ - a new home for the cpp tree, migrated from triton/trunk/cpp
>>
>> This is merely an illustration of what I would consider correct under
>> this new scheme. I've included the last two to show how I think we
>> might begin to move things out of triton (which is more or less the
>> old qpid model as is) and into new top-level modules.
>>
>> The names under qpid/ should not in my opinion be brands unto
>> themselves; "Qpid" is our brand, and Qpid has named components. They
>> are simply distinct modules with defined interfaces and dependencies.
>> They *can* be released independently, and in some cases we would have
>> reason to do so, but in general I think creating one release
>> distribution is preferable.
>>
>> Thanks!
>> Justin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal to adjust our source tree layout
Posted by Robbie Gemmell <ro...@gmail.com>.
If we were going to move them down a level then I wouldnt pick what seems
like a fairly random new name for the folder, especially if the motiviation
is to make things clearer. Thats definitely not where names like
trident/triton take me, and I have no idea where it would take someone new
coming along looking for all the existing stuff that is as far as they are
concerned just now, what Qpid is.
I dont have anything to suggest myself right now, but the end state example
doesnt particularly inspire me as easier to work with either, requiring
lots of different chekouts to stay out to date on the different components,
or alternatively a massive amount of playing with svn folder depths on
checkouts (which im not sure play nice with git-svn anyway).
Regarding the existing extra 'inner qpid folder', we have discussed
removing it in the past and decided not to simply because it had been that
way for so long, isnt really doing any harm , and doesnt seem worth the
hassle for merges, breaking peoples existing checkouts etc. Its presence
doesnt particularly bother me either FWIW, its easy enough to ignore
(though I actually dont, I checkout 'trunk')
Robbie
On 21 January 2013 17:17, Justin Ross <jr...@apache.org> wrote:
> Qpid has undergone some important changes in the last year. "What
> Qpid is" has shifted. In particular, the introduction of Proton is
> important because it means that Qpid is not just (mainly) the stuff
> under repos/asf/qpid/trunk/qpid anymore.
>
> One point of confusion (and certainly not the only! more emails to
> follow) is the source tree. Here's what we have now:
>
> jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/
> branches/
> doap_qpid.rdf
> proton/
> site/
> tags/
> trunk/
>
> Some of those things are alike, and some are not. Since the
> introduction of "proton" and "site" at this level, we've begun to mix
> the long-existing qpid/$language model with the new one that has
> distinct and independently releasable modules.
>
> The first step I propose to clean things up is pretty simple. Take
> qpid/{branches,tags,trunk} and move them under a name, just as proton
> is organized.
>
> In other words, move to this:
>
> qpid/
> doap_qpid.rdf
> site/
> proton/
> trunk/
> branches/
> tags/
> trident/ - qpid as we have known it
> trunk/
> branches/
> tags/
>
> Queue naming debate, ;). I chose "trident" for my illustration
> because I like how it sounds. I would also take this opportunity
> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
>
> After that step, I see it evolving over time as in the following example:
>
> qpid/
> doap_qpid.rdf
> site/
> proton/
> triton/
> ---
> jms/ - a new jms implementation powered by proton
> janet/ - a new home for the java tree, migrated from triton/trunk/java
> casper/ - a new home for the cpp tree, migrated from triton/trunk/cpp
>
> This is merely an illustration of what I would consider correct under
> this new scheme. I've included the last two to show how I think we
> might begin to move things out of triton (which is more or less the
> old qpid model as is) and into new top-level modules.
>
> The names under qpid/ should not in my opinion be brands unto
> themselves; "Qpid" is our brand, and Qpid has named components. They
> are simply distinct modules with defined interfaces and dependencies.
> They *can* be released independently, and in some cases we would have
> reason to do so, but in general I think creating one release
> distribution is preferable.
>
> Thanks!
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Proposal to adjust our source tree layout
Posted by Justin Ross <jr...@apache.org>.
Sorry, I mixed "trident" and "triton" in my examples. I mean them to
stand for the same thing. I've been mulling both names as contenders.
On Mon, Jan 21, 2013 at 12:17 PM, Justin Ross <jr...@apache.org> wrote:
> Qpid has undergone some important changes in the last year. "What
> Qpid is" has shifted. In particular, the introduction of Proton is
> important because it means that Qpid is not just (mainly) the stuff
> under repos/asf/qpid/trunk/qpid anymore.
>
> One point of confusion (and certainly not the only! more emails to
> follow) is the source tree. Here's what we have now:
>
> jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/
> branches/
> doap_qpid.rdf
> proton/
> site/
> tags/
> trunk/
>
> Some of those things are alike, and some are not. Since the
> introduction of "proton" and "site" at this level, we've begun to mix
> the long-existing qpid/$language model with the new one that has
> distinct and independently releasable modules.
>
> The first step I propose to clean things up is pretty simple. Take
> qpid/{branches,tags,trunk} and move them under a name, just as proton
> is organized.
>
> In other words, move to this:
>
> qpid/
> doap_qpid.rdf
> site/
> proton/
> trunk/
> branches/
> tags/
> trident/ - qpid as we have known it
> trunk/
> branches/
> tags/
>
> Queue naming debate, ;). I chose "trident" for my illustration
> because I like how it sounds. I would also take this opportunity
> eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*).
>
> After that step, I see it evolving over time as in the following example:
>
> qpid/
> doap_qpid.rdf
> site/
> proton/
> triton/
> ---
> jms/ - a new jms implementation powered by proton
> janet/ - a new home for the java tree, migrated from triton/trunk/java
> casper/ - a new home for the cpp tree, migrated from triton/trunk/cpp
>
> This is merely an illustration of what I would consider correct under
> this new scheme. I've included the last two to show how I think we
> might begin to move things out of triton (which is more or less the
> old qpid model as is) and into new top-level modules.
>
> The names under qpid/ should not in my opinion be brands unto
> themselves; "Qpid" is our brand, and Qpid has named components. They
> are simply distinct modules with defined interfaces and dependencies.
> They *can* be released independently, and in some cases we would have
> reason to do so, but in general I think creating one release
> distribution is preferable.
>
> Thanks!
> Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org