<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hi Pierre,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">By library do you mean a library of components and JSON interfaces?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regards</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Rajdeep</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 9, 2019 at 12:18 AM Pierre Tardy <<a href="mailto:tardyp@gmail.com">tardyp@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rajdeep,<br>
<br>
We already have a yeoman generator:<br>
<a href="https://github.com/buildbot/guanlecoja/tree/master/generator-guanlecoja" rel="noreferrer" target="_blank">https://github.com/buildbot/guanlecoja/tree/master/generator-guanlecoja</a><br>
<br>
I think the current boilerplate has more than just boilerplate.<br>
It also has some code that could be factorized.<br>
It is better not to put too much in a generator, as it is hard to<br>
upgrade after a first instanciation<br>
So I would recommend a generator plus a library.<br>
<br>
Regards<br>
Pierre<br>
Pierre<br>
<br>
Le lun. 8 avr. 2019 à 18:44, Rajdeep Bharati<br>
<<a href="mailto:rajdeepbharati13@gmail.com" target="_blank">rajdeepbharati13@gmail.com</a>> a écrit :<br>
><br>
> @Mojca Miklavec Oh, I see.<br>
><br>
> @Pierre Tardy Regarding the npm package: I think it would be better to create a project generator CLI (which would create the boilerplate project, similar to vue-cli or create-react-app). Do you think that would work? Can I use yeoman to do this?<br>
><br>
> Thank you for help.<br>
> Rajdeep<br>
><br>
> On Mon, Apr 8, 2019 at 7:05 PM Mojca Miklavec <<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>> wrote:<br>
>><br>
>> Dear Rajdeep,<br>
>><br>
>> On Sun, 7 Apr 2019 at 19:41, Rajdeep Bharati wrote:<br>
>> ><br>
>> > I found something which might help us: <a href="https://bors.tech/homu-io/" rel="noreferrer" target="_blank">https://bors.tech/homu-io/</a> <a href="https://github.com/barosl/homu" rel="noreferrer" target="_blank">https://github.com/barosl/homu</a>.<br>
>> > I will try it set it up on my local system and get back to you.<br>
>> > Mojca<br>
>><br>
>> This sounds nice, but I wonder if it would actually address any of our<br>
>> problems (I suspect not). Also, it explicitly says that the project<br>
>> was kind of abandoned and continued elsewhere?<br>
>><br>
>> What this tool is trying to solve is to check the code again after<br>
>> potentially long code review process, and run CI again "just before<br>
>> merging". However some of our builds would take hours, or, well, on<br>
>> Travis you might get 2 hours of waiting time and then one hour of<br>
>> building, just to experience a timeout at the end anyway. This makes<br>
>> the "just before merging" kind of not-too-well-defined. Plus, half of<br>
>> our Travis failures are false negatives, and before this can be useful<br>
>> on the buildbot, we would need to be able to enable checking pull<br>
>> requests in a "safe way" (addendum: for such checking we could<br>
>> probably just as well engage a couple of machines which are completely<br>
>> decoupled from our main builders, which would run, say, just 10.5,<br>
>> 10.6, 10.9, and would not upload the results anywhere). When checking<br>
>> the base ... we have so little activity that this is practically never<br>
>> an issue. And with ports there are so many distinct ports, that this<br>
>> is also hardly ever an issue; and when it is, you would already notice<br>
>> that the PR cannot be merged.<br>
>><br>
>> Mojca<br>
</blockquote></div>