Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Not sure if this is applicable, but there is no import method from
buildbot 0.8.x to buildbot 0.9+

Buildbot do not import previous commit  as changes when starting, it
only looks for new things.

Pierre

Le lun. 1 avr. 2019 à 23:03, Mojca Miklavec  a écrit :
>
> On Mon, 1 Apr 2019 at 18:52, Rajdeep Bharati wrote:
> >
> > When I would be configuring the real (production) macports buildmaster, 
> > then would the old database be used?
>
> Not if you deploy it on a fresh server, unless you explicitly put the
> database there (import it from elsewhere).
>
> (I don't know how many commits buildbot pulls in when you first start it.)
>
> Mojca

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi,

I think MacPorts has quite specific huge scale in term of the number
of packages it builds, and optimisations on non rebuilding everything.

So for this project what would be interesting is to research the best
visualisation for MacPort, rather than making compromises so that it
is useful for everybody.
This does not mean we don't want to make it generic as much as we can,
it is just we want it to be super efficient for macports.

Having a quality dashboard for macport will still benefit for the
community in term of example of how things can be, and how
customisable Buildbot is.

Another benefit for Buildbot is that it would be the first project to
be specific for react/vue, and we need to improve the interface for
that.
I would like to have react/vue boilerplate improved, so that the core
of it is extracted in a separate npm package.
This npm package could then be kept when we rewrite the core ui
framework in webpack/typescript. This would be a good oportunity to
make the API evolve for better suit in reactive frameworks.
I already saw some issues with the Collection class in buildbot data
which is not well compatible with vue.

Regards
Pierre

Le mar. 26 mars 2019 à 11:26, Mojca Miklavec  a écrit :
>
> On Tue, 26 Mar 2019 at 10:48, Rajdeep Bharati wrote:
> >
> > Would rewriting the waterfall view (with custom features) using Vue be one 
> > of the goals/stretch goals?
> > And I presume that the plugin will become a part of buildbot core?
>
> I leave that up to Pierre to answer.
>
>
> My personal wish (but I lack some deep insight into buildbot itself)
> would be to have a better waterfall view out of the box, so that other
> projects could benefit as well.
>
> Some of the strange views specific to MacPorts (which builds something
> else in every build on the same builder) would probably be more tricky
> to implement in a generic way, even though ... it might perhaps be
> possible to let the buildbot configuration assign a keyword to each
> build on the fly, and then implement a special view where the user can
> specify a keyword as a filter and buildbot would display just the
> matching builds.
>
> In our case we could specify the port name as the keyword. Other
> projects building from different branches or using different settings
> might specify a keyword like "PR", "development", "stable", "beta",
> etc. And then the user could choose to show just builds matching
> "beta", or just builds matching one specific port in our case.
>
> The ability to quickly show the builds matching a particular commit,
> or the ability to easily jump to the builds done on March 8th 2018 ...
> could also be implemented in a generic way.
>
> Mojca

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Right.
I would advise to start from a fresh config with a git poller a simple
build recipe to train yourself at buildbot.


Le dim. 24 mars 2019 à 13:02, Mojca Miklavec  a écrit :

> On Sat, 23 Mar 2019 at 15:30, Rajdeep Bharati wrote:
> >
> > Is the old master.cfg file written in Python 2?
>
> Yes. Buildbot 0.8.x only supported Python 2. The new version just
> dropped support for Python 2.
>
> > Can someone tell me a possible alternative for
> ```buildbot.plugins.status.GitHubStatus``` in 2.x
>
> I would need to check (I assume Pierre nows it), but you may leave
> such details out for now (along with many others).
>
> Mojca
>

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

I provided you inline comments. I were very near from the solution :)
Pierre


Le dim. 24 mars 2019 à 13:32, Rajdeep Bharati 
a écrit :

> Ok, I'll do that.
> I've also made some changes to the Vue plugin. Now it's showing that a
> Root component is present (as you can see in the attachment), but it's not
> rendering anything. Could you please review it?
> https://github.com/rajdeepbharati/buildbot-vue-plugin-boilerplate. Sorry
> for taking so much time.
>
>  Screenshot 2019-03-24 at 5.59.32 PM.png
> <https://drive.google.com/file/d/1FkNr-t7VRWtypEjstKBB-qxLEv0FincJ/view?usp=drive_web>
>
> Rajdeep
>
>
> On Sun, Mar 24, 2019 at 5:36 PM Pierre Tardy  wrote:
>
>> Right.
>> I would advise to start from a fresh config with a git poller a simple
>> build recipe to train yourself at buildbot.
>>
>>
>> Le dim. 24 mars 2019 à 13:02, Mojca Miklavec  a
>> écrit :
>>
>>> On Sat, 23 Mar 2019 at 15:30, Rajdeep Bharati wrote:
>>> >
>>> > Is the old master.cfg file written in Python 2?
>>>
>>> Yes. Buildbot 0.8.x only supported Python 2. The new version just
>>> dropped support for Python 2.
>>>
>>> > Can someone tell me a possible alternative for
>>> ```buildbot.plugins.status.GitHubStatus``` in 2.x
>>>
>>> I would need to check (I assume Pierre nows it), but you may leave
>>> such details out for now (along with many others).
>>>
>>> Mojca
>>>
>>

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi Rajdeep,

There should not be much to do in the webpack config. Just change
package.json to depend on vue rather than react

You first need to understand the vue lifecycle. It is not very different
from react, unless a bit less explicit.

https://vuejs.org/v2/guide/instance.html

Basically, you need to create a Vue() Object that attaches to the angularJS
created component.

so instead of
ReactDOM.render(
React.createElement(SampleReactComponent, props, null),
this.reactRawElement
);

you would do:
new Vue({
el: this.reactRawElement,
components: {
SampleVueComponent
}
[..] // Then need to configure a small template to configure the component,
and pass it the params
})

Regards
Pierre

On Thu, Mar 21, 2019 at 1:37 PM Rajdeep Bharati 
wrote:

> Hi,
> I tried (and am still trying) to implement it using Vue. I'm some facing
> issues:
> - How do I render my component inside Main.js in a similar manner as
> ReactDOM.render()?
> - I guess there's also some problem in the webpack.config.js
>
> Sorry for the delayed response. I'm slightly new to Vue.js, so some help
> would be great.
> Thank you.
>
> On Tue, Mar 19, 2019 at 11:41 PM Pierre Tardy  wrote:
>
>> Great! That was fast!
>>
>> Lets go harder challenge, then.
>> How about doing the same with Vue.js?
>>
>>
>> buildbot-vue-plugin-boilerplate
>>
>> Pierre
>>
>> On Tue, Mar 19, 2019 at 6:31 PM Rajdeep Bharati <
>> rajdeepbharat...@gmail.com> wrote:
>>
>>> Hi,
>>> I have set up the environment with the react plugin installed and
>>> configured, as you told. You can see the code here
>>> <https://github.com/rajdeepbharati/MacportsCustomBuildbot> and a demo
>>> in the video:
>>>
>>>  demo.mov
>>> <https://drive.google.com/file/d/1GD6LM0EgjXs3lXep3SBUy-AqMfOFx2FJ/view?usp=drive_web>
>>> Regards,
>>> Rajdeep
>>>
>>> On Tue, Mar 19, 2019 at 4:14 PM Rajdeep Bharati <
>>> rajdeepbharat...@gmail.com> wrote:
>>>
>>>> Sounds good to me. Thanks!
>>>>
>>>> On Tue, Mar 19, 2019 at 3:59 PM Pierre Tardy  wrote:
>>>>
>>>>> Hi Rajdeep,
>>>>>
>>>>> Sorry if I have not been clear.
>>>>> The project I have linked is quite a large project which will actually
>>>>> takes several summer in order to finish. What I meant is that it would be
>>>>> good for synergy if we have another student on that project, as this is on
>>>>> the same domain, and you could work with him/her to share your findings 
>>>>> and
>>>>> best practices.
>>>>>
>>>>> You can start working on macport custom buildbot UI without waiting
>>>>> for this project, and we can start working on that in modern javascript of
>>>>> typescript if needed.
>>>>>
>>>>> uglycoyte did a poc which you can find here:
>>>>> https://github.com/uglycoyote/buildbot-react-plugin-boilerplate
>>>>>
>>>>> I am not sure of the state of the PoC.
>>>>> I suggest you as a welcome challenge to build yourself a buildbot
>>>>> environment, with the react plugin installed in, displaying "hello from
>>>>> Rajdeep's Buildbot"
>>>>>
>>>>> Would that work for you?
>>>>>
>>>>> Regards
>>>>> Pierre
>>>>> On Mon, Mar 18, 2019 at 10:53 AM Pierre Tardy 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We have our own GSoC project to transition the UI from coffeescript:
>>>>>>
>>>>>> https://github.com/buildbot/buildbot/wiki/Buildbot-GSoC-Projects-2019#transition-web-uis-data-module-from-coffeescript-to-typescript
>>>>>> The ideal would be to have one student for each project.
>>>>>>
>>>>>> All the pointers are there. I would be happy to help on either
>>>>>> project.
>>>>>>
>>>>>> Regards,
>>>>>> Pierre
>>>>>>
>>>>>> On Mon, Mar 18, 2019 at 9:41 AM Mojca Miklavec 
>>>>>> wrote:
>>>>>>
>>>>>>> Dear Rajdeep,
>>>>>>>
>>>>>>> On Sun, 17 Mar 2019 at 19:55, Rajdeep Bharat wrote:
>>>>>>> >
>>>>>>> > Hello, I am Rajdeep, a GSoC aspirant.
>>>>>>> > I was going through the Buildbot views proj

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

