accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: ACCUMULO-3177 and ACCUMULO-3178
Date Sat, 06 Dec 2014 06:10:24 GMT
Sean,

The normal process is CtR, and lazy consensus. I understand that you've had
time constraints, and that this has been the cause of your inability to
provide a timely review. However, I feel I've been more than fair drawing
this out so that you can have every opportunity to provide a review on your
own timeline. It has been two months since the original review was posted,
and a week and a half since I stated my intentions here, and two days since
I posted a reminder that it had been a week of inactivity.

I can assume good faith all day, but I cannot await for activity on your
part indefinitely. I do not consider a brief comment in JIRA indicating
that you had forgotten to comment the week prior that you were in process
of reviewing, "activity" in any tangible sense which would indicate a
forthcoming response, either, especially since you failed to acknowledge my
direct questions in this thread or provide any review within several hours
after that comment. You also haven't provided any response here in the last
10 days, where I have been explicitly trying to keep you up-to-date and
provide you opportunities to be involved before I pushed the changes. If
you had wished for me to continue to assume good faith, you could have
provided a partial review, or raise one issue at a time, or anything other
than simply hint that something might be eventually forthcoming.

I do not believe it to be in the best interest of the community to expect
such little interactions to bind the hands of other committers to inaction
indefinitely, and it's certainly not fair to our contributors who put
effort into the patch or to users who would like to see these features in a
future release.

For what it's worth, I was very reluctant to push without your explicit
review, but after privately getting advice from 4 other committers as to
how to deal with the unresponsiveness you've shown, I felt that I had no
other choice but to place the ball firmly in your court. By taking the
action I did to push those contributions, I have placed the responsibility
with you to either revert the commits with an explicit veto and explanation
(initiating a consensus vote), or by providing additional feedback/JIRAs
for alterations if you feel changes need to be made. This is the normal
process of development in our community, and as such, I feel it was
entirely appropriate.

You suggest that I should have alternatively contacted you privately or by
updating the JIRA issues... but I don't see how either of those options are
superior to the method I did take, which was to comment in this thread in
which you were participating, publicly and transparently. You also suggest
that I should have requested a hard deadline and expressed my pressing
desire. I believe I've effectively already taken similar actions, in this
thread, both by stating my explicit intentions and by politely requesting a
timely response. You also are fully aware that I did, in fact, privately
contact you by email to request a Google Hangout or phone conversation, so
we could clarify any possible misunderstandings or miscommunications, or as
an opportunity to work out any differences of opinion we might have. You
declined that, in favor of the mailing lists. I also know that you were
explicitly informed that I had made multiple failed attempts to contact you
via IRC. So, you do know that I've made attempts to privately contact you.
And, as a result of all of that, I've been using the mailing lists. Please
don't try to suggest that I could have done more to include you.

This was also not a unilateral action. Not only have the contributions I
pushed received numerous +1s from other committers who did provide timely
reviews, but I also sought advice from other committers before ultimately
pushing.

I feel I've bent over backwards to give you every opportunity to provide
your feedback. I do not see what else I could have done. I think your
expectations for me to have done more are entirely unreasonable. I'm not
aware of any other incident in our community where such great lengths have
been taken to accommodate another developers time. Typically when somebody
is unable to provide a timely review, they don't prevent the other
committer from pushing... they simply review after the fact. This was true
today, even, with the metrics2 changes. I had wished to review those
changes, but since I was unable to get to it in time, I simply expressed my
lament at that fact, and made a note to review it later, when I had time,
because it would have been unreasonable to expect that those changes be
subject to my personal schedule.

If you have an issue with the content of the patches I pushed, please
address them at a technical level, by referring to the actual code. There
is no timeline on that. You're free to address the code at your leisure.

Thank you.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Fri, Dec 5, 2014 at 11:11 PM, Sean Busbey <busbey@cloudera.com> wrote:

