Stream: general

Topic: contributing-policy


oli (Mar 16 2019 at 16:02, on Zulip):

Not sure which teams to ping on https://github.com/rust-lang/rust/pull/59234 so... reposting here to whomever is interested. It's about documenting our "rebase, not merge" policy.

davidtwco (Mar 16 2019 at 16:08, on Zulip):

cc @WG-compiler-meta, I guess.

Santiago Pastorino (Mar 16 2019 at 18:13, on Zulip):

+1 to documenting the policy :)

centril (Mar 16 2019 at 21:37, on Zulip):

+1 to documenting ofc; no harm in that so long as it is the policy... However, +2 to dropping the policy altogether because I think it's rather hostile to new contributors. I've seen new people stop contributing because of it. Does it offer many practical advantages?

oli (Mar 17 2019 at 08:19, on Zulip):

Does it offer many practical advantages?

I've been told yes, but @eddyb only referred me to someone else who actually knew what the problems are

davidtwco (Mar 17 2019 at 13:22, on Zulip):

+1 to documenting ofc; no harm in that so long as it is the policy... However, +2 to dropping the policy altogether because I think it's rather hostile to new contributors. I've seen new people stop contributing because of it. Does it offer many practical advantages?

@centril can you elaborate on this? what about the policy is hostile to new contributors? I'm genuinely curious, nothing there seems particularly egregious.

centril (Mar 17 2019 at 13:26, on Zulip):

@oli was "someone" eternaleye? It would be good to justify this with the documentation we write... if we are to make devs go through pain, let's at least say why.

@davidtwco

@centril can you elaborate on this? what about the policy is hostile to new contributors? I'm genuinely curious, nothing there seems particularly egregious.

Rebasing, especially when you have to deal with submodules is not exactly git-101, I would consider it advanced usage of git. I know of cases where folks walked away from contributions to rust because of this policy. Even more experienced contributors regularly screw up rebasing.

davidtwco (Mar 17 2019 at 13:35, on Zulip):

That's interesting. I suspect we could probably document better the steps to rebase and pitfalls to avoid (e.g. submodules are never something I've had a issue with as I just run x.py during the rebase and let that check them out and then that's always been fine). I can't personally think of a way to avoid rebasing when using bors to test everything merged with master.

I can't say I understand someone being motivated enough to make a contribution but then a rebase is enough to make that no longer worth it. :shrug:

centril (Mar 17 2019 at 13:37, on Zulip):

@davidtwco Just last week I screwed up a rebase due to accidentally adding submodule updates and then had to spend an unwelcome amount of time fixing it (https://github.com/rust-lang/rust/pull/58995) ;)

davidtwco (Mar 17 2019 at 13:38, on Zulip):

Sure, these things will always happen occasionally, it's unavoidable. I don't think that is representative of most instances where a rebase is necessary.

centril (Mar 17 2019 at 13:39, on Zulip):

Sure. When that occasional thing happens to a newbie it becomes a problem imo

centril (Mar 17 2019 at 13:40, on Zulip):

but... documenting better would be nice

davidtwco (Mar 17 2019 at 13:40, on Zulip):

I'm not suggesting that it isn't a friction point, or that we shouldn't aim to minimize it where we can to make things easier for all contributors. But, had you asked me to rank the friction points in our process, that wouldn't have been high on the list at all, so it just surprised me is all.

centril (Mar 17 2019 at 13:41, on Zulip):

Hehe :slight_smile:

Last update: Nov 20 2019 at 12:20UTC