You can take control of the VM by downloading a ransomware or botnet or
whatever.

You usually counter that by making sure the PR VMs are restricted in term
of network access they can do, and also restricted in the number of time it
is alive (basically just the time of the build)

Another much more simple option is to trigger the PR testing  via a PR
comment from an admin.

If a macPort maintainer sends a message like "Go Buildbot", then buildbot
would catche that a start a build, provided that the PR got basic review,
and is not suspicious.


Pierre


Le jeu. 28 mars 2019 à 13:03, Rajdeep Bharati 
a écrit :

> All right. Could you please give an example of a malicious PR? Would it be
> one which is done (locally tested) from an old version of macOS?
>
> On Wed, Mar 27, 2019 at 9:55 PM Mojca Miklavec  wrote:
>
>> Dear Rajdeep,
>>
>> It's not just a question of how to fetch a PR. That shouldn't be too
>> difficult, I hope (and probably the link you provided works as intended).
>>
>> The tricky question is how to prevent malicious PRs from doing damage on
>> the builders. I assume that a proper solution would require starting a
>> fresh VM for each build. There is some support in the buildbot already:
>>
>> http://docs.buildbot.net/2.1.0/manual/configuration/workers-libvirt.html
>> https://github.com/kholia/OSX-KVM
>> but we would need to find a way to create VMs with macOS, so it might not
>> be trivial to do it. On top of that what we would really need the PRs for
>> are the old machines (say, 10.6, or even 10.4 if we would want to go to
>> extremes) where it might be even less trivial to automate this in a nice
>> way.
>>
>> (A compromise solution would be to only allow trusted developers to test
>> pull requests on devoted builders, where we would also need to make sure to
>> uninstall the software after the PR is done building.)
>>
>> While implementing this remains almost the number one requested thing
>> when people contribute to packages, I'm not sure how much time doing this
>> would take. It could be that this could be done in a day or a few days, but
>> it's also possible that there would be some stumbling block that would
>> require more hacking skills and would prevent us from proceeding, and not
>> even two months would suffice. In one way, I wouldn't mind if a student
>> would work on this for the full summer to get this working; on the other
>> hand, if there's a block and none of us is skilled enough to overcome it,
>> it makes more sense to proceed with other stuff that can certainly be done.
>>
>> Mojca
>>
>>
>> On Wed, 27 Mar 2019 at 16:05, Rajdeep Bharati 
>> wrote:
>>
>>> I could use the GitHubPullrequestPoller
>>> 
>>>  which
>>> periodically polls the Github API for new/updated PRs.
>>>
>>> Here is an example:
>>> https://github.com/halide/build_bot/blob/master/master/master.cfg
>>>
>>> c['change_source'].append(GitHubPullrequestPoller(
>>> owner = 'halide',
>>> repo = 'Halide',
>>> token = token,
>>> pullrequest_filter = pr_filter,
>>> pollInterval = 60*5, # Check Halide PRs every five minutes
>>> pollAtLaunch = True))
>>> Rajdeep
>>>
>>> On Wed, Mar 27, 2019 at 3:59 AM Mojca Miklavec 
>>> wrote:
>>>
 Dear Rajdeep,

 On Tue, 26 Mar 2019 at 19:51, Rajdeep Bharati wrote:
 >
 > I have submitted a draft proposal:
 https://docs.google.com/document/d/12wRjA8sOWNOuApHZ_fm0n1aIPLVPt9Xm2yGiMwiK3AI/edit.
 Could you please provide some feedback?

 Cool, thank you very much, it looks nice, please give us a bit of time.

 One question: what precisely is your plan for setting up disposable
 builds for PRs?

 Mojca

>>>

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

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.

>From my experience, I'd say settuping securing and optimising macos
precommit CI is a full 3 month work.

The number one mistake for young talented people is to underestimate things.

https://en.wikipedia.org/wiki/Pareto_principle

Regards,
Pierre


Le jeu. 28 mars 2019 à 18:50, Rajdeep Bharati 
a écrit :

> I will try to set up libvirt. I can keep the PR comment from admin as a
> backup option.
>
> Rajdeep
>
> On Thu, Mar 28, 2019 at 5:37 PM Pierre Tardy  wrote:
>
>> You can take control of the VM by downloading a ransomware or botnet or
>> whatever.
>>
>> You usually counter that by making sure the PR VMs are restricted in term
>> of network access they can do, and also restricted in the number of time it
>> is alive (basically just the time of the build)
>>
>> Another much more simple option is to trigger the PR testing  via a PR
>> comment from an admin.
>>
>> If a macPort maintainer sends a message like "Go Buildbot", then buildbot
>> would catche that a start a build, provided that the PR got basic review,
>> and is not suspicious.
>>
>>
>> Pierre
>>
>>
>> Le jeu. 28 mars 2019 à 13:03, Rajdeep Bharati 
>> a écrit :
>>
>>> All right. Could you please give an example of a malicious PR? Would it
>>> be one which is done (locally tested) from an old version of macOS?
>>>
>>> On Wed, Mar 27, 2019 at 9:55 PM Mojca Miklavec 
>>> wrote:
>>>
>>>> Dear Rajdeep,
>>>>
>>>> It's not just a question of how to fetch a PR. That shouldn't be too
>>>> difficult, I hope (and probably the link you provided works as intended).
>>>>
>>>> The tricky question is how to prevent malicious PRs from doing damage
>>>> on the builders. I assume that a proper solution would require starting a
>>>> fresh VM for each build. There is some support in the buildbot already:
>>>>
>>>> http://docs.buildbot.net/2.1.0/manual/configuration/workers-libvirt.html
>>>> https://github.com/kholia/OSX-KVM
>>>> but we would need to find a way to create VMs with macOS, so it might
>>>> not be trivial to do it. On top of that what we would really need the PRs
>>>> for are the old machines (say, 10.6, or even 10.4 if we would want to go to
>>>> extremes) where it might be even less trivial to automate this in a nice
>>>> way.
>>>>
>>>> (A compromise solution would be to only allow trusted developers to
>>>> test pull requests on devoted builders, where we would also need to make
>>>> sure to uninstall the software after the PR is done building.)
>>>>
>>>> While implementing this remains almost the number one requested thing
>>>> when people contribute to packages, I'm not sure how much time doing this
>>>> would take. It could be that this could be done in a day or a few days, but
>>>> it's also possible that there would be some stumbling block that would
>>>> require more hacking skills and would prevent us from proceeding, and not
>>>> even two months would suffice. In one way, I wouldn't mind if a student
>>>> would work on this for the full summer to get this working; on the other
>>>> hand, if there's a block and none of us is skilled enough to overcome it,
>>>> it makes more sense to proceed with other stuff that can certainly be done.
>>>>
>>>> Mojca
>>>>
>>>>
>>>> On Wed, 27 Mar 2019 at 16:05, Rajdeep Bharati <
>>>> rajdeepbharat...@gmail.com> wrote:
>>>>
>>>>> I could use the GitHubPullrequestPoller
>>>>> <http://docs.buildbot.net/current/manual/configuration/changesources.html#chsrc-GitHubPullrequestPoller>
>>>>>  which
>>>>> periodically polls the Github API for new/updated PRs.
>>>>>
>>>>> Here is an example:
>>>>> https://github.com/halide/build_bot/blob/master/master/master.cfg
>>>>>
>>>>> c['change_source'].append(GitHubPullrequestPoller(
>>>>> owner = 'halide',
>>>>> repo = 'Halide',
>>>>> token = token,
>>>>> pullrequest_filter = pr_filter,
>>>>> pollInterval = 60*5, # Check Halide PRs every five minutes
>>>>> pollAtLaunch = True))
>>>>> Rajdeep
>>>>>
>>>>> On Wed, Mar 27, 2019 at 3:59 AM Mojca Miklavec 
>>>>> wrote:
>>>>>
>>>>>> Dear Rajdeep,
>>>>>>
>>>>>> On Tue, 26 Mar 2019 at 19:51, Rajdeep Bharati wrote:
>>>>>> >
>>>>>> > I have submitted a draft proposal:
>>>>>> https://docs.google.com/document/d/12wRjA8sOWNOuApHZ_fm0n1aIPLVPt9Xm2yGiMwiK3AI/edit.
>>>>>> Could you please provide some feedback?
>>>>>>
>>>>>> Cool, thank you very much, it looks nice, please give us a bit of
>>>>>> time.
>>>>>>
>>>>>> One question: what precisely is your plan for setting up disposable
>>>>>> builds for PRs?
>>>>>>
>>>>>> Mojca
>>>>>>
>>>>>

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

