Re: Migrating Wayland & Weston to GitLab

[Daniel Stone]

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

[Pekka Paalanen]

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

[Ucan, Emre (ADITG/ESB)]

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

[Daniel Stone]

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

[Daniel Stone]

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

[Kristian Høgsberg]

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

[Pekka Paalanen]

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

[Erik De Rijcke]

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

[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

Re: Migrating Wayland & Weston to GitLab

[Daniel Stone]

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

[Pekka Paalanen]

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

[Daniel Stone]

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

[Peter Hutterer]

On 11/5/18 21:27 , Daniel Stone wrote:

Hi Peter,

On 10 May 2018 at 00:48, Peter Hutterer  wrote:

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

[Daniel Stone]

Hi Jonas,

On 8 May 2018 at 11:00, Jonas Ådahl  wrote:
> 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

[Daniel Stone]

Hi Peter,

On 10 May 2018 at 00:48, Peter Hutterer  wrote:
> 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

[Peter Hutterer]

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

[Jonas Ådahl]

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