qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <justin.r...@gmail.com>
Subject Re: Qpid source code reorg update
Date Tue, 26 Apr 2016 14:34:22 GMT
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 <justin.ross@gmail.com> 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 <justin.ross@gmail.com>
> wrote:
>
>> On Mon, Apr 18, 2016 at 9:00 AM, Robbie Gemmell <robbie.gemmell@gmail.com
>> > 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
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message