In buildbot, there is no difference between author and commiter, we only
keep the author.
Do you think committer info is really needed?


Pierre


Le lun. 1 avr. 2019 à 17:04, Rajdeep Bharati  a
écrit :

> I'm using npm run watch. In the boilerplate, there is no field called
> 'committer' in the change:
> https://github.com/uglycoyote/buildbot-react-plugin-boilerplate/blob/master/src/BuildbotJsonInterfaces.ts.
> It only contains the author field. I also tried using the other fields, but
> none of them had anything that resembles committer.
>
> Rajdeep
>
> On Mon, Apr 1, 2019 at 8:26 PM Pierre Tardy  wrote:
>
>> Hi Rajdeep,
>>
>> Against which data are you working on? are you using gulp dev proxy or
>> something?
>>
>> The committer name is normally a field in the change, but it works only
>> if the changesource extracts the data
>>
>> Regards
>> Pierre
>>
>>
>> Le lun. 1 avr. 2019 à 16:37, Rajdeep Bharati 
>> a écrit :
>>
>>> I have set up a simple datepicker widget with view #1. See the demo in
>>> the video below.
>>>
>>>  Screen Recording 2019-04-01 at 8.02.02 PM.mov
>>> <https://drive.google.com/file/d/1zaTPwzyri2V8wiMe6MfN8x9qs4V2NiBm/view?usp=drive_web>
>>>
>>> However, I have some doubts/problems:
>>> - The last date is showing only till 26th March (I'm not able to get
>>> builds before that date). I guess I haven't done the configuration properly?
>>> - How do I get the committer name/handle in buildbot?
>>>
>>> Thank you.
>>> Rajdeep
>>>
>>>
>>> On Sat, Mar 30, 2019 at 11:49 AM Rajdeep Bharati <
>>> rajdeepbharat...@gmail.com> wrote:
>>>
>>>> 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 <
>>>> rajdeepbharat...@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 
>>>>> 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
>>>>>&g

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi Rajdeep,

Against which data are you working on? are you using gulp dev proxy or
something?

The committer name is normally a field in the change, but it works only if
the changesource extracts the data

Regards
Pierre


Le lun. 1 avr. 2019 à 16:37, Rajdeep Bharati  a
écrit :

> I have set up a simple datepicker widget with view #1. See the demo in the
> video below.
>
>  Screen Recording 2019-04-01 at 8.02.02 PM.mov
> <https://drive.google.com/file/d/1zaTPwzyri2V8wiMe6MfN8x9qs4V2NiBm/view?usp=drive_web>
>
> However, I have some doubts/problems:
> - The last date is showing only till 26th March (I'm not able to get
> builds before that date). I guess I haven't done the configuration properly?
> - How do I get the committer name/handle in buildbot?
>
> Thank you.
> Rajdeep
>
>
> On Sat, Mar 30, 2019 at 11:49 AM Rajdeep Bharati <
> rajdeepbharat...@gmail.com> wrote:
>
>> 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 <
>> rajdeepbharat...@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 
>>> 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
>>>>
>>>

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Great! That was fast!

Lets go harder challenge, then.
How about doing the same with Vue.js?


buildbot-vue-plugin-boilerplate

Pierre

On Tue, Mar 19, 2019 at 6:31 PM Rajdeep Bharati 
wrote:

