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
<[email protected]> 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 <[email protected]> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
