waffle-gl / waffle

A C library for selecting an OpenGL API and window system at runtime
https://waffle.freedesktop.org
BSD 2-Clause "Simplified" License
35 stars 16 forks source link

Move links to point to gitlab.freedesktop.org #51

Closed gfxstrand closed 5 years ago

gfxstrand commented 5 years ago

A fork of waffle has been created on gitlab.freedesktop.org and we (mostly Intel people) would like it to become the new home of Waffle so that releases can be managed by the freedesktop community rather than by they very few people who have access to this repository. This waffle repo hasn't seen a commit in 17 months and hasn't seen a release in 3 years in spite of active development on things like modifiers support.

jljusten commented 5 years ago

I hoped to sync up with @chadversary first to confirm the plan, but since we haven't had much luck with that, I'll take ownership for this task.

evelikov commented 5 years ago

I've briefly mentioned this to Chad at XDC. He seemed OK with the idea, although a +1 on the gitlab.fd.o issue would be appreciated.

I think we want a separate group since there's more to waffle than just the source repo.

https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/82

gfxstrand commented 5 years ago

I would have like to use the GitHub -> GitLab migration feature to also pull over the wiki and issue tracker but that requires someone with fairly high-level privileges on the GitHub repo to provide the right token needed for the transfer.

I think we want a separate group since there's more to waffle than just the source repo.

What else is there that would require a separate group? Each repo in GitLab can have it's own issue tracker and wiki. Also, having it in the mesa group means mesa people can control releases which was kind-of the whole point.

evelikov commented 5 years ago

There's three repositories - website, code and arch packaging.

Sure we want releases, but we don't need 100+ people with commit access. Not yet at least. I've been meaning to roll a release or two for ages, and simplify the process in the interim.

Yet I don't have access to do so :-(

gfxstrand commented 5 years ago

There's three repositories - website, code and arch packaging.

The website can be rolled into the main repo like we do for mesa. The only reason to have it in it's own repo is due to the way GitHub does sites. On fd.o we have more options.

Sure we want releases, but we don't need 100+ people with commit access. Not yet at least.

Sure. I also don't think it'll really hurt either. That many people have access to libdrm and only a tiny subset actually commit to it.

I've been meaning to roll a release or two for ages, and simplify the process in the interim.

That's exactly the problem we want to solve. Moving it into mesa will mean that we (the mesa community) can imbue anyone with powers to make releases.

dcbaker commented 5 years ago

I just noticed that gitlab has subgroups and xorg is using them. Maybe we could put waffle in a subgroup of mesa?

jljusten commented 5 years ago

Is the main concern dealing with the separate website repo? A separate sub-group seems a bit like overkill for waffle. Piglit also has a web-page. What is the plan in that case? I also think it would be overkill for piglit to have a sub-group.

We might consider down-sizing the waffle web-site. Perhaps it could get by as a wiki in gitlab? I'm sure a re-direct could be developed for the main url.

But, if we wanted to keep hosting like it is today, perhaps we could put the website data in a branch of the waffle repo that is detached from the code branches. Github has automatic support for something like this where you just name the branch gh-pages. Maybe gitlab can do something similar.

Or, maybe you have a concern other than just the web-site?

gfxstrand commented 5 years ago

I agree with @jljusten. I think we're wasting way too much energy worrying about a tiny detail. There are a dozen different things we can do with the website.

jljusten commented 5 years ago

Ref: https://gitlab.freedesktop.org/mesa/waffle/issues/3