So my gut feel is that as a particular component "stabilizes" to the point where it is independently releasable and is thought to be something that will not be soon broken up into further components, then it might elect to move to git at that point. I'm imagining that not all components will be ready/want to move at the same time... but I'm open to whatever works best for people.
-- Rob On 17 March 2015 at 20:35, Rajith Muditha Attapattu <[email protected]> wrote: > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