> Hi,
> I have set up the environment with the react plugin installed and
> configured, as you told. You can see the code here
> <https://github.com/rajdeepbharati/MacportsCustomBuildbot> and a demo in
> the video:
>
>  demo.mov
> <https://drive.google.com/file/d/1GD6LM0EgjXs3lXep3SBUy-AqMfOFx2FJ/view?usp=drive_web>
> Regards,
> Rajdeep
>
> On Tue, Mar 19, 2019 at 4:14 PM Rajdeep Bharati <
> rajdeepbharat...@gmail.com> wrote:
>
>> Sounds good to me. Thanks!
>>
>> On Tue, Mar 19, 2019 at 3:59 PM Pierre Tardy  wrote:
>>
>>> Hi Rajdeep,
>>>
>>> Sorry if I have not been clear.
>>> The project I have linked is quite a large project which will actually
>>> takes several summer in order to finish. What I meant is that it would be
>>> good for synergy if we have another student on that project, as this is on
>>> the same domain, and you could work with him/her to share your findings and
>>> best practices.
>>>
>>> You can start working on macport custom buildbot UI without waiting for
>>> this project, and we can start working on that in modern javascript of
>>> typescript if needed.
>>>
>>> uglycoyte did a poc which you can find here:
>>> https://github.com/uglycoyote/buildbot-react-plugin-boilerplate
>>>
>>> I am not sure of the state of the PoC.
>>> I suggest you as a welcome challenge to build yourself a buildbot
>>> environment, with the react plugin installed in, displaying "hello from
>>> Rajdeep's Buildbot"
>>>
>>> Would that work for you?
>>>
>>> Regards
>>> Pierre
>>> On Mon, Mar 18, 2019 at 10:53 AM Pierre Tardy  wrote:
>>>
>>>> Hi,
>>>>
>>>> We have our own GSoC project to transition the UI from coffeescript:
>>>>
>>>> https://github.com/buildbot/buildbot/wiki/Buildbot-GSoC-Projects-2019#transition-web-uis-data-module-from-coffeescript-to-typescript
>>>> The ideal would be to have one student for each project.
>>>>
>>>> All the pointers are there. I would be happy to help on either project.
>>>>
>>>> Regards,
>>>> Pierre
>>>>
>>>> On Mon, Mar 18, 2019 at 9:41 AM Mojca Miklavec 
>>>> wrote:
>>>>
>>>>> Dear Rajdeep,
>>>>>
>>>>> On Sun, 17 Mar 2019 at 19:55, Rajdeep Bharat wrote:
>>>>> >
>>>>> > Hello, I am Rajdeep, a GSoC aspirant.
>>>>> > I was going through the Buildbot views project and had a few doubts:
>>>>> > - Do I need to work on the dashboards SPA of buildbots (
>>>>> https://github.com/buildbot/guanlecoja-ui) and rewrite it using a
>>>>> modern library like React?
>>>>> > - I have read this ticket: https://trac.macports.org/ticket/55978.
>>>>> Do I have to implement them separately in a MacPorts repository of
>>>>> buildbot, or do it in upstream directly?
>>>>> >
>>>>> > I am familiarizing myself with the buildbot codebase and would love
>>>>> to start contributing.
>>>>> > Can someone tell me if I'm on the right track?
>>>>>
>>>>> Thank you very much for reaching to us. I still owe you the response
>>>>> to the earlier email, but let's start with this one.
>>>>>
>>>>> The "buildbot idea" would be (co)mentored by someone from the Buildbot
>>>>> development team for the technical part ("How to do it?"), while the
>>>>> MacPorts mentor would help to steer towards the desired goal ("What to
>>>>> do?").
>>>>>
>>>>> So I would like to ask Pierre to explain the technical part in more
>>>>> details.
>>>>>
>>>>> (Pierre, how does the unfinished Coffeescript to Typescript conversion
>>>>> of the core affect designing new views and their "future-proof-ness"?)
>>>>>
>>>>> What I want to say from the MacPorts point of view is that what mainly
>>>>> kept us from switching to buildbot version beyond 0.8.x was a less
>>>>> user-friendly waterfall view. We kept postponing the switch since the
>>>>> time the buildbot was still at version 0.9.x. Now it's already at 2.x,
>>>>> and it would be about a high time that we do the upgrade. The existing
>>>>> buildbot setup was written in cca. 3 days during our in-person
>>>>> developer meeting in 2016, and then slightly improved over time.
>>>>>
>>>>> The changes would be added wherever it makes the most sense. If
>>>>> there's some view that's specific to MacPorts, we would keep it
>>>>> locally, while any other change that's considered useful for any
>>>>> buildbot user would best be pushed to their own repository (and
>>>>> reviewed by the buildbot development team).
>>>>>
>>>>> I wanted to add that this project is well related to the "collection
>>>>> of build statistics" idea. I will elaborate on this later, but we
>>>>> definitely need changes in the buildbot configuration to make it
>>>>> easier for our (hopefully) future web application to talk to the
>>>>> buildbot master.
>>>>>
>>>>> Mojca
>>>>>
>>>>>
>>>>> Mojca
>>>>>
>>>> --
>>>>
>>>>
>>>> --
>>>
>>>
>>> --

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi Rajdeep,

Sorry if I have not been clear.
The project I have linked is quite a large project which will actually
takes several summer in order to finish. What I meant is that it would be
good for synergy if we have another student on that project, as this is on
the same domain, and you could work with him/her to share your findings and
best practices.

You can start working on macport custom buildbot UI without waiting for
this project, and we can start working on that in modern javascript of
typescript if needed.

uglycoyte did a poc which you can find here:
https://github.com/uglycoyote/buildbot-react-plugin-boilerplate

I am not sure of the state of the PoC.
I suggest you as a welcome challenge to build yourself a buildbot
environment, with the react plugin installed in, displaying "hello from
Rajdeep's Buildbot"

Would that work for you?

Regards
Pierre
On Mon, Mar 18, 2019 at 10:53 AM Pierre Tardy  wrote:

> Hi,
>
> We have our own GSoC project to transition the UI from coffeescript:
>
> https://github.com/buildbot/buildbot/wiki/Buildbot-GSoC-Projects-2019#transition-web-uis-data-module-from-coffeescript-to-typescript
> The ideal would be to have one student for each project.
>
> All the pointers are there. I would be happy to help on either project.
>
> Regards,
> Pierre
>
> On Mon, Mar 18, 2019 at 9:41 AM Mojca Miklavec  wrote:
>
>> Dear Rajdeep,
>>
>> On Sun, 17 Mar 2019 at 19:55, Rajdeep Bharat wrote:
>> >
>> > Hello, I am Rajdeep, a GSoC aspirant.
>> > I was going through the Buildbot views project and had a few doubts:
>> > - Do I need to work on the dashboards SPA of buildbots (
>> https://github.com/buildbot/guanlecoja-ui) and rewrite it using a modern
>> library like React?
>> > - I have read this ticket: https://trac.macports.org/ticket/55978. Do
>> I have to implement them separately in a MacPorts repository of buildbot,
>> or do it in upstream directly?
>> >
>> > I am familiarizing myself with the buildbot codebase and would love to
>> start contributing.
>> > Can someone tell me if I'm on the right track?
>>
>> Thank you very much for reaching to us. I still owe you the response
>> to the earlier email, but let's start with this one.
>>
>> The "buildbot idea" would be (co)mentored by someone from the Buildbot
>> development team for the technical part ("How to do it?"), while the
>> MacPorts mentor would help to steer towards the desired goal ("What to
>> do?").
>>
>> So I would like to ask Pierre to explain the technical part in more
>> details.
>>
>> (Pierre, how does the unfinished Coffeescript to Typescript conversion
>> of the core affect designing new views and their "future-proof-ness"?)
>>
>> What I want to say from the MacPorts point of view is that what mainly
>> kept us from switching to buildbot version beyond 0.8.x was a less
>> user-friendly waterfall view. We kept postponing the switch since the
>> time the buildbot was still at version 0.9.x. Now it's already at 2.x,
>> and it would be about a high time that we do the upgrade. The existing
>> buildbot setup was written in cca. 3 days during our in-person
>> developer meeting in 2016, and then slightly improved over time.
>>
>> The changes would be added wherever it makes the most sense. If
>> there's some view that's specific to MacPorts, we would keep it
>> locally, while any other change that's considered useful for any
>> buildbot user would best be pushed to their own repository (and
>> reviewed by the buildbot development team).
>>
>> I wanted to add that this project is well related to the "collection
>> of build statistics" idea. I will elaborate on this later, but we
>> definitely need changes in the buildbot configuration to make it
>> easier for our (hopefully) future web application to talk to the
>> buildbot master.
>>
>> Mojca
>>
>>
>> Mojca
>>
> --
>
>
> --

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi Rajdeep,

I created a pull request against the react boilerplate to cleanup the
angular.js integration:
https://github.com/uglycoyote/buildbot-react-plugin-boilerplate/pull/1

I guess using this method should work better for you for vue.js as well.

Pierre

On Fri, Mar 22, 2019 at 9:10 AM Rajdeep Bharati 
wrote:

> Yes, I can see it.
>
> On Fri, Mar 22, 2019 at 1:16 PM Pierre Tardy  wrote:
>
>> Hi Rajdeep.
>> I commented in the code. Do you see the comments?
>>
>> https://github.com/rajdeepbharati/buildbot-vue-plugin-boilerplate/commit/a1ff8178a327b52757d63e907036b6586a9cf5cc
>>
>> Pierre
>>
>> On Fri, Mar 22, 2019 at 8:35 AM Pierre Tardy  wrote:
>>
>>> Hi,
>>>
>>> Vue and React are the two major JS frameworks in 2018/2019. React is
>>> still the major one, probably thanks to the fact that react-native is very
>>> useful for mobile. So learning react allows you to make both webapps and
>>> mobile apps (even if you cannot really share UI code between the two
>>> frameworks)
>>>
>>> For the web, I like Vue better, recommend it and use it for all my new
>>> web projects, because I think it is easier to use, and produce less complex
>>> code for simple projects.
>>> I think react best practices are oriented more toward very large web
>>> apps, and using them for smaller apps is for me a waste of ressource.
>>> React indeed only support one way binding, and forces people to use
>>> state store like redux, which is for me very hard to use right, and
>>> requires lots of boilerplate code.
>>>
>>> On the contrary, vue.js scales better and allows you to write clean and
>>> readable code for small components, thanks to its support for two way
>>> binding.
>>> It is in my opinon easier for the beginner as its basic concepts are
>>> simple to comprehend, and harder to make it wrong.
>>> Vue still supports state store with vuex, which you can use when your
>>> app is large enough to require it.
>>>
>>> So I think vue is the best compromise between ideas from angular and
>>> ideas from react.
>>>
>>> This is good for a novice web developer to have experience in both,
>>> hence I asked Rajdeep to also consider vue.
>>> I challenged him to adapt the boilerplate to vue, because I was
>>> impressed he was able to set up so quickly.
>>> So I suggested a bit harder challenge to test how far we can go in the
>>> expectations. This is fine to struggle on a challenge, or else it is not a
>>> challenge :)
>>>
>>> Finally, challenge aside, you may decide which framework you want to use
>>> in your project I don't want to force you :)
>>>
>>>
>>> Pierre
>>>
>>>
>>> On Fri, Mar 22, 2019 at 5:13 AM Mojca Miklavec 
>>> wrote:
>>>
>>>> Dear Pierre,
>>>>
>>>> Out of curiosity: what is the difference between the two frameworks? I
>>>> mean, not technical difference, but I assume that the solution would only
>>>> be provided / written in one of the frameworks? Is Vue.js your internal
>>>> preference or newer trend over React.js? (I have some experience with
>>>> React, none with Vue.)
>>>>
>>>> Mojca
>>>>
>>> --
>>>
>>>
>>> --
>>
>>
>> --

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

On Fri, Mar 22, 2019 at 12:27 PM Rajdeep Bharati 
wrote:

> I set up the project according to your PR and it's working fine using
> React. For setting it up with Vue, do I need to write the components in
> typescript? Also, I had a doubt: after making changes to the code and
> testing, do I need to run `pip install -e .` again and again? The webpack
> or gulp dev server isn't working for me.
>

You make the pip install -e . once,
and then, after that you can run

npm run watch

to rebuild the code.

You will need to be part of the plugin system to be able to query the
buildbot api.
buildbot has its own API for having the latest commit (the change api)

Pierre

>
> Rajdeep
>
> On Fri, Mar 22, 2019 at 3:38 PM Rajdeep Bharati <
> rajdeepbharat...@gmail.com> wrote:
>
>> Thanks, I'll check it out.
>>
>> On Fri, Mar 22, 2019 at 3:12 PM Pierre Tardy  wrote:
>>
>>> Hi Rajdeep,
>>>
>>> I created a pull request against the react boilerplate to cleanup the
>>> angular.js integration:
>>> https://github.com/uglycoyote/buildbot-react-plugin-boilerplate/pull/1
>>>
>>> I guess using this method should work better for you for vue.js as well.
>>>
>>> Pierre
>>>
>>> On Fri, Mar 22, 2019 at 9:10 AM Rajdeep Bharati <
>>> rajdeepbharat...@gmail.com> wrote:
>>>
>>>> Yes, I can see it.
>>>>
>>>> On Fri, Mar 22, 2019 at 1:16 PM Pierre Tardy  wrote:
>>>>
>>>>> Hi Rajdeep.
>>>>> I commented in the code. Do you see the comments?
>>>>>
>>>>> https://github.com/rajdeepbharati/buildbot-vue-plugin-boilerplate/commit/a1ff8178a327b52757d63e907036b6586a9cf5cc
>>>>>
>>>>> Pierre
>>>>>
>>>>> On Fri, Mar 22, 2019 at 8:35 AM Pierre Tardy  wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Vue and React are the two major JS frameworks in 2018/2019. React is
>>>>>> still the major one, probably thanks to the fact that react-native is 
>>>>>> very
>>>>>> useful for mobile. So learning react allows you to make both webapps and
>>>>>> mobile apps (even if you cannot really share UI code between the two
>>>>>> frameworks)
>>>>>>
>>>>>> For the web, I like Vue better, recommend it and use it for all my
>>>>>> new web projects, because I think it is easier to use, and produce less
>>>>>> complex code for simple projects.
>>>>>> I think react best practices are oriented more toward very large web
>>>>>> apps, and using them for smaller apps is for me a waste of ressource.
>>>>>> React indeed only support one way binding, and forces people to use
>>>>>> state store like redux, which is for me very hard to use right, and
>>>>>> requires lots of boilerplate code.
>>>>>>
>>>>>> On the contrary, vue.js scales better and allows you to write clean
>>>>>> and readable code for small components, thanks to its support for two way
>>>>>> binding.
>>>>>> It is in my opinon easier for the beginner as its basic concepts are
>>>>>> simple to comprehend, and harder to make it wrong.
>>>>>> Vue still supports state store with vuex, which you can use when your
>>>>>> app is large enough to require it.
>>>>>>
>>>>>> So I think vue is the best compromise between ideas from angular and
>>>>>> ideas from react.
>>>>>>
>>>>>> This is good for a novice web developer to have experience in both,
>>>>>> hence I asked Rajdeep to also consider vue.
>>>>>> I challenged him to adapt the boilerplate to vue, because I was
>>>>>> impressed he was able to set up so quickly.
>>>>>> So I suggested a bit harder challenge to test how far we can go in
>>>>>> the expectations. This is fine to struggle on a challenge, or else it is
>>>>>> not a challenge :)
>>>>>>
>>>>>> Finally, challenge aside, you may decide which framework you want to
>>>>>> use in your project I don't want to force you :)
>>>>>>
>>>>>>
>>>>>> Pierre
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 22, 2019 at 5:13 AM Mojca Miklavec 
>>>>>> wrote:
>>>>>>
>>>>>>> Dear Pierre,
>>>>>>>
>>>>>>> Out of curiosity: what is the difference between the two frameworks?
>>>>>>> I mean, not technical difference, but I assume that the solution would 
>>>>>>> only
>>>>>>> be provided / written in one of the frameworks? Is Vue.js your internal
>>>>>>> preference or newer trend over React.js? (I have some experience with
>>>>>>> React, none with Vue.)
>>>>>>>
>>>>>>> Mojca
>>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> --
>>>>>
>>>>>
>>>>> --
>>>
>>>
>>> --

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

>  I am slightly concerned about Vue's market share
compared to React

The market share is indeed different, but this is in a huge market.

[image: image.png][image: image.png]

[image: image.png]
hopefully mailman won't mind the html email :-}

Pierre

On Fri, Mar 22, 2019 at 5:35 PM Mojca Miklavec  wrote:

> Dear Pierre,
>
> On Fri, 22 Mar 2019 at 08:34, Pierre Tardy wrote:
> >
> > Hi,
> >
> > Vue and React are the two major JS frameworks in 2018/2019. React is
> still the major one, probably thanks to the fact that react-native is very
> useful for mobile. So learning react allows you to make both webapps and
> mobile apps (even if you cannot really share UI code between the two
> frameworks)
> >
> > For the web, I like Vue better, recommend it and use it for all my new
> web projects, because I think it is easier to use, and produce less complex
> code for simple projects.
> > I think react best practices are oriented more toward very large web
> apps, and using them for smaller apps is for me a waste of ressource.
> > React indeed only support one way binding, and forces people to use
> state store like redux, which is for me very hard to use right, and
> requires lots of boilerplate code.
> >
> > On the contrary, vue.js scales better and allows you to write clean and
> readable code for small components, thanks to its support for two way
> binding.
> > It is in my opinon easier for the beginner as its basic concepts are
> simple to comprehend, and harder to make it wrong.
> > Vue still supports state store with vuex, which you can use when your
> app is large enough to require it.
> >
> > So I think vue is the best compromise between ideas from angular and
> ideas from react.
>
> Thanks a lot for the very detailed and useful summary. I tried to
> google a bit, but I could not get it so clearly explained for the sake
> of our needs :)
>
> > This is good for a novice web developer to have experience in both,
> hence I asked Rajdeep to also consider vue.
> > I challenged him to adapt the boilerplate to vue, because I was
> impressed he was able to set up so quickly.
> > So I suggested a bit harder challenge to test how far we can go in the
> expectations. This is fine to struggle on a challenge, or else it is not a
> challenge :)
>
> Sure, I have nothing against good challenges :)
> I just wanted to fully understand the direction in which you wanted to
> head.
>
> > Finally, challenge aside, you may decide which framework you want to use
> in your project I don't want to force you :)
>
> Personally I don't have any strong preferences yet and would trust
> your judgement. As long as it's not something that needs to be
> replaced after four months as that framework just got out of fashion,
> I'm fine with it. I am slightly concerned about Vue's market share
> compared to React, but I still lack the expertise to judge any better.
> (Tcl is also a quite neat language, but it's market share is
> problematic to attract new contributors to the project.)
>
> I would like the project to add some elements specific to macports to
> our local configuration, but ideally as little as possible and the
> project would be done in a way that it would serve plenty of other
> buildbot users, not just us. In that case it makes sense to follow
> buildbot's preferences, not ours, even if we had any.
>
> Mojca
>
--

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi,

