[Feedhenry-raincatcher] RainCatcher Monorepo

[Paolo Haji]

Along with lerna we can start adding global utils to the top level, so `*npm
start*` could fire up all demo-apps (with optional task runner and through
forever/nodemon). If we move to a nice logging library like debug
<https://github.com/visionmedia/debug> we can have consolidated logs and in
a filterable form that would be useful for both local dev and cluster
deployments.

As for tags, I'm not sure it will be of much value keeping their history
since they'll not be actual tags that show up as GH releases, we can keep
the old repos around as reference until then.

Our releases as a monorepo would be consolidating all version numbers
across all modules right? We can start off with a new major c.f. angular 4.x
<http://angularjs.blogspot.com.br/2016/12/ok-let-me-explain-its-going-to-be.html>

On Thu, Feb 23, 2017 at 12:19 PM, Peter Darrow <pdarrow at redhat.com> wrote:

> Wojciech as I mentioned the tool is buggy and really doesn't make a master
> branch, I think it leaves that up to us. I was mostly looking for feedback
> on the approach. So is this what you're proposing:
>
>    1. Move the demo apps into a "apps" subdirectory
>    2. Move the modules into a "packages" subdirectory
>    3. Move the documentation into a "docs" subdirectory
>    4. Combine all branches named "master" from each individual repo into
>    one master branch
>    5. Combine all branches named "development" from each individual repo
>    into one master branch
>    6. Copy the tags from each individual repo to the monorepo with the
>    following naming scheme: "<original tag name>-<original repo name>"
>    7. Ensured the history stays intact.
>
> #6 is the one I'm most curious about—how should we attempt to migrate
> these tags? Or do we not migrate at all as Emilio suggests and just keep
> the old repos around for resurrecting old tags, etc.?
>
> Emilio as far as building and running the apps, https://lernajs.io/
> should help us with some of this but we may need a small script to help
> devs run all the apps at once (a slimmed down raincatcher-cli maybe?). Any
> suggestions there?
>
> Peter
>
> On Thu, Feb 23, 2017 at 10:49 AM, Wojciech Trocki <wtrocki at redhat.com>
> wrote:
>
>> Where is master :P ?
>>
>> Import seems to be doing something we do not want - creating new branch
>> for each of the module. Best would be to have only 2 branches for that mono
>> repo:
>> - master (containing all modules from master with history)
>> - development (with all modules from development branch)
>>
>> Having it this way would mean that we would not be able to have every
>> component on development branch.
>> If perl is a problem maybe we should use some different tools. Fastline
>> migration seems to be something we can use:
>>
>> https://github.com/fastlane/monorepo/
>>
>> Regards
>>
>>
>> Wojciech Trocki
>> Red Hat Mobile
>>
>> On Thu, Feb 23, 2017 at 2:21 PM, Peter Darrow <pdarrow at redhat.com> wrote:
>>
>>> Hey all,
>>>
>>> I spent a bunch of time yesterday stitching together our repos into a
>>> single repo. My goal was to try and identify issues that might make this
>>> challenging. You can see the results here: https://github.com/feedh
>>> enry-raincatcher/raincatcher-stitched/. My approach was the following:
>>>
>>>
>>>    1. Move the demo apps into a "apps" subdirectory
>>>    2. Move the modules into a "packages" subdirectory
>>>    3. Move the documentation into a "docs" subdirectory
>>>    4. Copy the branches from each individual repo to a branch on the
>>>    monorepo with the following naming scheme: "<original branch
>>>    name>-<original repo name>".
>>>    5. Copy the tags from each individual repo to the monorepo with the
>>>    following naming scheme: "<original tag name>-<original repo name>"
>>>    6. Ensured the history stays intact.
>>>
>>> I found a tool that promised to implement this exact approach (
>>> http://search.cpan.org/dist/Git-FastExport/script/git-stitch-repo).
>>> It's written in Perl and I spent an unreasonable amount of time yesterday
>>> trying to configure my system to install CPAN modules :/. Eventually I got
>>> it working, but if you take a look at the stitched repo, it seems to have
>>> done an incomplete job. I'm not a Perl developer so I don't think it would
>>> be worth my time to try to contribute a fix, but I think I could implement
>>> something similar with a bit of effort.
>>>
>>> What do you guys think—do we need to migrate all of the branches from
>>> each repo, or just the master from each one? Do we care about the history?
>>> Is it important to keep every single tag? Let me know what you think!
>>>
>>> Peter
>>>
>>> _______________________________________________
>>> Feedhenry-raincatcher mailing list
>>> Feedhenry-raincatcher at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>
>>>
>>
>
> _______________________________________________
> Feedhenry-raincatcher mailing list
> Feedhenry-raincatcher at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170223/c3b91a27/attachment.htm>