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
