GSoC 2019 [Buildbot ideas]

[Rajdeep Bharati]

A standalone npm package can be kept will sample components written in
React and Vue, with environment variables specifying which framework is
being used.

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.

Rajdeep

On Sat, Mar 30, 2019 at 11:20 AM Rajdeep Bharati <rajdeepbharati13 at gmail.com>
wrote:

> I think this plugin can reside in buildbot/www/
> <https://github.com/buildbot/buildbot/tree/master/www> 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.
> Please correct me if I'm wrong.
>
> Regarding the calendar widget: That's a good idea. I will try to implement
> it and show you a prototype.
>
> On Fri, Mar 29, 2019 at 3:15 PM Mojca Miklavec <mojca at macports.org> wrote:
>
>> On Fri, 29 Mar 2019 at 09:18, Pierre Tardy wrote:
>> >
>> > My fear is that this is part of the many stretch goals, and this is
>> beginning to be very optimistic schedule.
>> > I think it is best to make a great finished GSoC rather than lots of
>> very cool but unfinished mini projects.
>>
>> I would say that it makes sense to keep all the items you already
>> wrote (no need to delete them), but move some of them to extension
>> goals.
>>
>> Also, there is no point in burning out in the first two weeks by
>> spending 60 hours per week working on the project, and then quit / be
>> unable to continue.
>>
>> It does make sense to play a bit with various pet projects, but we
>> should really make sure that whatever we really want to achieve is
>> done in an excellent way, and then other stuff may follow, depending
>> on time. It's hard to predict how much time certain tasks need, but
>> it's important to deliver a smaller amount of high quality code rather
>> than high quantities of unfinished products.
>>
>> A question to both of you (Pierre, Rajdeep): what's the status of the
>> boilerplate code you wrote so far? Can any of that be polished,
>> documented etc., so that it can be officially published?
>> (I'm really not that familiar with JS.)
>>
>>
>> Regarding the calendar widget: after something thinking what I believe
>> would make sense is to pick just a single timestamp and then either
>> show all the builds before or all the builds after that timestamp (in
>> decreasing or increasing order, letting the user to browse back and
>> forth from there; maybe we could even have a button "go one
>> day/week/month back/forth"). What I miss at the moment is that I might
>> know that I committed something 3 months ago (I can check the exact
>> time of commit in repository), but it's non-trivial to find just that
>> single point in time without manual bisection and lots of
>> trial-and-error. There is no need to set both start and end time.
>>
>> Mojca
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190330/11974970/attachment-0001.html>