> Christopher I said I was still reviewing literally hours before you pushed
> these changes. I also explained that my review was delayed by the
> excessively drawn out discussions that have been happening lately.
>
> This is unbecoming behavior, especially in the light of our recent
> interactions. I appreciate that people have their own timelines they are
> trying to meet, but we are still a community and need to presume others are
> acting in good faith when they say they are still actively working on
> something.
>
> Instead, it would have been more helpful had you either contacted me
> privately or updated tickets to explain your pressing desire to get the
> patches in and asked me for a hard deadline that I could finish by. That
> would have given me the opportunity to decide if I can dedicate the time to
> finish documenting the problems I see in the current patches. Bringing up
> changes now will require asking yet again for the attention of the
> community rather than just a less visible exchange between myself and a new
> contributor.
>
> On Fri, Dec 5, 2014 at 7:12 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > I went ahead and pushed due to lack of activity on this thread, or any
> > noticeable activity in any of the reviews or JIRAs. We're CtR and lazy
> > consensus, and I believe 2 months open since the original patches were
> > published in ReviewBoard, and 10 days since this thread was opened has
> been
> > more than sufficient time for any imminent concerns to have been raised.
> > Any further issues can be addressed in follow-up JIRAs or by initiating a
> > revert with a consensus vote expressing the veto.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Fri, Dec 5, 2014 at 11:13 AM, Christopher <ctubbsii@apache.org>
> wrote:
> >
> > > Sean, I understand if you don't have time to review these now... would
> > you
> > > mind doing so in a follow-up issue, or by exercising a revert if you
> see
> > an
> > > issue with them? I think it's reasonable to go ahead and push these
> > changes
> > > now.
> > >
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > > On Thu, Dec 4, 2014 at 5:47 PM, Christopher <ctubbsii@apache.org>
> wrote:
> > >
> > >> Last update on this thread was over a week ago. Jenna was kind enough
> to
> > >> squash in my reviews (which were essentially provided to her as a
> patch
> > on
> > >> top of her patch via GitHub). She has updated the ReviewBoard entries,
> > and
> > >> I have commented with my +1.
> > >>
> > >>
> > >> --
> > >> Christopher L Tubbs II
> > >> http://gravatar.com/ctubbsii
> > >>
> > >> On Wed, Nov 26, 2014 at 4:12 PM, Christopher <ctubbsii@apache.org>
> > wrote:
> > >>
> > >>> On Wed, Nov 26, 2014 at 3:07 PM, Sean Busbey <busbey@cloudera.com>
> > >>> wrote:
> > >>>
> > >>>> I will be as timely as I can.
> > >>>>
> > >>>> Thanks. However, please understand that if you are unable to respond
> > >>> timely, progress can/should/will proceed without you. I just want to
> > make
> > >>> sure you have opportunity.
> > >>>
> > >>>
> > >>>> Please keep in mind that our community is volunteer based, people
> > have a
> > >>>> multitude of commitments, and it is a holiday week.
> > >>>>
> > >>>>
> > >>> Sure, I just want to make sure you have ample time to review and we
> can
> > >>> address any objections you may have (if you still have any), but I
> want
> > >>> some time constraint, so these contributions don't sit idle
> > indefinitely
> > >>> (that's not fair to the contributor, or to those who'd like to
> leverage
> > >>> these features). As long as the discussion is active
> (holidays/weekends
> > >>> considered, of course), I will not attempt to push.
> > >>>
> > >>>
> > >>>> I had presumed more feedback wasn't pressing since no one had
> > mentioned
> > >>>> on
> > >>>> the tickets how my original concerns were addressed by the revamps.
> If
> > >>>> someone could give me a summary on each it would make things go
much
> > >>>> faster.
> > >>>>
> > >>>>
> > >>> Your feedback is pressing because you're the only one who expressed
> > >>> concerns, and I want to make sure you have ample opportunity to be
> > >>> involved. But, I don't want it to wait forever. I did believe I had
> > >>> responded sufficiently to your questions/concerns... but if there's
> > still
> > >>> something outstanding that I have not answered or addressed, please
> > raise
> > >>> it again, explicitly, and in the context of the proposed changes, so
> I
> > can
> > >>> respond to it.
> > >>>
> > >>> Sure, I can give you a summary as I understand it:
> > >>>
> > >>> Overview of the issues:
> > >>>
> > >>> ACCUMULO-3177: Adds a per-table VolumeChooser to replace the
> > >>> RandomVolumeChooser as the default VolumeChooser, with the default
> > >>> per-table implementation (a new per-table property is added for this)
> > is
> > >>> now the RandomVolumeChooser. This is modeled after the per-table
> > balancer.
> > >>> The intent is to enable balancing decisions for a tablet's persistent
> > >>> storage across volumes in the same way we allow balancing tablet's
> > >>> "compute" operations across Tablet Servers. To do this, a
> > >>> "VolumeChooserEnvironment" object is created and added to the chooser
> > API,
> > >>> which exposes the environment to the chooser (such as the tableId,
> from
> > >>> which the namespace can be retrieved, etc.)
> > >>>
> > >>> ACCUMULO-3178: Adds an additional example/reference implementation
> for
> > a
> > >>> per-table VolumeChooser, called a "PreferredVolumeChooser", which
> > allows
> > >>> users to specify a specific volume (or set of volumes) in a custom
> > >>> per-table property. This is used as a test case (integration test)
> for
> > >>> ACCUMULO-3177. (Note: your original concerns about deduplication of
> > HDFS's
> > >>> HSM effort expressed in ACCUMULO-3089 seem to apply only to this
> > issue, not
> > >>> to ACCUMULO-3177; however, my hope is that you'll see that this is
> > >>> sufficiently unrelated to that, that your original objections do not
> > apply.)
> > >>>
> > >>> Also, some background (from my perspective):
> > >>>
> > >>> Recall: As explained on ACCUMULO-3089, your original concerns were
> > >>> addressed by splitting the original issue into separate tasks, to
> help
> > >>> clarify the scope and intentions of that issue with more narrowly
> > defined
> > >>> changesets. You were requested to explain your objections
> specifically
> > in
> > >>> the context of the changesets on those tasks, because I believed you
> to
> > >>> have misunderstood the scope of the issue (as I stated on
> > ACCUMULO-3089),
> > >>> and I hoped that doing so would help clarify where your objections
> > were, in
> > >>> relation to the proposed code changes. As far as I can tell, you did
> do
> > >>> that, with your comments on the subsequent issues.
> > >>>
> > >>> You commented on ACCUMULO-3177, suggesting that it might be better
to
> > >>> apply the configuration property on a namespace instead of a table.
I
> > >>> responded to that comment with an explanation of how table and
> > namespace
> > >>> configurations work in this context. As such, I hold that your
> comment
> > >>> represents a recommended "best practice" for table management
> > >>> (specifically, limiting the granting of ALTER_TABLE), but not an
> > objection
> > >>> to the table/namespace configuration-based implementation/addition
> > itself.
> > >>>
> > >>> You have also commented on ACCUMULO-3178, with an indication that you
> > >>> did not feel that the VolumeChooser interface itself was strictly
> > "public
> > >>> API", which I took to mean that you'd be more flexible in tolerating
> > >>> changes to that API with a higher degree of risk. I did not see an
> > >>> objection to ACCUMULO-3178, but it does depend on ACCUMULO-3177. You
> > also
> > >>> suggested not making these dependent on ACCUMULO-3176 (because of the
> > >>> presence of a limited workaround by adding configuration to a
> namespace
> > >>> first), a request which was accommodated (but ultimately unnecessary
> if
> > >>> ACCUMULO-3176 is permitted) in a separate review which you did not
> > comment
> > >>> on after requesting it to be made.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> --
> > >>>> Sean
> > >>>> On Nov 26, 2014 12:27 PM, "Christopher" <ctubbsii@apache.org>
> wrote:
> > >>>>
> > >>>> > Thank you for your response. I request that you please be
timely,
> as
> > >>>> these
> > >>>> > issues have sat idle for a long time, and the maintenance
burden
> of
> > >>>> keeping
> > >>>> > them current with the HEAD of master is becoming excessive.
I
> await
> > >>>> your
> > >>>> > reviews/objections. Thanks.
> > >>>> >
> > >>>> >
> > >>>> > --
> > >>>> > Christopher L Tubbs II
> > >>>> > http://gravatar.com/ctubbsii
> > >>>> >
> > >>>> > On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <
> busbey@cloudera.com>
> > >>>> wrote:
> > >>>> >
> > >>>> > > I will follow up on both of those tickets with my objections,
> > >>>> please do
> > >>>> > not
> > >>>> > > apply them.
> > >>>> > >
> > >>>> > > On Tue, Nov 25, 2014 at 2:08 PM, Christopher <
> ctubbsii@apache.org
> > >
> > >>>> > wrote:
> > >>>> > >
> > >>>> > > > My intention is to, sometime this week, take a thorough
look
> at
> > >>>> the
> > >>>> > > patches
> > >>>> > > > and reviews available for ACCUMULO-3177 (create
a per-table
> > >>>> > > VolumeChooser)
> > >>>> > > > and ACCUMULO-3178 (example implementation of an
alternate
> > >>>> > > > VolumeChooser/test case for ACCUMULO-3177). Given
the
> > discussions
> > >>>> > > > surrounding ACCUMULO-3176, and because they originated
as the
> > >>>> overall
> > >>>> > > > ACCUMULO-3089 (which had some objections that may
not have
> been
> > >>>> > > resolved) I
> > >>>> > > > wanted to give this notice, to ensure that there
is
> opportunity
> > >>>> for
> > >>>> > > > objections to occur and be discussed here first.
> > >>>> > > >
> > >>>> > > > Presumably, the objections for ACCUMULO-3176 are
different
> from
> > >>>> any
> > >>>> > that
> > >>>> > > > might be held for 3177 and 3178, but there was limited
> follow-up
> > >>>> > > > clarification of the objections raised after the
issues were
> > >>>> re-scoped
> > >>>> > as
> > >>>> > > > separate, more specific, JIRA sub-tasks. So, I'm
not sure
> there
> > >>>> are any
> > >>>> > > > still outstanding for those. Since the reviews are
still open
> > for
> > >>>> > those,
> > >>>> > > I
> > >>>> > > > just wanted to invite discussion either here, or
(perhaps even
> > >>>> better)
> > >>>> > in
> > >>>> > > > the specific review in ReviewBoard.
> > >>>> > > >
> > >>>> > > > --
> > >>>> > > > Christopher L Tubbs II
> > >>>> > > > http://gravatar.com/ctubbsii
> > >>>> > > >
> > >>>> > >
> > >>>> > >
> > >>>> > >
> > >>>> > > --
> > >>>> > > Sean
> > >>>> > >
> > >>>> >
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> >
>
>
>
> --
> Sean
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message