Re: [discuss] how to label milestone

[Ivan Kelly <iv...@apache.org>]

> All the bug fixes are deferred to release manager cherry-picking to bug fix
> branches. Since master and branches are quickly diverged with changes,
> it is very painful for cherry-picks later and there is no clear process for
> cherry-pick and labelling.

What is painful here? If it's the conflict resolution, this pain would
just be spread out, with it being felt by whomever is merging, but
then it would also be worse, because cherry-picks would happen out of
order.

In the past I've had more success with processes which keep day to day
development on master 100% of the time. If and when you want to cut a
release branch, at that point, you go through the commits in master
since the last release, and select those that should make the bugfix
release. Once you have the list, cherry-picking, in-order, can occur.
This creates more work for the release manager, but it removes the
need to think about the releases from the developer in their
day-to-day.

> Shall we consider following the process what BookKeeper is using, having a
> merge script to handle labelling issues/milestones and also cherry-picks?

That script turns a 5 second task into a 5 minute task. It also
creates a decision point for the developer where the answer is not
always clear. If no bugfix releases are currently planned, should I
still cherry-pick in branch-1.22?

-Ivan

Re: [discuss] how to label milestone

[Ivan Kelly <iv...@apache.org>]

> The pain comes from issues marked for a bug release milestone but it is
> merged directly to master and never cherry-picked to branch for bugfix
> releases.
> So the release manager has to compare branches and master and also have to
> compare labels, milestones and even look into the details of pull requests
> to understood whether a change is cherry-picked or not.

This is a problem, but it should be 99% automatable. In fact it should
be automated, that before cutting a release, that we have a script
that validates that all issues labelled for the release have a change
present in the commit log, and all commit log messages are referenced
by some issue or PR. Gerrit has a change-id that makes this easy, but
I'm not sure about github.

-Ivan

Re: [discuss] how to label milestone

[Sijie Guo <gu...@gmail.com>]

On Mon, Sep 3, 2018 at 12:14 AM Ivan Kelly <iv...@apache.org> wrote:

> > All the bug fixes are deferred to release manager cherry-picking to bug
> fix
> > branches. Since master and branches are quickly diverged with changes,
> > it is very painful for cherry-picks later and there is no clear process
> for
> > cherry-pick and labelling.
>
> What is painful here?



> If it's the conflict resolution, this pain would
> just be spread out, with it being felt by whomever is merging, but
> then it would also be worse, because cherry-picks would happen out of
> order.
>

Sure. But if when merging a PR also cherry-pick to corresponding branches,
the conflicts will be reduced a lot.

The pain comes from issues marked for a bug release milestone but it is
merged directly to master and never cherry-picked to branch for bugfix
releases.
So the release manager has to compare branches and master and also have to
compare labels, milestones and even look into the details of pull requests
to understood whether a change is cherry-picked or not.


>
> In the past I've had more success with processes which keep day to day
> development on master 100% of the time. If and when you want to cut a
> release branch, at that point, you go through the commits in master
> since the last release, and select those that should make the bugfix
> release. Once you have the list, cherry-picking, in-order, can occur.
> This creates more work for the release manager, but it removes the
> need to think about the releases from the developer in their
> day-to-day.
>

That works for me. what I really want is a process here that everyone
follows. I have been seeing issues merged to master but marked for bugfixes
releases,
and issues merged without labels and milestones. That will just kill the
release manager.


>
> > Shall we consider following the process what BookKeeper is using, having
> a
> > merge script to handle labelling issues/milestones and also cherry-picks?
>
> That script turns a 5 second task into a 5 minute task.


Sure it requires more steps on merging issues, however it enforces people
label components, types and releases correctly. If we don't label things
correctly,
the project and release processes will quickly become out of control. No
one is able to quickly figure out how a change lands at what releases.

People sometimes are just lazy. If they can just click a button to merge
one PR, they do it and things quickly become messy because there is no
enforcement.



> It also
> creates a decision point for the developer where the answer is not
> always clear.


I think as a committer, he/she should try to be aware of those things (e.g.
whether this bug is critical, whether it should be included to a release or
not). It is sort of the committer's commitment to the project.

If he doesn't know whether he should cherry-pick or not, he can just merge
to master and leave it to release manager to decide. The point here is we
need to some enforcement to make sure a merged change
is labelled correctly for a release. so when the release manager going
through the issues and commits, he is able to quickly know what he should
do.


> If no bugfix releases are currently planned, should I
> still cherry-pick in branch-1.22?
>



>
> -Ivan
>