Re: Migrating Wayland & Weston to GitLab
Hi, On 4 June 2018 at 09:05, Daniel Stone wrote: > On 29 May 2018 at 10:59, Daniel Stone wrote: >> I would like to get the issues migrated as well. In order to do that >> though, we need some more fixes to the 'bztogl' migration tool we've >> been using to push issues from Bugzilla to GitLab, as well as do >> migrations for some other projects which requested to migrate their >> issues a while ago. It also needs a fair few changes in order to fix >> support for Phabricator task import as well. >> >> But even once those are done, we need to clean up the bugs we're >> importing. The plan is to only import open bugs: closed bugs will stay >> in Bugzilla/Phabricator forever as a read-only archive, and GitLab >> will only have new active issues. I think a sensible transition plan >> would be for us to aim to do the import at the end of June, which >> means sweeping through all our open bugs before then, closing them if >> they're no longer useful or just cleaning up titles/etc to be helpful >> in future. > > I've started cleaning through the bugs as well, but would appreciate > all the help I can get. With the cleanup and the Phabricator script fixing having gone far more quickly than thought, I've migrated the issues now: https://gitlab.freedesktop.org/wayland/wayland/issues/ https://gitlab.freedesktop.org/wayland/weston/issues/ If you want to be notified of all new issues, you can 'watch' either the Wayland group or the Wayland/Weston projects. You can also subscribe to individual issue labels (e.g. 'DRM/KMS backend') if you want to keep a narrow interest. Currently the issues are a bit of a hodge-podge, but I intend to spend some time going through applying relevant labels and fixing up any stray formatting etc. Of course, any help with the triage would be excellent: simply add the labels you think are relevant and drop the 'bugzilla' label so we know it's been reasonably triaged. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
On Tue, 5 Jun 2018 11:33:49 +0100 Daniel Stone wrote: > Personally, I'd like to use MRs for at least Weston development. I'm > much happier reviewing them there than mail, and although the workflow > isn't perfect, mail certainly isn't either. > > Some other people said they preferred a mail workflow for > wayland-protocols. That does make a little more sense to me, though if > Weston moves to GitLab, then it would make wayland-protocols the odd > one out for protocol development: AGL using Gerrit review, > Enlightenment/EFL using Phabricator review, GENIVI using Gerrit > review, Mutter/GTK+ using GNOME GitLab MRs, KDE using Phabricator > review, Qt using Gerrit review, Tizen using a mix of Gerrit and > Phabricator, Weston using fd.o GitLab MRs, and wlc/wlroots using > GitHub review. But our volume of protocol review is small enough that > it's probably not a massive deal. > > Similarly, I have a preference for using MRs for the core Wayland > repo, but again we don't have a super high volume of patches right > now. > > Using MRs would also allow us to hook up CI pipelines so we could get > fast feedback on whether the basic build and checks succeeded, which I > think is pretty helpful given the number of times we've broken > distcheck lately. > > What do others think? I think CI is reason enough to use a gitlab MR-based patch submission. wayland-protocols OTOH does not have significant tests for CI, it only makes sure the XML is accepted by wayland-scanner, so there CI is not a significant reason. On other points of view, I don't have a strong preference. I've done email reviews and I've done a bit of github reviews, but for anything non-trivial I practically always get the branch or apply the patches and look at them in gitk, git-grep and a code editor. FWIW, I never look at code on my phone, and I still do not have any HiDPI displays, so on the debate of gitlab visual layout I'm on the side of "it's wasting screen space". That's probably obvious if you know what gitk looks like. ;-) Thanks, pq pgpiaCd9ySzVI.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Migrating Wayland & Weston to GitLab
Hi Daniel, I will be happy to use MRs over emails. Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -Original Message- > From: wayland-devel [mailto:wayland-devel- > boun...@lists.freedesktop.org] On Behalf Of Daniel Stone > Sent: Dienstag, 5. Juni 2018 12:34 > To: Erik De Rijcke > Cc: wayland > Subject: Re: Migrating Wayland & Weston to GitLab > > Hi Erik, > > On 31 May 2018 at 09:36, Erik De Rijcke wrote: > > First of all I'd like to say that the move to Gitlab makes me really happy > > \o/! It will definitely lower the contribution barrier for a lot of people > > (including me!) as things are now far more accessible, visible and overall > > easier to manage. > > > > Which brings me to a remark/question on how merge requests are done. Is > > there any plan to allow/move merge requests to Gitlab? Having a central > > point of all things code related would really make things clear and visible, > > and overall easier to contribute. > > Being able to utilize Gitlab, manage your account, create your own fork and > > then having to do a git-send-email would really defeat the point of the > > whole move to Gitlab imho. > > > > Anyway, just my 2 cents. Very glad to see this Gitlab thing moving forward! > > Personally, I'd like to use MRs for at least Weston development. I'm > much happier reviewing them there than mail, and although the workflow > isn't perfect, mail certainly isn't either. > > Some other people said they preferred a mail workflow for > wayland-protocols. That does make a little more sense to me, though if > Weston moves to GitLab, then it would make wayland-protocols the odd > one out for protocol development: AGL using Gerrit review, > Enlightenment/EFL using Phabricator review, GENIVI using Gerrit > review, Mutter/GTK+ using GNOME GitLab MRs, KDE using Phabricator > review, Qt using Gerrit review, Tizen using a mix of Gerrit and > Phabricator, Weston using fd.o GitLab MRs, and wlc/wlroots using > GitHub review. But our volume of protocol review is small enough that > it's probably not a massive deal. > > Similarly, I have a preference for using MRs for the core Wayland > repo, but again we don't have a super high volume of patches right > now. > > Using MRs would also allow us to hook up CI pipelines so we could get > fast feedback on whether the basic build and checks succeeded, which I > think is pretty helpful given the number of times we've broken > distcheck lately. > > What do others think? > > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
Hi Erik, On 31 May 2018 at 09:36, Erik De Rijcke wrote: > First of all I'd like to say that the move to Gitlab makes me really happy > \o/! It will definitely lower the contribution barrier for a lot of people > (including me!) as things are now far more accessible, visible and overall > easier to manage. > > Which brings me to a remark/question on how merge requests are done. Is > there any plan to allow/move merge requests to Gitlab? Having a central > point of all things code related would really make things clear and visible, > and overall easier to contribute. > Being able to utilize Gitlab, manage your account, create your own fork and > then having to do a git-send-email would really defeat the point of the > whole move to Gitlab imho. > > Anyway, just my 2 cents. Very glad to see this Gitlab thing moving forward! Personally, I'd like to use MRs for at least Weston development. I'm much happier reviewing them there than mail, and although the workflow isn't perfect, mail certainly isn't either. Some other people said they preferred a mail workflow for wayland-protocols. That does make a little more sense to me, though if Weston moves to GitLab, then it would make wayland-protocols the odd one out for protocol development: AGL using Gerrit review, Enlightenment/EFL using Phabricator review, GENIVI using Gerrit review, Mutter/GTK+ using GNOME GitLab MRs, KDE using Phabricator review, Qt using Gerrit review, Tizen using a mix of Gerrit and Phabricator, Weston using fd.o GitLab MRs, and wlc/wlroots using GitHub review. But our volume of protocol review is small enough that it's probably not a massive deal. Similarly, I have a preference for using MRs for the core Wayland repo, but again we don't have a super high volume of patches right now. Using MRs would also allow us to hook up CI pipelines so we could get fast feedback on whether the basic build and checks succeeded, which I think is pretty helpful given the number of times we've broken distcheck lately. What do others think? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
Hi all, On 29 May 2018 at 10:59, Daniel Stone wrote: > On 7 May 2018 at 16:59, Daniel Stone wrote: >> The first thing to happen is to migrate the central Git push point to >> GitLab. anongit.fd.o and cgit will still work as read-only mirrors, >> but you will not be able to push to git.fd.o. This would happen for >> all of wayland, wayland-protocols, weston and wayland-web. libinput we >> could move separately, wayland-build-tools is open to discussion (does >> it still work?), and wayland-java appears to be completely abandoned. >> >> All this would require is for everyone with push rights to set up >> their GitLab account with SSH keys as per the instructions at [0]. On >> a designated flag day, the push URL would become a GitLab one, and >> direct pushes to git.fd.o would be rejected. Users would be able to >> view and fork the repository at gitlab.fd.o, though not necessarily >> able to do any more than that. Since this is easy and low-impact, I'd >> propose to do this at the end of this week or early next week, if >> there are no objections. > > I intend to migrate the wayland/wayland-protocols/wayland-web/weston > repository hosting only (issues disabled, MR submission disabled) this > evening. Anyone trying to push to git.fd.o will get an error message > pointing them to the wiki page telling them how to configure their > remotes and set up their accounts. Anyone having trouble with this is > welcome to contact me and I can help figure it out. In addition to the wayland and weston repositories (already migrated), I migrated the wayland-web repository last night. This now uses GitLab Pages, which means we can use any kind of static site generator we would like. Anyone who wants to improve the site is certainly more than welcome to fork the repository and have a go at improving the content or system. > I would like to get the issues migrated as well. In order to do that > though, we need some more fixes to the 'bztogl' migration tool we've > been using to push issues from Bugzilla to GitLab, as well as do > migrations for some other projects which requested to migrate their > issues a while ago. It also needs a fair few changes in order to fix > support for Phabricator task import as well. > > But even once those are done, we need to clean up the bugs we're > importing. The plan is to only import open bugs: closed bugs will stay > in Bugzilla/Phabricator forever as a read-only archive, and GitLab > will only have new active issues. I think a sensible transition plan > would be for us to aim to do the import at the end of June, which > means sweeping through all our open bugs before then, closing them if > they're no longer useful or just cleaning up titles/etc to be helpful > in future. I've started cleaning through the bugs as well, but would appreciate all the help I can get. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
On Thu, May 31, 2018 at 3:53 AM Pekka Paalanen wrote: > > On Thu, 31 May 2018 08:47:48 +0100 > Daniel Stone wrote: > > > Hi all, > > > > On 29 May 2018 at 10:59, Daniel Stone wrote: > > > I intend to migrate the wayland/wayland-protocols/wayland-web/weston > > > repository hosting only (issues disabled, MR submission disabled) this > > > evening. Anyone trying to push to git.fd.o will get an error message > > > pointing them to the wiki page telling them how to configure their > > > remotes and set up their accounts. Anyone having trouble with this is > > > welcome to contact me and I can help figure it out. > > > > > > This leaves the wayland-build-tools and wayland-java repositories > > > orphaned in cgit; both have been inactive for quite some time. > > > > I've done this now. For the meantime, I've left wayland-protocols back > > on the old infrastructure; given the discussion about what we should > > be doing with wayland-protocols, it seemed prudent to wait. > > > > The following people have access from the Wayland group as it stands: > > daniels, anholt, derek, bryce, whot, pq, krh, jwrdegoede, tomeu, > > nroberts, dvdhrm, jadahl, jekstrand, rdp.effort, zubzub, sardemff7, > > iksaif, bnf, uartie, darxus, sree > > > > I would propose to prune the following developers who are no longer > > (TTBOMK) active in Wayland and haven't been for at least a couple of > > years: > > anholt > > tomeu > > nroberts > > dvdhrm > > jekstrand > > iksaif > > bnf > > uartie > > darxus > > sree > > > > Pruning people wouldn't at all be a one-way process; everyone would of > > course be more than welcome back if they rejoined, and I'd be happy to > > see them keep contributing. > > Sounds good to me. > > > I also propose to give the following people 'master' permission, > > allowing them to add/remove people from the project, as well as do > > special things like force-push: myself, Derek, Kristian, and Pekka. > > > > Does anyone have any thoughts at all on this, or alternative > > suggestions, or? > > Fine by me. I wonder if Kristian wants it, he has been totally silent > on the Wayland side for years now, but I do like having one more admin > there. Silent, but still here :) I don't mind helping out with the admin role. Kristian > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
On Thu, 31 May 2018 08:47:48 +0100 Daniel Stone wrote: > Hi all, > > On 29 May 2018 at 10:59, Daniel Stone wrote: > > I intend to migrate the wayland/wayland-protocols/wayland-web/weston > > repository hosting only (issues disabled, MR submission disabled) this > > evening. Anyone trying to push to git.fd.o will get an error message > > pointing them to the wiki page telling them how to configure their > > remotes and set up their accounts. Anyone having trouble with this is > > welcome to contact me and I can help figure it out. > > > > This leaves the wayland-build-tools and wayland-java repositories > > orphaned in cgit; both have been inactive for quite some time. > > I've done this now. For the meantime, I've left wayland-protocols back > on the old infrastructure; given the discussion about what we should > be doing with wayland-protocols, it seemed prudent to wait. > > The following people have access from the Wayland group as it stands: > daniels, anholt, derek, bryce, whot, pq, krh, jwrdegoede, tomeu, > nroberts, dvdhrm, jadahl, jekstrand, rdp.effort, zubzub, sardemff7, > iksaif, bnf, uartie, darxus, sree > > I would propose to prune the following developers who are no longer > (TTBOMK) active in Wayland and haven't been for at least a couple of > years: > anholt > tomeu > nroberts > dvdhrm > jekstrand > iksaif > bnf > uartie > darxus > sree > > Pruning people wouldn't at all be a one-way process; everyone would of > course be more than welcome back if they rejoined, and I'd be happy to > see them keep contributing. Sounds good to me. > I also propose to give the following people 'master' permission, > allowing them to add/remove people from the project, as well as do > special things like force-push: myself, Derek, Kristian, and Pekka. > > Does anyone have any thoughts at all on this, or alternative > suggestions, or? Fine by me. I wonder if Kristian wants it, he has been totally silent on the Wayland side for years now, but I do like having one more admin there. Thanks, pq pgpJEhLlJ478B.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
Hi All, First of all I'd like to say that the move to Gitlab makes me really happy \o/! It will definitely lower the contribution barrier for a lot of people (including me!) as things are now far more accessible, visible and overall easier to manage. Which brings me to a remark/question on how merge requests are done. Is there any plan to allow/move merge requests to Gitlab? Having a central point of all things code related would really make things clear and visible, and overall easier to contribute. Being able to utilize Gitlab, manage your account, create your own fork and then having to do a git-send-email would really defeat the point of the whole move to Gitlab imho. Anyway, just my 2 cents. Very glad to see this Gitlab thing moving forward! Erik 'zubzub' De Rijcke 2018-05-31 9:47 GMT+02:00 Daniel Stone : > Hi all, > > On 29 May 2018 at 10:59, Daniel Stone wrote: > > I intend to migrate the wayland/wayland-protocols/wayland-web/weston > > repository hosting only (issues disabled, MR submission disabled) this > > evening. Anyone trying to push to git.fd.o will get an error message > > pointing them to the wiki page telling them how to configure their > > remotes and set up their accounts. Anyone having trouble with this is > > welcome to contact me and I can help figure it out. > > > > This leaves the wayland-build-tools and wayland-java repositories > > orphaned in cgit; both have been inactive for quite some time. > > I've done this now. For the meantime, I've left wayland-protocols back > on the old infrastructure; given the discussion about what we should > be doing with wayland-protocols, it seemed prudent to wait. > > The following people have access from the Wayland group as it stands: > daniels, anholt, derek, bryce, whot, pq, krh, jwrdegoede, tomeu, > nroberts, dvdhrm, jadahl, jekstrand, rdp.effort, zubzub, sardemff7, > iksaif, bnf, uartie, darxus, sree > > I would propose to prune the following developers who are no longer > (TTBOMK) active in Wayland and haven't been for at least a couple of > years: > anholt > tomeu > nroberts > dvdhrm > jekstrand > iksaif > bnf > uartie > darxus > sree > > Pruning people wouldn't at all be a one-way process; everyone would of > course be more than welcome back if they rejoined, and I'd be happy to > see them keep contributing. > > I also propose to give the following people 'master' permission, > allowing them to add/remove people from the project, as well as do > special things like force-push: myself, Derek, Kristian, and Pekka. > > Does anyone have any thoughts at all on this, or alternative suggestions, > or? > > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
Hi all, On 29 May 2018 at 10:59, Daniel Stone wrote: > I intend to migrate the wayland/wayland-protocols/wayland-web/weston > repository hosting only (issues disabled, MR submission disabled) this > evening. Anyone trying to push to git.fd.o will get an error message > pointing them to the wiki page telling them how to configure their > remotes and set up their accounts. Anyone having trouble with this is > welcome to contact me and I can help figure it out. > > This leaves the wayland-build-tools and wayland-java repositories > orphaned in cgit; both have been inactive for quite some time. I've done this now. For the meantime, I've left wayland-protocols back on the old infrastructure; given the discussion about what we should be doing with wayland-protocols, it seemed prudent to wait. The following people have access from the Wayland group as it stands: daniels, anholt, derek, bryce, whot, pq, krh, jwrdegoede, tomeu, nroberts, dvdhrm, jadahl, jekstrand, rdp.effort, zubzub, sardemff7, iksaif, bnf, uartie, darxus, sree I would propose to prune the following developers who are no longer (TTBOMK) active in Wayland and haven't been for at least a couple of years: anholt tomeu nroberts dvdhrm jekstrand iksaif bnf uartie darxus sree Pruning people wouldn't at all be a one-way process; everyone would of course be more than welcome back if they rejoined, and I'd be happy to see them keep contributing. I also propose to give the following people 'master' permission, allowing them to add/remove people from the project, as well as do special things like force-push: myself, Derek, Kristian, and Pekka. Does anyone have any thoughts at all on this, or alternative suggestions, or? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
Hi Pekka, Thanks for the reply! On 29 May 2018 at 11:20, Pekka Paalanen wrote: > On Tue, 29 May 2018 10:59:52 +0100 > Daniel Stone wrote: >> But even once those are done, we need to clean up the bugs we're >> importing. The plan is to only import open bugs: closed bugs will stay >> in Bugzilla/Phabricator forever as a read-only archive, and GitLab >> will only have new active issues. I think a sensible transition plan >> would be for us to aim to do the import at the end of June, which >> means sweeping through all our open bugs before then, closing them if >> they're no longer useful or just cleaning up titles/etc to be helpful >> in future. > > The sweep is to reduce the work you need to do in the migration, right? > Aside from the obvious maintenance work we should have been doing all > these years but didn't. Partly. The migration does involve some manual legwork: I do an import into a local test instance first, check it to make sure the bugs haven't been completely mangled, and only then do the real import. There are also some random issues with Bugzilla's export API affecting some but not all bugs[0]; fewer bugs, fewer chances to hit those. Probably most important is the spam issue: the bugs get closed on Bugzilla with a link to the newly-opened GitLab issue. Sending people a Bugzilla mail saying their bug has been moved, followed later by a GitLab mail saying it's been closed after triage, isn't going to make us popular at all. But yeah, it's also a good moment for us to clear out and actually have a usable issue tracker again. :) Trying to figure out a good workflow with things like labels, milestones, todos, assignments, etc, is far easier when we're starting with a clean(ish) slate of (mostly) relevant issues, rather than five years of irrelevant garbage. Cheers, Daniel [0]: https://gitlab.gnome.org/World/bztogl/issues/26#note_84840 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
On Tue, 29 May 2018 10:59:52 +0100 Daniel Stone wrote: > Hi, > > On 7 May 2018 at 16:59, Daniel Stone wrote: > > Repository migration > > > > > > [admin hat still on] > > > > The first thing to happen is to migrate the central Git push point to > > GitLab. anongit.fd.o and cgit will still work as read-only mirrors, > > but you will not be able to push to git.fd.o. This would happen for > > all of wayland, wayland-protocols, weston and wayland-web. libinput we > > could move separately, wayland-build-tools is open to discussion (does > > it still work?), and wayland-java appears to be completely abandoned. > > > > All this would require is for everyone with push rights to set up > > their GitLab account with SSH keys as per the instructions at [0]. On > > a designated flag day, the push URL would become a GitLab one, and > > direct pushes to git.fd.o would be rejected. Users would be able to > > view and fork the repository at gitlab.fd.o, though not necessarily > > able to do any more than that. Since this is easy and low-impact, I'd > > propose to do this at the end of this week or early next week, if > > there are no objections. > > I intend to migrate the wayland/wayland-protocols/wayland-web/weston > repository hosting only (issues disabled, MR submission disabled) this > evening. Anyone trying to push to git.fd.o will get an error message > pointing them to the wiki page telling them how to configure their > remotes and set up their accounts. Anyone having trouble with this is > welcome to contact me and I can help figure it out. > > This leaves the wayland-build-tools and wayland-java repositories > orphaned in cgit; both have been inactive for quite some time. > > I would like to get the issues migrated as well. In order to do that > though, we need some more fixes to the 'bztogl' migration tool we've > been using to push issues from Bugzilla to GitLab, as well as do > migrations for some other projects which requested to migrate their > issues a while ago. It also needs a fair few changes in order to fix > support for Phabricator task import as well. > > But even once those are done, we need to clean up the bugs we're > importing. The plan is to only import open bugs: closed bugs will stay > in Bugzilla/Phabricator forever as a read-only archive, and GitLab > will only have new active issues. I think a sensible transition plan > would be for us to aim to do the import at the end of June, which > means sweeping through all our open bugs before then, closing them if > they're no longer useful or just cleaning up titles/etc to be helpful > in future. The sweep is to reduce the work you need to do in the migration, right? Aside from the obvious maintenance work we should have been doing all these years but didn't. > Does anyone have any opinions on this? Fine by me! Thanks, pq pgpCeatgoJji7.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
Hi, On 7 May 2018 at 16:59, Daniel Stone wrote: > Repository migration > > > [admin hat still on] > > The first thing to happen is to migrate the central Git push point to > GitLab. anongit.fd.o and cgit will still work as read-only mirrors, > but you will not be able to push to git.fd.o. This would happen for > all of wayland, wayland-protocols, weston and wayland-web. libinput we > could move separately, wayland-build-tools is open to discussion (does > it still work?), and wayland-java appears to be completely abandoned. > > All this would require is for everyone with push rights to set up > their GitLab account with SSH keys as per the instructions at [0]. On > a designated flag day, the push URL would become a GitLab one, and > direct pushes to git.fd.o would be rejected. Users would be able to > view and fork the repository at gitlab.fd.o, though not necessarily > able to do any more than that. Since this is easy and low-impact, I'd > propose to do this at the end of this week or early next week, if > there are no objections. I intend to migrate the wayland/wayland-protocols/wayland-web/weston repository hosting only (issues disabled, MR submission disabled) this evening. Anyone trying to push to git.fd.o will get an error message pointing them to the wiki page telling them how to configure their remotes and set up their accounts. Anyone having trouble with this is welcome to contact me and I can help figure it out. This leaves the wayland-build-tools and wayland-java repositories orphaned in cgit; both have been inactive for quite some time. I would like to get the issues migrated as well. In order to do that though, we need some more fixes to the 'bztogl' migration tool we've been using to push issues from Bugzilla to GitLab, as well as do migrations for some other projects which requested to migrate their issues a while ago. It also needs a fair few changes in order to fix support for Phabricator task import as well. But even once those are done, we need to clean up the bugs we're importing. The plan is to only import open bugs: closed bugs will stay in Bugzilla/Phabricator forever as a read-only archive, and GitLab will only have new active issues. I think a sensible transition plan would be for us to aim to do the import at the end of June, which means sweeping through all our open bugs before then, closing them if they're no longer useful or just cleaning up titles/etc to be helpful in future. Does anyone have any opinions on this? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
On 11/5/18 21:27 , Daniel Stone wrote: Hi Peter, On 10 May 2018 at 00:48, Peter Huttererwrote: On Mon, May 07, 2018 at 04:59:49PM +0100, Daniel Stone wrote: The first thing to happen is to migrate the central Git push point to GitLab. anongit.fd.o and cgit will still work as read-only mirrors, but you will not be able to push to git.fd.o. This would happen for all of wayland, wayland-protocols, weston and wayland-web. libinput we could move separately, wayland-build-tools is open to discussion (does it still work?), and wayland-java appears to be completely abandoned. regarding libinput: I'll release 1.11 over the next month or so, so the options are basically: move now or move after that. I'd rather not switch git repos between RCs. Yeah, what I was trying to say was more like: there's no reason to pair the two together, so whatever we do and decide with Wayland here, libinput can move separately at its own pace. Probably makes sense to put it in a new group by now, especially if you want to group related tools with it, give it its own site, etc etc. I know what you meant :) and my comment was "now" or "after the release", whichever is convenient. If you want to switch it all in one go, that's fine with me but 2 weeks from now would be inconvenient. and yes, another group would be great. Cheers, Peter Otherwise I'm happy to move, I'm struggling with bugzilla, so I'm mostly hoping that GitLab is going to be better (without having evaluated it deeply :) What could possibly go wrong? :) More seriously, that sounds good - please remind me when the release has happened and you're ready to move and I'll get it migrated. Thanks for all the work on this btw. No problem! Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
Hi Jonas, On 8 May 2018 at 11:00, Jonas Ådahlwrote: > On Mon, May 07, 2018 at 04:59:49PM +0100, Daniel Stone wrote: >> My proposal is that as of the repo migration, we trial GitLab merge >> requests on a couple of patchsets where we'd expect to see the need >> for complex structured comments and multiple revisions. These >> revisions should probably be shadow-posted to the list, to make sure >> we didn't miss anything. >> >> Once we'd been through a couple of rounds and we had a general >> consensus amongst reviewers that we had a good workflow we were happy >> to use, we would add that to CONTRIBUTING.md as well as README, >> informing would-be contributors that we now preferred to receive >> patches through GitLab, though would continue to accept patches >> through the list for a short time (informing those who did submit via >> the list that they should move to GitLab). Once the next release had >> passed, we would stop doing that, and have GitLab MRs as our sole >> point of code review. >> >> >> >> So - thoughts? > > First: Yay, Gitlab! > > Now some questions/concerns. > > It is common that a patch series gets per-patch reviews, each patch > may receive multiple reviews, and we keep track of that by adding the > Reviewed-by/Acked-by tags. How are we suppose to keep doing that with > Gitlab? It's a good question. > There are two explicit issues related to reviewing: > > How do we keep track of who reviewed, acked or tested what patch? As far > as I know, there is no such UI in Gitlab (yet?) for that, and also AFAIK > no way to comment on individual commits in a merge request. > > The other issue is how do we "save" the reviewed-ness. The only way I > know will work is to require the contributor to click the > allow-maintainer-edits, then having the patch merger fetch the branch, > rewrite the branch by adding Reviewed-by:s, pushing back the branch > overwriting the one in the merge request, then clicking the merge > button. All that is a bit cumbersome, especially when there is a green > merge button waiting to be clicked. > > The alternative is to just stop using commit message tags, relying on > digging out the merge request and see who commented what, which would be > a bit unfortunate I think. It'd also loose the acknowledgements in the > git log however, which is indeed a loss. > > Then there is the linear history vs merge commits. Gitlab supports both, > with requirement for linear history being that the contributor clicks the > allow-maintainer-edits, which makes it possible to rebase the merge > request branch before merging. I'm not sure it's possible to make it > checked by default however, which might be a bit unfortunate. All good questions, and I don't really have an opinion either way. We could do what we do now, which is rely on people to type out explicit tags into a comment box, and copy & paste those across. Or we could infer those from more free-form review comments. Rather than leaning heavily on the big green button, we could pull the commits, rebase and add the tags ourselves, then just directly push. But I don't think this closes the merge request? I think what I would prefer most is sensible free-form comments on GitLab, which maintainers could then use at their discretion to decide whether or not to push from. But in the short term, maybe a decent compromise solution is: * people push to GitLab and open a MR * the MR is reviewed, revised, etc etc * as developers are comfortable with it, they add R-b/A-b tags explicitly, as we do now * rather than land with the big green button, we write some exceedingly lame script (maybe based off https://github.com/zaquestion/lab) which scrapes the MR for tags, rewrites commit messages to apply them, adds a link to the MR to every commit, pushes and then closes the MR I don't have a great answer for per-commit tags to be honest, but again, since this is something we now do manually, maybe we could just keep on doing that. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
Hi Peter, On 10 May 2018 at 00:48, Peter Huttererwrote: > On Mon, May 07, 2018 at 04:59:49PM +0100, Daniel Stone wrote: >> The first thing to happen is to migrate the central Git push point to >> GitLab. anongit.fd.o and cgit will still work as read-only mirrors, >> but you will not be able to push to git.fd.o. This would happen for >> all of wayland, wayland-protocols, weston and wayland-web. libinput we >> could move separately, wayland-build-tools is open to discussion (does >> it still work?), and wayland-java appears to be completely abandoned. > > regarding libinput: I'll release 1.11 over the next month or so, so the > options are basically: move now or move after that. I'd rather not > switch git repos between RCs. Yeah, what I was trying to say was more like: there's no reason to pair the two together, so whatever we do and decide with Wayland here, libinput can move separately at its own pace. Probably makes sense to put it in a new group by now, especially if you want to group related tools with it, give it its own site, etc etc. > Otherwise I'm happy to move, I'm struggling with bugzilla, so I'm mostly > hoping that GitLab is going to be better (without having evaluated it > deeply :) What could possibly go wrong? :) More seriously, that sounds good - please remind me when the release has happened and you're ready to move and I'll get it migrated. > Thanks for all the work on this btw. No problem! Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
On Mon, May 07, 2018 at 04:59:49PM +0100, Daniel Stone wrote: > Hi all, > As some of you have seen, freedesktop.org is migrating its Git hosting > to GitLab[0]. Whilst the documentation is still a little scratchy - > partly deliberate whilst we've been bootstrapping our infrastructure > and monitoring how some smaller pilot projects have gone using it - > here is what it definitely means for Wayland (wearing my fd.o admin > hat), and some of my suggestions of what we should do as a project > (wearing my 'one of many Wayland contributors' hat). > > The latter suggestions are just my suggestion and opinion, which I'm > putting out there for discussion. > > > GitLab background > -- [...] > Repository migration > > > [admin hat still on] > > The first thing to happen is to migrate the central Git push point to > GitLab. anongit.fd.o and cgit will still work as read-only mirrors, > but you will not be able to push to git.fd.o. This would happen for > all of wayland, wayland-protocols, weston and wayland-web. libinput we > could move separately, wayland-build-tools is open to discussion (does > it still work?), and wayland-java appears to be completely abandoned. regarding libinput: I'll release 1.11 over the next month or so, so the options are basically: move now or move after that. I'd rather not switch git repos between RCs. Otherwise I'm happy to move, I'm struggling with bugzilla, so I'm mostly hoping that GitLab is going to be better (without having evaluated it deeply :) Thanks for all the work on this btw. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Migrating Wayland & Weston to GitLab
On Mon, May 07, 2018 at 04:59:49PM +0100, Daniel Stone wrote: > Hi all, ... snip ... > > Code review > - > > [admin hat on] > > GitLab also provides code reviews through merge requests[3], which are > like GitHub's pull requests (push to a branch or separate repo, create > a request for someone to review and merge that code), but much more > attuned to our workflows. Specifically, GitHub is geared towards > chronological commit streams (initial code, fix, fix, fix, fix, fix, > more stuff, more fixes) which ultimately get squashed into one - which > was replicated by Phabricator. GitLab does allow for the merge-ordered > microcommits we have on the list today, including allowing you to > rebase them before submitting new versions, and also not squashing the > results. > > More usefully, it also allows you to create these with 'git push' then > following the URL it offers you to create a MR. Being a real git > branch allows reviewers to pull the pristine tree as the submitter had > (without lossily running through patch files), and also for CI > pipelines to be run on those branches so they can see problems without > needing the reviewer as a proxy to 'make distcheck'. > > Comments on GitLab MRs can either be placed as a general comment on > the MR, or directly associated with lines of code. These comments can > either be comments (general chatter), or marked as an 'issue', which > must be explicitly marked as resolved in order to move on. This makes > it more difficult to forget review comments in subsequent revisions. > > > [admin hat off, contributor hat on] > > Every time someone comes on to #wayland saying that they want to > submit a patch series but can't figure out how to use git-send-email, > it kills me. Every time I look at the state of Patchwork and realise > that it's a wasteland because the commit -> Patchwork hooks are > necessarily lossy, I despair a bit. That's if it even correctly > identifies and groups the patches in the first place, which it doesn't > despite two years of development specifically aimed at having it work > well for dri-devel@ and intel-gfx@. > > Not having code review hooked into issue tracking means that even > after we've demanded our contributors jump through the git-send-email > hoops, their contributions can disappear into the void. I think having > it hooked up to issue tracking, with assignable labels and target > milestones, with discussions people can actually follow (rather than > Mailman archives, where any discussion spanning a month boundary is > split in two), would really lower the barrier to contributing. > > We can also put a CONTRIBUTING.md file which is shown to people when > they create merge requests, outlining how we review and what we're > looking for. CI means that we can pick up the mechanical failures > early, rather than waiting for a human to come by, run the tests > themselves, and inform someone who may no longer have time or interest > at that point. > > Something I've been told anecdotally by people either contributing to > or using wlc/wlroots/etc, is that one of the reasons they used that > over libweston is because our archaic setup means it's pointlessly > difficult to communicate with us. They've got a point. > > My proposal is that as of the repo migration, we trial GitLab merge > requests on a couple of patchsets where we'd expect to see the need > for complex structured comments and multiple revisions. These > revisions should probably be shadow-posted to the list, to make sure > we didn't miss anything. > > Once we'd been through a couple of rounds and we had a general > consensus amongst reviewers that we had a good workflow we were happy > to use, we would add that to CONTRIBUTING.md as well as README, > informing would-be contributors that we now preferred to receive > patches through GitLab, though would continue to accept patches > through the list for a short time (informing those who did submit via > the list that they should move to GitLab). Once the next release had > passed, we would stop doing that, and have GitLab MRs as our sole > point of code review. > > > > So - thoughts? First: Yay, Gitlab! Now some questions/concerns. It is common that a patch series gets per-patch reviews, each patch may receive multiple reviews, and we keep track of that by adding the Reviewed-by/Acked-by tags. How are we suppose to keep doing that with Gitlab? There are two explicit issues related to reviewing: How do we keep track of who reviewed, acked or tested what patch? As far as I know, there is no such UI in Gitlab (yet?) for that, and also AFAIK no way to comment on individual commits in a merge request. The other issue is how do we "save" the reviewed-ness. The only way I know will work is to require the contributor to click the allow-maintainer-edits, then having the patch merger fetch the branch, rewrite the branch by adding Reviewed-by:s, pushing back the branch overwriting the one in the
Migrating Wayland & Weston to GitLab
Hi all, As some of you have seen, freedesktop.org is migrating its Git hosting to GitLab[0]. Whilst the documentation is still a little scratchy - partly deliberate whilst we've been bootstrapping our infrastructure and monitoring how some smaller pilot projects have gone using it - here is what it definitely means for Wayland (wearing my fd.o admin hat), and some of my suggestions of what we should do as a project (wearing my 'one of many Wayland contributors' hat). The latter suggestions are just my suggestion and opinion, which I'm putting out there for discussion. GitLab background -- [fd.o admin hat on] GitLab is a web service developed by gitlab.com, offering code hosting, online code review, issue tracking, CI integration, hosting of generated web pages, and so on. They offer a fully open-source Community Edition, as well as a proprietary subscription-based Enterprise Edition with several tiers. fd.o currently hosts a plethora of services, including a normal git daemon and SSH server for hosting, cgit for repository browsing, Bugzilla for issue tracking, Mailman for mailing lists, Patchwork for tracking patch submissions, web hosting (static pages or ikiwiki). We also host an instance of Phabricator, which we rolled out as a test to see if it could provide us with better workflows. Long story short, it didn't: its issue tracking is pretty good, but code review not, as it requires a specific 'git-phab' tool to work properly, and supporting microcommits and rebasing workflows is an explicit anti-goal. Its UI is also totally unsuited for the forge-like setup fd.o has, as well as community projects: it's designed for internal use by dedicated software teams. All of this came up during XDC in Helsinki, where after sitting down and talking we decided that the UI would need a lot of work to be useful. Since then, Phabricator's development model has also closed up with very little possibility for community contributions, which isn't good for us. It's probably notable that the vast majority of people who used phabricator.fd.o were from Collabora, where we use it for all our issue tracking internally. Last year, GNOME went through a similar search[1] for a more modern and integrated tool which would let them have issue tracking linked with code hosting, the ability to push branches and generate merge requests people could review via the web from those, CI linked with merge requests and repositories, etc. I participated in that from the point of view of giving Phabricator a fair run out, being more familiar with it than others. Over the course of the discussions, I ended up supporting their conclusion that GitLab was the best tool for them, mainly through seeing the huge strides they'd made between (at the time) 8.x to 9.x, and subsequently. GitLab also has a well-documented REST API, as well as external web hooks, which can be used to extend its behaviour in ways which aren't possible for most of our tools. Most of the functionality available through its web interface is also available through a documented API. Currently we deal with extensions with local changes to the codebase, which makes upgrades painful. One reason we're looking for a single, more modern, tool is to free up some admin time. Not only is GitLab more featureful than our existing suite of tools, but our biggest admin problem at the moment is exactly those tools. Tracking the releases and deployment of all those tools is hugely time-consuming, and all the duct tape which holds them together is incredibly fragile. Dealing with spam is also a massive problem across a lot of them, and that's even before you get to GDPR issues. Running services which don't support modern identity management is also a problem. Users hate having to sign up in multiple places (SSH account, Bugzilla, lists, Patchwork), where we maintain a username/password store. None of these services support external authentication providers (which users have complained of), none of them support 2FA (a genuine security concern), and dealing with PII erasure requests on the GDPR is basically unworkable. Late last year, some of the people responsible for GNOME's migration put us in touch with GitLab's community outreach team, who offered to support us in our migration if that's what we wanted to do. After going through the options, we have accepted a donation-in-kind from them, of paying for us to run a GitLab CE instance (we declined an EE license, or remote hosting) on Google cloud infrastructure. This will let us replace life-expired physical machines as we wind down the services which run on them. Repository migration [admin hat still on] The first thing to happen is to migrate the central Git push point to GitLab. anongit.fd.o and cgit will still work as read-only mirrors, but you will not be able to push to git.fd.o. This would happen for all of wayland, wayland-protocols, weston and wayland-web. libinput we