<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> chosen. So we gave up trying.<br>
<br>
If you gave up after just a single failure to apply, I don't really<br>
understand why giving up. I understand that GSOC team has troubles<br>
explaining to every single organisation why they were not chosen.<br></blockquote><div><br></div><div>Yes, this was probably more like a threshold, we also found that the admin work needed was quite big, and wanted to refocus our efforts to development.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Very often it can be just a big number of *better* applications<br>
(whatever 'better' means) and the limited number of slots. Just<br>
curious: did you ever attend the mentor meeting at Google?<br></blockquote><div><br></div><div>Personally, I was never able to attend, but I think we had some mentor there already. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I liked the GSOC mentoring though, and I would be glad to do it again.<br>
<br>
Then you should simply apply.<br></blockquote><div>or co-mentor with another project who do the admin work :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I acknowledge your pain points on Buildbot eight, and agree that nine will<br>
> probably not help that much with the current turnkey visualisation plugins.<br>
> Other people are also frustrated by the nine version of the waterfall,<br>
> including the webkit people <a href="https://github.com/buildbot/buildbot/issues/3884" rel="noreferrer" target="_blank">https://github.com/buildbot/buildbot/issues/3884</a><br>
> I added lengthy explaination in this issue on why it is like that and why it<br>
> is not easy to improve. But help is appreciated.<br>
><br>
> My suggestion for webkit is also valid for macports. What you may need is a<br>
> new UI plugin, which is carefully crafted for your requirements.<br>
<br>
Is this something that can be done in a generic way for other projects<br>
as well or is this really something that each project should prepare<br>
from scratch?<br></blockquote><div><br></div><div>The goal is to allow people with reasonable web frontend background to build their custom dashboard in 2 or 3 days.</div>Each project does not require that, this is why we try to have some generic versions.<br class="inbox-inbox-Apple-interchange-newline"><div><br></div><div>It is much harder to make generic tools than to make specific ones. We had a lot of issues with console and grid, which was working great with some people, but for other was not , because of the different SCM, or the different pipeline setup.</div><div>That is why Buildbot is a framework to build specific workflows.</div><div><br></div><div>For people with lots of builders, the design trade-off will be different. If we manage to build a new dashboard for people with lots of builders, I think this would be even better.</div><div>Doing first a specific one is a good first step, then we can show it to others and  step backward to see how it can be useful to them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I understand that probably creating summaries on per-port basis is<br>
something that should probably be done by us, but I can imagine that<br>
there should be some solution that would allow anyone to have a<br>
slightly better view.<br></blockquote><div>I am not sure exactly what you have in mind.</div><div>The grid view has builder tag support: <a href="https://nine.buildbot.net/#/grid">https://nine.buildbot.net/#/grid</a></div><div>You could setup your builders with a tag per port, and then use this kind of filtering in order to have a per port view.</div><div>We would need to change the UI for grid view, because obviously the current UI will be unusable for thousands of tags.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Just curious: do you have any examples of a super similar plugin that<br>
goes in this direction?</blockquote><div><br></div><div>The examples we have are the console/grid/waterfall plugins. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I think this is a very good match for a GSOC project. This would be a<br>
> project to address your points 3, 4 and 5.<br>
<br>
It would probably help to prepare a rough description together. I know<br>
what we need to achieve, but I don't know what needs to be done.<br></blockquote><div>I think we first need to have a sketch of the dashboard of how you see data is displayed. maybe several sketches with options, and then I can help to translate that with more technical details. This is also good to let some part of the technical details to the student proposal for easier filtering/selection.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(There's another thing: some potential students asked if it is<br>
necessary to have access to macOS to be able to apply with our org. My<br>
answer was that while this is not a strict requirement, it would<br>
greatly help if they do, in particular it would be nearly impossible<br>
to keep such students after GSOC is over. But if there are candidates<br>
who could stick with buildbot org, I don't mind at all.)<br></blockquote><div>Yes, for us it was very hard to keep student around, we had only one who did contribute from time to time for another 3-4 months.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I think this can be done by recruiting a front-end student. Probably this<br>
> kind is a bit easier to recruit, and the problem are simple enough to<br>
> enunciate clearly for a student.<br>
<br>
Except that I don't know how front-end students working on Linux/Mac<br>
would even notice MacPorts to look at project ideas :) :) :)<br></blockquote><div><br></div><div>Well GSoc is supposed to help for that. I believe we can tag the project front-end or javascript, and this will attract students. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
A new VM would be perfect, but I admit I have no clue what is required<br>
on macOS to do that.<br></blockquote><div>I think this good be sorted out by the student in the proposal build phase.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> In any case it is a tough problem that is not easy to resolve as basically<br>
> the goal of the CI is to give developers access to machines, a malicious<br>
> developer will easily take control of that machine.<br>
> A potential project for this problem would be to add some extra triggering<br>
> criterias for building a MR, like the approval of at least one trusted<br>
> member of the team.<br>
> It looks like a lone a bit short subject for GSoC, I would say.<br>
<br>
It could potentially be listed and then students can decide themselves<br>
which tasks they want to work on. But I believe it helps a lot if the<br>
mentor knows how to solve the problems himself/herself and only lacks<br>
time to do things, else it might be a bad experience in case a student<br>
is stuck. So if this task gets listed, someone needs to know how to<br>
implement a solution.<br></blockquote><div><br></div><div>That is why it is a bit harder. It is more like a research task were most of the work is finding out how to do it, then doing it is relatively straighforward once you found a solution. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
As far as mentoring is concerned, I know what we need, but I'm not<br>
familiar with frontend development at all, so I could not help a<br>
student stuck at technical issues, but could help guiding towards the<br>
desired goals.<br></blockquote><div>So this is a very good use of co-mentoring I can help with the technical issue, and you work on the goals.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Should we draft a project description and publish it on our ideas list<br>
(and potentially on your website as well in case some students<br>
interested in helping buildbot development stumble across it)?<br></blockquote><div><br></div><div>Yes, lets start it.</div><div>Like said earlier, having a drawing of what would be a good dashboard in your view is a good start, and then I can add some details on which data needs to be fetched and how they need to be gathered.</div><div><br></div><div>Pierre</div><div> </div></div></div>