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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev