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

[Ian Romanick]

On 3/25/21 3:13 PM, Jason Ekstrand wrote:
> 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.

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev