We’re accepting merge requests that make GitLab easier to package natively as long as they don’t complicate things.
Debian packages are live at https://launchpad.net/ubuntu/+source/gitlab/
Fedora packages issue https://gitlab.com/gitlab-org/gitlab-ce/issues/14043
Not yet Josef.
Latest development: https://launchpad.net/ubuntu/+source/gitlab/8.4.0+dfsg~rc2-4 !
Latest update from Pirate Praveen
2. After testing, I will upload to unstable.
3. I will then backport it to stable via personal repo, so people can start using in production
4. Once it moves to testing, I will upload it to official jessie (stable) backports.
5. Then I will start working on a gitlab ce instance we discussed earlier. git.fosscommunity.in I have to get you a quote for server.
6. Then last task would be setting up debian's gitlab ce instance. gitlab.debian.org
Good News! Another milestone!
I just got the apt-get installed gitlab running at gitlab.pxq.in!
It needs some testing to see how it fares, which I will do in the
Some dependencies are still in my personal repo
https://people.debian.org/~praveen/gitlab/pool/main/r/ which we need
to finish and move to debian archive.
We track progress of these tasks here
Added a link to the Debian status in the issue description https://gitlab.com/debian-ruby/TaskTracker/milestones/1
Recent Debian status in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651606
Josef, thanks for adding this idea. I edited the title and description, I hope that is OK with you. The current packages on https://about.gitlab.com/downloads/ have a different philosophy based on Omnibus. They provide a quick self contained install that doesn't affect any other installed software. Security updates and upgrades are much easier, see https://about.gitlab.com/2014/06/06/omnibus-gitlab-openssl-security-release/ People can now install GitLab in 2 minutes and it has greatly helped with its adaption. We see the appeal of native packages but this requires a lot of effort. I hope you can join in that effort.
Initial description by Josef:
Current Debian package has 190MB and unpacks into 771MB beast. It contains entire system, makes security updates impossible, and it is so wrong at so many levels...
After manual install there is 19MB of GitLab and 300MB of gems in vendor directory. About half of this gems is already available in Debian packages.
Challenge: Make 20MB GitLab deb package.
Since you will have to pack a lot of gems into deb packages (which is not as much of work as it sounds), creating a proper debian repository is neccessary prerequisite (wich also is not really hard).
Related to http://feedback.gitlab.com/forums/176466-general/suggestions/5968082-32-bit-packages and depends on http://feedback.gitlab.com/forums/176466-general/suggestions/5634188-add-a-repository-for-the-debian-ubuntu-packages.
Kamil, I like your idea to make the JUnit output a build artifact that we render.
We’re accepting merge requests after the 6 points in the comment are addressed.
This is now moved to https://gitlab.com/gitlab-org/gitlab-ce/issues/4012
We're not working on it now.
We still welcome any MRs and we're considering using Transifex after all.
We're emailing with Porus-P4 to get this implemented. We also need to be careful about performance and memory usage, see http://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby
The GitLab alternative Gogs is discussing how to handle translations in https://github.com/gogits/gogs/issues/571
Thanks for the links 123Haynes. What do other people think of us setting up a server for this?
Weblate looks very nice, what do other people think about it? Does someone have more links to the git feature they talk about?
Someone has to propose an application where we can maintain the translations. I think we need something open source and GitLab B.V. can host this application. Right now it looks like we'll go with .po/.pot files and gettext/fast_gettext.
No suggestion for that, someone should probably improve the code for that.
OneSky look pretty decent, free for public projects, what do other people think?
Ai, YAML support is a must.
GitLab B.V. would certainly be interested in hosting a solution, what do people think about Pootle and Zanata?
OneSky looks pretty solid, what do other people think?
Regarding the cheating, that is not something we'll consider, we want to work in public so there is no room for cheating.
I talked to Transifex. They were really nice and offered 6 months free in exchange for case study and blog post.
We need at least 2 years of free use so I think we need to discuss other options.
123Haynes, thanks for the input! I'm contacting Transifex to see if they mind hosting a mixed project (CE is open source, copyrighted code in EE).
123 Haynes We can evaluate the tool if we see the 'documented process to update the translations each release.'. How would that look with Transifex?
The core team is prepared to make translations happen for GitLab! There are a couple of steps to take before we can merge this:
1. We need a good app for this (see https://github.com/gitlabhq/gitlabhq/pull/6455#issuecomment-38612675 for what we tried and the problems).
2. We should have two translators in the the app for each major language (Spanish, German, French), having support for Japanese would be great.
3. There should be a merge request with green tests, see https://github.com/gitlabhq/gitlabhq/pull/6455
4. We should ensure this merge request doesn't break anything when browsing GitLab in English.
5. There should be two translation managers that want to manage the translation process for at least a year. René Klačan and Daniel Łukasiak have indicated they want to do this but more are welcome.
6. There should be a documented process to update the translations each release.
This discussion continues in https://github.com/gitlabhq/gitlabhq/pull/6455
mcfedr I think we can only do it if it was frictionless for new functional contributors, we're open to suggestions what framework to use to crowdsource translations
Is there anyone who is willing to make the translations? Is there anyone willing to change all the fixed text into translated text (there are some automated ways to do most of the work)?
Gistie looks cool and shows the direction we could go in. It is also nice that they seem to use Rugged a lot. Integrating Gistie directly into GitLab is not an option (it is not an engine, authorizations work different, the look&feel is different, etc). But we are welcoming proposals to bring more functionality to snippets in GitLab.
Please propose an implementation for this.
We’re accepting merge requests for adding two options to gitlab.yml for this: enable_git_over_ssh, enable_git_over_http
s7v7nislands there is no update, we're still accepting merge requests for this
Philipp Häfele, nobody is working on this, please submit an MR and leave a comment here linking to it.
Ben, that is why we are accepting MR's for two options, both enabled is what you want.
Title was updated, thanks for the suggestion Ben!
Ben, thank you for noticing the duplication.
We’re accepting merge requests for this.
Waiting for Rugged support, see https://gitlab.com/gitlab-org/gitlab-ce/issues/3409
So this config setting would be stored together with the email addresses for the email on push feature?
Code is ready Joe? Great! Go for it.
I'm wondering, do you want to set the wiki as the default it for all your projects or just some?
Thanks, I've added this idea to https://gitlab.com/gitlab-org/gitlab-ce/issues/2655
We’re accepting merge requests for this.
Also, add a test to prevent any new OpenStruct usage to be added while mentioning https://charlie.bz/blog/things-that-clear-rubys-method-cache
Things like style checks and bug detectors can be executed as parallel jobs in GitLab. Is that an option you can use?
In general we do not like plugins that connect deep into the source code since it makes it hard to upgrade GitLab.
We want to be able to do major changes to it (for example integrating it into GitLab itself with https://gitlab.com/gitlab-org/gitlab-ce/issues/2164 ) without breaking it.
If you need things in GitLab CI you can add them directly. If there is a use case that can only be solved with a plugin we'll consider it. But in general we prefer to add the code and the tests to GitLab CI itself so we can ensure that they do not break in the future.
I love this idea ^Sytse
Please have a look at the GitHub issue for this request: https://github.com/gitlabhq/gitlabhq/issues/4295#issuecomment-79603184
We like the idea of Edward Bopp: "I think, the first step is to allow users to create merge requests from repositories with custom URIs. This would not require a lot of work in terms of creating a protocol and dealing with spam issues, since one does not really have to deal with the “other” server except for pulling from it." and are accepting merge requests for this.
There was an extra 3 but the comment didn't get truncated.
This proposal would only be for public repo's.
I agree the fetch from the source would be slow.
Refetching periodically is not doable I agree.
Maybe we should explore a push alternative (instead of the pull we discussed above).
1. Click create PR/MR
2. Select a repo on another server (a server that you have OAuth access to)
3. Source server posts a JSON file to destination server
4. User is redirected to destination server and finishes the PR/MR
5. Source server reports the JSON file to the destination server on updates
How does that sound?
Hi Erik, thanks for your questions.
Full workflow with the simple approach would be:
0. You have an account on the destination web server
1. Go to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/new
2. In the first input field of the source branch field put in the url of a public git repo
3. Click compare branches
Mitar, for now we want to keep it simple with cross-server merge requests. A peer-to-peer GitLab with distributed hash table would be another feature request.
The git way of doing a cross-server merge request is emailing the output of request-pull
People https://twitter.com/Carols10cents/status/459753771807932416 suggested using OStatus http://status.net/wiki/OStatus for this.
Eduard, I like your idea of starting small by creating merge requests coming from repositories that are on a different GitLab server. Maybe an even smaller step is allowing you to fork projects from a different Gitlab server, but that can also be added later. Good luck with the implementation.
Personally (Sytse) I think that it would be great if this protocol worked without having to configure the servers explicitly. It might be needed to have a user account on both servers so that SPAM can be prevented.
Hi Eduard, thank you for proposing this. I've edited your suggestion to replace GitHub with GitLab Cloud to make it easier to achieve. Ideally this would depend on an open protocol that everyone including BitBucket and GitHub could adopt. We look forward to a world of federated git hosting.
What would we need to change in GitLab to do this? Can you point to the relevant documentation in other products?