On Mon, Apr 20, 2020 at 10:34 AM Gregory Nutt <spudan...@gmail.com> wrote: > If we rebase, we would have to update the release notes and related > documentation again. You have to freeze the code somewhere; there will > always be things that are omitted from the release that will have to > wait until the next release. I would vote that we not rebase the > release branch. I think we should keep it as stable as possible and > only bring in bug fixes.
I agree. The idea of opening a branch in preparation for the new release is that code in that branch is "frozen" except for bugfixes which are found during testing, fixed in master (to ensure they remain fixed), and backported to the release branch. > The main concern that I have is that there has been no testing or > qualification of the release. It was frozen but never verified We need to make the release candidate tarballs and put them up for testing/signing, and give people a couple of weeks to test them. I guess we aren't going to make the April 30 release but we're all still learning and trying to figure out the process. Just as we had trouble with other things in the beginning after we became a podling, those things got sorted out, and I am confident that the next release will go much more smoothly. The important thing is to proceed with the making of tarballs and putting them up for testing. Nathan
