[Feedhenry-raincatcher] Make RainCatcher's hydra Learnean?

[Peter Darrow]

This looks great! I'm a strong +1 on eliminating tooling that easily
becomes out of date (raincatcher-cli!) with something that's community
supported. I'm also a +1 on a monorepo, with individual npm packages (see
Babel <https://github.com/babel/babel/tree/master/packages>, for example).
As mentioned in the other thread, the forking workflow is an anti-pattern
and we should be able to come up with a way of extending modules that is
more sustainable. Summers & I are meeting with Patrick Curry and Darach
Cawley (both involved in the Aggregates & SOS projects that use
RainCatcher) so I'll make it a point to learn more about their development
workflow and how we can best meet their needs.

On Thu, Feb 9, 2017 at 10:26 AM, Paolo Haji <phaji at redhat.com> wrote:

> I think the cli project is going to go unmaintained, and would be a big
> cost in dev-time otherwise.
> I've only ever used it to clone the repos initially, and get started
> through its arbitrary npm linking, but since we have to constantly switch
> between checking out branches locally and installing pre-release versions
> to sanity-check them, it becomes very painful to manage these.
>
> pros would be:
> - reducing the number of different repos: perhaps down to 1 or keeping the
> demo apps as separate modules, not sure
> - consolidating releases across the different sub-modules: currently we
> have separate versions for each module, and bumps involve a lot of manual
> updating of the trees and some shrinkwrapping,
> with one repo we can use the same version for all sub-modules like babel
> does, makes it simpler for customers and platform templates as well
> - single feature branches: we've had a couple of epics that had 5+ feature
> branches with the same name, the workflow and final merging got complicated!
> - better supported than -cli: I haven't thought of lerna as an alternative
> to the cli because it would affect the repo structure itself, but it's a
> 3.2k star project used by a lot of high-profile projects itself.
> It is potentially another tool as Emilio pointed out, but better chances
> we get contributors that are familiar with (or willing to learn) that tool
> than our own reinvented wheel, isn't that what OSS is all about? ;)
>
> I thought this would be a nice fit stemming from Peter's comment in
> the Renaming Raincatcher packages thread, of course the forking-based model
> is still a bummer.
>
> On Thu, Feb 9, 2017 at 7:51 AM, paul wright <pwright at redhat.com> wrote:
>
>> Hi,
>>
>> I didn't know about raincatcher-cli, thanks @Wojciech
>>
>> From a docs POV, I'd like to move the end user info in the readme to
>> https://github.com/feedhenry-raincatcher/raincatcher-documentation
>> (asciidoc rather than markdown, book structure rather than readme).
>>
>> What would remain in the readme is any info about contributing to the
>> project that you want to write, and a link to the docs repo.
>>
>> Make sense?
>>
>> thanks,
>>
>> Paul
>>
>> On 09/02/17 09:34, Wojciech Trocki wrote:
>>
>> Just to make it clear.
>>
>> Would you guys see this as replacement of https://github.com/feedhenr
>> y-raincatcher/raincatcher-cli or something that is integrated into cli?
>> Raincatcher-cli offers somehow similar functionalities at the moment.
>>
>> Wojciech Trocki
>> Software Engineer, Red Hat Mobile
>>
>> On Thu, Feb 9, 2017 at 9:26 AM, Emilio Rodriguez Martinez <
>> emrodrig at redhat.com> wrote:
>>
>>> I worked with Lerna in the past and I have to say it's a great tool so
>>> I'm all in for it. Only downside I see is we would be adding another tool
>>> for the users to learn when working on the project.
>>>
>>> In any case, yeah, I think this is a much better approach than the named
>>> branches.
>>>
>>> On Thu, Feb 9, 2017 at 1:58 AM, Paolo Haji <phaji at redhat.com> wrote:
>>>
>>>> Hey guys,
>>>>
>>>> This seems to be a great tool to deal with the huge amount of small
>>>> repos we want to keep with raincatcher: https://lernajs.io/
>>>>
>>>> Looks like it's used by a lot of high-profile projects with needs
>>>> similar to ours. Beats creating a bunch of feature branches with the same
>>>> name.
>>>>
>>>> As a plus lerna-changelog <https://github.com/lerna/lerna-changelog> generates
>>>> nice changelogs based on PR tags to categorize changes. babel's
>>>> <https://github.com/babel/babel/blob/master/lerna.json#L10> example
>>>> <https://github.com/babel/babel/blob/master/CHANGELOG.md#bug-bug-fix>
>>>> uses emoji in their convention, which might appeal specially to Ger (cc'd)
>>>>
>>>> _______________________________________________
>>>> 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 listFeedhenry-raincatcher at redhat.comhttps://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/20170209/a9420c3e/attachment.htm>