gitlab migration

[Eric Anholt]

Adam Jackson <ajax at redhat.com> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180608/9d9455d2/attachment.sig>