brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Zaccardo <mike.zacca...@cloudsoftcorp.com>
Subject Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli
Date Tue, 24 Nov 2015 00:19:52 GMT
(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 <hzbarcea@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 <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
> >>>>>>>>>
> >>
>

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