hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Recent trend in JIRA management
Date Mon, 23 Jul 2018 23:37:49 GMT
On Mon, Jul 23, 2018 at 3:44 PM Josh Elser <elserj@apache.org> wrote:

> I've been operating under the "get approval" for branch-2.0 since it was
> explicitly asked for.
>
>
Thanks.



> @Stack you still want to operate in that manner since we're chatting
> about this?
>


Yeah. Please continue to *synchronize* on me. I want to have final-say on
all that goes into branch-2.0. I have a hard-won understanding of the
general state of this branch and want to keep it in a condition whereby it
continues to pass all nightlies on both hadoop2 and hadoop3. I've been
running tests on a small cluster and have developed understandings around
current perf and scale facility. I am also trying to practice an
important-bug-fixes-only in branch-2.0 policy -- *No Surprises!* -- and
find that my notion of what is an important bug-fix doesn't always jibe
with what others think (smile). In a few cases, i want to try the patch
under load before committing.

I'm working in this manner because I do not have the bandwidth to do random
spelunking of test/perf or ITBLL failures and so anyone who takes up hbase2
can be sure there'll be *No Surprises!* on upgrade. I think this tight-hold
on the reins appropriate early in the life of a new major release where we
are trying to earn and keep the trust of users who are thinking of making
the leap from hbase1 to hbase2.

While this is a little out of line w/ Andrew's lockless, approach,
hopefully I've explained why this approach. Otherwise, +1 on Andrew's ask
for rolling patches back through all branches and an end to chaotic
JIRA'ing. It is pain enough already doing branch compares and if
well-behaved in JIRA, yetus scripts have a chance at automating much of the
RM drudgery.

S


















> On 7/23/18 3:47 PM, Andrew Purtell wrote:
> > Thanks for the great question.
> >
> > I can't speak for every RM, but I believe the answer in general is no,
> you
> > do not need to get the RM's approval. Personally, I only ask that
> > committers hold off when trying to make a release, and only if I need
> time
> > to stabilize the unit tests on a branch. Normally I do a CTR like review
> > over the commit history in the branch since the last release, and often
> > only in response to unit test failures or API compatibility check errors.
> >
> > I would encourage everyone on the project to avoid coordination where
> > possible. Coordination is expensive. Use lock free design principles for
> > both the software and community practices.
> >
> >
> >
> > On Mon, Jul 23, 2018 at 12:42 PM Huaxiang Sun <hsun@cloudera.com.invalid
> >
> > wrote:
> >
> >> Thanks Andrew for bringing this up. I have one following up question.
> >> When pushing to 1.2/1.3/1.4, do we need to get RM's approval?
> >>
> >> Huaxiang
> >>
> >>> On Jul 23, 2018, at 12:24 PM, Andrew Purtell <apurtell@apache.org>
> >> wrote:
> >>>
> >>> I forgot to mention if a commit is only made to master, then the RM who
> >>> happens to be looking at history has to take on the task of backporting
> >> the
> >>> change if it turns out to be a bug fix germane to release branches. The
> >>> worst thing you can do as a committer is take a bug fix change, only
> >> commit
> >>> it to trunk, resolve the JIRA, and walk away. The second worst thing is
> >> to
> >>> commit only to trunk and leave the JIRA open. There is currently one
> one
> >>> committer doing these things on a frequent basis. I ask that this
> >> practice
> >>> stop. Please view this behavior as poor maintenance practice that
> should
> >> be
> >>> avoided. Frankly, better you not commit the change at all. You are not
> >>> helping the project. It is a net negative.
> >>>
> >>> On Mon, Jul 23, 2018 at 12:18 PM Andrew Purtell <apurtell@apache.org>
> >> wrote:
> >>>
> >>>> There is a recent trend in JIRA management where a change being
> tracked
> >> by
> >>>> one JIRA is committed only to master, or maybe master and branch-2,
> and
> >>>> then the JIRA is left open. The fix versions may or may not be
> updated.
> >> The
> >>>> biggest offender is Ted Yu but newer committers are also occasionally
> >> doing
> >>>> it. Ted has no excuse, the rest is understandable.
> >>>>
> >>>> Please be advised this makes release management difficult. The RM has
> to
> >>>> look at every commit in the repository and then make sure JIRA
> reflects
> >> the
> >>>> correct fix version. Otherwise the generated change log for the
> release
> >>>> will be incorrect. If more patches are pending for other branches, and
> >> the
> >>>> fix versions are not set correctly, then the RM may miss the patch and
> >> not
> >>>> include it into the release.
> >>>>
> >>>> This is the best practice:
> >>>>
> >>>> 1. Set the fix versions for all relevant branches on the JIRA
> >>>> 2. Assemble patches for all relevant branches on the JIRA
> >>>> 3. Commit all of the patches at once to all relevant branches
> >>>> 4. Mark the JIRA resolved
> >>>>
> >>>> I understand there are a lot of branches now, and some changes require
> >>>> backports. In this case, commit the patch at hand to the branches it
> >> will
> >>>> apply to, then open a new JIRA (could be as a subtask) for the
> backport.
> >>>> Make sure to set fix versions appropriately so the RMs will see it.
> >>>>
> >>>> If our slipping JIRA discipline is not improved we will have incorrect
> >>>> release change logs, fewer releases, releases missing changes they
> >> should
> >>>> include, and other poor outcomes.
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Andrew
> >>>>
> >>>> Words like orphans lost among the crosstalk, meaning torn from truth's
> >>>> decrepit hands
> >>>>    - A23, Crosstalk
> >>>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Andrew
> >>>
> >>> Words like orphans lost among the crosstalk, meaning torn from truth's
> >>> decrepit hands
> >>>    - A23, Crosstalk
> >>
> >>
> >
>

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