On Tue, Aug 6, 2019 at 1:14 AM Myrle Krantz <my...@apache.org> wrote: > If someone makes a commit who you are not expecting to make a commit, or in > an area you weren't expecting changes in, you'll notice that, right?
Not counterarguments, but just more color on the hesitation: - Probably, but it's less obvious on a big project than a small one! - More likely: person commits in an area they know, and it breaks something elsewhere unexpectedly. Tests can catch most but not all of this. That's a risk everywhere though. - Or: most commits aren't _authored_ by committers here (I think?) but _merged_ by committers. It's still possible to watch for this, but harder. - It's harder to retroactively review commits and revert if needed, not impossible Honestly I think most of Spark is run with the attitude you describe. It's the core and SQL modules that generate the worry, because correctness and semantics are much more sensitive there. I know at one time we tried the notion of 'maintainers' for areas of the code, where it was strongly suggested that a change to module X be reviewed by one of a few experts on that part of the code. It was never really enforced and so dropped. I recall it was a little controversial at the time: why are you trying to create committers with more/less power over the code? Yet I think that's the substance of the 'what harm can it do?' argument: just make sure committers stick to their appropriate area and then there's really no worry. > In order to do that, you'd need to create this kind of in-between status > Apache-wide. I would be very much opposed to doing that for a couple of > reasons: > * It adds complexity for infra and events with no clear benefits to the > projects. > * The risk of creating a second-class status at the ASF is just too high for > my comfort. This is a good practical argument. I'd still push back on the idea that there is no benefit (cf. supra), but it may not be worth the headache or simple admin overhead. I don't buy the second-class citizen argument so much. We already have a board, PMC, committer statuses. It's just that we're used to these tiers. I don't think you're being dogmatic about it, but, some are, some of the same people railing against squashing new ideas because they're different! > Documents are IP. You're better off if you have an ICLA for that stuff, > regardless of where it lands in your project content. And the most natural > point in time to request an ICLA is at committer invitation. Side point: ICLAs are always nice-to-have but not required, no? most contributions don't come from those with an ICLA nor would we want to block contributions on signing one. It's just orthogonal. I take your point that a regular contributor probably should sign an ICLA, and a regular contributor should be a committer, just not that they should be a committer because they should sign an ICLA. You can tell there's a range of opinions here. I'm probably less 'conservative' about adding committers than most on the PMC, right or wrong, but more conservative than some at the ASF. I think there's room to inch towards the middle ground here and this is good discussion informing the thinking. --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
