On Thu, 2015-03-19 at 11:15 -0400, Justin Ross wrote:
> >
> > > Agreed. I think theyd only want to have qpid- if they were in git,
> > > like qpid-proton and qpid-jms.
> > >
> > > The existing second qpid dir will go away with these changes either
> > > way though since it is within the trunk dir currently, and these
> > > proposed new dirs would contain the trunk etc.
> >
> > IMO there should NEVER be qpid- prefixes on anything in the qpid repo,
> > regardless of whether we get rid of the useless top-level qpid directory
> > or whether we it all to git
> >
> > Anybody who checks out the qpid repo *knows* they have checked out the
> > qpid repo, there's no need to embed a reminder in every directory name
> > in the repo that yes, this is indeed a checkout of the qpid repo.
> 
> 
> As far as subversion goes, the proposal doesn't include any extra qpids.
> It's all
> 
>   https://svn.apache.org/repos/asf/qpid/$module/{trunk,branches,tags}
> 
> where module is cpp, java, dispatch, etc.
> 
> I think Robbie's right about including qpid in the git repo name.  That
> helps to clarify what you're getting, particularly for components with
> generic names such as jms.
> 
> When it comes to git, there is no "the qpid repo" (as in, "anyone who
> checks out the qpid repo").  Since each module is a top-level entity, I
> think they need the association.

That makes sense. As long as there's just one "qpid" at the top level
and we don't keep stuttering it all the way down.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to