Re: [HEADS-UP] Brooklyn graduation <- git repos, docs, cli

Tue, 24 Nov 2015 06:37:51 -0800

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 <[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












--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102



























					Reply via email to