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