Apologies for the length. Responses inline. In short, I'd retract my veto
on the code change subject to the results of a majority vote, as the
quickest way to make progress.
On Fri, Jul 11, 2014 at 8:59 AM, Sean Busbey <[EMAIL PROTECTED]> wrote:
A couple of things about this point. First, there seems to be the
implication that because I've been working with Accumulo for some time that
I'm incapable of empathizing with the frustrations of new contributors.
You've made this implication before, and I find it a bit antagonistic, and
it's simply not true. My stated views are as they are, in full knowledge
of, and empathy for, the frustrations that new contributors may encounter.
Second, there does not appear to be any reason to believe that any one of
us has more or less capacity to consider these consequences than another
one of us, and I think it would be best to avoid making arguments based on
the premise that one of us does. After all, one could just as easily make
the argument that experience with the project also provides insight into
the experiences of a greater number of new contributors' experiences. I'd
rather not devolve our arguments to such a state. I'd rather we focus our
arguments on their merits, rather than the authority (either by virtue of
experience or lack thereof) of the person making the argument and
implications of the capacity the other has to have a fully informed
opinion. Otherwise, we're essentially suggesting "your opinion doesn't
count as much as mine", and I don't think such suggestions are beneficial
to the progress of the argument.
I don't mind easing them into it. I just think that the current state is
sufficient easing, whereas any further easing would begin to trade off too
I don't believe we are at a point of irreconcilable differences.
The irreconcilable difference I think is not a completely dichotomous one.
I just think it's just a matter of scale: you find the current state
insufficiently easy and that further easing would not lose too much,
whereas I think the current state is sufficiently easy and that further
easing would lose too much. The difference is slight, I'm sure, but it does
appear to be irreconcilable (at least, irreconcilable in a timely manner,
without a vote).
The key part is "provided that committers follow the proposed changed
instructions..."; That itself is increased risk, because we are now relying
on committers to follow increased steps, when we can objectively see the
history and determine that committers are just as likely to inadvertently
overlook these responsibilities as anybody. It's not that I don't believe
our committers can follow those instructions... it's just a simple
recognition that they haven't always done the best job in the past at doing
what is necessary to check licenses (myself included).
I think a git hook would help, yes, but I'd also want contributors thinking
about these things from the beginning, and I think we trade off some
conscious consideration on the part of contributors if we make the default
build too easy. I think contributors should begin thinking about these
things before they ever upload a patch to JIRA or submit a pull request,
and the current default settings is the only thing that has been considered
that accomplishes that, so that we do not train anybody to be lazy when it
comes to license checking. I really think the user should be confronted
with the results of a license check as soon as possible. Now, I also think
that confrontation could be made more verbose... and I fully support and
encourage anybody willing to tackle the RAT tickets that would do that (I
may even take them up myself, if I ever have time).
I'd be willing to retract my veto on the code change, subject to the
outcome of a majority vote. I don't know that anybody else has formally
vetoed the code change, so if I'm the only one, a majority vote would seem
to be the quickest way to resolve this and put it behind us, if you want to
call one up.
Christopher L Tubbs II