The tarballs should be uploaded to [1] and/or [2] right? But I don't see any entry for nuttx/. Should a mentor create it?
1. https://dist.apache.org/repos/dist/dev/incubator/ 2. https://dist.apache.org/repos/dist/release/incubator/ On Tue, Apr 21, 2020 at 5:19 AM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > > 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! > > > > > > > > > > > >
