Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I think that's mostly a complaint about the conditionals we've written so far, tbh. As I commented on the bug, when I clicked the container job (which the rules happen to have evaluated to being "manual"), every job (recursively) downstream of it got enqueued, which isn't what you're describing. So I think if you can describe the UX you'd like we can write rules to make that reality. But I don't really know which jobs are most expensive in terms of bandwidth, or storage, or CPUs, and even if I knew those I don't know how to map those to currency. So I'm not sure if the UI we'd like would minimize the cost the way we'd like. - ajax ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [igt-dev] RFC: Migration to Gitlab
On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > - Sticking to fdo bugzilla and disabling gitlab issues for at least > drm-intel for the time being. Doing that migration in the same go is a > bit much I think. Reassignment across bugzilla and gitlab will be an > issue. Can you elaborate a bit on the issues here? The actual move-the-bugs process has been pretty painless for the parts of xorg we've done so far. - ajax ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: gitlab migration
On Mon, 2018-06-11 at 12:33 +0200, Michel Dänzer wrote: > As the maintainer of xf86-video-amdgpu and -ati, I'm fine with migrating > these to GitLab for Git and patch review. > > However, I'm not sure what to do about bugs/issues. My first thought was > to allow creating new issues in GitLab and disable creating new reports > in Bugzilla, but not to migrate existing reports from Bugzilla. However, > it still happens fairly often that a report is initially filed against > the Xorg drivers, even though it's actually an issue in the X server, > Mesa or the kernel (old habits die hard...). Therefore, I'm inclined to > stick to Bugzilla until at least the X server and Mesa have moved to > GitLab for issue tracking, to hopefully allow moving such misfiled issues. I've hacked up the migration script to allow moving individual issues by bug number instead of matching a whole product/component [1]. This has already been useful to sort out some of the junkdrawer components like App/Other. Running the script does require someone with supercow powers on both sides, but I'm happy to do so as needed. With that in mind, I think it may be time to enable issues and merge requests for xserver, and disable the remaining (server) bz components for new issues. Any objections? [1] - https://gitlab.freedesktop.org/freedesktop/bztogl/merge_requests/1 - ajax ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Heads up: Xorg repository moves
Hey, if you haven't been following xorg-devel@, we're planning to move our repository hosting to freedesktop's gitlab instance. This is basically transparent from the client side, your git urls won't change, but you get continuous integration hooks for free if you want them. Longer term, we'd like to move from a bugzilla/mailing list model to tracking issues and merge requests in gitlab as well, but we're leaving that optional and per-component. I'd hoped to also take this opportunity to merge several of the X- related projects under the Xorg namespace and (gitlab) group, in particular openchrome nouveau and xcb. Individual subproject ACLs are much easier to manage in gitlab, so this is also something of a formality. But I understand if people would prefer to keep their own top-level project identity, and if this is your project, please do speak up. There are also some questions about which repos are worth migrating/archiving or moving to other namespaces. For details please see the freedesktop gitlab ticket: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 We would like to complete the majority of the move by Monday, July 9, but can defer any given component as long as needed. Please raise any issues or suggestions on the ticket. - ajax ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [ANNOUNCE] xf86-video-ati 7.9.0
On Thu, 2017-03-16 at 10:59 +0100, poma wrote: > There are two applicable patches within Fedora: > https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/fix-dri-removal.patch?id=d5f48e7d5b6c An artifact of Fedora trying to not build DRI1. It's a fix in the wrong place, xserver should define the appropriate symbols if any DRI is built. > https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/radeon-6.12.2-lvds-default-modes.patch?id=9495e5b874d8 Mostly a hack for LCDs that only claim one supported resolution and desktop environments too chicken to let you set arbitrary modes from the display control panel. Again, not really thrilled with the implementation of it, might be better solved in another place. > Are these patches required, if so, care to explain? "Required", no. Nice to have, arguably. - ajax ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
