Re: gitlab migration

Re: gitlab migration

[Michel Dänzer]

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

[sylvain.bertrand-Re5JQEeQqe8AvxtiuMwx3w]

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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: gitlab migration

[Daniel Stone]

Hi Sylvain,
It looks like Mutt is mangling email addresses - I've fixed Michel's.

On 11 June 2018 at 14:30,  <sylvain.bertrand@gmail.com> 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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: gitlab migration

[Daniel Stone]

Hi Michel,

On 11 June 2018 at 11:33, Michel Dänzer <michel@daenzer.net> 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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: gitlab migration

[sylvain.bertrand-Re5JQEeQqe8AvxtiuMwx3w]

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,  <sylvain.bertrand@gmail.com> 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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: gitlab migration

[Daniel Stone]

Hi Sylvain,

On 12 June 2018 at 13:38,  <sylvain.bertrand@gmail.com> 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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: gitlab migration

[sylvain.bertrand-Re5JQEeQqe8AvxtiuMwx3w]

On Tue, Jun 12, 2018 at 01:41:55PM +0100, Daniel Stone wrote:
> Hi Sylvain,
> 
> On 12 June 2018 at 13:38,  <sylvain.bertrand@gmail.com> 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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: gitlab migration

[Alexander E. Patrakov]

Daniel Stone <daniel@fooishbar.org>:
>
> Hi Sylvain,
>
> On 12 June 2018 at 13:38,  <sylvain.bertrand@gmail.com> 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

[Daniel Stone]

Hi Alexander,

On 12 June 2018 at 14:53, Alexander E. Patrakov <patrakov@gmail.com> wrote:
> Daniel Stone <daniel@fooishbar.org>:
>> > 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

[Alexander E. Patrakov]

Daniel Stone <daniel@fooishbar.org>:
>
> Hi Alexander,
>
> On 12 June 2018 at 14:53, Alexander E. Patrakov <patrakov@gmail.com> wrote:
> > Daniel Stone <daniel@fooishbar.org>:
> >> > 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

[Michel Dänzer]

On 2018-06-12 01:35 PM, Daniel Stone wrote:
> On 11 June 2018 at 11:33, Michel Dänzer <michel@daenzer.net> 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

[James Cloos]

>>>>> "DS" == Daniel Stone <daniel@fooishbar.org> 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 <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: gitlab migration

[Adam Jackson]

On Mon, 2018-06-11 at 12:33 +0200, Michel Dänzer wrote:

> As the maintainer of xf86-video-amdgpu and -ati, I'm fine with migrating
> these to GitLab for Git and patch review.
> 
> However, I'm not sure what to do about bugs/issues. My first thought was
> to allow creating new issues in GitLab and disable creating new reports
> in Bugzilla, but not to migrate existing reports from Bugzilla. However,
> it still happens fairly often that a report is initially filed against
> the Xorg drivers, even though it's actually an issue in the X server,
> Mesa or the kernel (old habits die hard...). Therefore, I'm inclined to
> stick to Bugzilla until at least the X server and Mesa have moved to
> GitLab for issue tracking, to hopefully allow moving such misfiled issues.

I've hacked up the migration script to allow moving individual issues
by bug number instead of matching a whole product/component [1]. This
has already been useful to sort out some of the junkdrawer components
like App/Other. Running the script does require someone with supercow
powers on both sides, but I'm happy to do so as needed.

With that in mind, I think it may be time to enable issues and merge
requests for xserver, and disable the remaining (server) bz components
for new issues. Any objections?

[1] - https://gitlab.freedesktop.org/freedesktop/bztogl/merge_requests/1

- ajax
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx