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 <http://mrowqa.pl> 2017-08-21 23:29 GMT+02:00 Josh Matthews <j...@joshmatthews.net>: > 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! :) >>>> >>>> >>> >> > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Wolny od wirusów. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
