Re: Where is the testing? (was: Re: [PATCH] fs/xfs: Avoid unreadble filesystem if V4 superblock)

[Erwan Velu <erwanaliasr1@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4244 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5636 bytes --]