You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Andrew Purtell <ap...@apache.org> on 2018/07/23 19:18:33 UTC
Recent trend in JIRA management
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
Re: Recent trend in JIRA management
Posted by Andrew Purtell <an...@gmail.com>.
If in your judgement that is what you think is best, that's fine. We are supposed to be doing minors more frequently after all. Mainly I am concerned about trunk being a dumping ground and the lack of rigor in setting fix versions and resolving JIRAs.
For a bug fix relevant for a release branch, though, if you as committer don't put the change into the release branch too and/or forget to update the fix version, then the bug fix may be ignored. This is especially true if the fix is only committed to trunk.
Thanks in advance!
> On Jul 23, 2018, at 12:52 PM, Huaxiang Sun <hs...@cloudera.com.INVALID> wrote:
>
> Thanks for clarification, Andrew. I was thinking that it needs RM’s approval to commit to
> branch-1.2/1.3/1.4, so unless it is a critical/major fix, by default, it goes to branch-1.
>
> It is now clear and I think every committer will follow this best practice.
>
> Thanks
> Huaxiang
>
>> On Jul 23, 2018, at 12:47 PM, Andrew Purtell <ap...@apache.org> 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 <hs...@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 <ap...@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 <ap...@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
>>>
>>>
>>
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>> - A23, Crosstalk
>
Re: Recent trend in JIRA management
Posted by Huaxiang Sun <hs...@cloudera.com.INVALID>.
Thanks for clarification, Andrew. I was thinking that it needs RM’s approval to commit to
branch-1.2/1.3/1.4, so unless it is a critical/major fix, by default, it goes to branch-1.
It is now clear and I think every committer will follow this best practice.
Thanks
Huaxiang
> On Jul 23, 2018, at 12:47 PM, Andrew Purtell <ap...@apache.org> 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 <hs...@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 <ap...@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 <ap...@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
>>
>>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
Re: Recent trend in JIRA management
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Better mention the release manager when you want to commit to the branch.
If no response in a day or so then just go head. At least for 2.1 you can
follow this rule.
2018-07-25 11:06 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> So only branch-2.0 need RM's approval. For other release
> branchs(1.2/1.3/1.4/2.1), they are same with trunk branch and only need one
> +1 from a committer, right?
>
> 2018-07-24 7:37 GMT+08:00 Stack <st...@duboce.net>:
>
> > On Mon, Jul 23, 2018 at 3:44 PM Josh Elser <el...@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 <ap...@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
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: Recent trend in JIRA management
Posted by Guanghao Zhang <zg...@gmail.com>.
So only branch-2.0 need RM's approval. For other release
branchs(1.2/1.3/1.4/2.1), they are same with trunk branch and only need one
+1 from a committer, right?
2018-07-24 7:37 GMT+08:00 Stack <st...@duboce.net>:
> On Mon, Jul 23, 2018 at 3:44 PM Josh Elser <el...@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 <ap...@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
> > >>
> > >>
> > >
> >
>
Re: Recent trend in JIRA management
Posted by Stack <st...@duboce.net>.
On Mon, Jul 23, 2018 at 3:44 PM Josh Elser <el...@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 <ap...@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 <ap...@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
> >>
> >>
> >
>
Re: Recent trend in JIRA management
Posted by Josh Elser <el...@apache.org>.
I've been operating under the "get approval" for branch-2.0 since it was
explicitly asked for.
@Stack you still want to operate in that manner since we're chatting
about this?
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 <hs...@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 <ap...@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 <ap...@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
>>
>>
>
Re: Recent trend in JIRA management
Posted by Andrew Purtell <ap...@apache.org>.
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 <hs...@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 <ap...@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 <ap...@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
>
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: Recent trend in JIRA management
Posted by Huaxiang Sun <hs...@cloudera.com.INVALID>.
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 <ap...@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 <ap...@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
Re: Recent trend in JIRA management
Posted by Andrew Purtell <ap...@apache.org>.
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 <ap...@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