When this topic will be out, I'd would be glad to help. Cheers, Erwan, Le mer. 8 sept. 2021 à 18:19, Daniel Kiper <dki...@net-space.pl> a écrit :
> On Wed, Sep 08, 2021 at 11:20:08AM +0200, Erwan Velu wrote: > > Le mer. 8 sept. 2021 à 03:24, Glenn Washburn < > developm...@efficientek.com> > > a écrit : > > > > > On Thu, 2 Sep 2021 10:56:49 +0200 > > > Carlos Maiolino <cmaiol...@redhat.com> wrote: > > > > > > > On Wed, Sep 01, 2021 at 02:40:57PM +0200, Daniel Kiper wrote: > > > > > CC-ing Javier... > > > > > > > > > > On Mon, Aug 30, 2021 at 01:48:50PM +0200, Carlos Maiolino wrote: > > > > > > Hi. > > > > > > On Mon, Aug 30, 2021 at 11:18:31AM +0200, Erwan Velu wrote: > > > > > > > Good day list, > > > > > > > Le jeu. 26 août 2021 à 15:26, Carlos Maiolino > > > > > > > <[1]cmaiol...@redhat.com> a écrit : > > > > > > > > > > > > > > [..] > > > > > > > Thanks for spotting this! > > > > > > > > > > > > > > I'm adding the maintainers in CC. Carlos who commit the > > > > > > > patch I'm fixing, agreed on the content. > > > > > > > > > > > > I didn't test the patch itself yet, but I've reproduced the > > > > > > issue. I was quite sure I had tested this patch on a V4 fs, but > > > > > > looks like I miscalculated the sizing. Thanks again. I'll try to > > > > > > test the patch here asap. > > > > > > > > > > Did you test this patch? If yes may I add your Tested-by to it? > > > > > > > > Yup, patch works fine, just finished testing it, I was just trying to > > > > understand where/why I miscalculated the inode size on V4 > > > > filesystems, and the reason was the same why Erwan split the > > > > last/first members of inode v2/v3 in two different unused structs. > > > > > > > > Feel free to add to the patch: > > > > > > > > Tested-by: Carlos Maiolino <cmaiol...@redhat.com> > > > > > > It looks like the xfs_test test succeeds with tag grub-2.06-rc1a, fails > > > with tag grub-2.06, and succeeds with current master. Yes, as expected. > > > However, what this tells me is that no "make check" tests were done > > > before finalizing the 2.06 release. I was under the impression that > that > > > was part of the release procedure. If its not, it would seem that we're > > > not using the tests at a time when they would have the most impact. > > > > > > It is my understanding that we have travis-ci tests that get run (at > > > some point?), however they are only build tests and so would not have > > > caught this. It was precisely this scenario that I hoped to avoid by > > > doing more thorough continuous integration, which runs the extensive > > > array of "make check" tests, when I submitted the Gitlab-CI patch > > > series (which would've caught this automatically if it had been > merged). > > > To me this scenario is the poster child for taking action on this > > > front. Can we make this a priority? > > > > > > > > That also triggers to me the question of the difficulty to make a > release. > > I'm pretty new to this project but from my other experiences, I'm missing > > what prevents doing a stable branch per release to perform critical > updates > > on them. > > I'm a big fan of how the Linux kernel manages this: once the commit is > > merged in master, it can be backported into the stable branches if the > > patch makes sense. > > Then, the stable branch can be released whenever it makes sense. > > This increases the maintenance burden (but can be delegated to dedicated > > people) but gives users the insurance of having an up to date & secured > > product. > > > > This topic was probably already addressed or questioned by the past > > soplease receive this as a simple questioning and not a straight > criticism > > of the project maintenance. > > The Linux project is more mature in many areas than the GRUB right now. > Additionally, due to various reasons development of the GRUB almost > stopped for years. Currently we are clearing the backlog and trying to > regain the control on the project. So, we have to focus on most > important things due to limited resources. Though I think at some point > we change and improve the release process too. > > Daniel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