Vue and React are the two major JS frameworks in 2018/2019. React is still
the major one, probably thanks to the fact that react-native is very useful
for mobile. So learning react allows you to make both webapps and mobile
apps (even if you cannot really share UI code between the two frameworks)

For the web, I like Vue better, recommend it and use it for all my new web
projects, because I think it is easier to use, and produce less complex
code for simple projects.
I think react best practices are oriented more toward very large web apps,
and using them for smaller apps is for me a waste of ressource.
React indeed only support one way binding, and forces people to use state
store like redux, which is for me very hard to use right, and requires lots
of boilerplate code.

On the contrary, vue.js scales better and allows you to write clean and
readable code for small components, thanks to its support for two way
binding.
It is in my opinon easier for the beginner as its basic concepts are simple
to comprehend, and harder to make it wrong.
Vue still supports state store with vuex, which you can use when your app
is large enough to require it.

So I think vue is the best compromise between ideas from angular and ideas
from react.

This is good for a novice web developer to have experience in both, hence I
asked Rajdeep to also consider vue.
I challenged him to adapt the boilerplate to vue, because I was impressed
he was able to set up so quickly.
So I suggested a bit harder challenge to test how far we can go in the
expectations. This is fine to struggle on a challenge, or else it is not a
challenge :)

Finally, challenge aside, you may decide which framework you want to use in
your project I don't want to force you :)


Pierre


On Fri, Mar 22, 2019 at 5:13 AM Mojca Miklavec  wrote:

