Re: drm-misc migration to Gitlab server
On 29/04/2024 14:56, Jani Nikula wrote: On Mon, 29 Apr 2024, Helen Koike wrote: On 01/04/2024 13:49, Tvrtko Ursulin wrote: No issues accessing the repo just a slight confusion and how to handle the workflow. More specifically, if I have a patch which wants to be merged to drm-misc-next, is the mailing list based worklflow still the way to go, or I should create a merge request, or I should apply for commit access via some new method other than adding permissions to my legacy fdo ssh account? I have this same question, I thought we would keep the workflow with dim tool, but after I pointed drm-misc remote to gitlab, dim is not happy. If I don't point drm-misc to gitlab, dim say it is outdated (but I'm using the last top of the tree of maintainer-tools). So I was wondering if dim requires changes or if the workflow changed. The workflow has not changed, only the location of the repo. Thanks for confirming. I'm afraid there's insufficient info here to say what exactly is going on though. I re-executed dim setup and it seems to be working now. Thanks. Helen BR, Jani.
Re: drm-misc migration to Gitlab server
On Mon, 29 Apr 2024, Helen Koike wrote: > On 01/04/2024 13:49, Tvrtko Ursulin wrote: >> No issues accessing the repo just a slight confusion and how to handle >> the workflow. More specifically, if I have a patch which wants to be >> merged to drm-misc-next, is the mailing list based worklflow still the >> way to go, or I should create a merge request, or I should apply for >> commit access via some new method other than adding permissions to my >> legacy fdo ssh account? > > I have this same question, I thought we would keep the workflow with dim > tool, but after I pointed drm-misc remote to gitlab, dim is not happy. > > If I don't point drm-misc to gitlab, dim say it is outdated (but I'm > using the last top of the tree of maintainer-tools). > > So I was wondering if dim requires changes or if the workflow changed. The workflow has not changed, only the location of the repo. I'm afraid there's insufficient info here to say what exactly is going on though. BR, Jani. -- Jani Nikula, Intel
Re: drm-misc migration to Gitlab server
On 01/04/2024 13:49, Tvrtko Ursulin wrote: On 12/03/2024 13:56, Maxime Ripard wrote: Hi, On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: ## Changing the default location repo Dim gets its repos list in the drm-rerere nightly.conf file. We will need to change that file to match the gitlab repo, and drop the old cgit URLs to avoid people pushing to the wrong place once the transition is made. I guess the next merge window is a good time to do so, it's usually a quiet time for us and a small disruption would be easier to handle. I'll be off-duty during that time too, so I'll have time to handle any complication. ## Updating the documentation The documentation currently mentions the old process to request a drm-misc access. It will all go through Gitlab now, so it will change a few things. We will also need to update and move the issue template to the new repo to maintain consistency. I would expect the transition (if everything goes smoothly) to occur in the merge-window time frame (11/03 -> 24/03). The transition just happened. The main drm-misc repo is now on gitlab, with the old cgit repo being setup as a mirror. If there's any issue accessing that gitlab repo, please let me know. No issues accessing the repo just a slight confusion and how to handle the workflow. More specifically, if I have a patch which wants to be merged to drm-misc-next, is the mailing list based worklflow still the way to go, or I should create a merge request, or I should apply for commit access via some new method other than adding permissions to my legacy fdo ssh account? I have this same question, I thought we would keep the workflow with dim tool, but after I pointed drm-misc remote to gitlab, dim is not happy. If I don't point drm-misc to gitlab, dim say it is outdated (but I'm using the last top of the tree of maintainer-tools). So I was wondering if dim requires changes or if the workflow changed. Thanks, Helen Regards, Tvrtko
Re: drm-misc migration to Gitlab server
On 12/03/2024 13:56, Maxime Ripard wrote: Hi, On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: ## Changing the default location repo Dim gets its repos list in the drm-rerere nightly.conf file. We will need to change that file to match the gitlab repo, and drop the old cgit URLs to avoid people pushing to the wrong place once the transition is made. I guess the next merge window is a good time to do so, it's usually a quiet time for us and a small disruption would be easier to handle. I'll be off-duty during that time too, so I'll have time to handle any complication. ## Updating the documentation The documentation currently mentions the old process to request a drm-misc access. It will all go through Gitlab now, so it will change a few things. We will also need to update and move the issue template to the new repo to maintain consistency. I would expect the transition (if everything goes smoothly) to occur in the merge-window time frame (11/03 -> 24/03). The transition just happened. The main drm-misc repo is now on gitlab, with the old cgit repo being setup as a mirror. If there's any issue accessing that gitlab repo, please let me know. No issues accessing the repo just a slight confusion and how to handle the workflow. More specifically, if I have a patch which wants to be merged to drm-misc-next, is the mailing list based worklflow still the way to go, or I should create a merge request, or I should apply for commit access via some new method other than adding permissions to my legacy fdo ssh account? Regards, Tvrtko
Re: drm-misc migration to Gitlab server
Hi Maxime, On Thu, 14 Mar 2024 09:39:24 +0100 Maxime Ripard wrote: > > We've migrated the drm-misc repo to: > https://gitlab.freedesktop.org/drm/misc/kernel.git > > The branch names are the same I have switched over for tomorrow and test fetches work fine. -- Cheers, Stephen Rothwell pgp8BgNSqexBp.pgp Description: OpenPGP digital signature
Re: drm-misc migration to Gitlab server
Hi Stephen, On Wed, Feb 21, 2024 at 09:46:43AM +1100, Stephen Rothwell wrote: > Hi Daniel, > > On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote: > > > > On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote: > > > On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > > > > This will be mostly transparent to current committers and users: we'll > > > > still use dim, in the exact same way, the only change will be the URL of > > > > the repo. This will also be transparent to linux-next, since the > > > > linux-next branch lives in its own repo and is pushed by dim when > > > > pushing a branch. > > > > > > Actually, I double-checked and linux-next pulls our branches directly, > > > so once the transition is over we'll have to notify them too. > > > > cc sfr - once we move the DRM repos to a different location, what's > > the best way to update linux-next? > > > > That being said, we could set up read-only pull mirrors in the old > > location ... something I want to do in March (because what else are > > you going to do on holiday?) is to kill the write repos on kemper > > (git.fd.o), move them to being on molly (cgit/anongit.fd.o) only, and > > just have a cronjob that regularly pulls from all the gl.fd.o repos, > > rather than pushing from GitLab. > > These are (I think) all the drm trees/branches that I fetch every day: > > git://anongit.freedesktop.org/drm-intel#for-linux-next > git://anongit.freedesktop.org/drm-intel#for-linux-next-fixes > git://anongit.freedesktop.org/drm/drm-misc#for-linux-next > git://anongit.freedesktop.org/drm/drm-misc#for-linux-next-fixes We've migrated the drm-misc repo to: https://gitlab.freedesktop.org/drm/misc/kernel.git The branch names are the same Maxime signature.asc Description: PGP signature
Re: drm-misc migration to Gitlab server
Hi, On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > ## Changing the default location repo > > Dim gets its repos list in the drm-rerere nightly.conf file. We will > need to change that file to match the gitlab repo, and drop the old cgit > URLs to avoid people pushing to the wrong place once the transition is > made. > > I guess the next merge window is a good time to do so, it's usually a > quiet time for us and a small disruption would be easier to handle. I'll > be off-duty during that time too, so I'll have time to handle any > complication. > > ## Updating the documentation > > The documentation currently mentions the old process to request a > drm-misc access. It will all go through Gitlab now, so it will change a > few things. We will also need to update and move the issue template to > the new repo to maintain consistency. > > I would expect the transition (if everything goes smoothly) to occur in > the merge-window time frame (11/03 -> 24/03). The transition just happened. The main drm-misc repo is now on gitlab, with the old cgit repo being setup as a mirror. If there's any issue accessing that gitlab repo, please let me know. Maxime signature.asc Description: PGP signature
Re: drm-misc migration to Gitlab server
Hi, On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > ## Changing the default location repo > > Dim gets its repos list in the drm-rerere nightly.conf file. We will > need to change that file to match the gitlab repo, and drop the old cgit > URLs to avoid people pushing to the wrong place once the transition is > made. > > I guess the next merge window is a good time to do so, it's usually a > quiet time for us and a small disruption would be easier to handle. I'll > be off-duty during that time too, so I'll have time to handle any > complication. Looking back at the drm.git transition this week, there's probably some adjustments to make. First, we shouldn't remove the old repos URLs from nightly.conf entirely but use the drm_old_urls array we now have to migrate people seamlessly over time. Since a lot of people are going to commit compared to drm though, it's probably best to setup the cgit drm-misc repo as a mirror / read-only right away and just before committing the nightly.conf modifications. This way we will avoid a duplication of drm-misc if someone for some reason didn't switch to the new URL. And then there's the drm-tip topic. drm-tip at the moment gives write access to the drm, drm-intel, drm-misc and drm-xe committers. All these have the gitlab groups setup but drm-intel. The best scenario would have been to migrate drm-tip before drm-misc so we don't have a period of time where some people that could have been granted privileges on the gitlab side wouldn't have cgit credentials, and thus wouldn't be able to push to drm-tip. However, it's not clear yet how drm-intel wants to set things up, so we might have to do that still. Or do both at the same time, for additional fun. Maxime signature.asc Description: PGP signature
Re: drm-misc migration to Gitlab server
Hi Daniel, On Wed, 28 Feb 2024 17:33:28 +0100 Daniel Vetter wrote: > > > git://git.freedesktop.org/git/drm/drm.git#drm-fixes > > git://git.freedesktop.org/git/drm/drm.git#drm-next > > To test out the process we've moved drm.git first. It's now here: > > https://gitlab.freedesktop.org/drm/kernel.git > > Still the same two branches. Can you please update the url? We haven't > enabled the auto-mirror for this one, since we want to make sure the > upgrade path in the tooling works and people do switch over to the new > repo. Done. They seem to be fine. -- Cheers, Stephen Rothwell pgp8RJ1W7oaUD.pgp Description: OpenPGP digital signature
Re: drm-misc migration to Gitlab server
Hi Stephen! On Wed, Feb 21, 2024 at 09:46:43AM +1100, Stephen Rothwell wrote: > On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote: > > > > On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote: > > > On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > > > > This will be mostly transparent to current committers and users: we'll > > > > still use dim, in the exact same way, the only change will be the URL of > > > > the repo. This will also be transparent to linux-next, since the > > > > linux-next branch lives in its own repo and is pushed by dim when > > > > pushing a branch. > > > > > > Actually, I double-checked and linux-next pulls our branches directly, > > > so once the transition is over we'll have to notify them too. > > > > cc sfr - once we move the DRM repos to a different location, what's > > the best way to update linux-next? > > > > That being said, we could set up read-only pull mirrors in the old > > location ... something I want to do in March (because what else are > > you going to do on holiday?) is to kill the write repos on kemper > > (git.fd.o), move them to being on molly (cgit/anongit.fd.o) only, and > > just have a cronjob that regularly pulls from all the gl.fd.o repos, > > rather than pushing from GitLab. > > These are (I think) all the drm trees/branches that I fetch every day: > > git://anongit.freedesktop.org/drm-intel#for-linux-next > git://anongit.freedesktop.org/drm-intel#for-linux-next-fixes > git://anongit.freedesktop.org/drm/drm-misc#for-linux-next > git://anongit.freedesktop.org/drm/drm-misc#for-linux-next-fixes > git://git.freedesktop.org/git/drm/drm.git#drm-fixes > git://git.freedesktop.org/git/drm/drm.git#drm-next To test out the process we've moved drm.git first. It's now here: https://gitlab.freedesktop.org/drm/kernel.git Still the same two branches. Can you please update the url? We haven't enabled the auto-mirror for this one, since we want to make sure the upgrade path in the tooling works and people do switch over to the new repo. For the others the plan is keep the old places automatically mirrored, at least until the dust has settled. Thanks! > git://git.freedesktop.org/git/drm/drm.git#topic/drm-ci > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#for-linux-next > https://gitlab.freedesktop.org/agd5f/linux#drm-next > https://gitlab.freedesktop.org/drm/msm.git#msm-next > https://gitlab.freedesktop.org/drm/tegra.git#for-next > https://gitlab.freedesktop.org/lumag/msm.git#msm-next-lumag > > If someone could just send me all the new equivalent URLs when the > change happens, I will fix them up in my config. > > -- > Cheers, > Stephen Rothwell -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: drm-misc migration to Gitlab server
Hi Maxime Just wanted to chime in with a big thank your for volunteering to push this forward! Best vacations when you come back and are surprised that the 5 year old project is magically moving :-) -Sima On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > Hi, > > As you might have noticed in your mails, Daniel Stone and I have been > working on adding all the drm-misc maintainers and committers to Gitlab. > > The current repository was still in the cgit instance and was creating > an unnecessary burden on the admins. > > For example, any new user had to create an issue and go through Daniel > to create an cgit account, even though that user already needed to have > a gitlab account to create the issue in the first place. Adding an SSH > key was a similar story. By moving to Gitlab, we'll remove most of that > burden. > > This will be mostly transparent to current committers and users: we'll > still use dim, in the exact same way, the only change will be the URL of > the repo. This will also be transparent to linux-next, since the > linux-next branch lives in its own repo and is pushed by dim when > pushing a branch. > > In the next few days, you might notice conflicting notifications. As we > figured out the drm-misc group and repo structure, we've added members > at multiple levels and we will clean things up in the next few days. The > final organization is that every drm-misc committers and maintainer will > have permissions over the drm-misc group and its projects, so if it's > not the case please let us know. > > # What we do next > > ## Adding the a remaining users > > I was able to identify most of the users with an account on the old git > server. However, there's a few I couldn't match with certainty to a > gitlab account: > > * andr2000 > * jsarha > > Please let me know your Gitlab user so I can add them to the group. > > ## Changing the default location repo > > Dim gets its repos list in the drm-rerere nightly.conf file. We will > need to change that file to match the gitlab repo, and drop the old cgit > URLs to avoid people pushing to the wrong place once the transition is > made. > > I guess the next merge window is a good time to do so, it's usually a > quiet time for us and a small disruption would be easier to handle. I'll > be off-duty during that time too, so I'll have time to handle any > complication. > > ## Updating the documentation > > The documentation currently mentions the old process to request a > drm-misc access. It will all go through Gitlab now, so it will change a > few things. We will also need to update and move the issue template to > the new repo to maintain consistency. > > I would expect the transition (if everything goes smoothly) to occur in > the merge-window time frame (11/03 -> 24/03). > > Let me know if you have any questions, or if there's anything we missed, > Maxime -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: drm-misc migration to Gitlab server
Hi Daniel, On Mon, 26 Feb 2024 15:50:10 +0100 Daniel Vetter wrote: > > > git://git.freedesktop.org/git/drm/drm.git#topic/drm-ci > > This one you can drop right away, it's all merged, apologies for not > telling you earlier. Thanks, removed now. -- Cheers, Stephen Rothwell pgpd6KgfsRTmt.pgp Description: OpenPGP digital signature
Re: drm-misc migration to Gitlab server
On Wed, Feb 21, 2024 at 09:46:43AM +1100, Stephen Rothwell wrote: > Hi Daniel, > > On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote: > > > > On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote: > > > On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > > > > This will be mostly transparent to current committers and users: we'll > > > > still use dim, in the exact same way, the only change will be the URL of > > > > the repo. This will also be transparent to linux-next, since the > > > > linux-next branch lives in its own repo and is pushed by dim when > > > > pushing a branch. > > > > > > Actually, I double-checked and linux-next pulls our branches directly, > > > so once the transition is over we'll have to notify them too. > > > > cc sfr - once we move the DRM repos to a different location, what's > > the best way to update linux-next? > > > > That being said, we could set up read-only pull mirrors in the old > > location ... something I want to do in March (because what else are > > you going to do on holiday?) is to kill the write repos on kemper > > (git.fd.o), move them to being on molly (cgit/anongit.fd.o) only, and > > just have a cronjob that regularly pulls from all the gl.fd.o repos, > > rather than pushing from GitLab. > > These are (I think) all the drm trees/branches that I fetch every day: > > git://anongit.freedesktop.org/drm-intel#for-linux-next > git://anongit.freedesktop.org/drm-intel#for-linux-next-fixes > git://anongit.freedesktop.org/drm/drm-misc#for-linux-next > git://anongit.freedesktop.org/drm/drm-misc#for-linux-next-fixes > git://git.freedesktop.org/git/drm/drm.git#drm-fixes > git://git.freedesktop.org/git/drm/drm.git#drm-next > git://git.freedesktop.org/git/drm/drm.git#topic/drm-ci This one you can drop right away, it's all merged, apologies for not telling you earlier. -Sima > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#for-linux-next > https://gitlab.freedesktop.org/agd5f/linux#drm-next > https://gitlab.freedesktop.org/drm/msm.git#msm-next > https://gitlab.freedesktop.org/drm/tegra.git#for-next > https://gitlab.freedesktop.org/lumag/msm.git#msm-next-lumag > > If someone could just send me all the new equivalent URLs when the > change happens, I will fix them up in my config. > > -- > Cheers, > Stephen Rothwell -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: drm-misc migration to Gitlab server
On Mon, Feb 26, 2024 at 12:00:15PM +, Daniel Stone wrote: > On Mon, 26 Feb 2024 at 11:57, Jani Nikula wrote: > > On Mon, 26 Feb 2024, Maxime Ripard wrote: > > > For the recent-ish subscriptions, it's possible since we've required to > > > open a Gitlab issue for a while, so we have the association between the > > > Gitlab account and the SSH account already. > > > > > > During the Gitlab setup, the groups were also created already with the > > > people that had an SSH account at the time, and Gitlab account. > > > > > > But for the rest, yeah, I had to ping Daniel S. about it. He could find > > > a few matches, but there's some where we just don't know if or what the > > > Gitlab account is. > > > > > > Generally speaking, we've been conservative about it, and only added > > > accounts we were sure of. > > > > Ah, I didn't make myself clear. I'm more interested in the process going > > forward, for new access requests. Anyone can create an account and > > request access; how does a maintainer verify the request? For our > > purposes it's basically just matching againt the email addresses in > > existing commits in the repo. > > It's a fair question. If you want to verify that someone is > @intel.com, maybe get them to email you out-of-band to check it. If > you want to check something else, just ask an admin I suppose. It looks like we can make the email verification mandatory: https://docs.gitlab.com/ee/security/email_verification.html And we can have a public email on the profile. I guess requesting the public email of a profile to match their contribution and be verified would be enough? Maxime signature.asc Description: PGP signature
Re: drm-misc migration to Gitlab server
On Mon, 26 Feb 2024 at 12:03, Jani Nikula wrote: > On Mon, 26 Feb 2024, Daniel Stone wrote: > > It's a fair question. If you want to verify that someone is > > @intel.com, maybe get them to email you out-of-band to check it. If > > you want to check something else, just ask an admin I suppose. > > I thought you wanted not to be bothered with access requests! ;D Hey, we have like four other people with GitLab admin privileges ... I just want to not have to deal with LDAP mainly.
Re: drm-misc migration to Gitlab server
On Mon, 26 Feb 2024, Daniel Stone wrote: > On Mon, 26 Feb 2024 at 11:57, Jani Nikula wrote: >> On Mon, 26 Feb 2024, Maxime Ripard wrote: >> > For the recent-ish subscriptions, it's possible since we've required to >> > open a Gitlab issue for a while, so we have the association between the >> > Gitlab account and the SSH account already. >> > >> > During the Gitlab setup, the groups were also created already with the >> > people that had an SSH account at the time, and Gitlab account. >> > >> > But for the rest, yeah, I had to ping Daniel S. about it. He could find >> > a few matches, but there's some where we just don't know if or what the >> > Gitlab account is. >> > >> > Generally speaking, we've been conservative about it, and only added >> > accounts we were sure of. >> >> Ah, I didn't make myself clear. I'm more interested in the process going >> forward, for new access requests. Anyone can create an account and >> request access; how does a maintainer verify the request? For our >> purposes it's basically just matching againt the email addresses in >> existing commits in the repo. > > It's a fair question. If you want to verify that someone is > @intel.com, maybe get them to email you out-of-band to check it. If > you want to check something else, just ask an admin I suppose. I thought you wanted not to be bothered with access requests! ;D BR, Jani. -- Jani Nikula, Intel
Re: drm-misc migration to Gitlab server
On Mon, 26 Feb 2024 at 11:57, Jani Nikula wrote: > On Mon, 26 Feb 2024, Maxime Ripard wrote: > > For the recent-ish subscriptions, it's possible since we've required to > > open a Gitlab issue for a while, so we have the association between the > > Gitlab account and the SSH account already. > > > > During the Gitlab setup, the groups were also created already with the > > people that had an SSH account at the time, and Gitlab account. > > > > But for the rest, yeah, I had to ping Daniel S. about it. He could find > > a few matches, but there's some where we just don't know if or what the > > Gitlab account is. > > > > Generally speaking, we've been conservative about it, and only added > > accounts we were sure of. > > Ah, I didn't make myself clear. I'm more interested in the process going > forward, for new access requests. Anyone can create an account and > request access; how does a maintainer verify the request? For our > purposes it's basically just matching againt the email addresses in > existing commits in the repo. It's a fair question. If you want to verify that someone is @intel.com, maybe get them to email you out-of-band to check it. If you want to check something else, just ask an admin I suppose. Cheers, Daniel
Re: drm-misc migration to Gitlab server
On Mon, 26 Feb 2024, Maxime Ripard wrote: > On Mon, Feb 26, 2024 at 01:33:24PM +0200, Jani Nikula wrote: >> On Tue, 20 Feb 2024, Maxime Ripard wrote: >> > ## Adding the a remaining users >> > >> > I was able to identify most of the users with an account on the old git >> > server. However, there's a few I couldn't match with certainty to a >> > gitlab account: >> > >> > * andr2000 >> > * jsarha >> > >> > Please let me know your Gitlab user so I can add them to the group. >> >> Is there no way for project owners/maintainers to see the email >> addresses for members or access requests? >> >> We've been pretty lax with giving reporter role to deal with issues, but >> it's quite a different thing to give developer role with push access, >> and feels like you'll need a side channel to match usernames with email >> addresses. > > For the recent-ish subscriptions, it's possible since we've required to > open a Gitlab issue for a while, so we have the association between the > Gitlab account and the SSH account already. > > During the Gitlab setup, the groups were also created already with the > people that had an SSH account at the time, and Gitlab account. > > But for the rest, yeah, I had to ping Daniel S. about it. He could find > a few matches, but there's some where we just don't know if or what the > Gitlab account is. > > Generally speaking, we've been conservative about it, and only added > accounts we were sure of. Ah, I didn't make myself clear. I'm more interested in the process going forward, for new access requests. Anyone can create an account and request access; how does a maintainer verify the request? For our purposes it's basically just matching againt the email addresses in existing commits in the repo. BR, Jani. -- Jani Nikula, Intel
Re: drm-misc migration to Gitlab server
On Mon, Feb 26, 2024 at 01:33:24PM +0200, Jani Nikula wrote: > On Tue, 20 Feb 2024, Maxime Ripard wrote: > > ## Adding the a remaining users > > > > I was able to identify most of the users with an account on the old git > > server. However, there's a few I couldn't match with certainty to a > > gitlab account: > > > > * andr2000 > > * jsarha > > > > Please let me know your Gitlab user so I can add them to the group. > > Is there no way for project owners/maintainers to see the email > addresses for members or access requests? > > We've been pretty lax with giving reporter role to deal with issues, but > it's quite a different thing to give developer role with push access, > and feels like you'll need a side channel to match usernames with email > addresses. For the recent-ish subscriptions, it's possible since we've required to open a Gitlab issue for a while, so we have the association between the Gitlab account and the SSH account already. During the Gitlab setup, the groups were also created already with the people that had an SSH account at the time, and Gitlab account. But for the rest, yeah, I had to ping Daniel S. about it. He could find a few matches, but there's some where we just don't know if or what the Gitlab account is. Generally speaking, we've been conservative about it, and only added accounts we were sure of. Maxime signature.asc Description: PGP signature
Re: drm-misc migration to Gitlab server
On Tue, 20 Feb 2024, Maxime Ripard wrote: > ## Adding the a remaining users > > I was able to identify most of the users with an account on the old git > server. However, there's a few I couldn't match with certainty to a > gitlab account: > > * andr2000 > * jsarha > > Please let me know your Gitlab user so I can add them to the group. Is there no way for project owners/maintainers to see the email addresses for members or access requests? We've been pretty lax with giving reporter role to deal with issues, but it's quite a different thing to give developer role with push access, and feels like you'll need a side channel to match usernames with email addresses. BR, Jani. -- Jani Nikula, Intel
Re: drm-misc migration to Gitlab server
Hi Stephen, On Tue, 20 Feb 2024 at 22:46, Stephen Rothwell wrote: > On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote: > > cc sfr - once we move the DRM repos to a different location, what's > > the best way to update linux-next? > > These are (I think) all the drm trees/branches that I fetch every day: > > [...] > > If someone could just send me all the new equivalent URLs when the > change happens, I will fix them up in my config. Thanks a lot! We'll give you a shout with a couple of days' heads-up before we move then. Cheers, Daniel
Re: drm-misc migration to Gitlab server
Hi Daniel, On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote: > > On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote: > > On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > > > This will be mostly transparent to current committers and users: we'll > > > still use dim, in the exact same way, the only change will be the URL of > > > the repo. This will also be transparent to linux-next, since the > > > linux-next branch lives in its own repo and is pushed by dim when > > > pushing a branch. > > > > Actually, I double-checked and linux-next pulls our branches directly, > > so once the transition is over we'll have to notify them too. > > cc sfr - once we move the DRM repos to a different location, what's > the best way to update linux-next? > > That being said, we could set up read-only pull mirrors in the old > location ... something I want to do in March (because what else are > you going to do on holiday?) is to kill the write repos on kemper > (git.fd.o), move them to being on molly (cgit/anongit.fd.o) only, and > just have a cronjob that regularly pulls from all the gl.fd.o repos, > rather than pushing from GitLab. These are (I think) all the drm trees/branches that I fetch every day: git://anongit.freedesktop.org/drm-intel#for-linux-next git://anongit.freedesktop.org/drm-intel#for-linux-next-fixes git://anongit.freedesktop.org/drm/drm-misc#for-linux-next git://anongit.freedesktop.org/drm/drm-misc#for-linux-next-fixes git://git.freedesktop.org/git/drm/drm.git#drm-fixes git://git.freedesktop.org/git/drm/drm.git#drm-next git://git.freedesktop.org/git/drm/drm.git#topic/drm-ci git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#for-linux-next https://gitlab.freedesktop.org/agd5f/linux#drm-next https://gitlab.freedesktop.org/drm/msm.git#msm-next https://gitlab.freedesktop.org/drm/tegra.git#for-next https://gitlab.freedesktop.org/lumag/msm.git#msm-next-lumag If someone could just send me all the new equivalent URLs when the change happens, I will fix them up in my config. -- Cheers, Stephen Rothwell pgpxX0CUBJ8uy.pgp Description: OpenPGP digital signature
Re: drm-misc migration to Gitlab server
On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote: > On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > > This will be mostly transparent to current committers and users: we'll > > still use dim, in the exact same way, the only change will be the URL of > > the repo. This will also be transparent to linux-next, since the > > linux-next branch lives in its own repo and is pushed by dim when > > pushing a branch. > > Actually, I double-checked and linux-next pulls our branches directly, > so once the transition is over we'll have to notify them too. cc sfr - once we move the DRM repos to a different location, what's the best way to update linux-next? That being said, we could set up read-only pull mirrors in the old location ... something I want to do in March (because what else are you going to do on holiday?) is to kill the write repos on kemper (git.fd.o), move them to being on molly (cgit/anongit.fd.o) only, and just have a cronjob that regularly pulls from all the gl.fd.o repos, rather than pushing from GitLab. Cheers, Daniel
Re: drm-misc migration to Gitlab server
On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote: > Hi, > > As you might have noticed in your mails, Daniel Stone and I have been > working on adding all the drm-misc maintainers and committers to Gitlab. > > The current repository was still in the cgit instance and was creating > an unnecessary burden on the admins. > > For example, any new user had to create an issue and go through Daniel > to create an cgit account, even though that user already needed to have > a gitlab account to create the issue in the first place. Adding an SSH > key was a similar story. By moving to Gitlab, we'll remove most of that > burden. > > This will be mostly transparent to current committers and users: we'll > still use dim, in the exact same way, the only change will be the URL of > the repo. This will also be transparent to linux-next, since the > linux-next branch lives in its own repo and is pushed by dim when > pushing a branch. Actually, I double-checked and linux-next pulls our branches directly, so once the transition is over we'll have to notify them too. Maxime signature.asc Description: PGP signature
drm-misc migration to Gitlab server
Hi, As you might have noticed in your mails, Daniel Stone and I have been working on adding all the drm-misc maintainers and committers to Gitlab. The current repository was still in the cgit instance and was creating an unnecessary burden on the admins. For example, any new user had to create an issue and go through Daniel to create an cgit account, even though that user already needed to have a gitlab account to create the issue in the first place. Adding an SSH key was a similar story. By moving to Gitlab, we'll remove most of that burden. This will be mostly transparent to current committers and users: we'll still use dim, in the exact same way, the only change will be the URL of the repo. This will also be transparent to linux-next, since the linux-next branch lives in its own repo and is pushed by dim when pushing a branch. In the next few days, you might notice conflicting notifications. As we figured out the drm-misc group and repo structure, we've added members at multiple levels and we will clean things up in the next few days. The final organization is that every drm-misc committers and maintainer will have permissions over the drm-misc group and its projects, so if it's not the case please let us know. # What we do next ## Adding the a remaining users I was able to identify most of the users with an account on the old git server. However, there's a few I couldn't match with certainty to a gitlab account: * andr2000 * jsarha Please let me know your Gitlab user so I can add them to the group. ## Changing the default location repo Dim gets its repos list in the drm-rerere nightly.conf file. We will need to change that file to match the gitlab repo, and drop the old cgit URLs to avoid people pushing to the wrong place once the transition is made. I guess the next merge window is a good time to do so, it's usually a quiet time for us and a small disruption would be easier to handle. I'll be off-duty during that time too, so I'll have time to handle any complication. ## Updating the documentation The documentation currently mentions the old process to request a drm-misc access. It will all go through Gitlab now, so it will change a few things. We will also need to update and move the issue template to the new repo to maintain consistency. I would expect the transition (if everything goes smoothly) to occur in the merge-window time frame (11/03 -> 24/03). Let me know if you have any questions, or if there's anything we missed, Maxime signature.asc Description: PGP signature
