On 24 February 2016 at 14:15, Justin Ross <justin.r...@gmail.com> wrote: > 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. >
Something I thought of since is that there are things linking to e.g the specs dir. Coupled with the discussion below around perhaps also migrating bits to git, we might actually want to consider leaving some of these things in place they are and do the further reorgs of the rest as part of establishing their new repos. > >> 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. > Ok. If we were to migrate them (which I would also like) then a question would be around exactly how/when to do it, and what would result. For example, the easiest thing might be to migrate the entire qpid/trunk/[qpid/] dir contents and then trim the resulting repo to only leave the bits desired (eg cpp + tools in one case). That will presumably keep all the history and all the matching branches and tags, but give the largest resulting repo in terms of file size. It would however presumably just be the same size it already is in its git mirror form currently. > 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. > Sounds good to me, it will still be there in the history if ever needed, but the lack of updates suggests it wont be. > >> # 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 > If that works, seems reasonable to me. Any python client users out there who might think otherwise? This optional bit isn't something I've personally used that I recall. > >> # 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
