[Feedhenry-raincatcher] RainCatcher Monorepo

Thu Mar 2 18:10:40 UTC 2017

On Wed, Mar 1, 2017 at 8:58 AM, Peter Darrow <pdarrow at redhat.com> wrote:

> Hey all,
>
> So after chatting with Paolo and Wojciech last week, we decided it
> probably makes the most sense to just migrate the migrate the master and
> development branches from each repo, and leave the repos up (with
> deprecation warnings on them) for any other branches people are working on
> or tags we need.
>

+1, will we leave the final code at HEAD or will we clear it our and leave
the code at HEAD~1?

>
> I've pushed up this proposed structure to https://github.com/feedhenr
> y-raincatcher/raincatcher. As you can see, development is 220 commits
> ahead of master. Does this seem right to you guys? You can see the
> comparison here: https://github.com/feedhenry-r
> aincatcher/raincatcher/compare/development. Approximately 35 of the
> commits are merges I made as a part of the migration, but that still leave
> 185 commits ahead which seems like a lot.
>
>
/s/apps/demos or examples?

Eventually we may want to break the examples into their own project (ex
https://github.com/wildfly-swarm/wildfly-swarm-examples), but right now
while the project is small and we are doing a lot of quick development
keeping them together makes a lot of sense.

> The next steps I propose are:
>
>    1. Configure travis to build all of the projects in the monorepo (on
>    each branch and PR)
>    2. Identify and manually migrate any branches that people are working
>    on outside of master and development
>    3. Choose a day/time to stop development on the individual repos
>    (likely late on a Friday)
>    4. Run the migration script one last time
>    5. Resume regular development on the monorepo
>    6. Update script(s) for publishing releases to npm
>
> Does this seem reasonable to everyone? I was thinking this Friday might be
> a good opportunity to switch over, but I'd love to get your feedback.
>

It seems reasonable, maybe add a run of the portal app in here as well?
Also who is going to write the blog post to discuss the migration?

> Cheers,
> Peter
>
> On Thu, Feb 23, 2017 at 11:41 AM, Paolo Haji <phaji at redhat.com> wrote:
>
>> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20170302/8d72199a/attachment.htm>