Another update. CI is now in decent, if not perfect, shape. I've added lots of suppressions for apparently real memory leaks. I'll send a separate email regarding those.
Now that the vote on the migration to git has passed, I've raised two INFRA jiras to start the migration process: https://issues.apache.org/jira/browse/INFRA-11794 https://issues.apache.org/jira/browse/INFRA-11795 On Tue, Apr 26, 2016 at 7:34 AM, Justin Ross <[email protected]> wrote: > Hi, everyone. I'm now in the midst of getting the various CI environments > working, adding some temporary valgrind suppressions and fixing > incompatibilities with various versions of the buildchain tools. > > After CI is in suitably good shape, I would like to start the process to > migrate qpid-cpp and qpid-python to git. That will require a vote, which I > will kick off shortly. > > On Thu, Apr 21, 2016 at 7:06 AM, Justin Ross <[email protected]> > wrote: > >> I've committed the major pieces of this, and I'm now doing more testing >> and improving the documentation. >> >> These changes are likely going to affect CI and test configurations. In >> particular, the cpp tree now depends on an installed qpid python. I've >> added new install instructions to the python tree. >> >> If you have a chance, and you think you may be affected, please take a >> look at the new state of things and let me know if there's any trouble. >> I'll be working on addressing problems today while the dust settles. >> >> Justin >> >> On Mon, Apr 18, 2016 at 9:44 AM, Justin Ross <[email protected]> >> wrote: >> >>> On Mon, Apr 18, 2016 at 9:00 AM, Robbie Gemmell < >>> [email protected]> wrote: >>>> >>>> Looks good. Again, goes much further than I was originally expecting >>>> initially :) >>>> >>>> I'm not sure I would copy the specs dir though, at least not until >>>> some future point if particular need arises, since little/nothing will >>>> really reference the copy. >>>> >>> >>> Okay, I'll hold off on that. >>> >>> >>>> The readme for the update no longer mentions the Java QMF bits, >>>> suggesting they aren't getting moved, but I see they are still in the >>>> reorg fork at a previously-moved-there location, so just in case: if >>>> nobody is committing to update and release them, as seems to be the >>>> case currently, then I'd also leave them where they are in the current >>>> repo until cause arises to do otherwise. >>>> >>> >>> Yes. It's been ambiguous in my mind as well as in the proposal. I will >>> leave them as-is for now and wait for a response from Fraser. After a >>> time, if I don't hear from him, I'll proceed with removing them in a >>> second-round cleanup. >>> >>> >>>> The above said, perhaps their current nested structure is the main >>>> reason they were moved in the fork, in which case perhaps removing >>>> them from trunk first is the way to go. Ditto the WCF bits. >>>> >>>> Might be best to create a pre-reorg tag of everything before commencing. >>>> >>> >>> Definitely. Good idea. >>> >>> >>>> Finally, I'd suggest to use svn directly to do the significant >>>> moves/copies, as using git-svn for example sometimes wont end up doing >>>> exactly what you wanted/expected in those cases. >>>> >>> >>> Will do. Thanks for the feedback and guidance. >>> >>> I've made a dry run and met with success, so I will kick this off >>> shortly. >>> >>> Justin >>> >> >> >
