You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Alex Heneveld <al...@cloudsoftcorp.com> on 2015/11/20 13:51:33 UTC
Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
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 <hz...@gmail.com> 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" <hz...@gmail.com> 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 <hz...@gmail.com>
>>>>>> 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
>>>>>>>
Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
Hi,
Here are my £0.02:
(1) +0.5. I'm agree with the point you made Alex. But as few modules within
this project will be use elsewhere, I think a `brooklyn-commons` make more
sense than `brooklyn-server`
(2) +1
(2A) +1
(3) +1
(4) +1, I like git submodules
(5) +1
Best.
On Fri, 20 Nov 2015 at 12:51 Alex Heneveld <al...@cloudsoftcorp.com>
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 <hz...@gmail.com>
> 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" <hz...@gmail.com> 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 <hz...@gmail.com>
> >>>>>> 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
> >>>>>>>
>
> --
Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
http://www.cloudsoftcorp.com/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron
Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
Posted by Ron Wheeler <rw...@artifact-software.com>.
Getting docs separated into their own project is a good idea since it
makes it easier fr users to start to contribute.
Ron
On 24/11/2015 9:01 AM, Hadrian Zbarcea wrote:
> This thread is becoming confusing. The intent was to focus on how to
> split the current git repo. New repos do not affect this discussion in
> any way and should be had else-thread. Started a vote actually for that.
>
> Be back with more,
> Hadrian
>
> On 11/23/2015 07:19 PM, Mike Zaccardo wrote:
>> (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 <hz...@gmail.com>
>> 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 <hz...@gmail.com>
>>>>>> 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" <hz...@gmail.com>
>>>>>>>> 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
>>>>>>>>>>> <hzbarcea@gmail.com
>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>
>>>
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
Posted by Hadrian Zbarcea <hz...@gmail.com>.
This thread is becoming confusing. The intent was to focus on how to
split the current git repo. New repos do not affect this discussion in
any way and should be had else-thread. Started a vote actually for that.
Be back with more,
Hadrian
On 11/23/2015 07:19 PM, Mike Zaccardo wrote:
> (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 <hz...@gmail.com> 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 <hz...@gmail.com>
>>>>> 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" <hz...@gmail.com> 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 <hzbarcea@gmail.com
>>>
>>>>>>>>>> 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
>>>>>>>>>>>
>>>>
>>
>
Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
Posted by Mike Zaccardo <mi...@cloudsoftcorp.com>.
(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 <hz...@gmail.com> 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 <hz...@gmail.com>
> >>> 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" <hz...@gmail.com> 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 <hzbarcea@gmail.com
> >
> >>>>>>>> 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
> >>>>>>>>>
> >>
>
Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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 <hz...@gmail.com>
>>> 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" <hz...@gmail.com> 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 <hz...@gmail.com>
>>>>>>>> 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
>>>>>>>>>
>>
Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
Posted by Hadrian Zbarcea <hz...@gmail.com>.
(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 <hz...@gmail.com> 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" <hz...@gmail.com> 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 <hz...@gmail.com>
>>>>>>> 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
>>>>>>>>
>