brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Bouron <thomas.bou...@cloudsoftcorp.com>
Subject Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
Date Fri, 20 Nov 2015 13:51:24 GMT
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 <alex.heneveld@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 <hzbarcea@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" <hzbarcea@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
> >>>>>>>
>
> --
Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
http://www.cloudsoftcorp.com/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message