Re: Ceph Release Branch Management

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

 



On Tue, Feb 4, 2020 at 4:13 PM Josh Durgin <jdurgin@xxxxxxxxxx> wrote:
>
> On 2/4/20 3:13 PM, Patrick Donnelly wrote:
> > So we've started doing hotfix releases (v14.2.6 & v14.2.7), yay!
> > Unfortunately, this process is involving some kind of rebase which is
> > wrecking the release commit history. Exhibit A:
> >
> > https://github.com/ceph/ceph/pull/32602
> >
> > I'm in the process of fixing my backports but for those looking after
> > I'm done, my backport PR now has 156 commits including merges where
> > only 2 should exist.
> >
> > This must not continue. Asking backporters to rebase every backport PR
> > whenever we do a hotfix is a non-starter, IMHO.
> >
> > There's been discussions about using some various branching strategies
> > to make this work better but that would complicate the existing
> > release process and/or muck up upgrade tests. (In particular, it's
> > been suggested that the release branch _only_ point to a tagged
> > release.)
> >
> > Without entering into a drawn out discussion on how we could fix the
> > release process, I'm going to suggest the following git workflow to
> > avoid rebases within the current limitation of the release branch
> > always pointing to the cutting edge state:
> >
> > (1) Hotfix need identified: save current branch state:
> >
> > git checkout $release
> > git branch $release-save
> > git push upstream $release-save # push branch save to GitHub for
> > disaster recovery
> >
> > (2) In GitHub, restrict branch push rights on $release.
> >
> > (3) Hard reset to last tagged release:
> >
> > git reset --hard vX.Y.Z
> > git push --force upstream HEAD:$release
> >
> > (4) Do hotfix merges.
> >
> > (5) Tag/test release.
> >
> > (6) Merge the saved branch onto the release branch:
> >
> > git merge $release-save
> > git push upstream $release # no --force should be necessary!
> >
> >
> > No history is lost. The commit history reflects the reality of what
> > happened. No backport rebasing.
>
> This was exactly the procedure we used - if you check via the cli you'll
> see all those commits are in fact still in the nautilus branch. There
> was no rebasing. For example, git log origin/nautilus..FETCH_HEAD after
> fetching that PR shows only 2 commits.

My apologies Josh. You're quite right. Shame on me for not actually
looking at the commit history!

> I'm not sure why github did not update the list of commits in PRs after
> the nautilus branch was restored - it seems like a bug. I'm curious if
> anyone knows how to make github refresh its view again.

I don't know except to do the rebase :(

-- 
Patrick Donnelly, Ph.D.
He / Him / His
Senior Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
_______________________________________________
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