Re: nautilus, octopus and pacific branches restored

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 14, 2021 at 8:47 PM J. Eric Ivancich <ivancich@xxxxxxxxxx> wrote:
>
> Hi Ilya,
>
> This process seems to have led to mistakes and wasted cycles by some (many?) contributors, such as me, and some of which you make reference to. For example, after the initial force-push on a base branch I unknowingly did a rebase on a backport branch, due to an automated email, only to have to undo the rebase once the base branch was restored. Some of my backports generated lots of extraneous emails, now list many additional contributors, along with some additional invites for reviewers.

Right, see Patrick's reply for why this happens.

>
> First, did I miss an announcement ahead of time that this would take place and how I should handle the noise?

There was no separate announcement but you may have seen hotfix
release emails going by.  master and release branches are never
rebased or force pushed to otherwise, so if you see it happen it is
because a hotfix release is being built and someone from the release
team is handling it.  Just as a confirmation, another indication is
that the base branch would be "locked" by requiring six reviews.

The best course of action is to ignore it and let the release team
sort out the affected PRs.  If you are in hurry, changing the base
branch from e.g. octopus to octopus-saved and then back to octopus
for an octopus PR will get rid of extraneous commits and contributors
(but not labels or review requests, unfortunately).

>
> And will this process be used for future releases? I don’t know what the deficiencies of our release process are and why this work-around was the preferred option, but I’m left imagining that there must be a better way that’s far less noisy and disruptive.

Yes, this process will be used for hotfix releases until the release
tooling is able to build, sign and get the release out the door from
an arbitrarily named branch.  This came up at the last CLT meeting [1]
and a bunch of times before that, hopefully it will get fixed soon!

[1] https://lists.ceph.io/hyperkitty/list/dev@xxxxxxx/thread/AQDOCJGUVXCN7Y5OBNOO3OA5AV24SQLT/

Thanks,

                Ilya

>
> Thanks for considering,
>
> Eric
>
> > On Apr 20, 2021, at 3:42 PM, Ilya Dryomov <idryomov@xxxxxxxxx> wrote:
> >
> > Hi everyone,
> >
> > You may have noticed some unusual activity in the backport PRs in the
> > past week, namely force pushes to the base branch and temporary changes
> > of the same, resulting in humongous changesets/diffstats being shown.
> > This was done to work around some deficiencies in the release process,
> > apologies for the inconvenience.
> >
> > Now that 14.2.20, 15.2.11 and 16.2.1 are out the door, everything has
> > been restored.  Jenkins is currently backed up processing "make check"
> > and "ceph API tests" jobs, but it should clear up by tomorrow.  Please
> > retrigger with "jenkins test make check", "jenkins test api", etc if
> > needed.
> >
> > Some of you have clicked the unhelpful "Update branch" button, which
> > generated an unneeded merge commit.  Please get rid of it, either by
> > rebasing or simply rolling back to the parent.  I went through the PRs
> > and commented on those that need action, but please double check that
> > there are no merge commits or unrelated changes in the "Commits" list
> > before merging.
> >
> > Thanks,
> >
> >                Ilya
>
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx




[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux