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 -- 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
