[Feedhenry-raincatcher] RainCatcher Monorepo

Fri Mar 3 14:24:56 UTC 2017

+1 for the documentation on migrating branches.

Other than that Onwards from me!!

Nice one Peter!!

On Fri, Mar 3, 2017 at 2:15 PM, Peter Darrow <pdarrow at redhat.com> wrote:

> Summers I think we'll leave the final code at HEAD. I agree while the
> project is small and we're iterating quickly that we should keep things
> centralized. As far as manual QA of the portal app goes, I think that's a
> good idea for a sanity check. And re: blog post, I have no problem writing
> that!
>
> Emilio: Great point, I will document the steps required to migrate active
> branches—it will probably be manual but pretty straightforward I think.
>
> *Note: I plan on completing this migration today. If you have strong
> feelings for or against this, please voice them in the next few hours.*
>
> On Fri, Mar 3, 2017 at 7:07 AM, Emilio Rodriguez Martinez <
> emrodrig at redhat.com> wrote:
>
>> Any idea on how are we going to migrate our unfinished work to the
>> monorepo? I think it would be nice to prepare a quick email explaining the
>> steps needed to do this as I guess it will be quite a manual process.
>>
>> Other than that everything looks good to me, I'm really looking forward
>> to see this working :)
>>
>> On Thu, Mar 2, 2017 at 7:10 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>>
>>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20170303/520d896e/attachment.htm>