From: Loic Dachary <loic@dachary.org>
To: Nathan Cutler <ncutler@suse.cz>,
Abhishek Varshney <abhishek.varshney@flipkart.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>,
Abhishek Lekshmanan <abhishek@suse.com>
Subject: Re: starting with jewel v10.2.5
Date: Thu, 27 Oct 2016 12:21:58 +0200 [thread overview]
Message-ID: <5811D546.2050607@dachary.org> (raw)
In-Reply-To: <278431d9-747e-baf6-90f5-8980c992a1c6@suse.cz>
On 27/10/2016 12:19, Nathan Cutler wrote:
> On 10/27/2016 12:02 PM, Loic Dachary wrote:
>> Hi Abhishek & Nathan & Abhishek,
>>
>> Hopefully jewel will start testing with QE tomorrow or early next week.
>>
>> In the past we kept backporting but we were very careful not to merge anything because the release process is not able to work with a SHA1, it will create the next jewel release with whatever is at the tip of that branch. This limitation has been there for years and there is little chance that it will be resolved any time soon. It routinely creates frustration when something is merged by accident and tests have to be run again (or worse: they are not run and the release is done anyway). It also creates extra work for the backporters who need to collect backports that could have been merged because they passed the tests.
>>
>> Instead, I propose that we backport, test and merge to wip-jewel, as if it was the jewel branch, until the release is done. And when it's done we rebase wip-jewel on top of jewel (or we verify that there is no need to rebase), we push all commits from wip-jewel to jewel, we delete the wip-jewel branch and we resume backporting to the jewel branch.
>>
>> In a nutshell it means we have a little extra work:
>>
>> a) re-targeting backports to wip-jewel in each PR (which is now possible with github)
>> b) pushing wip-jewel to jewel after the release and re-targeting backports to jewel
>>
>> And the benefits are that
>>
>> a) we don't have to stop merging while QE runs tests and the release is prepared, which takes a few weeks
>> b) there is no risk of an accidental merge that would break the release process
>>
>> What do you think ?
>
> I wouldn't say it completely removes the risk of an accidental merge to jewel, but it certainly reduces it :-)
:-) One would have to a) open a PR against jewel, b) not be noticed by someone from the backport team, c) be merged by someone who is not aware of the new convention. It's indeed not impossible.
> Anyway, it sounds good to me. The only awkwardness is that it will require existing backport PRs to be closed and reopened (AFAIK there is no other way to "retarget" a PR to a different branch).
It is now possible, when you click "Edit" on the PR title you also have the option to change the target branch of the PR.
Cheers
--
Loïc Dachary, Artisan Logiciel Libre
next prev parent reply other threads:[~2016-10-27 13:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-27 10:02 starting with jewel v10.2.5 Loic Dachary
2016-10-27 10:19 ` Nathan Cutler
2016-10-27 10:21 ` Loic Dachary [this message]
[not found] ` <87lgxajayr.fsf@suse.com>
2016-10-27 12:29 ` Loic Dachary
2016-10-27 15:04 ` Abhishek Varshney
2016-10-27 16:11 ` Loic Dachary
2016-10-27 17:53 ` Ken Dreyer
2016-10-27 19:52 ` Alfredo Deza
2016-11-10 10:44 ` Loic Dachary
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5811D546.2050607@dachary.org \
--to=loic@dachary.org \
--cc=abhishek.varshney@flipkart.com \
--cc=abhishek@suse.com \
--cc=ceph-devel@vger.kernel.org \
--cc=ncutler@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.