On 3/25/21 3:13 PM, Jason Ekstrand wrote: > On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke <kenn...@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.
Since I suspect Gentoo will be one of the few distros that carry this branch for a long time, I asked Matt about this. I think he's fine with infrequent YY.MM or YY.QQ.xx type releases where the least significant part is incremented for non-feature changes and the YY is incremented every year regardless of the kind of change. As long as I can continue to count on using the Intel CI from time to time to test the legacy branch... I'm okay with splitting whenever. >>>> 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 > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
