Thanks but I'm aware that there is still outstanding work. LICENSE files will be updated and qpid-jms-amqp-0-x-test-utils will almost certainly disappear. Separating the two actually proved more painful than I anticipated and as a result I needed a staging post.
I would also like to move both of these to Git, so we have a consistent version control story across the whole project. I think to schedule this after work is concluded on QPID-7622. This will be done before v7.0 is released. On 9 February 2017 at 11:43, Rob Godfrey <[email protected]> wrote: > +1 on move the new (client) repo to git. > > I can't see any compelling reason to create a git mirror of this new svn > location - we should just be targeting moving all the components onto git > this year. > > -- Rob > > On 9 February 2017 at 12:38, Robbie Gemmell <[email protected]> > wrote: > >> The LICENCE and NOTICE files in the new repo will need updating. I >> also wondered if the qpid-jms-amqp-0-x-test-utils utils module could >> just be factored out? It doesnt seem like its going to be adding >> significant value in the new repo to warrant the new module. >> >> I also wondered about the plan for completing the clients new >> repo/area in terms of things like: git mirror, GitHub mirror, GitHub >> integrations, Travis/Appveyor CI builds? I ask as it occurs to me that >> now would be the next best time to move the repo to Git, before that >> work is done, as it would be less work overall for us and infra, cause >> less disruption for everyone over time, and give us a better result >> now. As I understand things from prior moves, doing so necessitates >> infra recreate the Git and GitHub mirrors (plus redo all the >> integrations), which in case of the latter also breaks existing forks >> off on their own. Given this isnt the first time some of this stuff >> has moved it would seem nice not to have to distrupt things yet again >> later and get such changes out the way now. Benefits would be avoiding >> creating repeated work (mainly for infra, but us too), reducing hassle >> for devs/'users', doing away with the annoying sync delays of the >> current multi-hop system (it took 32 minutes for the most recent >> commit to sync end to end and close its related GitHub PR), and being >> consistent within the project. >> >> Robbie >> >> On 7 February 2017 at 20:44, Keith W <[email protected]> wrote: >> > I made an initial commit on QPID-7622 separating Qpid Broker for Java >> > from the Qpid JMS 0-x Client. The client now lives at >> > https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x. More commits >> > will follow over the next few days to eliminate the client-only code >> > from the broker. There are also a few refactorings needed in the >> > Broker before the 0-8 and 0-10 protocol code can be moved to their >> > respective plugin modules. >> > >> > I have refactored Jenkins to take account of the changes and will be >> > monitoring it for the next few days. >> > >> > Moving the Broker to JDK 1.8 will take place soon once the dust has >> > settled, under a separate JIRA. >> > >> > >> > >> > >> > On 12 January 2017 at 18:13, Keith W <[email protected]> wrote: >> >>>> So, for the moment, I suggest these components remain SVN in the >> following way: >> >>>> >> >>>> https://svn.apache.org/repos/asf/qpid/java/ - will continue to house >> >>>> everything it houses today (Broker, Integration Tests etc) except for >> >>>> 0-x client and 0-x client docs. >> >>>> https://svn.apache.org/repos/asf/qpid/qpid-jms-client-amqp-0-x - a >> >>>> new repository created for the rehired 0-x client. The Maven >> >>>> artefact name will remain unchanged (qpid-client) >> >>> >> >>> I'd be fine with that (maybe drop 'client' from the 'repo' name to >> >>> align, and avoid containing the other clients artifact name). >> >> >> >> I'm happy with the suggestion to drop the 'client' part. So, that would >> give us: >> >> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x >> >> >> >> >> >>> That >> >>> said, having made the transition a few times now its worth saying its >> >>> not that much effort normally, especially compared to the rest of the >> >>> change here. In some ways I think making the changes would be less >> >>> painful if done while/after moving to git, and similarly for any >> >>> ongoing backporting efforts. It is a while since a move was deferred >> >>> for the last reorg :) >> >> >> >> I think I'd prefer to do the tree surgery in svn. I'm hoping (unless >> >> there are more comments on this thread) this work can be done next >> >> week. >> >> Once the new structure is settled down. I'll look to schedule the move >> >> to git as soon as we can. >> >> --------------------------------------------------------------------- >> 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]
