[Mesa-dev] [RFC] Concrete proposal to split classic
kenneth at whitecape.org
Thu Mar 25 21:32:08 UTC 2021
On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> On 3/25/21 10:49 AM, Jason Ekstrand wrote:
> > 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the mesa-dev