On Wed, Feb 24, 2016 at 5:09 AM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> Hi Justin, > > This actually goes quite far beyond what I was expecting before the > upcoming cpp etc releases, looks like you have been busy! :) > > Just to confirm, is the thinking that the current heirarchy in > https://svn.apache.org/repos/asf/qpid/trunk/qpid/ dissappear entirely, > with most of the resulting subdirs of the 'qpid-svn-reorg/qpid/' on > the github repo effectively being added as new svn trunk+branches+tags > heirarchies alongside the remaining dirs currently at > https://svn.apache.org/repos/asf/qpid? Thats how it mostly reads, just > wanted to cofirm since some paths shown in the readme dont quite line > up with that. > Correct. I'll steal some of your verbiage for my proposal so this is more explicit. > Mentioning git...when the java bits were looking to move within svn, > discussion and testing around any subsequent future moves to git > suggested there will be some issues keeping the full history of > commits for a given component in the resulting git repos due to all > the moves. As this would effectively move all of the current code, I > guess that could make it harder still. However, given the svn repo and > history will stay in place (as it has for the other compoents that > migrated), and these bits may never migrate to git repos, this isnt > necessarily an issue but just something to note for consideration. > It's a good point. If we want to migrate any repos to git, we should do it now. I'd like to do it for qpid-cpp and qpid-python. The rest are, in my view, "parked" projects with no declared plans for new releases. As you've suggested, we should talk about the direction for each one. > Beyond the above, I had some component-specific thoughts/questions: > > # WCF > > These bits havent actually been getting released of late (not since > 0.28 in May 2014, though it is in the subsequent tags) or even updated > (not since Nov 2012), so should we bother to move them? Perhaps even > time for a different discussion about them? > I propose we remove this one from our source tree. Since taking it out of the big Qpid release, I haven't heard any complaints. > # Saslwrapper > > If it is only [optionally] used by the old python client as suggested, > should it perhaps be in the tree with that? It doesnt seem to have > been touched in 5 years, or released at all in the last couple. > Splitting it out isnt so clear to me. > This one has been forked to github now, and since it's seeing more attention there than we give it, I'd like to consider the github fork authoritative and remove the one in our tree. https://github.com/toddlipcon/python-sasl > # Java QMF tools > > To your note around whether it may make sense to add these into > qpid-java, I think them remaining separate seems perferable. > > Adding them in goes against the grain of making the java bits more > independently releasable, with further modularisation of the existing > grouped bits already a possibility in future. The tools were also > written primarily against the C++ broker given its reliance on QMF for > management and although a QMF broker plugin was added for the java > broker later that allowed the tools to work to an extent against both > brokers, that doesnt look to be keeping up. > > Other than some trivial removals a year ago to match the python tools, > there havent been any changes for 18 months. In looking at when they > were last released (0.32 a year ago, which [almost] explains the > versions still being 0.32-SNAPSHOT in svn), I came to realise they > aren't actually listed on the website. > > I think it makes sense to leave these bits separate, or possibly even > have a different discussion about them too. > Works for me. Fraser, are you planning future releases for this component? Justin
