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 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Wed, 2018-08-01 at 14:38 +0200, Guillem Jover wrote: > It would be nice if the xorg.modules (from modular) got updated too, so > that some of this could be automated locally. :) My goodness, we have written this down so many slightly different ways. I've pushed some updates that I hope are right since I don't know of anything actually using that file, let me know if anything looks wrong or you need more. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Sun, 2018-07-29 at 21:49:44 +0100, Daniel Stone wrote: > On Sun, 29 Jul 2018 at 16:53, Alan Coopersmith > wrote: > > On 07/29/18 03:07 AM, Daniel Stone wrote: > > > This took a little longer than hoped, but all the repos have now been > > > moved. Great! :) > > I updated all my local clones with: > > > > git remote set-url origin `git remote get-url origin | sed \ > >'s%ssh://git.freedesktop.org/git/%ssh://g...@gitlab.freedesktop.org/%'` > > > > but got errors that gitlab couldn't find app/bdftopcf, app/rendercheck, > > and app/x11perf. > > > > Did something go wrong with them? I don't see them in the web ui at > > https://gitlab.freedesktop.org/xorg/app either. > > Not wrong as such, just moved. These are the modules which (as > requested) changed relative path during the migration: > xorg/app/bdftopcf -> xorg/util/bdftopcf > xorg/app/rendercheck -> xorg/test/rendercheck > xorg/app/x11perf -> xorg/test/x11perf > xorg/app/xtsttopng -> xorg/test/xtsttopng > xorg/driver/glamor -> xorg/driver/glamor-history > xorg/xprint -> xorg/xserver-xprint > avivo/xf86-video-avivo -> xorg/driver/xf86-video-avivo > glitz -> xorg/driver/glitz-history > > If you try to fetch from the old URL it will still work, and if you > try to push to the old URL it will tell you the correct new URL to > use. > > > I also got the same error from xf86-video-nouveau, xf86-video-openchrome, > > libvdpau, and xcb/* but I'm assuming that was my script going too far and > > those projects not migrating yet. > > Right, exactly. Nothing under a non-xorg/ path has yet moved. It would be nice if the xorg.modules (from modular) got updated too, so that some of this could be automated locally. :) Thanks, Guillem ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On 07/29/18 01:49 PM, Daniel Stone wrote: Not wrong as such, just moved. These are the modules which (as requested) changed relative path during the migration: xorg/app/bdftopcf -> xorg/util/bdftopcf xorg/app/rendercheck -> xorg/test/rendercheck xorg/app/x11perf -> xorg/test/x11perf xorg/app/xtsttopng -> xorg/test/xtsttopng xorg/driver/glamor -> xorg/driver/glamor-history xorg/xprint -> xorg/xserver-xprint avivo/xf86-video-avivo -> xorg/driver/xf86-video-avivo glitz -> xorg/driver/glitz-history Ah, thanks - I didn't realize stuff was moving around - things work when given the right path. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
Hi Alan, On Sun, 29 Jul 2018 at 16:53, Alan Coopersmith wrote: > On 07/29/18 03:07 AM, Daniel Stone wrote: > > This took a little longer than hoped, but all the repos have now been moved. > > Huge thanks for doing this. > > I updated all my local clones with: > > git remote set-url origin `git remote get-url origin | sed \ >'s%ssh://git.freedesktop.org/git/%ssh://g...@gitlab.freedesktop.org/%'` > > but got errors that gitlab couldn't find app/bdftopcf, app/rendercheck, > and app/x11perf. > > Did something go wrong with them? I don't see them in the web ui at > https://gitlab.freedesktop.org/xorg/app either. Not wrong as such, just moved. These are the modules which (as requested) changed relative path during the migration: xorg/app/bdftopcf -> xorg/util/bdftopcf xorg/app/rendercheck -> xorg/test/rendercheck xorg/app/x11perf -> xorg/test/x11perf xorg/app/xtsttopng -> xorg/test/xtsttopng xorg/driver/glamor -> xorg/driver/glamor-history xorg/xprint -> xorg/xserver-xprint avivo/xf86-video-avivo -> xorg/driver/xf86-video-avivo glitz -> xorg/driver/glitz-history If you try to fetch from the old URL it will still work, and if you try to push to the old URL it will tell you the correct new URL to use. > I also got the same error from xf86-video-nouveau, xf86-video-openchrome, > libvdpau, and xcb/* but I'm assuming that was my script going too far and > those projects not migrating yet. Right, exactly. Nothing under a non-xorg/ path has yet moved. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On 07/29/18 03:07 AM, Daniel Stone wrote: Hi, On Mon, 23 Jul 2018 at 16:24, Adam Jackson wrote: My earlier assertion about the git url not being changed is only true for pulls. For pushes, you will indeed need to update the remote to the new URL: $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver Repo moves will be (early) this week. BZ moves for the more boring components (protocol, libs, apps, deprecated/abandoned stuff) will follow shortly thereafter. This took a little longer than hoped, but all the repos have now been moved. Huge thanks for doing this. I updated all my local clones with: git remote set-url origin `git remote get-url origin | sed \ 's%ssh://git.freedesktop.org/git/%ssh://g...@gitlab.freedesktop.org/%'` but got errors that gitlab couldn't find app/bdftopcf, app/rendercheck, and app/x11perf. Did something go wrong with them? I don't see them in the web ui at https://gitlab.freedesktop.org/xorg/app either. I also got the same error from xf86-video-nouveau, xf86-video-openchrome, libvdpau, and xcb/* but I'm assuming that was my script going too far and those projects not migrating yet. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
Hi, On Mon, 23 Jul 2018 at 16:24, Adam Jackson wrote: > My earlier assertion about the git url not being changed is only true > for pulls. For pushes, you will indeed need to update the remote to the > new URL: > > $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver > > Repo moves will be (early) this week. BZ moves for the more boring > components (protocol, libs, apps, deprecated/abandoned stuff) will > follow shortly thereafter. This took a little longer than hoped, but all the repos have now been moved. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Mon, 2018-07-23 at 11:23 -0400, Adam Jackson wrote: > Nobody did, so, this is done now. > > My earlier assertion about the git url not being changed is only true > for pulls. For pushes, you will indeed need to update the remote to the > new URL: > > $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver > > Repo moves will be (early) this week. BZ moves for the more boring > components (protocol, libs, apps, deprecated/abandoned stuff) will > follow shortly thereafter. For detailed migration progress beyond the repo moves, please follow: https://gitlab.freedesktop.org/xorg/meta/issues/1 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Mon, 2018-07-09 at 14:30 -0400, Adam Jackson wrote: > Currently the xorg group in gitlab is derived from the pre-existing > freedesktop LDAP group. This is a bit excessive, there's over 250 > people in the group in total and not even a fifth of those are > regularly active. If you're both a group member and a project member > the highest privilege level is used; currently, this would mean all of > these accounts are maintainers for every project. > > That's not _different_ from the current state of affairs, but since we > now have the easy ability to delegate access control per-project, we > should take the opportunity to prune the list of xorg group > members. These accounts will still exist in gitlab, and if the > contributor returns they are welcome to rejoin. As a totally arbitrary > cutoff I'd suggest pruning anyone who hasn't had an Author or Commit > credit in git in the last, say, three years. > > If you want a differently arbitrary cutoff, or have other feedback, > please speak up. Nobody did, so, this is done now. My earlier assertion about the git url not being changed is only true for pulls. For pushes, you will indeed need to update the remote to the new URL: $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver Repo moves will be (early) this week. BZ moves for the more boring components (protocol, libs, apps, deprecated/abandoned stuff) will follow shortly thereafter. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Mon, 2018-07-02 at 10:23 -0700, Keith Packard wrote: > For the first step, I'd like to propose moving the x server git > repository to gitlab in the coming week, with the switch-over happening > on the morning of July 9. This is now done: https://gitlab.freedesktop.org/xorg/xserver The old git URLs still work, so this change should be transparent for existing checkouts. We'll be moving more repositories over the coming weeks. Currently the xorg group in gitlab is derived from the pre-existing freedesktop LDAP group. This is a bit excessive, there's over 250 people in the group in total and not even a fifth of those are regularly active. If you're both a group member and a project member the highest privilege level is used; currently, this would mean all of these accounts are maintainers for every project. That's not _different_ from the current state of affairs, but since we now have the easy ability to delegate access control per-project, we should take the opportunity to prune the list of xorg group members. These accounts will still exist in gitlab, and if the contributor returns they are welcome to rejoin. As a totally arbitrary cutoff I'd suggest pruning anyone who hasn't had an Author or Commit credit in git in the last, say, three years. If you want a differently arbitrary cutoff, or have other feedback, please speak up. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Adam Jackson writes: > I don't really see a reason not to move the repos for everything. It's > a pretty invisible change since the old URLs keep working, and I'm > itchy to see CI wired up. Sounds good to me; I was trying to not over-load poor Daniel. If he's up for it, or can use help from us, let's do it. -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Mon, 2018-07-02 at 10:23 -0700, Keith Packard wrote: > Adam Jackson writes: > > > I'd like us to start moving repos and bug tracking into gitlab. > > I would also like to get to a merge-request model at some > point. However, I think we can take this in stages and start by moving > the git repos over to gitlab, and then move the bugs over, and finally > start doing patch review via the gitlab issue tracker. > > For the first step, I'd like to propose moving the x server git > repository to gitlab in the coming week, with the switch-over happening > on the morning of July 9. I don't really see a reason not to move the repos for everything. It's a pretty invisible change since the old URLs keep working, and I'm itchy to see CI wired up. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Adam Jackson writes: > I'd like us to start moving repos and bug tracking into gitlab. I would also like to get to a merge-request model at some point. However, I think we can take this in stages and start by moving the git repos over to gitlab, and then move the bugs over, and finally start doing patch review via the gitlab issue tracker. For the first step, I'd like to propose moving the x server git repository to gitlab in the coming week, with the switch-over happening on the morning of July 9. Daniel has already created accounts for everyone in the xorg group, but I believe there is a process for each user to authenticate via email and upload ssh keys. You can also set up two-factor authentication, which seems like a good idea to me. -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Fri, 2018-06-08 at 14:08 -0400, Adam Jackson wrote: > I'd like us to start moving repos and bug tracking into gitlab. > Hopefully everyone's aware that gitlab exists and why fdo projects are > migrating to it. If not, the thread about Mesa's migration provides > some useful background: > > https://lists.x.org/archives/mesa-dev/2018-May/195634.html > > This should be mostly mechanical, except for moving some of the older > junk into the archive and deciding which drivers _not_ to move yet (I > imagine intel has some of its processes hooked up to bz, for example). I've started a ticket in fdo gitlab to track this migration: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 I'd like to get the proposal nailed down before we start migrating, so if you have needs or opinions please make them known on the ticket. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Tue, 2018-06-12 at 17:38 -0400, James Cloos wrote: > Two comments: > > BZ is superior to GL (or GH or the like). > > Mailing lists are vastly superior to any web-only crap. 'web-only' is only a problem until you actually go write a command line client for it. Which, you can do if you really need these sort of workflows. Additionally I'm with daniels here, Gitlab and Github are two massively different things with different workflows and if you're just going off the assumption "if it sounds like the word Github then it must be another github" you're not actually contributing anything useful to the discussion, especially if you don't actually provide any points as to "gitlab is bad because of X or Y reason". > > -JimC -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Hi Felix, On Wed, 13 Jun 2018 at 10:24, Felix Miata wrote: > Daniel Stone composed on 2018-06-13 09:24 (UTC+0100): > > Felix Miata wrote: > >> James Cloos composed on 2018-06-12 17:38 (UTC-0400): > >> > BZ is superior to GL (or GH or the like). > > >> Strongly agree, especially for returning useful search results!!! > > > What kind of searches have you tried which returned better search > > results on Bugzilla than GitLab? > > I gave up trying too long ago to remember. Best of my recollection is all of > them, generally getting too many to sift through, or zarro. I'm speaking of > gitlab/github (which is it anyway?) generally, not any specific project's. BZ > I > got used to over 17 years go, when learning new things had not yet become > problematic. GitLab and GitHub are two completely different services. They offer different features in different ways through different user interfaces, and have both been evolving pretty quickly. Saying emphatically!!! that GitLab's search results are useless, based on vague recollections of having used a _different service_ which was so long ago you can't even remember, isn't really a great contribution to a discussion. > Bad as yesteryear's web was, the current one is worse. Firefox ESR 60 download > is 648% the size of Firefox 1.0. All the benefit of broadband has been eaten > up > by bottlenecks, bloated browsers and gargantuan web pages. Googling 'gitlab > xorg' or 'github xorg' don't provide anything resembling an actual home page > URI > like https://bugs.freedesktop.org/. https://www.x.org/wiki/Development/ > doesn't > either. Maybe these are a good sign, one to indicate Ajax's migration hasn't > actually started. Yes. This thread is to discuss migrating to GitLab at some point in the future. Since it has not happened yet, there is no entrypoint to speak of. I can't solve your problems with web browsers, bottlenecks and people using JavaScript, but again, both Bugzilla and GitLab are web-based tools, and GitLab has a complete API with CLI-based tools you can use instead of a browser. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Hi Felix, On Wed, 13 Jun 2018 at 04:17, Felix Miata wrote: > James Cloos composed on 2018-06-12 17:38 (UTC-0400): > > Two comments: > > > BZ is superior to GL (or GH or the like). > > Strongly agree, especially for returning useful search results!!! What kind of searches have you tried which returned better search results on Bugzilla than GitLab? Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Tue, 12 Jun 2018 at 22:36, James Cloos wrote: > > "DS" == Daniel Stone writes: > DS> No need to test; it's guaranteed to fail since we require Recaptcha > DS> for login due to massive spam issues. > > Which is of course grossly unethical and malicious and should never be > used by any site, under any circumstances. > > If some sort of captcha is ever desired, it always must be something > which works with non-ecmacsipt, TUI browsers. > > A simple math question with a simple html text box for the answer is OK. > Or a technical question specific to the given project. > > But never goog's malicious crap. I assume that you're unaware of the levels of spam we've been dealing with, including the number of times we've been blacklisted by major mail providers, the extent to which search engines used to distrust us, and the amount of admin time spent dealing with it. Now you've got whatever it was out of your system, maybe you could come back with some kind of actionable feedback, or a constructive plan to address the genuine problems that we've been discussing both here and at various conferences for the last two or three years which have led to GitLab. Maybe you could venture a real suggestion for dealing with spam which also works with noscript lynx or whatever; ideally one which was better than our previous version which did genuinely cause people issues. Or maybe you could go look at the CLI client for GitLab I've already pointed to, and read the API documentation. Or just continue the useless flames trying to enforce your opinion as universal fact, every single line of which should carry '[citation needed]'. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Tue, Jun 12, 2018 at 01:41:55PM +0100, Daniel Stone wrote: > Hi Sylvain, > > On 12 June 2018 at 13:38, wrote: > > On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote: > >> GitLab has a pretty comprehensive and well-documented API which might > >> help if you don't want to use a web browser. There are also clients > >> like 'lab': https://gitlab.com/zaquestion/lab which provide a good CLI > >> interface. > > > > Those "web APIs" usually require the use of an heavy javascript browser for > > authentification or "app authorization". > > > > That said, I could not even create an account with a noscript/xhtml basic > > browser (if you want to test that, install the famous noscript module with > > an > > empty "white list" in firefox or chromium, or use lynx or links or w3m). > > No need to test; it's guaranteed to fail since we require Recaptcha > for login due to massive spam issues. Why is this captcha not noscript/xhtml basic friendly? (You could use also netsurf browser which has some static css support) regards, -- Sylvain ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote: > Hi Sylvain, > It looks like Mutt is mangling email addresses - I've fixed Michel's. > > On 11 June 2018 at 14:30, wrote: > > On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote: > >> Adding the amd-gfx list, in cases somebody there has concerns or other > >> feedback. > > > > For feedback: > > I attempted a migration on gitlab of my repos but I was blocked because it's > > not noscript/xhtml basic browser friendly. > > > > I was successfull with launchpad.net (which has now git support). > > > > I did not test if the issue system was noscript/xhtml basic friendly though. > > GitLab has a pretty comprehensive and well-documented API which might > help if you don't want to use a web browser. There are also clients > like 'lab': https://gitlab.com/zaquestion/lab which provide a good CLI > interface. Hi, Those "web APIs" usually require the use of an heavy javascript browser for authentification or "app authorization". That said, I could not even create an account with a noscript/xhtml basic browser (if you want to test that, install the famous noscript module with an empty "white list" in firefox or chromium, or use lynx or links or w3m). regards, -- Sylvain ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
James Cloos composed on 2018-06-12 17:38 (UTC-0400): > Two comments: > BZ is superior to GL (or GH or the like). Strongly agree, especially for returning useful search results!!! > Mailing lists are vastly superior to any web-only Strongly agree!!! -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Two comments: BZ is superior to GL (or GH or the like). Mailing lists are vastly superior to any web-only crap. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
> "DS" == Daniel Stone writes: DS> No need to test; it's guaranteed to fail since we require Recaptcha DS> for login due to massive spam issues. Which is of course grossly unethical and malicious and should never be used by any site, under any circumstances. If some sort of captcha is ever desired, it always must be something which works with non-ecmacsipt, TUI browsers. A simple math question with a simple html text box for the answer is OK. Or a technical question specific to the given project. But never goog's malicious crap. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On 2018-06-12 01:35 PM, Daniel Stone wrote: > On 11 June 2018 at 11:33, Michel Dänzer wrote: >> On 2018-06-08 08:08 PM, Adam Jackson wrote: >>> I'd like us to start moving repos and bug tracking into gitlab. >>> Hopefully everyone's aware that gitlab exists and why fdo projects are >>> migrating to it. If not, the thread about Mesa's migration provides >>> some useful background: >>> >>> https://lists.x.org/archives/mesa-dev/2018-May/195634.html >>> >>> This should be mostly mechanical, except for moving some of the older >>> junk into the archive and deciding which drivers _not_ to move yet (I >>> imagine intel has some of its processes hooked up to bz, for example). >> >> 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. > > One thing some Mesa people said during that discussion is that they > like the ability to move issues between Mesa and the kernel, which > won't be possible if they're on split systems. So I probably wouldn't > hold my breath for that to be honest. Then I'd rather not use GitLab issues for these drivers at all either for the time being. The same argument applies to xserver as well, but I won't stand in the way of migrating that to GitLab issues. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Daniel Stone : > > Hi Alexander, > > On 12 June 2018 at 14:53, Alexander E. Patrakov wrote: > > Daniel Stone : > >> > That said, I could not even create an account with a noscript/xhtml basic > >> > browser (if you want to test that, install the famous noscript module > >> > with an > >> > empty "white list" in firefox or chromium, or use lynx or links or w3m). > >> > >> No need to test; it's guaranteed to fail since we require Recaptcha > >> for login due to massive spam issues. > > > > Have you tested whether Chinese or Russian users can login or sign up? > > Asking because Recaptcha was blocked for quite a long time by Russian > > authorities. > > We do have active users from both countries currently. Great, thanks for confirmation! -- Alexander E. Patrakov ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Hi Alexander, On 12 June 2018 at 14:53, Alexander E. Patrakov wrote: > Daniel Stone : >> > That said, I could not even create an account with a noscript/xhtml basic >> > browser (if you want to test that, install the famous noscript module with >> > an >> > empty "white list" in firefox or chromium, or use lynx or links or w3m). >> >> No need to test; it's guaranteed to fail since we require Recaptcha >> for login due to massive spam issues. > > Have you tested whether Chinese or Russian users can login or sign up? > Asking because Recaptcha was blocked for quite a long time by Russian > authorities. We do have active users from both countries currently. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Daniel Stone : > > Hi Sylvain, > > On 12 June 2018 at 13:38, wrote: > > On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote: > >> GitLab has a pretty comprehensive and well-documented API which might > >> help if you don't want to use a web browser. There are also clients > >> like 'lab': https://gitlab.com/zaquestion/lab which provide a good CLI > >> interface. > > > > Those "web APIs" usually require the use of an heavy javascript browser for > > authentification or "app authorization". > > > > That said, I could not even create an account with a noscript/xhtml basic > > browser (if you want to test that, install the famous noscript module with > > an > > empty "white list" in firefox or chromium, or use lynx or links or w3m). > > No need to test; it's guaranteed to fail since we require Recaptcha > for login due to massive spam issues. Have you tested whether Chinese or Russian users can login or sign up? Asking because Recaptcha was blocked for quite a long time by Russian authorities. Cannot test the situation myself now, because I emigrated several months ago. -- Alexander E. Patrakov ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Hi Sylvain, On 12 June 2018 at 13:38, wrote: > On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote: >> GitLab has a pretty comprehensive and well-documented API which might >> help if you don't want to use a web browser. There are also clients >> like 'lab': https://gitlab.com/zaquestion/lab which provide a good CLI >> interface. > > Those "web APIs" usually require the use of an heavy javascript browser for > authentification or "app authorization". > > That said, I could not even create an account with a noscript/xhtml basic > browser (if you want to test that, install the famous noscript module with an > empty "white list" in firefox or chromium, or use lynx or links or w3m). No need to test; it's guaranteed to fail since we require Recaptcha for login due to massive spam issues. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Hi Michel, On 11 June 2018 at 11:33, Michel Dänzer wrote: > On 2018-06-08 08:08 PM, Adam Jackson wrote: >> I'd like us to start moving repos and bug tracking into gitlab. >> Hopefully everyone's aware that gitlab exists and why fdo projects are >> migrating to it. If not, the thread about Mesa's migration provides >> some useful background: >> >> https://lists.x.org/archives/mesa-dev/2018-May/195634.html >> >> This should be mostly mechanical, except for moving some of the older >> junk into the archive and deciding which drivers _not_ to move yet (I >> imagine intel has some of its processes hooked up to bz, for example). > > 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. One thing some Mesa people said during that discussion is that they like the ability to move issues between Mesa and the kernel, which won't be possible if they're on split systems. So I probably wouldn't hold my breath for that to be honest. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Hi Sylvain, It looks like Mutt is mangling email addresses - I've fixed Michel's. On 11 June 2018 at 14:30, wrote: > On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote: >> Adding the amd-gfx list, in cases somebody there has concerns or other >> feedback. > > For feedback: > I attempted a migration on gitlab of my repos but I was blocked because it's > not noscript/xhtml basic browser friendly. > > I was successfull with launchpad.net (which has now git support). > > I did not test if the issue system was noscript/xhtml basic friendly though. GitLab has a pretty comprehensive and well-documented API which might help if you don't want to use a web browser. There are also clients like 'lab': https://gitlab.com/zaquestion/lab which provide a good CLI interface. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote: > Adding the amd-gfx list, in cases somebody there has concerns or other > feedback. For feedback: I attempted a migration on gitlab of my repos but I was blocked because it's not noscript/xhtml basic browser friendly. I was successfull with launchpad.net (which has now git support). I did not test if the issue system was noscript/xhtml basic friendly though. -- Sylvain ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On 2018-06-08 08:08 PM, Adam Jackson wrote: > I'd like us to start moving repos and bug tracking into gitlab. > Hopefully everyone's aware that gitlab exists and why fdo projects are > migrating to it. If not, the thread about Mesa's migration provides > some useful background: > > https://lists.x.org/archives/mesa-dev/2018-May/195634.html > > This should be mostly mechanical, except for moving some of the older > junk into the archive and deciding which drivers _not_ to move yet (I > imagine intel has some of its processes hooked up to bz, for example). 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. Adding the amd-gfx list, in cases somebody there has concerns or other feedback. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On 9 June 2018 at 00:11, Eric Anholt wrote:
> Adam Jackson writes:
>> I'd like us to start moving repos and bug tracking into gitlab.
>> Hopefully everyone's aware that gitlab exists and why fdo projects are
>> migrating to it. If not, the thread about Mesa's migration provides
>> some useful background:
>>
>> https://lists.x.org/archives/mesa-dev/2018-May/195634.html
>>
>> This should be mostly mechanical, except for moving some of the older
>> junk into the archive and deciding which drivers _not_ to move yet (I
>> imagine intel has some of its processes hooked up to bz, for example).
Migrating bugs is pretty easy, but there are currently over 2800 bugs
in the 'xorg' product, of which 921 are in the server +
xf86-video-modesetting + xf86-input-{evdev,libinput} components. The
import does preserve components as tags, and it does add a 'bugzilla'
tag to make it fairly easy to see what has and hasn't been triaged,
but I would seriously recommend doing a massive clean-up pass before
doing the migration. Easier said than done, of course.
>> As far as contribution model, I'd personally prefer to stop using
>> mailing lists, and for most of the X components I expect that's
>> probably an improvement, because most components do not have especially
>> active maintenance and it's currently very easy for patches to get lost
>> in the mailing list history. Conversely for the server it can be
>> difficult to keep track of a patch series' approval state. Again, not
>> solely my decision to make, so I'd like to hear some rough consensus on
>> how to proceed. Anyone with strong opinions, please do speak up.
>
> I, for one, would love to see xserver use a MR-based contribution
> process. Every once in a while I go to review some old patches I had
> personally marked as still to be reviewed, and find they're already
> merged. I'm sure the reverse is happening, too.
>
> For our libraries with less active maintainership, MRs that stay open
> until they're actually handled should be an even bigger win.
>
> I'm also *really* interested in a merge process that runs through the
> server's automated tests before the code hits master. I know that won't
> be day 1, but gitlab is progress toward that.
Totally AOL from me. It looks like the repo currently runs exactly the
same tests on GitLab CI as it did through Travis, for Linux at least.
For Windows we can set up a GitLab -> Appveyor hook to check and just
reuse that directly. That leaves us with OS X: we don't have an OS X
CI worker set up for fd.o, and Travis have flatly said they don't plan
to build any integration with GitLab. GStreamer do have OS X workers
for Jenkins, and they're actively looking into migrating to GitLab; I
believe their OS X worker more or less works. Maybe once they've moved
we could reuse that and cover all three platforms that way.
I'd be interested to see the relative speed of our worker compared to
Travis. If it is a bit slower, then we're actively working on sourcing
more CI workers, both x86 and ARM; hopefully within the month or so.
If it's already faster, great.
Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Adam Jackson writes: > I'd like us to start moving repos and bug tracking into gitlab. > Hopefully everyone's aware that gitlab exists and why fdo projects are > migrating to it. If not, the thread about Mesa's migration provides > some useful background: > > https://lists.x.org/archives/mesa-dev/2018-May/195634.html > > This should be mostly mechanical, except for moving some of the older > junk into the archive and deciding which drivers _not_ to move yet (I > imagine intel has some of its processes hooked up to bz, for example). > > As far as contribution model, I'd personally prefer to stop using > mailing lists, and for most of the X components I expect that's > probably an improvement, because most components do not have especially > active maintenance and it's currently very easy for patches to get lost > in the mailing list history. Conversely for the server it can be > difficult to keep track of a patch series' approval state. Again, not > solely my decision to make, so I'd like to hear some rough consensus on > how to proceed. Anyone with strong opinions, please do speak up. I, for one, would love to see xserver use a MR-based contribution process. Every once in a while I go to review some old patches I had personally marked as still to be reviewed, and find they're already merged. I'm sure the reverse is happening, too. For our libraries with less active maintainership, MRs that stay open until they're actually handled should be an even bigger win. I'm also *really* interested in a merge process that runs through the server's automated tests before the code hits master. I know that won't be day 1, but gitlab is progress toward that. signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
