I usually make such judgement about commit bit based upon community activity in coding and reviewing. If somebody has no activity about those commit bits, I would have no way to know about this guy, Simply I can't make a judgement about coding activity based upon non-coding activity.
Those bugs and commit stuff are pretty critical in this project as I described. I would rather try to decrease such possibility, not increase it even when such "commit bit" is unnecessary. We have found and discussed nicer other ways to recognise them, for instance, listing them in somewhere else in Spark website. Once they are in that list, I suspect it's easier and closer to the committership to, say, get an Apache email if it matters. Shall we avoid such possibilities at all and go for such other safer ways? I think you also accept commit bit is unnecessary in this case. So, we don't unnecessarily give it to them, which is anyhow critical in this project. > Based on this argumentation you will never invite any committers or even merge any pull requests. BTW, how did you reach that conclusion? I want somebody who can review PRs and fix such bugs, rather than who has more possibility to make such mistakes. 2019년 8월 6일 (화) 오후 7:26, Myrle Krantz <my...@apache.org>님이 작성: > Hey Hyukjin, > > Apologies for sending this to you twice. : o) > > On Tue, Aug 6, 2019 at 9:55 AM Hyukjin Kwon <gurwls...@gmail.com> wrote: > >> Myrle, >> >> > We need to balance two sets of risks here. But in the case of access >> to our software artifacts, the risk is very small, and already has >> *multiple* mitigating factors, from the fact that all changes are tracked >> to an individual, to the fact that there are notifications sent when >> changes are made, (and I'm going to stop listing the benefits of a modern >> source control system here, because I know you are aware of them), on >> through the fact that you have automated tests, and continuing through the >> fact that there is a release process during which artifacts get checked >> again. >> > 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? >> > What you're talking about here is your security model for your source >> repository. But restricting access isn't really the right security model >> for an open source project. >> >> I don't quite get the argument about commit bit. I _strongly_ disagree >> about "the risk is very small,". >> Not all of committers track all the changes. There are so many changes in >> the upstream and it's already overhead to check all. >> Do you know how many bugs Spark faces due to such lack of reviews that >> entirely blocks the release sometimes, and how much it takes time to fix up >> such commits? >> We need expertise and familiarity to Spark. >> > > Let's unroll that a bit. Say that you invite a non-coding contributor to > be a committer. To make an inappropriate commit two things would have to > happen: this person would have to decide to make the commit, and this > person would have to set up access to the git repository, either by > enabling gitbox integration, or accessing the apache git repository > directly. Before you invite them you make an estimation of the probability > that they would do the first: that is decide to make an inappropriate > commit. You decide that that is fairly unlikely. But for a non-coding > contributor the chances of them actually going through the mechanics of > making a commit is even more unlikely. I think we can safely assume that > the chance of someone who you've determined is committed to the community > and knows their limits of doing this is simply 00.00%. > > That leaves the question of what the chance is that this person will leak > their credentials to a malicious third party intent on introducing bugs > into Spark code. Do you believe there are such malicious third parties? > How many attacks have there been on Spark committer credentials? I believe > the likelihood of this happening is 00.00% (but I am willing to be swayed > by evidence otherwise -- should probably be discussed on the private@ > list though if it's out there.: o). > > But let's say I'm wrong about both of those probabilities. Let's say the > combined probability of one of those two things happening is actually > 0.01%. This is where the advantages of modern source control and tests > come in. Even if there's only a 50% chance that watching commits will > catch the error, and only a further 50% chance that tests will catch the > error, and only a further 50% chance that the error will be caught in > release testing, those chances multiply out at 00.00125%. > > Based on those guestimates the risk is somewhere between 00.00% and > 00.00125%. The risk is very small. You take bigger risks every day in > order to move your project forward. > > >> It virtually means we will add some more overhead to audit each commit, >> even for committers'. Why should we bother add such overhead to harm the >> project? >> To me, this is the most important fact. I don't think we should just >> count the number of positive and negative ones. >> > > Based on this argumentation you will never invite any committers or even > merge any pull requests. > > But you do invite committers and you do merge pull requests because it's > good for your project. Because the risk of doing nothing is greater. > > >> For other reasons, we can just add or discuss about the "this kind of >> in-between status Apache-wide", which is a bigger scope than here. You can >> ask it to ASF and discuss further. >> > > I can say with considerable confidence: There will be no "in-between" > status Apache-wide. But if you disagree, and want to start a discussion to > suggest that, d...@community.apache.org is a good place to go with it. > > Best Regards, > Myrle > >>
