<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">A standalone npm package can be kept will sample components written in React and Vue, with environment variables specifying which framework is being used.</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">Something that I didn't understand: We have the buildbot-react-plugin-boilerplate, which we add to our master.cfg. Now there would be several views inside that. Do you want those views to have separate tabs on the left side navbar of buildbot UI? Currently, there is a single tab with the name of the plugin.</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">Rajdeep</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 30, 2019 at 11:20 AM Rajdeep Bharati <<a href="mailto:rajdeepbharati13@gmail.com">rajdeepbharati13@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"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I think this plugin can reside in <a href="https://github.com/buildbot/buildbot/tree/master/www" target="_blank">buildbot/www/</a> directory, and it would be pretty similar to other views (except the fact that it will be a plugin and act as a way to write more views using react/vue; it won't be a view itself). Developers may add more views inside that, and it can become a part of buildbot. This package would be more generic, and the Macports one will be optimized for our use case. It can be documented and also be made into a pip package.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Please correct me if I'm wrong.</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">Regarding the calendar widget: That's a good idea. I will try to implement it and show you a prototype.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019 at 3:15 PM Mojca Miklavec <<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</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">On Fri, 29 Mar 2019 at 09:18, Pierre Tardy wrote:<br>
><br>
> My fear is that this is part of the many stretch goals, and this is beginning to be very optimistic schedule.<br>
> I think it is best to make a great finished GSoC rather than lots of very cool but unfinished mini projects.<br>
<br>
I would say that it makes sense to keep all the items you already<br>
wrote (no need to delete them), but move some of them to extension<br>
goals.<br>
<br>
Also, there is no point in burning out in the first two weeks by<br>
spending 60 hours per week working on the project, and then quit / be<br>
unable to continue.<br>
<br>
It does make sense to play a bit with various pet projects, but we<br>
should really make sure that whatever we really want to achieve is<br>
done in an excellent way, and then other stuff may follow, depending<br>
on time. It's hard to predict how much time certain tasks need, but<br>
it's important to deliver a smaller amount of high quality code rather<br>
than high quantities of unfinished products.<br>
<br>
A question to both of you (Pierre, Rajdeep): what's the status of the<br>
boilerplate code you wrote so far? Can any of that be polished,<br>
documented etc., so that it can be officially published?<br>
(I'm really not that familiar with JS.)<br>
<br>
<br>
Regarding the calendar widget: after something thinking what I believe<br>
would make sense is to pick just a single timestamp and then either<br>
show all the builds before or all the builds after that timestamp (in<br>
decreasing or increasing order, letting the user to browse back and<br>
forth from there; maybe we could even have a button "go one<br>
day/week/month back/forth"). What I miss at the moment is that I might<br>
know that I committed something 3 months ago (I can check the exact<br>
time of commit in repository), but it's non-trivial to find just that<br>
single point in time without manual bisection and lots of<br>
trial-and-error. There is no need to set both start and end time.<br>
<br>
Mojca<br>
</blockquote></div>
</blockquote></div>