Re: [Mesa-dev] [RFC] Concrete proposal to split classic
> And, yeah, I'd love to drop vec4 but yeah... One advantage to keeping > vec4 in the tree for some stuff is that it means we have full-featured > hardware able to test vec4 NIR. That seems like a feature. I have to keep caring about Midgard for the next indefinitely so please don't break vec4 NIR ;-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker wrote: > > Hi list, > > We've talked about it a number of times, but I think it's time time to > discuss splitting the classic drivers off of the main development branch > again, although this time I have a concrete plan for how this would > work. > > First, why? Basically, all of the classic drivers are in maintanence > mode (even i965). Second, many of them rely on code that no one works > on, and very few people still understand. There is no CI for most of > them, and the Intel CI is not integrated with gitlab, so it's easy to > unintentionally break them, and this breakage usually isn't noticed > until just before or just after a release. 21.0 was held up (in small > part, also me just getting behind) because of such breakages. > > I konw there is some interest in getting i915g in good enough shape that > it could replace i915c, at least for the common case. I also am aware > that Dave, Ilia, and Eric (with some pointers from Ken) have been > working on a gallium driver to replace i965. Neither of those things are > ready yet, but I've taken them into account. > > Here's the plan: > > 1) 21.1 release happens > 2) we remove classic from master > 3) 21.1 reaches EOL because of 21.2 > 4) we fork the 21.1 branch into a "classic-lts"¹ branch > 5) we disable all vulkan and gallium drivers in said branch, at least at >the Meson level I'm +1 for the -lts branch.. the layering between mesa "classic" and gallium is already starting to get poked thru in the name of performance, and we've already discovered cases of classic drivers being broken for multiple months with no one noticing. I think a slower moving -lts branch is the best approach to keeping things working for folks with older hw. But possibly there is some value in not completely disabling gallium completely in the -lts branch. We do have some older gallium drivers which do not have CI coverage and I think are not used frequently by developers who are tracking the latest main/master branch. I'm not suggesting that we remove them from the main (non-lts) branch but it might be useful to be able to recommend users of those drivers stick with the -lts version for better stability? BR, -R > 6) We change the name and precidence of the glvnd loader file > 7) apply any build fixups (turn of intel generators for versions >= 7.5, >for example > 8) maintain that branch with build and critical bug fixes only > > This gives ditros and end users two options. > 1) then can build *only* the legacy branch in the a normal Mesa provides >libGL interfaces fashion > 2) They can use glvnd and install current mesa and the legacy branch in >parallel > > Because of glvnd, we can control which driver will get loaded first, and > thus if we decide i915g or the i965 replacement is ready and turn it on > by default it will be loaded by default. An end user who doesn't like > this can add a new glvnd loader file that makes the classic drivers > higher precident and continue to use them. > > Why fork from 21.1 instead of master? > > First, it allows us to delete classic immediately, which will allow > refactoring to happen earlier in the cycle, and for any fallout to be > caught and hopefully fixed before the release. Second, it means that > when a user is switched from 21.1 to the new classic-lts branch, there > will be no regressions, and no one has to spend time figuring out what > broke and fixing the lts branch. > > When you say "build and critical bug fixes", what do you mean? > > I mean update Meson if we rely on something that in the future is > deprecated and removed, and would prevent building the branch or an > relying on some compiler behavior that changes, gaping exploitable > security holes, that kind of thing. > > footnotes > ¹Or whatever color you like your > bikeshed___ > 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
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On Wed, Mar 24, 2021 at 10:28 AM Rob Clark wrote: > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker wrote: > > > > Hi list, > > > > We've talked about it a number of times, but I think it's time time to > > discuss splitting the classic drivers off of the main development branch > > again, although this time I have a concrete plan for how this would > > work. > > > > First, why? Basically, all of the classic drivers are in maintanence > > mode (even i965). Second, many of them rely on code that no one works > > on, and very few people still understand. There is no CI for most of > > them, and the Intel CI is not integrated with gitlab, so it's easy to > > unintentionally break them, and this breakage usually isn't noticed > > until just before or just after a release. 21.0 was held up (in small > > part, also me just getting behind) because of such breakages. > > > > I konw there is some interest in getting i915g in good enough shape that > > it could replace i915c, at least for the common case. I also am aware > > that Dave, Ilia, and Eric (with some pointers from Ken) have been > > working on a gallium driver to replace i965. Neither of those things are > > ready yet, but I've taken them into account. > > > > Here's the plan: > > > > 1) 21.1 release happens > > 2) we remove classic from master > > 3) 21.1 reaches EOL because of 21.2 > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch > > 5) we disable all vulkan and gallium drivers in said branch, at least at > >the Meson level > > I'm +1 for the -lts branch.. the layering between mesa "classic" and > gallium is already starting to get poked thru in the name of > performance, and we've already discovered cases of classic drivers > being broken for multiple months with no one noticing. I think a > slower moving -lts branch is the best approach to keeping things > working for folks with older hw. > > But possibly there is some value in not completely disabling gallium > completely in the -lts branch. We do have some older gallium drivers > which do not have CI coverage and I think are not used frequently by > developers who are tracking the latest main/master branch. I'm not > suggesting that we remove them from the main (non-lts) branch but it > might be useful to be able to recommend users of those drivers stick > with the -lts version for better stability? I agree with this. Generally, I don't think we should delete anything from the -lts branch. Doing so only risks more breakage. We probably want to change some meson build defaults to not build anything but old drivers but that's it. --Jason > BR, > -R > > > 6) We change the name and precidence of the glvnd loader file > > 7) apply any build fixups (turn of intel generators for versions >= 7.5, > >for example > > 8) maintain that branch with build and critical bug fixes only > > > > This gives ditros and end users two options. > > 1) then can build *only* the legacy branch in the a normal Mesa provides > >libGL interfaces fashion > > 2) They can use glvnd and install current mesa and the legacy branch in > >parallel > > > > Because of glvnd, we can control which driver will get loaded first, and > > thus if we decide i915g or the i965 replacement is ready and turn it on > > by default it will be loaded by default. An end user who doesn't like > > this can add a new glvnd loader file that makes the classic drivers > > higher precident and continue to use them. > > > > Why fork from 21.1 instead of master? > > > > First, it allows us to delete classic immediately, which will allow > > refactoring to happen earlier in the cycle, and for any fallout to be > > caught and hopefully fixed before the release. Second, it means that > > when a user is switched from 21.1 to the new classic-lts branch, there > > will be no regressions, and no one has to spend time figuring out what > > broke and fixing the lts branch. > > > > When you say "build and critical bug fixes", what do you mean? > > > > I mean update Meson if we rely on something that in the future is > > deprecated and removed, and would prevent building the branch or an > > relying on some compiler behavior that changes, gaping exploitable > > security holes, that kind of thing. > > > > footnotes > > ¹Or whatever color you like your > > bikeshed___ > > 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa 20.3.5
Hi List, Mesa 20.3.5 is now available. This is a quite large release with a huge number of fixes in it, and is the last planned release for the 20.3.x series. Radv and ACO dominate the changes for this release, but there are some other things mixed in there. Cheers, Dylan Changlog Alyssa Rosenzweig (3): pan/bi: Fix M1/M2 decoding in disassembler panfrost: Don't advertise OES_copy_image panfrost/lcra: Fix constraint counting Anuj Phogat (2): intel/anv: Fix condition to set MipModeFilter for YUV surface intel/anv: Fix condition for planar yuv surface Bas Nieuwenhuizen (8): radv: Do not hash vk_object_base in descriptor set layout. radv: Improve spilling on discrete GPUs. radv: Fix vram override with fully visible VRAM. radv: Ignore WC flags for VRAM. radv: Don't use dedicated memory info to indicate sharing. vulkan/device_select: Stop using device properties 2. radv: Expose robustBufferAccessUpdateAfterBind correctly. radv: Use stricter HW resolve swizzle compat check. Boris Brezillon (2): panfrost: Fix tiler job injection (again) panfrost: Fix a polygon list corruption in the multi-context case Caio Marcelo de Oliveira Filho (2): spirv: Allow variable pointers pointing to an array of blocks anv: Lower ViewIndex to zero when multiview is disabled Daniel Schürmann (2): aco: fix nir_intrinsic_ballot with wave32 aco: fix shared VGPR allocation on RDNA2 Dave Airlie (3): zink: don't pick a cpu device ever. glsl: fix leak in gl_nir_link_uniform_blocks glx: proposed fix for setSwapInterval Dylan Baker (12): docs: Add sha256sum for 20.3.4 .pick_status.json: Update to e346f61a91266bde48cc0857f82ca6348e38dc03 .pick_status.json: Update to ea27f2bf092f462171fe14a44619565d14f43fb8 .pick_status.json: Update to 38b2e137665f36f1b0fe58e40971548d9eafa865 .pick_status.json: Update to 4fdbc22c42dd4672e1660e7598dcd7874880b2f1 .pick_status.json: Update to b1ab69f467b7b10e383f3b6bb957c7e6669a3772 .pick_status.json: Update to 5d2c9fd161eb1c6b29852e22431fa8bc804bf5af .pick_status.json: Update to 2407952ec99ab1c2a16e01a9e300f799e4d53320 .pick_status.json: Update to 60ea60ec4deaf42c55bd8367a15cb0ab885d662e ci: mark a couple of LLVMPIPE tests as expected pass docs: add release notes for 20.3.5 VERSION: bump for 20.3.5 release Erico Nunes (1): lima: fix max sampler views Georg Lehmann (1): vulkan/device_select: Only call vkGetPhysicalDeviceProperties2 if the device supports it. Giovanni Mascellani (2): disk_cache: Fail creation when cannot inizialize queue. anv: Allow null handle in DestroyDescriptorUpdateTemplate. Hyunjun Ko (1): ir3: fix has_src() to return correctly in ir3_nir_lower_tex_prefetch Ian Romanick (6): i965: Don't parse driconf again nir/algebraic: Fix a >> #b << #b for sizes other than 32-bit intel/compiler: Enable the ability to emit CMPN instructions intel/compiler: Make the CMPN builder work like the CMP builder intel/compiler: Use CMPN for min / max on Gen4 and Gen5 nir/algebraic: Fix some min/max of b2f replacements Icecream95 (2): panfrost: Add the tiler heap to fragment jobs st/mesa: Update constants on alpha test change if it's lowered James Park (1): gallium/tessellator: Fix warning suppression Jason Ekstrand (4): nir: Don't optimize bcsel-of-shuffle across blocks intel/fs: Shuffle can't handle source modifiers anv/formats: Advertise linear sampling on depth formats intel/fs: Handle payload node interference in destinations Jeremy Huddleston (1): Adjust dylib compatibility versions to match what was set by mesa-18.3's autotools-based builds Jordan Justen (1): i965/gen11: Fix must-be-ones bit positions in 3D_MODE Lionel Landwerlin (7): anv: only signal wsi fence BO on last command buffer anv: discard all timeline wait/signal value=0 anv: don't wait for completion of work on vkQueuePresent() anv: Fix wait_count missing increment anv: reset binary syncobj to be signaled before submission anv: fix MI_PREDICATE_RESULT write intel/fs/vec4: add missing dependency in write-on-write fixed GRFs Marek Olšák (2): glthread: fix interpreting vertex size == GL_BGRA for vertex attribs mesa: flush glBegin/End before changing GL_DEPTH_STENCIL_TEXTURE_MODE Matt Turner (1): turnip: Remove unused TU_DEBUG_IR3 flag Mauro Rossi (1): android: pan/bi: reorder static dependencies in gallium/dri Michel Dänzer (1): intel/tools: Use subprocess.Popen to read output directly from a pipe Mike Blumenkrantz (7): radv: null bo list pointer for null descriptors on update radv: zero the bo descriptor array when allocating a new set zink: handle 1bit undef values in ntv gallium/trace: add a pipe_scre
Re: [Mesa-dev] docs: consistent language
+1 to recommending the use of US English spelling in Mesa docs & code. I certainly would not want to impose any heavy burdens on contributors who are accustomed to UK/AU spelling. I don't think we should block any patches because of UK/US/AU spelling, and people should feel free to not think about it and use their normal language when contributing. Consistency can be nice when searching for code. The main reason I like fixing typos and pure misspellings (wrong in all dialects) in our code is to improve searchability. It's usually no trouble to read a sentence with some typos. But try searching for a function or enum where the name has a typo, and you likely won't find it, and then have to waste time digging through the code until you finally find it. US/UK/AU spelling variations usually haven't come up in that regard, though I did notice that midgard and llvmpipe are using "optimise" (16 uses) in some functions, while optimize (1087 uses) is more common. One awkward bit is that Gallium hooks like pipe->finalize_nir() already impose a US spelling. Having the driver set pipe->finalize_nir = driver_finalise_nir seems a bit awkward. On the other hand, using both finalize_nir (US spelling to match the hook) and optimise_nir (UK spelling because there's no hook to match) becomes internally inconsistent...so maybe it's better to just pick one. Having a policy of preferring US spelling seems nice, as we could auto-ack any patches to make the docs and code consistent, like we already do for typo fixes and pure spelling or grammatical fixes. That way we remove the need for debate on each encounter, while also not blocking people's work and contributions over trivial matters. --Ken On Tuesday, March 16, 2021 5:19:43 AM PDT Erik Faye-Lund wrote: > Just one detail to fill in: > > I just got a question on #dri-devel if this suggestion would place an > additional burden on most developers to additionally look up every word > of new documentation to see if it's US or UK English. > > I'm not proposing to place any additional burden on people writing > docs. I think it's fine if people do a best-effort (which arguably can > be low; this isn't a very important detail), and then we'll either > catch things during reviews or fix it up afterwards. > > It's not like the Mesa docs are perfect in terms of spelling or grammar > anyway, I just want to resolve which of the forks in the road we follow > trying to clean things up ;) > > On Mon, 2021-03-15 at 13:44 +0100, Erik Faye-Lund wrote: > > TLDR; I'm proposing to standardize on US English in our public-facing > > documentation. > > > > I proposed an MR a while back that changed the only occurrence of the > > UK English spelling "optimisation" for the US English spelling > > "optimization", which is already used 34 times in the docs. I've done > > similar changes in the past. > > > > But this time Ian brought up the good point that picking a preferred > > language should probably be done using group consensus on the mailing > > list than just picking what's currently most popular. > > > > So, I hereby propose to pick US English as our default language for > > user-facing documentation. > > > > I'm not proposing to force anyone to use a particular English variant > > for things like comments, commit messages or variable names. I don't > > think there's much value in enforcing that, and I think it'd be > > perfectly fine if any particular driver wanted to pick a particular > > variant of English. > > > > The main reason I want to standardize on an English variant is that > > I'm > > trying create a word-list for domain-specific/technical language to > > detect spelling mistakes in the docs more easily. And not having to > > add > > both US and UK English words makes this list easier to maintain. I'm > > not planning on going 100% systematically though the dictionary to > > detect UK English words that might be in my system dictionary, just > > to > > fix the words that currently cause me (a tiny amount of) pain ;) > > > > The main reason why I'm proposing US English over for instance UK > > English is that this seems to be the dominant variant currently in > > the > > documentation. So it seems like the pragmatic choice to me. > > > > Thoughts? Any objections to sticking to US English in the docs? > > > > The MR in question: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8572 > > > > Ian's response: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8572#note_808593 > > > > Previous changes: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6864 > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6894 > > > > > > ___ > > 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.fr
[Mesa-dev] [ANNOUNCE] mesa 21.0.1
Hi List,
The first regular stable release of the 21.0 series, 21.0.1 is now
available. This is two weeks of hard work from all of the developers,
and should now be stable enough to replace 20.3.x in daily usage.
There's a bunch of CI related patches in this release, but otherwise
it's a bit of everything, with no one part dominating.
Cheers,
Dylan
changes
===
Benjamin Tissoires (3):
CI: windows: augment the timeout of building the windows container
CI: windows: split the layers to meet new registry requirements
CI: windows: Force using LLVM 12
Caio Marcelo de Oliveira Filho (1):
anv: Lower ViewIndex to zero when multiview is disabled
Daniel Stone (1):
CI: Try really hard to get updated Windows TLS certs
Dylan Baker (14):
docs: update calendar and link releases notes for 21.0.0
.pick_status.json: Update to b1ab69f467b7b10e383f3b6bb957c7e6669a3772
.pick_status.json: Mark bddc0e023c2c87d3248691ea62b77626704cc5a4 as
backported
.pick_status.json: Mark a67d3e7c9e2c1ae9b05153a281cf73926b9f6af7 as
backported
.pick_status.json: Mark db67d9c0d11c886c5b960126b8bf0a230e65d980 as
backported
.pick_status.json: Mark 8955d179d3e47982ccd67b8aecb0f5bed73d60b6 as
backported
.pick_status.json: Update to 2407952ec99ab1c2a16e01a9e300f799e4d53320
ci: disable panfrost and radeonsi while the runners are struggling
.pick_status.json: Update to e3f703e4646b57534e49e0975cc3df20bf7b4a54
.pick_status.json: Update to 277ea7a015cd7df10a9dc65d5def0762cf2e9599
Revert "ci: disable panfrost and radeonsi while the runners are
struggling"
ci: mark a couple of LLVMPIPE tests as expected pass
docs: add release notes for 21.0.1
VERSION: bump for 21.0.1
Erik Faye-Lund (3):
gallium/st: fix shader_has_one_variant
gallium/st: fix shader_has_one_variant
zink: fix emulation of no mipfilter
Hyunjun Ko (1):
ir3: fix has_src() to return correctly in ir3_nir_lower_tex_prefetch
Ilia Mirkin (2):
gallium,st: add missing viewport swizzles
nv50: initialize target for blit source surfaces
Jason Ekstrand (1):
intel/fs: Handle payload node interference in destinations
Jesse Natalie (2):
CI: Use a sha for the Windows SPIRV-LLVM-Translator dependency
panfrost: Add a Meson dependency on bi_opcodes.h for bifrost_compiler
Jordan Justen (1):
i965/gen11: Fix must-be-ones bit positions in 3D_MODE
Lionel Landwerlin (2):
anv: fix MI_PREDICATE_RESULT write
intel/fs/vec4: add missing dependency in write-on-write fixed GRFs
Mauro Rossi (1):
android: anv: add libcutils shared dependency
Michel Dänzer (1):
aco/tests: Use _exit in child process
Mike Blumenkrantz (3):
lavapipe: fix push descriptor set indexing
zink: always use requested format for sampler view creation
compiler/spirv: fix image sample queries
Neha Bhende (2):
mesa: set states in fast path for restoring light attributes
gallium/u_vbuf: use updated pipe_draw_start_count while using draw_vbo
Pierre Moreau (1):
spirv: Ignore WorkgroupSize in non-compute stages
Pierre-Eric Pelloux-Prayer (1):
frontends/va: fix protected slice data buffer read size
Rhys Perry (2):
aco: set compr for fp16 exports
aco: implement 64-bit VGPR {u,i}find_msb
Timothy Arceri (2):
Revert "glsl: default to compat shaders in compat profile"
glsl: fix declarations of gl_MaxVaryingFloats
Timur Kristóf (1):
aco: Fix constant address offset calculation for ds_read2 instructions.
Tony Wasserka (1):
radv: Fix improper max_index_count argument for indexed draws
git tag: mesa-21.0.1
https://mesa.freedesktop.org/archive/mesa-21.0.1.tar.xz
SHA256: 379fc984459394f2ab2d84049efdc3a659869dc1328ce72ef0598506611712bb
mesa-21.0.1.tar.xz
SHA512:
b31b78778b6092dfaf0712f90de3074217574389c4236f8379c127739874f6bd1b47883140a26445d25e58df87e6207278efd048453096ee710d334b1dcfe419
mesa-21.0.1.tar.xz
PGP: https://mesa.freedesktop.org/archive/mesa-21.0.1.tar.xz.sig
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On 2021-03-23 09:38:59, Eric Anholt wrote: > On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand wrote: > > > > Trying to pick this discussion back up. Daniel Stone thinks it's a > > half hour of API bashing to retarget all the MRs so, if the fd.o > > admins have some heads up, it should be tractable. Should we do this > > right after branching 21.1 along with the LTS branch? > > +1 Jason, I opened a related Mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4501 I made this change in crucible, and used a script to update the 7 MR target branches: https://gitlab.freedesktop.org/mesa/crucible/-/issues/5 As mentioned in the Mesa issue, I think we should use piglit as another test run before changing Mesa: https://gitlab.freedesktop.org/mesa/piglit/-/issues/50 Piglit currently has 60 open merge requests. -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen wrote: > > On 2021-03-23 09:38:59, Eric Anholt wrote: > > On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand wrote: > > > > > > Trying to pick this discussion back up. Daniel Stone thinks it's a > > > half hour of API bashing to retarget all the MRs so, if the fd.o > > > admins have some heads up, it should be tractable. Should we do this > > > right after branching 21.1 along with the LTS branch? > > > > +1 > > Jason, > > I opened a related Mesa issue: > https://gitlab.freedesktop.org/mesa/mesa/-/issues/4501 > > I made this change in crucible, and used a script to update the 7 MR > target branches: > https://gitlab.freedesktop.org/mesa/crucible/-/issues/5 > > As mentioned in the Mesa issue, I think we should use piglit as > another test run before changing Mesa: > https://gitlab.freedesktop.org/mesa/piglit/-/issues/50 > > Piglit currently has 60 open merge requests. I'm in favor of branch rename, but was in the camp of "hope gitlab comes up with a way to make this easy for us".. but as far as fallback plan, converting trees with fewer outstanding MRs first seems like a pretty good idea so solid +1 for that BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On March 24, 2021 22:25:10 Rob Clark wrote: On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen wrote: On 2021-03-23 09:38:59, Eric Anholt wrote: On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand wrote: Trying to pick this discussion back up. Daniel Stone thinks it's a half hour of API bashing to retarget all the MRs so, if the fd.o admins have some heads up, it should be tractable. Should we do this right after branching 21.1 along with the LTS branch? +1 Jason, I opened a related Mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4501 I made this change in crucible, and used a script to update the 7 MR target branches: https://gitlab.freedesktop.org/mesa/crucible/-/issues/5 As mentioned in the Mesa issue, I think we should use piglit as another test run before changing Mesa: https://gitlab.freedesktop.org/mesa/piglit/-/issues/50 Piglit currently has 60 open merge requests. I'm in favor of branch rename, but was in the camp of "hope gitlab comes up with a way to make this easy for us".. but as far as fallback plan, converting trees with fewer outstanding MRs first seems like a pretty good idea so solid +1 for that If you read enough off the things, you'll see that Jordan wrote a python script that re-targets all the open MRs so that's not a manual process. It's not a GitLab-sanctioned solution but it's the next best thing. The one downside is that all the MRs will get their last updated timestamp reset but that seems like a pretty small price to pay. Jordan, is there any way you can make the script sort by last updated before it re-targets the MRs so they at least stay in the same order? Updating them in MR # order wouldn't be bad either, I guess. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On 2021-03-24 21:14:57, Jason Ekstrand wrote: > > Jordan, is there any way you can make the script sort by last updated before > it > re-targets the MRs so they at least stay in the same order? Updating them in > MR > # order wouldn't be bad either, I guess. > It already does process them sorting by the oldest "update time" first, so roughly speaking the order sorted by update time should be the same. I don't know what might happen if 2 MRs were updated within the same second. But, the updates are actually a bit slow (maybe ~1 update per second), so there doesn't seem to be much risk, as far as I can see, of, for instance, 10 updates happening within the same second. -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
