Re: [dev-servo] Request for student team project proposals.

[Josh Matthews]

On 10/16/17 12:09 PM, Artur Jamro wrote:

Hi Josh,

Hope you are doing well. We will start contributing soon. Thus, we want to
ask who is going to be our reviewer? Have you already chosen someone?


It depends on who is available to review the changes when your group 
opens a new pull request. If you have questions about the work, it's 
best to ask them on this mailing list or in 
https://github.com/servo/servo/issues/6633 so that any of the Servo 
developers can help guide you.



And also another thing - do you have some spare money in your budget by any
chance? Most of the students during their Bachelor's thesis project get
paid for the work and it would be nice if we got even some small amount of
money for this project. It is not a must-be for us and it would not stop us
from contributing, but it is nice to have :)


If you get a faculty member to contact me, I can discuss this further 
with them.


Cheers,
Josh

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] GitHub Universe recap

[Emily Dunham]

Last week I attended and spoke about Servo's automation at GitHub Universe,
which as the name implies is our code hosting platform's flagship event.
The keynotes covered some new features that they've been rolling out
through the year and plan to release in the near future. Long story short,
they're slowly but surely building in most of the features that Servo has
been implementing with bots in the past.

* Since July, they've supported first-time contributor badges -
https://github.com/blog/2397-making-it-easier-to-grow-communities-on-github.
This is basically the lite version of our Highfive's welcome message.

* They're working on, though it's not released yet, a feature analogous to
the file-watching we implement through Highfive. If you want to be notified
on every PR that changes a given file in a repo that Highfive works on, you
can add yourself at
https://github.com/servo/highfive/blob/master/handlers/watchers/watchers.ini

* The annual report, https://octoverse.github.com/, is out. Congratulations
to Servo on being the 9th most discussed repo on GitHub!

* They're making it easier for new contributors to find communities by
giving special treatment to issues tagged "good first issue" and "help
wanted". They're basically building a GitHub-wide tool analogous to our
starters.servo.org. I've filed https://github.com/servo/servo/issues/18905
to discuss how we can take advantage of the free publicity from the special
tags.

- edunham
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Request for student team project proposals.

[Artur Jamro]

Hi Josh,

Hope you are doing well. We will start contributing soon. Thus, we want to
ask who is going to be our reviewer? Have you already chosen someone?

And also another thing - do you have some spare money in your budget by any
chance? Most of the students during their Bachelor's thesis project get
paid for the work and it would be nice if we got even some small amount of
money for this project. It is not a must-be for us and it would not stop us
from contributing, but it is nice to have :)

-- 
Regards,
Artur "Mrowqa" Jamro
www.mrowqa.pl 

2017-08-21 23:29 GMT+02:00 Josh Matthews :

> Just to confirm that your message was received - this sounds like a good
> plan to me. Please let me know if you would like any further information
> from me! https://github.com/servo/servo/issues/18178 is an example of a
> WebGL-related piece of work that could be very useful to Servo.
>
> Cheers,
> Josh
>
> Cheers,
> Josh
>
> On 8 August 2017 at 17:07, Artur Jamro  wrote:
>
>> Hi Josh,
>>
>> sorry for the long delay - we were discussing projects ourselves and when
>> we began our internships we forgot about sending a response to you. We are
>> more than happy to confirm that we want to work on MutationObserver API and
>> WebGL. Thank you for all your responses. If you do not have any further
>> questions for us, we will start contributing in the October, so you can
>> expect us on the mailing list and/or IRC channel :)
>>
>> --
>> Regards,
>> Artur "Mrowqa" Jamro
>> www.mrowqa.pl 
>>
>> 2017-07-06 12:08 GMT-07:00 Josh Matthews :
>>
>>> I too would like to apologize for the delay again; last week was
>>> extremely hectic for work reasons.
>>>
>>> I'm not sure exactly what time estimates you're looking for. All of
>>> these projects were selected such that it should be possible to complete
>>> the work during the project period (MutationObserver, network performance),
>>> or make a meaningful contribution to an large, incomplete area (WebGL), or
>>> make significant progress investigating an open interesting problem (event
>>> loops).
>>>
>>> As for more information about the event loop idea - our script thread
>>> event loop effectively looks like this:
>>>
>>> loop {
>>> /* perform a non-blocking receive operation on a large set of
>>> channels */
>>> let event = self.some_event_source.try_recv()
>>> .or_else(|| self.some_other_event_source.try_recv())
>>> .or_else(|| self.another_event_source.try_recv())
>>> };
>>> /* if the receive operation returned an event, process it. */
>>> if let Ok(event) = event {
>>> handle_event(event);
>>> }
>>> }
>>>
>>> The channels are thread-safe queues that other code uses to enqueue
>>> asynchronous events that will be processed in order. Unfortunately the
>>> channels allow no introspection, so there's no way to determine how many
>>> events are in the queue at any given time. If the event representing user
>>> input is added to the queue, it can be useful to figure out how long it
>>> actually takes before that event is processed, and report statistics about
>>> queue length at regular intervals. The goal of this project would be to
>>> build a replacement for this event loop that can maintain the same
>>> properties (thread-safe, in-order queue) while allowing us more
>>> introspection about it.
>>>
>>> As for the workflow, we always recommend minimizing the number of
>>> changes in a PR whenever possible for the reasons that you mention.
>>> Multiple commits in the same PR are fine when they are related; smaller PRs
>>> are easier to review and will be dealt with quicker for that reason. All
>>> PRs are assigned a reviewer, and for student projects we try to ensure that
>>> any new work receives review within a day or two.
>>>
>>> Does that answer your questions? My experience is that rebasing work
>>> over top of existing commits that are undergoing changes due to code review
>>> does not have to be a significant source of delay or extra effort if the
>>> rebasing is postponed until the original commits stop being changed.
>>>
>>> Cheers,
>>> Josh
>>>
>>>
>>>
>>> On 6/24/17 4:45 AM, Artur Jamro wrote:
>>>
 Hi!

 Firstly, we would like to apologize for time delay. One of us was abroad
 and had problems with Internet access.

 We really like the first and third proposition and we would like to
 work on
 them. If we still have some time after we finish these tasks, then we
 might
 contribute more. Can you also give us more details about the fourth
 proposition and time estimates for all of them?

 We have also some questions about the workflow. Will our changes be
 thematically squashed into big commits or do you prefer small ones?
 Should
 each such a commit be a single pull request? How long does it usually
 take
 for a single pull request to be reviewed by 

[dev-servo] Collecting working benchmarks

[Josh Matthews]

We already have a wiki page that collects various benchmarks we've 
noticed over the years. I've added a section to that page to collect the 
benchmarks that actually finish running and produce results: 
https://github.com/servo/servo/wiki/Benchmarks#known-to-work-in-servo


Cheers,
Josh
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo