Sorry, I missed the [DISCUSS] thread and posted on the [VOTE] thread. But to repeat:
> * brooklyn - all files in the root (no subdirs) The files in the root are: LICENSE NOTICE README.md .gitignore .gitattribues pom.xml All of these except pom.xml would also be present in every *other* repository, with minor modifications. This repo is not pulling its weight. > * brooklyn-dist > usage/all > usage/dist > usage/scripts > usage/downstream-parent > usage/archetypes My recommendation: drop `brooklyn-dist` and put all of this stuff into `brooklyn`. I'm with Mike on this one; 6 repositories - now 7 if there's a new one for the Go CLI - risks overcomplicating things (and not just for newcomers). A top-level project for the distribution and odds and ends, plus projects for "server", "web UI", "CLI" and "docs" is IMO acceptable - to most observers it's a logical split and people would know where they need to work. I'd accept "library" on the basis that we're trying to obsolete it by having a catalog of pure-YAML blueprints, but I suspect that it is going to hang around for quite a long time. Richard. On 26 November 2015 at 01:44, Alex Heneveld <[email protected]> wrote: > // migrating Mike's +0 comments to this thread > >> I think the proposed repo breakdown+organization is very logical, but my >> concern is that it spreads everything out amongst too many repos, >> potentially making it more difficult for newcomers to get a handle on >> things and creating too many scenarios with groups of dependent PRs across >> several repos. > > I'm glad you raised this. I grew up with big codebase projects and have a > soft spot for them for the reasons you bring up. But there is a trend > towards multiple smaller projects, and I've had a fair amount of feedback > that the brooklyn codebase is big and hard to get to grips with. While > sub-projects will make it a little harder to get to grips with all of it, > it should simplify a lot where someone wants to get to grips with a part of > it. And a potential contributor would be looking to contribute to just a > part in the first instance. You need to worry about the JS or Go projects > if you're working on server; and (even simpler for a new start) someone > working on the JS GUI or the Go client doesn't need to ever look at the > server. > > The worst part I agree is likely to be the cross-project-PR-set but it > should only hit someone making a complex change (esp the REST API and the > JS or CLI client) -- thus the pain is reserved for us and (we hope!) > alleviated for for everyone else. > > The best part I think will be encouraging independent JS UI development -- > where someone can run it with `grunt` pointing a binary-downloaded brooklyn > and not have to rebuild server or touch java -- and the same for BOM yaml > files in library. > > Best > Alex > > > On 25 November 2015 at 23:03, Alex Heneveld <[email protected] >> wrote: > >> Hi All- >> >> Here is a summary of the recent "git repos" thread and online chat and >> what we are currently proposing. I will follow-up with a [VOTE] thread for >> the creation of the repos and project migration. Please reply to this >> thread if you want to discuss; leave that thread for casting votes. >> >> We are planning to request the following git repos, mirrored at >> github.com/apache/* : >> >> * brooklyn - just pointers / summaries / scripts for working with the >> other projects >> * brooklyn-server - everythng to run the Brooklyn server (w REST API and >> Karaf) >> * brooklyn-client - CLI for accessing REST server (in go; subject of other >> vote) >> * brooklyn-ui - the JS GUI >> * brooklyn-library - blueprints and tools which run on brooklyn-server >> * brooklyn-docs - documentation (in markdown/ruby) >> * brooklyn-dist - for building distros, incl source + binary tgz w all the >> above >> >> More detail of the content of these repos is below. >> >> The motivation for this is so that people can check out smaller projects >> and focus more easily on the pieces relevant to them. IE someone working >> on the UI or on the docs should not even need to look at server or dist. >> In addition languages are consistent within projects. There will be times >> when a change necessitates PR's to multiple projects (e.g. new UI feature >> with support in REST API) but we believe the above split will minimise that. >> >> The addition of the *brooklyn-dist* project is the only change which has >> not been discussed at some length but its need was obvious when we >> discussed it. (It would be possible to put it into *brooklyn* but that >> would be rather confusing for people who land on that project and see a >> bunch of code but nothing useful; if anything of substance were in >> *brooklyn* people would probably expect it to be *brooklyn-server* which is >> a possibility but the consensus has been that it is better to keep it >> extremely light so as not to mask the other projects, any of which might be >> what someone visiting would be interested in.) >> >> There was also some discussion about the *brooklyn-server* project being >> called *brooklyn-commons* instead. The idea of a grassy commons is nice >> but *server* is a more descriptive and accurate name (as most of the other >> projects don't depend on it per se). >> >> Other key points: >> >> * The releases we make will continue to look the same: the dist project >> will make a single big source and big binary, and maven artifacts for all >> maven projects. Automation in the brooklyn project or the brooklyn-dist >> project will build the projects in all the other repos to minimise the >> impact of the multiple repositories. >> * If we include a submodules setup in *brooklyn* it will be optional; >> people who don't like submodules won't have to use them. We may instead >> find that it is more convenient to provide scripts for working with the >> other git modules. >> * When we transfer the code to these repos we will exclude the offensive >> big files in the history. The incubator brooklyn repo will continue to >> exist but we will mark it as deprecated forwarding to the new location. >> >> IMPORTANT: When we do this there will obviously be an impact on pull >> requests and branch development. We will endeavor to work through the PR >> queue and we will give some notice before the changes. If you miss this it >> won't be hard to take diffs and apply them to the different structure but >> it will be tedious! >> >> Best >> Alex >> >> >> * brooklyn >> empty for now, contains a README and instructions/scripts for >> subprojects; >> e.g. git submodules >> >> * brooklyn-dist >> usage/all -> all >> usage/dist -> dist >> usage/scripts -> scripts >> usage/downstream-parent >> usage/archetypes >> karaf (distro + other features - e.g. jsgui) >> ** new project brooklyn-server-cli which injects the JSGUI >> >> * brooklyn-server >> parent >> api, core, policy >> util/* >> usage/rest-* >> camp/* >> usage/camp >> usage/cli -> usage/server-cli-abstract >> (assumes jsgui war is on classpath; injects into launcher) >> usage/logback-* >> usage/launcher (refactor so that WAR gets injected by server CLI) >> storage/hazelcast >> usage/qa >> usage/test-* >> karaf (code + itest + features needed for itest) >> >> * brooklyn-ui >> jsgui >> >> * brooklyn-client [subject of a separate vote] >> (new project, in go) >> >> * brooklyn-library >> software/* >> examples/* >> sandbox/* (?!) >> >> * brooklyn-docs >> docs >> >> END >> >>
