libtock-rs: Do we want to merge Tock 2.0 PRs faster than a week-long wait?

[Johnathan Van Why]

libtock-rs currently has a code review policy that says all PRs containing new functionality should wait a week before merging. I am trying to get libtock-rs ready in time for Tock 2.0 testing, and that policy has been slowing me down.

I intend to discuss temporarily bypassing that policy for Tock 2.0 development efforts at this Friday's core WG call. I am sending this email now so that contributors who do not attend the core WG calls can give their input on the feature. If you have an opinion on the matter, please share it here :-)

-Johnathan Van Why

[Philip Levis]

This seems reasonable. Right now we’ve been merging PRs for Tock 2.0 very fast because they are just to the tock-2.0-dev branch. There’s an assumption that the merging of *that* branch to master will be very carefully reviewed. You could adopt an approach like this, or just move a bit faster as you suggest.

Phil

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/CAJqTQ1hyNcoA1vEg%3DTgg3NALVueQ_uA6CzuFe4expxk5H9OBrw%40mail.gmail.com.

———————
Philip Levis (he/him)
Associate Professor, Computer Science and Electrical Engineering

Faculty Director, lab64 Maker Space
Stanford University
http://csl.stanford.edu/~pal

[Johnathan Van Why]

I wasn't anticipating a separate "big code review" merge like we're doing with tock-2.0-dev. I was thinking more that we would merge as soon as all the usual and requested reviewers have reviewed each PR, rather than waiting for other reviewers to jump in.