(1) +1 `brooklyn-commons` as per Thomas' suggestion (2) +1 named `br` or `bk` (2A) +1 named `brooklyn-commons-cli` (3) +1 (4) +0 as I have little experience with GSMs (5) +1
On Fri, Nov 20, 2015 at 12:09 PM Hadrian Zbarcea <[email protected]> wrote: > Missed one thing: where's the parent gonna be? If in apache/brooklyn > then we'll have circular deps. > > Hadrian > > On 11/20/2015 09:51 AM, Hadrian Zbarcea wrote: > > (1) +1 (server is more descriptive) > > (2) +0.5 ; I easily see it as being part of the ./brooklyn (distro) > > project, but a separate repo is ok too > > (2A) -0 ; the karaf distro has it's own cli launcher > > (3) +1 ; I am also kinda neutral on this but based on the fact that > > somebody could just focus on docs, a big +1 from a community pov. > > (4) -0.5 ; I didn't see git submodules in use at ASF; and I prefer work > > in the isolation of a repo > > (5) I am not sure how much we'll be allowed to alter history, something > > I am following up. > > > > Hadrian > > > > On 11/20/2015 07:51 AM, Alex Heneveld wrote: > >> > >> Hi All- > >> > >> So we are sitting at: > >> > >> * brooklyn - master project, pointers to others > >> * brooklyn-core - contains util, api, core, policy, and rest api > >> * brooklyn-ui - JS GUI > >> * brooklyn-library - tomcat, cassandra, etc > >> > >> But a few things have occured to me: > >> > >> (1) It will be confusing have `brooklyn-core` as a git project of which > >> the sub-dir `core` containing *maven* project `brooklyn-core` is just > >> ONE part. Maybe that piece should be called `brooklyn-server` ? > >> > >> (2) David and Geoff sent a proposal for a CLI *client* -- which would > >> allow us to tweak the getting started guide to be based on a CLI. This > >> CLI client could be a separate project, maybe `brooklyn-cli`. As it > >> sounds like it will be written in go (which makes easy-to-install > >> binaries) and the way go works life will definitely be easier if this is > >> a separate project. > >> > >> (2A) We have an existing `brooklyn-cli` used to launch the server from > >> the CLI. Rename this `brooklyn-server-cli`? > >> > >> (3) The docs/ subdir (the web-site) also is a logically separate piece; > >> personally I think it deserves its own git repo (`brooklyn-docs`) and > >> not in `brooklyn` > >> > >> (4) I know git submodules are far from perfect but maybe that's a good > >> thing to put into `brooklyn`, along with a README and a master pom which > >> can build all subprojects. (It's either submodules or scripts I think, > >> and decent info in the README, because otherwise it will be confusing > >> for people using the code.) > >> > >> One nice thing about the above is that the different languages and > >> contribution areas are different git projects; docs (markdown) in one, > >> UI (js/html) in another, library (java/yaml) another, server (java), and > >> cli (go). Assuming people agree with the above we'd have a different > >> proposal: > >> > >> * brooklyn > >> * brooklyn-server > >> * brooklyn-docs > >> * brooklyn-ui > >> * brooklyn-cli > >> * brooklyn-library > >> > >> > >> Although it is a fair few projects it feels natural. In for a penny, in > >> for a pound. > >> > >> > >> Finally in terms of process I'd like to suggest a (5) that we: > >> > >> * remove references to "incubator" > >> * cut a 0.9.0 release > >> * bump to 1.0.0-snapshot > >> * do a git copy with history to move things into new repo structure in > >> someone's personal space (but removing the awful big binaries from early > >> history), and possibly test the submodules workflow > >> * point infra at that repo and with the list of commands we ran to make > >> that > >> > >> > >> Where people have opinions can I suggest they reply with something like: > >> > >> (1) +1 > >> (2) +1 > >> (2A) +1 > >> (3) +1 > >> (4) +0 > >> (5) +1 > >> > >> (^^^ my votes) > >> > >> > >> Best > >> Alex > >> > >> > >> > >> On 18/11/2015 20:22, Richard Downer wrote: > >>> +1 - that sounds like a good idea. I'd suggest that - at least > >>> initially - the docs go into this repository. > >>> > >>> I'm still not convinced about the versioning - BUT that is a separate > >>> issue and won't block consensus for splitting the repositories. > >>> > >>> Hadrian, any thoughts on the feasibility of editing the history to > >>> remove the large binary objects? That seems to have to got lost in > >>> this thread. > >>> > >>> Richard. > >>> > >>> > >>> > >>> On 18 November 2015 at 19:02, Hadrian Zbarcea <[email protected]> > >>> wrote: > >>>> Do you see apache/brooklyn as being the distro project? If that's the > >>>> case > >>>> +1 from me. > >>>> > >>>> Hadrian > >>>> > >>>> > >>>> On 11/18/2015 01:59 PM, Alex Heneveld wrote: > >>>>> For external relations purposes and as an umbrella should we also > have > >>>>> apache/brooklyn ? > >>>>> > >>>>> I tend to think yes. > >>>>> > >>>>> Best > >>>>> Alex > >>>>> On 18 Nov 2015 17:55, "Hadrian Zbarcea" <[email protected]> wrote: > >>>>> > >>>>>> So I see a lot of consensus on Alex's proposal with the following > >>>>>> amendment (s/brooklyn/brooklyn-core/): > >>>>>> * apache/brooklyn-core > >>>>>> * apache/brooklyn-ui > >>>>>> * apache/brooklyn-library > >>>>>> > >>>>>> If we can get a consensus on this I don't think we need to go to a > >>>>>> vote. > >>>>>> I > >>>>>> will address the other comments as direct replies, because I don't > >>>>>> see > >>>>>> them > >>>>>> as contradictory to this proposal. > >>>>>> > >>>>>> WDYT? > >>>>>> Hadrian > >>>>>> > >>>>>> On 11/17/2015 12:44 PM, Alex Heneveld wrote: > >>>>>> > >>>>>>> +1 to removing the large artifacts; it's just stupid having them > >>>>>>> there. > >>>>>>> > >>>>>>> Personally I would like to see the apache/incubator-brooklyn > >>>>>>> carved up > >>>>>>> as follows: > >>>>>>> > >>>>>>> * apache/brooklyn > >>>>>>> * apache/brooklyn-ui > >>>>>>> * apache/brooklyn-library > >>>>>>> > >>>>>>> The third one contains all the concrete items, like jboss and > >>>>>>> tomcat and > >>>>>>> cassandra etc. The UI is the jsgui. > >>>>>>> > >>>>>>> The first one is the main one, with everything else, including CLI > >>>>>>> and > >>>>>>> REST API, vanilla software process, and jclouds locations and osgi. > >>>>>>> > >>>>>>> > >>>>>>> The only other thing I'm wondering is whether brooklyn-api should > be > >>>>>>> separate, and very rarely changing. This would allow us > >>>>>>> potentially to > >>>>>>> run different versions of brooklyn-* in the same system, using the > >>>>>>> magic > >>>>>>> of OSGi. > >>>>>>> > >>>>>>> > >>>>>>> WDYT? > >>>>>>> > >>>>>>> Best > >>>>>>> Alex > >>>>>>> > >>>>>>> > >>>>>>> On 17/11/2015 17:03, Richard Downer wrote: > >>>>>>> > >>>>>>>> Hi Hadrian, > >>>>>>>> > >>>>>>>> I don't think there's any need to split the repository (although > >>>>>>>> I've > >>>>>>>> no strong opinions on this, if someone else has an idea). > >>>>>>>> > >>>>>>>> However there has been a long-standing issue with our repository's > >>>>>>>> history - in the dim and distant past, binary artifacts of Tomcat > >>>>>>>> etc. > >>>>>>>> used for testing were committed to the repository. These are long > >>>>>>>> gone, but they still exist in the git history, and everybody is > >>>>>>>> forced > >>>>>>>> to clone these large artifacts. > >>>>>>>> > >>>>>>>> Could we use the graduation migration as an opportunity to > >>>>>>>> rewrite the > >>>>>>>> git history to permanently remove these large artifacts? It'd > >>>>>>>> result > >>>>>>>> in a much quicker clone of the repo for new contributors to > >>>>>>>> Brooklyn. > >>>>>>>> > >>>>>>>> Richard. > >>>>>>>> > >>>>>>>> > >>>>>>>> On 17 November 2015 at 00:58, Hadrian Zbarcea <[email protected] > > > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hello Brooklyners, > >>>>>>>>> > >>>>>>>>> The Brooklyn graduation resolution is again on the board agenda. > >>>>>>>>> This > >>>>>>>>> time I > >>>>>>>>> paid paranoid attention to details and I hope the stars to be > >>>>>>>>> better > >>>>>>>>> aligned. > >>>>>>>>> > >>>>>>>>> Assuming all goes well, there will be a few tasks to take care > >>>>>>>>> post > >>>>>>>>> graduation, mostly related to dropping the "incubating" suffix. > >>>>>>>>> Part > >>>>>>>>> of that > >>>>>>>>> process it is possible to split the git repository into multiple > >>>>>>>>> smaller > >>>>>>>>> ones. It is possible to do it later, but doing it now would be > >>>>>>>>> easier > >>>>>>>>> and > >>>>>>>>> more natural, I think. > >>>>>>>>> > >>>>>>>>> Therefore, if anybody has any idea or proposal related to that, > >>>>>>>>> speak > >>>>>>>>> up > >>>>>>>>> now. In the absence of consensus the status quo will be > >>>>>>>>> maintained. I > >>>>>>>>> will > >>>>>>>>> work with infra and try to make the process as smooth as > >>>>>>>>> possible for > >>>>>>>>> the > >>>>>>>>> community regardless of which way we decide to go. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Hadrian > >>>>>>>>> > >> >
