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 <artur.ja...@gmail.com> 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 <http://mrowqa.pl> > > 2017-07-06 12:08 GMT-07:00 Josh Matthews <j...@joshmatthews.net>: > >> 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 some servo developer? Will we >>> have an assigned reviewer to our changes? >>> >>> We are concerned that code review could block our work in a case we want >>> to >>> create a new commit, but the previous one is still in review. Then >>> rebasing >>> newer commits could be painful. >>> >>> In worst case, due to Bachelor's thesis deadline, we may work on our fork >>> and then be submitting slowly, but successively new pull requests, one >>> after one. We would really like to avoid it since it unnecessarily makes >>> contributing more difficult and less productive. And we would like our >>> code >>> to change the world! :) >>> >>> >> > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