> Dear Pierre,
>
> Out of curiosity: what is the difference between the two frameworks? I
> mean, not technical difference, but I assume that the solution would only
> be provided / written in one of the frameworks? Is Vue.js your internal
> preference or newer trend over React.js? (I have some experience with
> React, none with Vue.)
>
> Mojca
>
--

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi Rajdeep.
I commented in the code. Do you see the comments?
https://github.com/rajdeepbharati/buildbot-vue-plugin-boilerplate/commit/a1ff8178a327b52757d63e907036b6586a9cf5cc

Pierre

On Fri, Mar 22, 2019 at 8:35 AM Pierre Tardy  wrote:

> Hi,
>
> Vue and React are the two major JS frameworks in 2018/2019. React is still
> the major one, probably thanks to the fact that react-native is very useful
> for mobile. So learning react allows you to make both webapps and mobile
> apps (even if you cannot really share UI code between the two frameworks)
>
> For the web, I like Vue better, recommend it and use it for all my new web
> projects, because I think it is easier to use, and produce less complex
> code for simple projects.
> I think react best practices are oriented more toward very large web apps,
> and using them for smaller apps is for me a waste of ressource.
> React indeed only support one way binding, and forces people to use state
> store like redux, which is for me very hard to use right, and requires lots
> of boilerplate code.
>
> On the contrary, vue.js scales better and allows you to write clean and
> readable code for small components, thanks to its support for two way
> binding.
> It is in my opinon easier for the beginner as its basic concepts are
> simple to comprehend, and harder to make it wrong.
> Vue still supports state store with vuex, which you can use when your app
> is large enough to require it.
>
> So I think vue is the best compromise between ideas from angular and ideas
> from react.
>
> This is good for a novice web developer to have experience in both, hence
> I asked Rajdeep to also consider vue.
> I challenged him to adapt the boilerplate to vue, because I was impressed
> he was able to set up so quickly.
> So I suggested a bit harder challenge to test how far we can go in the
> expectations. This is fine to struggle on a challenge, or else it is not a
> challenge :)
>
> Finally, challenge aside, you may decide which framework you want to use
> in your project I don't want to force you :)
>
>
> Pierre
>
>
> On Fri, Mar 22, 2019 at 5:13 AM Mojca Miklavec  wrote:
>
>> Dear Pierre,
>>
>> Out of curiosity: what is the difference between the two frameworks? I
>> mean, not technical difference, but I assume that the solution would only
>> be provided / written in one of the frameworks? Is Vue.js your internal
>> preference or newer trend over React.js? (I have some experience with
>> React, none with Vue.)
>>
>> Mojca
>>
> --
>
>
> --

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi Rajdeep,

We already have a yeoman generator:
https://github.com/buildbot/guanlecoja/tree/master/generator-guanlecoja

I think the current boilerplate has more than just boilerplate.
It also has some code that could be factorized.
It is better not to put too much in a generator, as it is hard to
upgrade after a first instanciation
So I would recommend a generator plus a library.

Regards
Pierre
Pierre

Le lun. 8 avr. 2019 à 18:44, Rajdeep Bharati
 a écrit :
>
> @Mojca Miklavec Oh, I see.
>
> @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?
>
> Thank you for help.
> Rajdeep
>
> On Mon, Apr 8, 2019 at 7:05 PM Mojca Miklavec  wrote:
>>
>> Dear Rajdeep,
>>
>> On Sun, 7 Apr 2019 at 19:41, Rajdeep Bharati wrote:
>> >
>> > I found something which might help us: https://bors.tech/homu-io/ 
>> > https://github.com/barosl/homu.
>> > I will try it set it up on my local system and get back to you.
>> > Mojca
>>
>> This sounds nice, but I wonder if it would actually address any of our
>> problems (I suspect not). Also, it explicitly says that the project
>> was kind of abandoned and continued elsewhere?
>>
>> What this tool is trying to solve is to check the code again after
>> potentially long code review process, and run CI again "just before
>> merging". However some of our builds would take hours, or, well, on
>> Travis you might get 2 hours of waiting time and then one hour of
>> building, just to experience a timeout at the end anyway. This makes
>> the "just before merging" kind of not-too-well-defined. Plus, half of
>> our Travis failures are false negatives, and before this can be useful
>> on the buildbot, we would need to be able to enable checking pull
>> requests in a "safe way" (addendum: for such checking we could
>> probably just as well engage a couple of machines which are completely
>> decoupled from our main builders, which would run, say, just 10.5,
>> 10.6, 10.9, and would not upload the results anywhere). When checking
>> the base ... we have so little activity that this is practically never
>> an issue. And with ports there are so many distinct ports, that this
>> is also hardly ever an issue; and when it is, you would already notice
>> that the PR cannot be merged.
>>
>> Mojca

Re: GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

A javascript library which you can simply call from your main.js and
which will implement all the boilerplate needed to connect your vue
component to the angularjs application

Regards
Pierre

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

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

> Could you add them to the project ?

Done.

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

Hi Rajdeep,

Buildbot calculates the version number based on tags. You you have to
fetch all the tags so that the version is correctly calculated.

git fetch --tags --all

then you can re-do the make virtualenv

Regards
Pierre

Le mar. 14 mai 2019 à 11:39, Rajdeep Bharati
 a écrit :
>
> Thanks for the feedback!
>
> I had a doubt in buildbot:
> When I install buildbot from source (github), then why is it showing version 
> 2.1.1dev... installed? Shouldn't it show the latest version (2.3.0)? It is up 
> to date with the master branch.
>
> Thank you.
> Rajdeep
>
> On Fri, May 10, 2019 at 3:17 AM Mojca Miklavec  wrote:
>>
>> On Wed, 8 May 2019 at 21:00, Rajdeep Bharati wrote:
>> >
>> > Hi,
>> >
>> > I created some issues and found some which would be relevant for the 
>> > project (as discussed in the IRC meeting):
>> >
>> > https://github.com/buildbot/buildbot/issues/4760
>> > https://github.com/buildbot/buildbot/issues/4761
>> > https://github.com/buildbot/buildbot/issues/4709
>> > https://github.com/buildbot/buildbot/issues/3471
>> > https://github.com/buildbot/buildbot/issues/3470
>> > https://github.com/buildbot/buildbot/issues/4750
>>
>> Thank you.
>> (Nice to see that I'm not the first one requesting these :)
>>
>> I assume that we'll also want to add other items for the rest of the
>> summer to that list?
>>
>> > @Mojca Miklavec Yesterday you mentioned:
>> >>
>> >> 16:33:15  regarding the features of the default waterfall view, 
>> >> another problem I saw was that unless one of the builds was done 
>> >> recently, the builder doesn't even show in waterfall; for example, there 
>> >> is no texlive or pplib displayed on 
>> >> https://build.contextgarden.net/#/waterfall
>>
>> And later Pierre said this was a feature :)
>>
>> > However, I am unable to find this problem in 
>> > https://nine.buildbot.net/#/waterfall (it's showing the builders not 
>> > having recent builds). I'm not sure (it might have been configured in that 
>> > manner in nine.buildbot, and not present by default).
>> >
>> > I will try to replicate this issue in my local setup.
>>
>> If you look at
>> https://build.contextgarden.net/#/console
>> you can see that there is a huge number of "fake commits" from one
>> project (from periodic scheduler) after the last build of another
>> project was done. Maybe there's a setting which tells you how many
>> latest builds / commits to fetch when drawing the waterfall view. I
>> didn't try to investigate what limits the number of displayed
>> builders.
>>
>> Now: for me by far more important missing feature is in fact support
>> for filtering on both console and waterfall. Once filtering and
>> removal of old builders gets implemented, this particular issue will
>> be less important.
>>
>> Mojca

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

Can you please make a PR?

Thanks
Pierre

Le mar. 21 mai 2019 à 16:21, Rajdeep Bharati
 a écrit :
