Releasing from a subtree if things are organised appropriately is possible, though it comes with its own issues, e.g for a git repo I guess that the release plugin would still need to tag everything, at which point the individual repo seems preferable again to me.
Robbie On 1 February 2017 at 17:58, Clebert Suconic <[email protected]> wrote: > I thought we could still release independently from a sub tree. > > > As for he tools project what about having the exporter on amq code base and > have it exporting the same format we use on Artemis importer? > > If you really need a bridge for what you think then we need the project as > suggested. > > > On Wed, Feb 1, 2017 at 12:47 PM Robbie Gemmell <[email protected]> > wrote: > >> I would echo Tim's comments, particularly around test client code. I'm >> in the middle of seperating things elsewhere that probably shouldn't >> have been lumped together initially. >> >> Beyond that, the first thing infra will likely tell folks to do is to >> use http://reporeq.apache.org for any new repository requests (as I >> found out recently, but couldn't actually use it myself due to the >> specifics of what I needed done). >> >> Robbie >> >> On 1 February 2017 at 16:20, Timothy Bish <[email protected]> wrote: >> > On 02/01/2017 09:09 AM, Clebert Suconic wrote: >> >> >> >> +1 >> >> >> >> Although, can we use the opportunity to go beyond the tools you are >> >> thinking now? >> > >> > >> > I'd be careful of the amount of things lumped into one subproject >> especially >> > if they are unrelated to the focus of that project as it drags down the >> ease >> > of doing quick releases with targeted features. >> > >> >> >> >> >> >> there are a couple of other things that would be nice to be shared as >> >> well. For instance some openwire parsers, some testsuite libraries for >> >> AMQP that we share with a copy & paste inheritance between artemis and >> >> activemq. >> > >> > >> > I'd suggest that anything OpenWire related might be better slotted into >> the >> > openwire project that was created previously. And I'd think long and >> hard >> > about how far into the wild we let the AMQP test client bits go because >> once >> > it gets into a release outside of a test jar the likely hood of having to >> > support it to the general public grows. >> > >> >> >> >> >> >> I have been thinking also to split docs into a separate repo. We would >> >> still release docs connected to a version, but we could then make >> >> changes to docs independently of the release, without having to spin a >> >> broker release to fix eventual typos on the docs. >> >> >> >> So, can we have an extras repo, and have all these as part of the new >> >> repo? >> > >> > >> > Again putting unrelated things into the same subproject complicates the >> > timing of releases and muddies the focus of the project so I'd shy away >> for >> > lumping broker docs into a tooling subproject. >> > >> >> >> >> (I'm not so sure if docs should be mixed with this all, perhaps we >> >> still need a separate repo for docs.. but I wanted to throw out the >> >> idea now anyways). >> >> >> >> >> >> >> >> >> >> On Wed, Feb 1, 2017 at 7:44 AM, Christopher Shannon >> >> <[email protected]> wrote: >> >>> >> >>> I'm going to ping infra to create a new project but wanted to get some >> >>> feedback from people first. The main motivation for this utility >> project >> >>> is >> >>> to create some command line store utilities for things like migrating a >> >>> KahaDB store to an Artemis store. >> >>> >> >>> I could request the name to be 'activemq-store-tools' or something like >> >>> that but we could also make it more generic such as >> 'activemq-cli-tools' >> >>> or >> >>> even just simply 'activemq-tools' if there is other stuff we wanted to >> >>> put >> >>> in there. Thoughts? >> >> >> >> >> >> >> > >> > >> > -- >> > Tim Bish >> > twitter: @tabish121 >> > blog: http://timbish.blogspot.com/ >> > >> > -- > Clebert Suconic
