[Mesa-dev] [RFC] Concrete proposal to split classic

[Kenneth Graunke]

On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> On 3/25/21 10:49 AM, Jason Ekstrand wrote:
[snip]
> > I'm not sure we want to totally declare those drivers dead. People can
> > still do feature or enhancement development of they want to, it just
> > happens in a different branch.
> > 
> > I think we need to be more clear about what "LTS mode" means for
> > developers and users here. It isn't that they can never change our be
> > improved. It's that we've gotten to the point where what they're
> > getting from being in the active development tree is breakage, not
> > "free" improvements. We're suggesting changing the social contract
> > with users, so to speak, from "these drivers still pick up
> > improvements from core" to "we won't break these drivers when we make
> > improvements to core in master."
> 
> That is interesting.  I doesn't sound very much like "long term stable"
> as in the original proposal.  What would the versioning scheme be?  In
> the original proposal, I would have expected versions go to 21.1.∞.  How
> would that work if some version adds a feature?  Would the versions (and
> branches from the branch?) follow the usual Mesa Year.Quarter.x scheme?

That's a good point.  It's a bit expanded from "put out to pasture" so
maybe "-lts" isn't great.  We could call it "-classic", unless Marek
wants to include r300g in there too.  "-legacy" seems reasonable.  It
looks like NVIDIA has various "legacy" branches with a version number
based on the original version where things branched off from.

So maybe we could do:

   - mesa-legacy21 21.1.X

where X increments on every release without worrying whether it adds
features or simply bug fixes.  We figure true features and major
development will be pretty rare anyway.

> > So, unless there's a solid reason why such work needs to happen in the
> > master branch, I don't see a reason to hold this up for it.  As long
> > as you're committed to test r200 and i915 when you make said changes,
> > we can do a feature release on the LTS branch. Users and distros just
> > shouldn't expect that to be a common thing.
> 
> This inverts the current testing problem.  Right now, r200 and i915 are
> poorly tested, but 965G through Sandybridge are very well tested.  While
> I can totally test core changes on r200 and i915, how would I verify
> that those changes don't break, say, Ironlake?

Post-fork, Intel CI would stop testing i965 on mainline obviously,
since it wouldn't exist there any longer.

But I imagine it would add a new mesa_legacy21 job (like mesa_master)
which would still test i965 and i915, per-commit.  Clayton/Nico could
also add "dev/idr/legacy" branches which trigger testing on i965/i915
only.  The existing expected results files would continue to work.

Then testing would be pretty similar to today, you'd just have a
different dev branch for targeting master (testing anv and iris)
or legacy21 (testign i915 and i965).

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20210325/7b408769/attachment.sig>