Another alternative is to have a few fast builders (e.g. whatever
configuration the try bots run) just run through the queue as they're
r+'d to get fast feedback.
(A (significant) problem with all these proposals is the increase in
infrastructure complexity: there's already semi-regular automation
failures.)
Huon
On 20/02/14 08:21, Clark Gaebel wrote:
As an alternative to "arbitrary code running on the buildbot", there
could be a b+ which means "please try building this" which core
contributors can comment with after a quick skim through the patch.
On Wed, Feb 19, 2014 at 3:38 PM, Felix S. Klock II
<[email protected] <mailto:[email protected]>> wrote:
On 19/02/2014 21:12, Flaper87 wrote:
2. Approval Process
[...] For example, requiring 2 r+ from 2 different reviewers
instead of 1. This might seem a bit drastic now, however as the
number of contributors grows, this will help with making sure
that patches are reviewed at least by 2 core reviewers and they
get enough attention.
I mentioned this on the #rust-internals irc channel but I figured
I should broadcast it here as well:
regarding fractional r+, someone I was talking to recently
described their employer's process, where the first reviewer (who
I think is perhaps part of a priveleged subgroup) assigned the
patch with the number of reviewers it needs so that it isn't a
flat "every patch needs two reviewers" but instead, someone says
"this looks like something big/hairy enough that it needs K reviewers"
just something to consider, if we're going to look into
strengthening our review process.
Cheers,
-Felix
On 19/02/2014 21:12, Flaper87 wrote:
Hi all,
I'd like to share some thoughts with regard to our current test
and approval process. Let me break this thoughts into 2 separate
sections:
1. Testing:
Currently, all patches are being tested after they are approved.
However, I think it would be of great benefit for contributors -
and reviewers - to test patches before and after they're
approved. Testing the patches before approval will allow folks
proposing patches - although they're expected to test the patches
before submitting them - and reviewers to know that the patch is
indeed mergeable. Furthermore, it will help spotting corner
cases, regressions that would benefit from a good discussion
while the PR is hot.
I think we don't need to run all jobs, perhaps just Windows, OSx
and Linux should be enough for a first test phase. It would also
be nice to run lint checks, stability checks etc. IIRC, GH's API
should allow us to notify this checks failures.
2. Approval Process
I'm very happy about how patches are reviewed. The time a patch
waits before receiving the first comment is almost 0 seconds and
we are spread in many patches. If we think someone else should
take a look at some patch, we always make sure to mention that
person.
I think the language would benefit from a more strict approval
process. For example, requiring 2 r+ from 2 different reviewers
instead of 1. This might seem a bit drastic now, however as the
number of contributors grows, this will help with making sure
that patches are reviewed at least by 2 core reviewers and they
get enough attention.
I think both of these points are very important now that we're
moving towards 1.0 and the community keeps growing.
Thoughts? Feedback?
--
Flavio (@flaper87) Percoco
http://www.flaper87.com
http://github.com/FlaPer87
_______________________________________________
Rust-dev mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/rust-dev
--
irc: pnkfelix onirc.mozilla.org <http://irc.mozilla.org>
email: {fklock,pnkfelix}@mozilla.com <mailto:[email protected]>
_______________________________________________
Rust-dev mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