>
> There's a bug in 
> https://github.com/buildbot/buildbot/blob/master/www/base/src/app/app.module.js
> Changes haven't been `require`d.
> These lines need to be added:
> require('./changes/changes.controller.js');
> require('./changes/changes.route.js');
> It's working after adding them
>
> Rajdeep
>
> On Tue, May 21, 2019 at 7:33 PM Pierre Tardy  wrote:
>>
>> Ouch, and we have https://buildbot.buildbot.net/ which is down
>> (probably because of that )
>>
>> looking at it..
>> Pierre
>>
>> Le mar. 21 mai 2019 à 15:57, Rajdeep Bharati
>>  a écrit :
>> >
>> > Hi
>> >
>> > I am having one issue with the buildbot (I think it's happening after the 
>> > new webpack PR, but not sure).
>> > In the navigation menu, `Last Changes` isn't displayed. I have used the 
>> > same buildmaster that I was using before
>> > (also tried polling different repositories).
>> >
>> > Could you tell me whether everything is okay on my side?
>> >
>> > Thanks
>> > Rajdeep
>> >
>> > On Sat, May 18, 2019 at 1:32 PM Rajdeep Bharati 
>> >  wrote:
>> >>
>> >> Thank you. Now it's working
>> >>
>> >> Rajdeep
>> >>
>> >> On Sat, May 18, 2019 at 12:29 PM Pierre Tardy  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> The buildbot_badges plugin is using cairo. You can try to uninstall
>> >>> that to move forward
>> >>> Pierre
>> >>>
>> >>> Le sam. 18 mai 2019 à 07:58, Rajdeep Bharati
>> >>>  a écrit :
>> >>> >
>> >>> > Hi,
>> >>> > I was trying out the webpack PR. Here's what I did:
>> >>> >
>> >>> > clone the branch git clone --single-branch --branch www-webpack 
>> >>> > https://github.com/p12tic/buildbot.git buildbotwebpack
>> >>> > cd, make virtualenv, activate
>> >>> > make frontend
>> >>> > Then outside the directory, I did:
>> >>> >
>> >>> > buildbot create-master wpmaster
>> >>> >
>> >>> > Now I got the following error:
>> >>> >
>> >>> > raise OSError("dlopen() failed to load a library: %s" % ' / 
>> >>> > '.join(names))
>> >>> >
>> >>> > OSError: dlopen() failed to load a library: cairo / cairo-2 / 
>> >>> > cairo-gobject-2 / cairo.so.2
>> >>> >
>> >>> > This is the full stack trace: https://pastebin.com/eDk9GVRK
>> >>> > There are some answers on SO, but they are using homebrew python (I'm 
>> >>> > using macports py). I guess that's why they didn't work?
>> >>> > Could you please help?
>> >>> >
>> >>> > Thank you.
>> >>> > Rajdeep
>> >>> >
>> >>> > On Wed, May 15, 2019 at 5:20 PM Rajdeep Bharati 
>> >>> >  wrote:
>> >>> >>
>> >>> >> Ok cool!
>> >>> >>
>> >>> >> Thanks
>> >>> >> Rajdeep
>> >>> >>
>> >>> >> On Wed, May 15, 2019 at 1:29 PM Pierre Tardy  wrote:
>> >>> >>>
>> >>> >>> Hi Rajdeep,
>> >>> >>>
>> >>> >>> Buildbot calculates the version number based on tags. You you have to
>> >>> >>> fetch all the tags so that the version is correctly calculated.
>> >>> >>>
>> >>> >>> git fetch --tags --all
>> >>> >>>
>> >>> >>> then you can re-do the make virtualenv
>> >>> >>>
>> >>> >>> Regards
>> >>> >>> Pierre
>> >>> >>>
>> >>> >>> Le mar. 14 mai 2019 à 11:39, Rajdeep Bharati
>> >>> >>>  a écrit :
>> >>> >>> >
>> >>> >>> > Thanks for the feedback!
>> >>> >>> >
>> >>> >>> > I had a doubt in buildbot:
>> >>> >>> > When I install buildbot from source (github), then why is it 
>> >>> >>> > showing version 2.1.1dev... instal

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

I re-up buildbot.buildbot.net

But the console view is broken.
https://github.com/buildbot/buildbot/issues/4777

Can you also have a look at this?

I can also see that buildbot_travis do not build anymore
https://github.com/buildbot/buildbot/issues/4778

probably I did merge the webpack PR a bit too early :)

Regards
Pierre

Le mar. 21 mai 2019 à 16:33, Rajdeep Bharati
 a écrit :
