[lustre-devel] [LSF/MM/BPF TOPIC] [DRAFT] Lustre client upstreaming

[Oleg Drokin]

On Sat, 2025-01-25 at 10:12 +1100, NeilBrown wrote:
> On Mon, 20 Jan 2025, Oleg Drokin wrote:
> > On Sun, 2025-01-19 at 09:48 +1100, NeilBrown wrote:
> > > 
> > > Once the transition completes there will still be process
> > > difficulties,
> > > but there are plenty of of process difficulties now (gerrit: how
> > > do I
> > > hate thee, let me count the ways...) but people seem to simply
> > > include
> > > that in the cost of doing business.
> > 
> > it's been awhile since I did patch reviews by emails, but I think
> > gerrit is much more user-friendly (if you have internet, anyway)
> 
> I guess it isn't exactly the gerrit interface but more the workflow
> that
> it encourages, or at least enables.
> The current workflow seems to be "patch at a time" rather than
> "patchset
> at a time".
> The fact that you cherry-pick patches into master is completely
> different to how most (all?) of the upstream community works.  It
> means
> that whole series isn't visible in the final git tree so we lose
> context.  And it seems to mean that a long series takes a loooooong
> time
> to land as it dribbles in to master.

In fact the whole series is visible in gerrit if you submit it as such.
But as you noted later the testing is unfortunately much les reliable
than we want, and because we only land things in order they are
submitted in the series - if you bunch unrelated stuff all together
suddenly it might take much longer to land.

> I would MUCH rather that a whole series was accepted or rejected as a
> whole - and was merged rather than cherry-picked to keep commit ids
> stable.

Gerrit has such a mode, but we decided it does not work well for us for
a variety of reasons.

> There are times when I would like the first few patches of a series
> to
> land earlier, but that should be up to the submitter to split the
> series. 

But you cannot if these later patches do depend on the earlier ones?

> And the automatic testing is a real pane.  Certainly it is valuable
> but
> it has a real cost too.  The false positives are a major pane.  I
> would
> rather any test that wasn't reliable were disabled (of fixed) as a
> priority.  Or at least made non-fatal.
> Also, it would be much nicer if the last in a series were tested
> first
> and if that failed then don't wasted resources testing all the
> others.
> Bonus points for a "bisect" to find where the failure starts, but
> that
> can be up to the develop to explicitly request testing at some points
> in
> the series.

Yes,  I agree there's much to be improved testing-wise. I did not come
up with my own parallel testing system because I was happy with the
default one after all.
And then my own system deteriorated (At least it does not set -1s left
and right, though that means people totally ignore those results too)