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
