In that case, I agree with Abhishek's proposal to merge all backport PRs
to ${release}-next, with the understanding that we may be retargeting
lots of PRs before people get used to this change.
Nathan
On 04/19/2018 09:40 PM, Alfredo Deza wrote:
On Thu, Apr 19, 2018 at 12:35 PM, Abhishek Lekshmanan <abhishek@xxxxxxxx> wrote:
Nathan Cutler <ncutler@xxxxxxx> writes:
I'm thinking that we might need to change our backports workflow to go
for luminous-next instead of luminous by default and merging to Luminous
only at QE handover so that the branch is almost close to release branch
and we have less issues with merges and workflow when final QE is
happening.
It will be difficult for folks to remember to target luminous-next.
The work product of the release preparation phase is a SHA1 that has
been signed off on and which then goes to QE to test. Would it be
possible to put this "to-be-released" SHA1 into luminous-next when the
release goes to QE? Then QE could test "luminous-next" and the release
packages could be built from "luminous-next" as well.
One of the final steps of the release process, after the official
release packages are built and made public on download.ceph.com, would
be to manually merge luminous-next into luminous. IIRC this is what Sage
proposed the last time this topic came up here.
Many of the build-scripts and jenkins jobs still referred to named
branches and some breakage is expected if we try the luminous-next
approach for building. I'm not sure if we have an easier way out of
this. Alfredo, Ken any ideas here?
Everything we do/have is branch-name based. Part of it is because
*everything else* is based on release names: download.ceph.com, docs,
automated nightlies, jenkins jobs, etc....
It would be problematic to make the universe of builds we have to
accommodate arbitrary release branches that are not named like the
release.
Having said that, I do agree that our release process is not very
faithful to what is being tested, many times before we've had commits
get in between the time we have a "good to go" on
cutting a release and having the branch open for pull request merges.
Our releases can take longer than a day (!) and in our worst case
scenarios it has taken over a week (!!!), and we don't
have any mechanisms to prevent this situation. This is an unfortunate
caveat of the current workflow.
What needs to be improved is our ability to be able to release from a
sha1. A few years ago I met with the Chef release team to discuss a
bit their release workflow, and they had several stages
in their release cycle, starting with a sha1 that was agreed as the
candidate for release. If the sha1 I didn't met a passing criteria it
would go back to the beginning to make fixes and to define again
what the sha1 release would be. If successful, it would then become
the actual release. All throughout, everyone and everything had direct
visibility as to what the upcoming release would be.
This is very unlike what we do today, partially because we can't do
something like "cut a luminous 12.2.5 release from <sha1>" anywhere,
but also because it was like this from the beginning and
a lot of these things are hardcoded on those assumptions :(
The ideal situation will take quite a bit of effort (to release from a sha1)
--
Abhishek
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Nathan Cutler
Software Engineer Distributed Storage
SUSE LINUX, s.r.o.
Tel.: +420 284 084 037
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
