grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Where is the testing? (was: Re: [PATCH] fs/xfs: Avoid unreadble file


From: Erwan Velu
Subject: Re: Where is the testing? (was: Re: [PATCH] fs/xfs: Avoid unreadble filesystem if V4 superblock)
Date: Wed, 8 Sep 2021 18:21:49 +0200

When this topic will be out, I'd would be glad to help.
Cheers,
Erwan,

Le mer. 8 sept. 2021 à 18:19, Daniel Kiper <dkiper@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 <development@efficientek.com>
> a écrit :
>
> > On Thu, 2 Sep 2021 10:56:49 +0200
> > Carlos Maiolino <cmaiolino@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]cmaiolino@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 <cmaiolino@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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]