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

[Jason Ekstrand]

On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke <kenneth at whitecape.org> wrote:
>
> On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> > On 3/25/21 10:49 AM, Jason Ekstrand wrote:
> > Can you be more specific? Also, is there a reason why that work can't
> > or shouldn't be done directly in the LTS branch?  As Ken pointed out,
>
> The bulk of things that I had going were to enable some extensions and
> make those extensions non-optional.  ARB_framebuffer_object was at the
> top of the list, but there were a couple of others.  I think ARB_fbo
> also affected the Gallium nouveau driver.  Some of that was derailed
> when I wasn't able to remove (classic) support for NV04 and NV05... and
> I don't remember exactly where I left it.  I would expect some of those
> kinds of changes to also happen in post-fork mainline too.

Hrm... That is a genuinely interesting extension on those platforms.
>From a "make it non-optional and dead-code" perspective, we can do
that on mainline immediately post-fork easily enough.  Enabling it on
legacy could be done separately.  If we wanted to also clean up the
core on the legacy branch then, yeah, it'd have to be done twice.

> > > 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?

I think we should make a distinction between what users should expect
and what devs are allowed to do.  It should be LTS from the
perspective that users shouldn't expect new features.  Then again,
they really shouldn't expect new features on those drivers anyway.
¯\_(ツ)_/¯

> 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.

Yeah, I don't know that we need to worry too much about stable vs.
feature releases on the legacy branch.  If we still wanted a concept
of major releases, we could slow it down to 1/year or something.
Really, whatever makes it easiest for the release maintainers is fine
with me.

> > > 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.

I think this should work fine.  It would end up being more like once
per piglit MR rather than once per mesa MR since the cadence on the
legacy branch should slow to a crawl.

If anything, it might make testing easier since you'll have the whole
pre-gen8 farm to yourself if you're hacking on the legacy branch. 🙃

--Jason