-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving away from GitHub #22
Comments
I agree with all of your points, but you do have to consider the primary disadvantage of Gitlab having a much smaller user base. The good, and perhaps also bad, thing about Github is its ubiquity, which results in many users being able to find your project and contribute to it. But if you're ok with the decreased visibility, then I'd say go for it. Edit: Perhaps the project could be primarily developed on Gitlab while also being mirrored on Github. |
Needs more discussion, folks. Speak up. |
Lets stay on Github until atleast one stable release is made. After that, the project might be "mature" enough to move on GitLab ... but now, we'll need as much contribution as possible |
I'm not sure we do need a ton of contributions. We've already got enough consistent contributors to build an i3 clone in a fairly short amount of time. |
I've found that most of the time, even projects with lots of contributors and exposure will be written almost entirely by one or two people. |
Gitlab sounds great, but I'm a little confused; is Gitlab self hosted or only on the web? |
It's both. There's a public gitlab running on gitlab.com, but the code is open source and you can deploy it on your own infrastructure if you want. We'd be using gitlab.com. |
I'd say go for it 👍 |
Because its an alternative to Github, I guess they've added migration options. |
Eh, for now let's just stay here. |
Maybe it's time to reconsider the move given that Microsoft is about to acquire Github? |
Yeah, it's time to reconsider this. I support a move to GitLab, even if Microsoft isn't buying them out. But I'd probably wait a while to make sure GitLab has sorted out any infrastructure issues that arise. |
This comment has been minimized.
This comment has been minimized.
I'll give my 2ct here, mainly as I'm personally indifferent to github. I have been until now and will be for now. I think it's one of the more fleshed out platforms, but I dislike how it centralises everything at a single company. Afaik the long term infrastructure for sway and related projects is sr.ht, which makes the current situation a bit more complicated. On the other hand, moving to gitlab at this point will probably require another move during the next couple of years, once sr.ht is at the point where it's suitable for sway. I propose to continue as before, long term plan to migrate but don't do anything rash. |
This comment has been minimized.
This comment has been minimized.
As a contributor who probably wouldn't have started contributing if the project was using Yeah, the plan is to eventually migrate to sr.ht - but it's not ready yet. In any case, I don't think we should rush into migrating right now. As @Ongy, I don't want to migrate to anything if it's to migrate again after that. |
This comment has been minimized.
This comment has been minimized.
This is a discussion for the sway team, and has no bearing on end users. The opinions of those who don't have some stake in sway/wlroots aren't helpful at all. |
The plan is to move sway and wlroots to sr.ht - this has been the plan for longer than there have been talks of Microsoft buying GitHub. However, in light of the recent news, I intend to speed up work on sr.ht so that people leaving GitHub have another choice. To this end, I want to work on bringing sway+wlroots over sooner rather than later. I know that it's not ready yet and that it would be disruptive to the project to move now. Can I get some feedback from core contributors on what you think sr.ht needs before it's suitable for sway+wlroots? If you don't already have an account please reach out and ask for one. The biggest one is obviously public code review tools, ideally which don't require git-send-email to use. |
Another proposal is to move to FreeDesktop.Org's GitLab instance, alongside the rest of the FDO projects. A blocker for this is proper builds.sr.ht integration in GitLab (not possible right now because of GitLab MR limitations). |
I've been working on a small project to overcome the GitLab API limitations: https://git.sr.ht/~emersion/dalligi It allows exposing builds.sr.ht as a GitLab runner. This should bridge the gap. It doesn't yet support multiple build manifests, nor does it mirror build logs. But that's planned. |
Dunno what this project is but maybe you guys should consider |
Strongly considering moving this project to Gitlab. Leave your opinions here. Advantages:
The text was updated successfully, but these errors were encountered: