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. 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. 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. 2019년 8월 6일 (화) 오후 3:14, Myrle Krantz <my...@apache.org>님이 작성: > Hey Sean, > > Even though we are discussing our differences, on the whole I don't think > we're that far apart in our positions. Still the differences are where the > conversation is actually interesting, so here goes: > > On Mon, Aug 5, 2019 at 3:55 PM Sean Owen <sro...@apache.org> wrote: > >> On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <my...@apache.org> wrote: >> > So... events coordinators? I'd still make them committers. I guess >> I'm still struggling to understand what problem making people VIP's without >> giving them committership is trying to solve. >> >> We may just agree to disagree, which is fine, but I think the argument >> is clear enough: such a person has zero need for the commit bit. >> Turning it around, what are we trying to accomplish by giving said >> person a commit bit? I know people say there's no harm, but I think >> there is at least _some_ downside. We're widening access to change >> software artifacts, the main thing that we put ASF process and checks >> around for liability reasons. I know the point is trust, and said >> person is likely to understand to never use the commit bit, but it >> brings us back to the same place. I don't wish to convince anyone else >> of my stance, though I do find it more logical, just that it's >> reasonable within The Apache Way. >> > > 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. > > >> > It also just occurred to me this morning: There are actually other >> privileges which go along with the "commit-bit" other than the ability to >> commit at will to the project's repos: people who are committers get an >> Apache e-mail address, and they get discounted entry to ApacheCon. People >> who are committers also get added to our committers mailing list, and are >> thus a little easier to integrate into our foundation-wide efforts. >> > >> > To apply this to the example above, the Apache e-mail address can make >> it a tad easier for an event coordinator to conduct official business for a >> project. >> >> Great points. Again if I'm making it up? a "VIP" should get an Apache >> email address and discounts. Sure, why not put them on a committers@ >> list too for visibility. >> > > 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. > > >> > But that's not what I'm arguing. I'm arguing that you can safely give >> commit access to anyone for whom you're reasonably certain they will do no >> harm. And your certainty of that can actually be much higher with >> non-coding committers. So if someone suggests a non-coding contributor for >> committer, it should be fairly easy to say "yes". Especially if you're on >> a project like Spark where PMC ⊂ committers. >> >> (Just to again be clear, we aren't talking only about 'non-coding' >> committers. If it's shorthand for 'not contributing to docs/code in >> the repo', we're on the same page.) >> > > Ack. I actually think of documentation which goes into the repo as code, > so I do think we're on the same page here. > > >> The case that started this is a corner case. The more interesting case >> is, in fact, a docs-only contributor. That hasn't quite come up -- we >> had a case of build- and config-only committer though. It's worth >> keeping these arguments in mind for this more ambiguous hypothetical. >> No objections in theory to making said person a committer, but in >> practice it may be a harder case, possibly unnecessarily hard. >> > > 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. > > >> > For solving the early and easy recognition problem, I've heard about >> people just saying "thank you" or making a "contributor of the month" >> honor. That kind of recognition doesn't necessarily have to be in the form >> of a status. >> >> Sure, we do some of that on PRs, but probably need to do more. There >> are some regular contributors doing good work, and I hope they feel >> recognized by the fact they get more attention because of their track >> record, but being explicit goes a long way. >> > > As they say: positive feedback to negative feedback ratio should be 7:1. > There are other parts of the foundation where we need to place more > emphasis on positive feedback too. > > Best, > Myrle >
