[Mesa-dev] Gitlab migration

Wed May 23 23:41:45 UTC 2018

On 2018-05-23 16:00:53, Jason Ekstrand wrote:
> On Wed, May 23, 2018 at 2:48 PM, Jordan Justen <jordan.l.justen at intel.com>
> wrote:
> 
> > On 2018-05-23 12:34:11, Jason Ekstrand wrote:
> > > Mesa developers,
> > >
> > > tl;dr.  Please go to gitlab.freedesktop.org, create your account, and
> > > upload your SSH keys.  Instructions are the bottom of this e-mail.
> > >
> > > The freedesktop.org admins are trying to move as many projects and
> > services
> > > as possible over to gitlab and somehow I got hoodwinked into
> > spear-heading
> > > it for mesa.
> >
> > I thought we'd be able to decide if or when. It sounds like this is
> > decided.
> >
> 
> You are free to state your objections.  No one has actually pulled the
> trigger yet. :-)
> 

Rather than "it's time to do this", how about "should we do this"?

FWIW, if the fdo admins think this hosting is viable long term and at
least as stable as the current servers, then I don't see a concern
with changing *only* the repo location.

> 
> > > There are a number of reasons for this change.  Some of those
> > > reasons have to do with the maintenance cost of our sprawling and aging
> > > infrastructure.  Some of those reasons provide significant benefit to the
> > > project being migrated:
> > >
> > >  * Project-led user/rights management.  If we're on gitlab, project
> > > maintainers can give people access and we no longer have to wait for the
> > > freedesktop admins to add a new person.  And the freedesktop admins don't
> > > have to take the time.
> > >
> > >  * Better web UI for git.
> >
> > s/Better/Worse/
> >
> > > Ok, so some people will argue with me on this
> > > one but it's at least how I feel. :-)
> >
> > /me bows
> >
> > >  * [Optional] Integrated commit history and issue tracking.  Bugzilla
> > tags
> > > are great but gitlab ties things together much better.
> > >
> > >  * [Optional] Merge-request workflow.  With the rise of github, there are
> > > many developers out there who are used to the merge-request workflow and
> > > switching to that may lower the barrier to entry for new contributors.
> >
> > On the down side, the contribution/review history is now tied up in
> > the gitlab infrastructure rather than a simple email archive.
> >
> 
> Yup, and that is a down side.  That's why I made it clear that this is
> optional and not going to be a thing we do right away.

Ok, why don't you save it for a future refactor? :)

We should say:

"Gitlab has many other features, but they won't be used at this time.
 Perhaps in the future we can consider using some of them after
 further discussion."

As opposed to a sales pitch for all of the things we won't be using.
:)

-Jordan

> 
> > >  * [Optional] Built-in wiki support
> >
> > The github (and gitlab) integrated wiki's look fairly busy/crappy with
> > all the gibhub/gitlab UI around the contents.
> >
> 
> Yeah, I don't expect we'll actually use it for real things but it's there
> if we want it.  Might be useful for piglit to keep some notes or something.
> 
> 
> > >  * [Optional] Built-in CI.  With gitlab, we can provide a docker image
> > and
> > > CI tasks to run in it which can do things such as build the website, run
> > > build-tests, etc.  I'm not sure if build-testing Android is feasible but
> > we
> > > could at least build-test autotools, meson, scons, and maybe even run
> > some
> > > LLVMpipe tests.
> >
> > Why can this only be done with gitlab?
> >
> 
> It *can* be done other ways but the fd.o admins are tired of everyone
> wanting some hand-rolled solution for this that or the other thing.  With
> the gitlab CI, we provide a docker image and a script and it "just works".
> There is literally zero overhead for the fd.o admins to maintain the thing.
> 
> 
> > > Before anyone freaks out about the possible changes that may be
> > incoming, I
> > > would like to make it crystal clear that many of the above things are
> > > optional.
> >
> > Yeah, this doesn't feel like a steamroller at all.
> >
> 
> I'm really not trying to steamroller. :-(  Like I said below, we don't need
> to use any of those optional features and we'll turn them off initially so
> that it's not even possible to make a PR or file an issue and the wiki
> won't even exist.  Once you add your key and change your push URL, you
> won't even notice that it's hosted on gitlab.
> 
> 
> > -Jordan
> >
> > > We can continue to use Bugzilla for issue tracking and the
> > > mailing list for patch review.  Both cgit and annongit will continue to
> > > work for the foreseeable future.  The new fancy features such as merge
> > > requests will all be disabled initially and we can consider enabling and
> > > using those features on a case-by-case basis.  The only immediate change
> > > will be that pushes will have to happen to gitlab instead of git.fd.o.
> > No
> > > one is trying to change your workflow, they're just trying to move our
> > git
> > > hosting to a different platform.
> > >
> > > One of the motivations for doing this now is that there has been some
> > > desire to move the mesa website away from raw HTML and over to a platform
> > > such as sphinx.  If we're going to do that, we need a system for building
> > > the website whenever someone pushes to mesa.  The solution that the fd.o
> > > admins would like us to use for that is the docker-based gitlab CI.
> > Laura
> > > has been working on this the last couple of weeks and the results are
> > > pretty nice looking so far.  You can check out a preview here:
> > > https://mesa-test.freedesktop.org/intro.html  Using sphinx gives us all
> > > sorts of neat things like nice text formatting, syntax highlighting, and
> > > autogenerated searchable navigation. Right now, it's still using one of
> > the
> > > standard sphinx themes so it looks a bit "default" but that's something
> > we
> > > can change.
> > >
> > > Making this transition happen will, obviously, require a small amount of
> > > involvement from the mesa development community.  In particular, you'll
> > all
> > > need to get your SSH keys set up through gitlab.  Here's what you need to
> > > do; it should take less than 5 minutes:
> > >
> > >  1. Go to gitlab.freedesktop.org
> > >  2. Click "Sign In / Register" in the upper left-hand corner
> > >  3. You already have an account.  Click "Forgot your password?", type in
> > > your fd.o-associated e-mail, and click "Reset Password".  Follow the
> > > directions in the e-mail.
> > >  4. Once you've successfully signed in, click on the little circle in the
> > > upper right-hand corner and select "Settings"
> > >  5. Click "SSH Keys" in the bar on the left and add your keys
> > >
> > > Assuming no one explodes too badly, we'll do the actual migration soon.
> > > Ideally, I'd like to not drag this out for more than a couple of weeks.
> > > When the actual migration happens, the only change mesa devs will have to
> > > make when this happens is to change the git remote they use for pushing
> > to
> > > point to gitlab.
> > >
> > > Thanks for your cooperation (was that premature?),
> > >
> > > --Jason
> > >
> > >
> > > _______________________________________________
> > > mesa-dev mailing list
> > > mesa-dev at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >