On Tue, Mar 17, 2015 at 3:20 PM, Rob Godfrey <[email protected]> wrote:
> On 17 March 2015 at 20:03, Rajith Muditha Attapattu <[email protected]> > wrote: > > I think doing the re-org in git might make our lives a bit easy and leave > > the existing svn repo untouched. > > So, I don't have a strong view on git, but I don't think leaving the > svn repo untouched is actually a good goal to have. If we move to git > I think we'd want to do something to make clear that the svn repo is > no longer in use (except maybe for bug fix releases of old versions... > would we even be able to do this?) as per Robbie's other thread on a > similar issue. > > My question with git is how easy it would then be to the subsequently > change / split the projects up. This is very much a first step, and I > wouldn't want the "java" project to last very long. Ideally we'd be > breaking that up into sensible components like "broker", "0-x client" > etc. within a reasonably short timeframe (i.e. hopefully before the > end of the year). Personally I'd think we'd want to wait until we'd > worked out the final project structure before we engaged with infra to > get git projects set up etc... but if it's all a no-op for infra and > they'll be happy with us asking for projects to be set up / split / > removed every couple of months until we're done, then I have no > issue... > You do raise a valid point about first settling the structure before moving to git. All though I do have a slight preference for what I suggested in the prev email about moving to git and doing the re-org at the same time, I would defer this to the folks who are actually going to do the work :) I would support whatever decision the community agrees upon. I didn't mean to sidetrack this discussion by suggesting the git move, but thought it might be one of the options we should consider. Again I will defer it to the folks who are going to do the heavy lifting ;). Rajith > > -- Rob > > > As you said, git might make it more easy to handle the tags. > > > > Given the change is quite disruptive, why not make the move into git at > the > > same time. > > Otherwise developers will have to change their bearing again when we > switch > > to git. > > > > I'd say kill two birds with one stone :p > > > > On Tue, Mar 17, 2015 at 2:45 PM, Robbie Gemmell < > [email protected]> > > wrote: > > > >> I'd love to move everything to Git, but was saving the discussion for > >> later, since I figured it probably made sense to reorganise things > >> within the current svn repo even if we did transition, resulting in > >> area-specific repos afterwards. > >> > >> That said, I guess you could import the whole existing trunk into each > >> new repo and then trim out the things not wanted instead. That might > >> actually be a way to get useful tags of the existing content (with all > >> the other components still included of course), I'm not actually sure > >> how tags would be handled in a transition if we reorganise first. > >> Though I'm not sure how we plan to handle them in svn anyway, hadnt > >> thought of it until now :) > >> > >> Robbie > >> > >> On 17 March 2015 at 18:13, Rajith Muditha Attapattu <[email protected] > > > >> wrote: > >> > Could we take this opportunity to move to git completely ? > >> > (The svn repo will be read only). > >> > > >> > We could perhaps then leave whatever we think might not change in the > svn > >> > repo (read-only) and only include items in the git tree that would see > >> > change going forward. > >> > > >> > Rajith > >> > > >> > On Tue, Mar 17, 2015 at 1:49 PM, Robbie Gemmell < > >> [email protected]> > >> > wrote: > >> > > >> >> On 17 March 2015 at 15:45, Alan Conway <[email protected]> > wrote: > >> >> > On Mon, 2015-03-16 at 18:12 +0000, Keith W wrote: > >> >> >> Hello all, > >> >> >> > >> >> >> I believe we reached agreement on the following thread [1] that we > >> would > >> >> >> reorganise trunk (to support independent component releases) once > the > >> >> 0.32 > >> >> >> was branched. > >> >> >> > >> >> >> Justin previously published a source tree layout proposal. I have > >> just > >> >> >> extended it to include the Java subtree too. > >> >> >> > >> >> >> > >> >> > >> > https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal > >> >> >> > >> >> >> As 0.32 is branched (and at the voting stage), is there anything > that > >> >> >> blocks us from beginning the re-org task? Are there comments on > the > >> >> >> proposed layouts? > >> >> >> > >> >> >> I am ready to work with other committers to help make sure the > >> >> transition > >> >> >> is a smooth one. > >> >> >> > >> >> >> cheers, Keith. > >> >> >> > >> >> >> > >> >> >> [1] > >> >> >> > >> >> > >> > https://www.mail-archive.com/[email protected]&q=subject:%22Re%3A+Any+ETA+on+a+QPid+0.32+release%22&o=newest > >> >> > > >> >> > Looks good but one request: can we please call the sub-directories > >> >> > proton, dispatch, cpp, jms ... > >> >> > NOT > >> >> > qpid-proton, qpid-dispatch, qpid-cpp... > >> >> > > >> >> > The repo is already called qpid, it has a (redundant) top level > >> >> > directory called qpid, lets not make everybody type qpid/qpid/qpid- > >> >> > first thing every morning. > >> >> > > >> >> > Cheers, > >> >> > Alan. > >> >> > > >> >> > >> >> 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. > >> >> > >> >> Robbie > >> >> > >> >> --------------------------------------------------------------------- > >> >> 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] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
