Yes, we are learning how to make the first apache release. Let's get it out and refine the process in the next time. Thanks you making this happen!
On Tue, Apr 21, 2020 at 6:12 AM Abdelatif Guettouche <abdelatif.guettou...@gmail.com> wrote: > > > Yes, only if the release don't have any bug, but the software always > > has bug, right? how people fix the issue? the first step is git clone > > the code from github: > > 1.Review the difference between the release and master > > 2.Review the history to see whether other people already fix the issue > > 3.... > > I still fail to see how it will make life any harder to find out if a > bug was fixed on master or not. > When a release contains a bug, that bug is either fixed on master or > still not discovered. > If it was fixed and we think it's crucial enough to re-release with an > increment patch (say 9.0.1), the user will need to upgrade. > Otherwise, the user can backport the change himself. > If the user discovers the bug and fixes it, he can provide a patch and > we decide to whether we release again or keep it for the next one. > > I guess during the branch freezing time, cherry picking is inevitable, > maybe it was for this one but for releases where showstoppers were > discovered, we can only cherry-pick them. > If what you are saying is to keep the commits backported to a minimum, > then yes, I agree. > Maybe next time before backporting we call a vote as you suggested and > not directly create a PR. > > Thanks everyone! > > It is important for us to learn from this first Apache release and > perfect the process to make it as smooth as possible each time. > > > On Mon, Apr 20, 2020 at 8:27 PM Alan Carvalho de Assis > <acas...@gmail.com> wrote: > > > > Yes, he did a great work, this morning for instance he stay up to > > 5:30AM working on it. > > > > So, lets move on with the NuttX 9.0 release and learn from this experience. > > > > BR, > > > > Alan > > > > On 4/20/20, Gregory Nutt <spudan...@gmail.com> wrote: > > > > > >> For future 2-month releases, I think that on the branch date, we > > >> should branch and immediately make -rc1 tarballs. > > >> > > >> Then the community can test, report bugs/showstoppers, and those will > > >> be fixed on master and backported to the branch. > > >> > > >> When it seems there are no more showstoppers, make -rc2 tarballs, let > > >> test a few more days. If no showstoppers this time, re-brand it as the > > >> final release. > > > > > > That sounds perfect. This release was our first experiment. I think we > > > should get it out the door and start thinking about how we can improve > > > the release process for the June release. > > > > > > I think we owe Abdelatif thanks. What has happened could not have > > > happened without his contribution. There was no one else standing up to > > > do this job and Abdelatif stepped in and did it. Their should be no > > > criticisms because none of us are in a place where we can "cast the > > > first stones" because we did not do the work. Rather, we should offer > > > our thanks. Suggestions for improvement are welcome and if you want to > > > be helpful, they should be included in a release procedure document. > > > > > > Thanks, Abde! > > > > > > > > >