>
> Done.
>
> On Tue, May 21, 2019 at 7:54 PM Pierre Tardy  wrote:
>>
>> Can you please make a PR?
>>
>> Thanks
>> Pierre
>>
>> Le mar. 21 mai 2019 à 16:21, Rajdeep Bharati
>>  a écrit :
>> >
>> > There's a bug in 
>> > https://github.com/buildbot/buildbot/blob/master/www/base/src/app/app.module.js
>> > Changes haven't been `require`d.
>> > These lines need to be added:
>> > require('./changes/changes.controller.js');
>> > require('./changes/changes.route.js');
>> > It's working after adding them
>> >
>> > Rajdeep
>> >
>> > On Tue, May 21, 2019 at 7:33 PM Pierre Tardy  wrote:
>> >>
>> >> Ouch, and we have https://buildbot.buildbot.net/ which is down
>> >> (probably because of that )
>> >>
>> >> looking at it..
>> >> Pierre
>> >>
>> >> Le mar. 21 mai 2019 à 15:57, Rajdeep Bharati
>> >>  a écrit :
>> >> >
>> >> > Hi
>> >> >
>> >> > I am having one issue with the buildbot (I think it's happening after 
>> >> > the new webpack PR, but not sure).
>> >> > In the navigation menu, `Last Changes` isn't displayed. I have used the 
>> >> > same buildmaster that I was using before
>> >> > (also tried polling different repositories).
>> >> >
>> >> > Could you tell me whether everything is okay on my side?
>> >> >
>> >> > Thanks
>> >> > Rajdeep
>> >> >
>> >> > On Sat, May 18, 2019 at 1:32 PM Rajdeep Bharati 
>> >> >  wrote:
>> >> >>
>> >> >> Thank you. Now it's working
>> >> >>
>> >> >> Rajdeep
>> >> >>
>> >> >> On Sat, May 18, 2019 at 12:29 PM Pierre Tardy  wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> The buildbot_badges plugin is using cairo. You can try to uninstall
>> >> >>> that to move forward
>> >> >>> Pierre
>> >> >>>
>> >> >>> Le sam. 18 mai 2019 à 07:58, Rajdeep Bharati
>> >> >>>  a écrit :
>> >> >>> >
>> >> >>> > Hi,
>> >> >>> > I was trying out the webpack PR. Here's what I did:
>> >> >>> >
>> >> >>> > clone the branch git clone --single-branch --branch www-webpack 
>> >> >>> > https://github.com/p12tic/buildbot.git buildbotwebpack
>> >> >>> > cd, make virtualenv, activate
>> >> >>> > make frontend
>> >> >>> > Then outside the directory, I did:
>> >> >>> >
>> >> >>> > buildbot create-master wpmaster
>> >> >>> >
>> >> >>> > Now I got the following error:
>> >> >>> >
>> >> >>> > raise OSError("dlopen() failed to load a library: %s" % ' / 
>> >> >>> > '.join(names))
>> >> >>> >
>> >> >>> > OSError: dlopen() failed to load a library: cairo / cairo-2 / 
>> >> >>> > cairo-gobject-2 / cairo.so.2
>> >> >>> >
>> >> >>> > This is the full stack trace: https://pastebin.com/eDk9GVRK
>> >> >>> > There are some answers on SO, but they are using homebrew python 
>> >> >>> > (I'm using macports py). I guess that's why they didn't work?
>> >> >>> > Could you please help?
>> >> >>> >
>> >> >>> > Thank you.
>> >> >>> > Rajdeep
>> >> >>> >
>> >> >>> > On Wed, May 15, 2019 at 5:20 PM Rajdeep Bharati 
>> >> >>> >  wrote:
>> >> >>> >>
>> >> >>> >> Ok cool!
>> >> >>> >>
>> >> >>> >> Thanks
>> >> >>> >&

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

Ouch, and we have https://buildbot.buildbot.net/ which is down
(probably because of that )

looking at it..
Pierre

Le mar. 21 mai 2019 à 15:57, Rajdeep Bharati
 a écrit :
>
> Hi
>
> I am having one issue with the buildbot (I think it's happening after the new 
> webpack PR, but not sure).
> In the navigation menu, `Last Changes` isn't displayed. I have used the same 
> buildmaster that I was using before
> (also tried polling different repositories).
>
> Could you tell me whether everything is okay on my side?
>
> Thanks
> Rajdeep
>
> On Sat, May 18, 2019 at 1:32 PM Rajdeep Bharati  
> wrote:
>>
>> Thank you. Now it's working
>>
>> Rajdeep
>>
>> On Sat, May 18, 2019 at 12:29 PM Pierre Tardy  wrote:
>>>
>>> Hi,
>>>
>>> The buildbot_badges plugin is using cairo. You can try to uninstall
>>> that to move forward
>>> Pierre
>>>
>>> Le sam. 18 mai 2019 à 07:58, Rajdeep Bharati
>>>  a écrit :
>>> >
>>> > Hi,
>>> > I was trying out the webpack PR. Here's what I did:
>>> >
>>> > clone the branch git clone --single-branch --branch www-webpack 
>>> > https://github.com/p12tic/buildbot.git buildbotwebpack
>>> > cd, make virtualenv, activate
>>> > make frontend
>>> > Then outside the directory, I did:
>>> >
>>> > buildbot create-master wpmaster
>>> >
>>> > Now I got the following error:
>>> >
>>> > raise OSError("dlopen() failed to load a library: %s" % ' / '.join(names))
>>> >
>>> > OSError: dlopen() failed to load a library: cairo / cairo-2 / 
>>> > cairo-gobject-2 / cairo.so.2
>>> >
>>> > This is the full stack trace: https://pastebin.com/eDk9GVRK
>>> > There are some answers on SO, but they are using homebrew python (I'm 
>>> > using macports py). I guess that's why they didn't work?
>>> > Could you please help?
>>> >
>>> > Thank you.
>>> > Rajdeep
>>> >
>>> > On Wed, May 15, 2019 at 5:20 PM Rajdeep Bharati 
>>> >  wrote:
>>> >>
>>> >> Ok cool!
>>> >>
>>> >> Thanks
>>> >> Rajdeep
>>> >>
>>> >> On Wed, May 15, 2019 at 1:29 PM Pierre Tardy  wrote:
>>> >>>
>>> >>> Hi Rajdeep,
>>> >>>
>>> >>> Buildbot calculates the version number based on tags. You you have to
>>> >>> fetch all the tags so that the version is correctly calculated.
>>> >>>
>>> >>> git fetch --tags --all
>>> >>>
>>> >>> then you can re-do the make virtualenv
>>> >>>
>>> >>> Regards
>>> >>> Pierre
>>> >>>
>>> >>> Le mar. 14 mai 2019 à 11:39, Rajdeep Bharati
>>> >>>  a écrit :
>>> >>> >
>>> >>> > Thanks for the feedback!
>>> >>> >
>>> >>> > I had a doubt in buildbot:
>>> >>> > When I install buildbot from source (github), then why is it showing 
>>> >>> > version 2.1.1dev... installed? Shouldn't it show the latest version 
>>> >>> > (2.3.0)? It is up to date with the master branch.
>>> >>> >
>>> >>> > Thank you.
>>> >>> > Rajdeep
>>> >>> >
>>> >>> > On Fri, May 10, 2019 at 3:17 AM Mojca Miklavec  
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> On Wed, 8 May 2019 at 21:00, Rajdeep Bharati wrote:
>>> >>> >> >
>>> >>> >> > Hi,
>>> >>> >> >
>>> >>> >> > I created some issues and found some which would be relevant for 
>>> >>> >> > the project (as discussed in the IRC meeting):
>>> >>> >> >
>>> >>> >> > https://github.com/buildbot/buildbot/issues/4760
>>> >>> >> > https://github.com/buildbot/buildbot/issues/4761
>>> >>> >> > https://github.com/buildbot/buildbot/issues/4709
>>> >>> >> > https://github.com/buildbot/buildbot/issues/3471
>>> >>> >> > https://github.com/buildbot/buildbot/issues/3470
>>> >>> >> > https://github.com/buildbot/buildbot/issue

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

Hi,

The buildbot_badges plugin is using cairo. You can try to uninstall
that to move forward
Pierre

Le sam. 18 mai 2019 à 07:58, Rajdeep Bharati
 a écrit :
>
> Hi,
> I was trying out the webpack PR. Here's what I did:
>
> clone the branch git clone --single-branch --branch www-webpack 
> https://github.com/p12tic/buildbot.git buildbotwebpack
> cd, make virtualenv, activate
> make frontend
> Then outside the directory, I did:
>
> buildbot create-master wpmaster
>
> Now I got the following error:
>
> raise OSError("dlopen() failed to load a library: %s" % ' / '.join(names))
>
> OSError: dlopen() failed to load a library: cairo / cairo-2 / cairo-gobject-2 
> / cairo.so.2
>
> This is the full stack trace: https://pastebin.com/eDk9GVRK
> There are some answers on SO, but they are using homebrew python (I'm using 
> macports py). I guess that's why they didn't work?
> Could you please help?
>
> Thank you.
> Rajdeep
>
> On Wed, May 15, 2019 at 5:20 PM Rajdeep Bharati  
> wrote:
>>
>> Ok cool!
>>
>> Thanks
>> Rajdeep
>>
>> On Wed, May 15, 2019 at 1:29 PM Pierre Tardy  wrote:
>>>
>>> Hi Rajdeep,
>>>
>>> Buildbot calculates the version number based on tags. You you have to
>>> fetch all the tags so that the version is correctly calculated.
>>>
>>> git fetch --tags --all
>>>
>>> then you can re-do the make virtualenv
>>>
>>> Regards
>>> Pierre
>>>
>>> Le mar. 14 mai 2019 à 11:39, Rajdeep Bharati
>>>  a écrit :
>>> >
>>> > Thanks for the feedback!
>>> >
>>> > I had a doubt in buildbot:
>>> > When I install buildbot from source (github), then why is it showing 
>>> > version 2.1.1dev... installed? Shouldn't it show the latest version 
>>> > (2.3.0)? It is up to date with the master branch.
>>> >
>>> > Thank you.
>>> > Rajdeep
>>> >
>>> > On Fri, May 10, 2019 at 3:17 AM Mojca Miklavec  wrote:
>>> >>
>>> >> On Wed, 8 May 2019 at 21:00, Rajdeep Bharati wrote:
>>> >> >
>>> >> > Hi,
>>> >> >
>>> >> > I created some issues and found some which would be relevant for the 
>>> >> > project (as discussed in the IRC meeting):
>>> >> >
>>> >> > https://github.com/buildbot/buildbot/issues/4760
>>> >> > https://github.com/buildbot/buildbot/issues/4761
>>> >> > https://github.com/buildbot/buildbot/issues/4709
>>> >> > https://github.com/buildbot/buildbot/issues/3471
>>> >> > https://github.com/buildbot/buildbot/issues/3470
>>> >> > https://github.com/buildbot/buildbot/issues/4750
>>> >>
>>> >> Thank you.
>>> >> (Nice to see that I'm not the first one requesting these :)
>>> >>
>>> >> I assume that we'll also want to add other items for the rest of the
>>> >> summer to that list?
>>> >>
>>> >> > @Mojca Miklavec Yesterday you mentioned:
>>> >> >>
>>> >> >> 16:33:15  regarding the features of the default waterfall 
>>> >> >> view, another problem I saw was that unless one of the builds was 
>>> >> >> done recently, the builder doesn't even show in waterfall; for 
>>> >> >> example, there is no texlive or pplib displayed on 
>>> >> >> https://build.contextgarden.net/#/waterfall
>>> >>
>>> >> And later Pierre said this was a feature :)
>>> >>
>>> >> > However, I am unable to find this problem in 
>>> >> > https://nine.buildbot.net/#/waterfall (it's showing the builders not 
>>> >> > having recent builds). I'm not sure (it might have been configured in 
>>> >> > that manner in nine.buildbot, and not present by default).
>>> >> >
>>> >> > I will try to replicate this issue in my local setup.
>>> >>
>>> >> If you look at
>>> >> https://build.contextgarden.net/#/console
>>> >> you can see that there is a huge number of "fake commits" from one
>>> >> project (from periodic scheduler) after the last build of another
>>> >> project was done. Maybe there's a setting which tells you how many
>>> >> latest builds / commits to fetch when drawing the waterfall view. I
>>> >> didn't try to investigate what limits the number of displayed
>>> >> builders.
>>> >>
>>> >> Now: for me by far more important missing feature is in fact support
>>> >> for filtering on both console and waterfall. Once filtering and
>>> >> removal of old builders gets implemented, this particular issue will
>>> >> be less important.
>>> >>
>>> >> Mojca

GSOC 2020

[Pierre Tardy]

Hi,

GSOC 2020 has been announced, I haven't seen a thread yet on macports being
an org.

We discussed the topic within Buildbot community, and we think we don't
have enough of our users as student, and are not attractive enough to be
effective.
But last years experience partnering with Macports was great, and we would
like to renew it.

I don't know if this still makes sense for you to have a CI-dedicated GSOC
project idea, but Buildbot team will be officially happy to help with
mentoring of such project.

Regards,
Pierre