-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/2015 10:07 AM, Martin Roth wrote: > As others have stated, my concern is the tradeoff between long and > short times. Too short a time, and people don't getting the chance to > review patches. Too long a time and it delays development, frustrates > developers, and requires rebasing the patch, maybe requiring MORE > review. > > Alternate thoughts or proposals: > - "Note that some contributors prefer to work on coreboot during > business hours, so consider leaving patches up longer than 24 hours > during weekends and holidays" > This of course presents other issues of dealing with holidays in > various countries, time zones, etc. > > - Trivial patches (Whitespace, spelling, and the like) can be > submitted with no delay. Non-trivial commits touching fewer than 20 > lines of code should be submitted no sooner than 24 hours after the > last major change. Changes larger than that 20 lines should wait at > least 48? 72? hours after the last major change. > > Paul also mentioned that a method of getting non-trivial patches in > quickly should be addressed as well. This should not be a regular > occurrence, but sometimes we need or desire to push a patch quickly. > He suggested 2 +2s and a statement to the mailing list. To me, this > defeats the purpose of quick. > > Yesterday tpearson requested on IRC that we get a patch in quickly. > It was, in my opinion significant, although just a single line change, > which made it easy to understand and review. We got 3 +2s on it in > just a few minutes. I thought that was a good barrier and would like > to propose that as the rule: If you can get 3 +2s, knowing that it's > going to be submitted immediately, it can be submitted. If this gets > abused, it can be reviewed and changed at some point in the future. > > Martin
Yes, this is a good compromise. There isn't very much we can do about latency on non-emergency patches; however due to the increased delays per-patch, patch trains will become the dominant method of submitting large changes (I am expecting a variant of Little's Law to hold here). As a result, the improved patch train handling set out in the CL becomes critical. I assume all reviewers are on board with the idea of not rebasing unless something is broken, and handling formatting or other non-functional changes at the end of a series? Thanks! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWOjtbAAoJEK+E3vEXDOFbTCoH/1d2B+2xZSpo+IdV+FWQaUrE XmkJzUDBZMGX0EcnIj5+sEArMHsRZdNeG86ovmx+mFhj5LLJ8i84QG6Ayhduwxm5 Anv8ccDCvyB8QpJ1Ju6NOv2esfLYhi8d4EBdhv4fj6w4eJzZPoLI3p6FIDYSwaFp jJy1K190oQYnQ1ff2gFdBK6zFm1V30cxyz9ogVJgUQJPvFe1KHa1QbwzDPYhguoH cMcdyYaWJLihy0T3W+jQSbw06K39D2MnA7D/InCgseQRkHdfVqcuLggie98DuEXg LrzjnwRp0d+cwBoRDCEfvfwF5UX6JjAOu0Q8rMGRShAk8rqXnXeWsNv4wO/cwyE= =Bbai -----END PGP SIGNATURE----- -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
