Dear infra team and others that this mail may concern,
As many of you know (I hope :p), one of this year's GSoC projects, is to package GitLab and all its dependencies for Fedora and later for EPEL. There have been at least 3 discussion threads about this since March [0][1][2][3].
I have been in contact with GitLab's core team and we talked about how we could all work together to make this happen and how GitLab could be eventually deployed in fedorahosted as an alternative git service. For the time being there are 2 major show-stoppers:
1) GitLab uses some forked gems.
These are the forked gems by GitLab which add some extra functionality or fix some bugs of the original gem:
Upstream | GitLab ------------------------------------- grit | gitlab-grit grack | gitlab-grack gollum-lib | gitlab-gollum-lib omniauth-ldap | gitlab_omniauth-ldap pygments.rb | gitlab-pygments.rb -------------------------------------
Vit Ondruch, my mentor, pointed me in these FESCO [4] and FPC [5] tickets, which pretty much conclude that:
"FESCo is fine with forks as long as they are parallel installable and don't interfere with each other."
and
"The FPC does not see a need for additional guidelines relating to forks at this time, they should be treated like any other package."
I also raised this issue in #fedora-devel today and they told me the same thing FESCo concluded.
I think GitLab's forks don't abide by FESCo's verdict, as both original and forked gem are called with the same library, eg. require 'grit', so there is no distinction between them.
I am cc'ing Sytse Sijbrandij from GitLab's core team to talk about what changes could be made in order for the forks to get accepted.
2) The feature of public browserability for non logged in users is not yet implemented.
This long awaited feature is the major show-stopper for getting GitLab deployed on fedorahosted. Quoting Sytse's proposal:
Of the two improvements I think that 2) is the most necessary. Without a public project UI Fedora will not switch to GitLab. There is already a public project git clone functionality in GitLab. Opening up more of the project such as issues might load to in-advert exposure of issues. Therefore we want to do it only on a major version upgrade. We started with GitLab 6.0 a week ago and would like to merge this fast so it can be included in the beta released on July 22. If Axilleas works on this then Dmitriy is prepared to coach him, this will be needed since this feature will impact the whole application.
Our proposal would be to: A) Start working on the public UI immediately B arrange a online meeting between Fedora and GitLab.com people to talk about packaging C) have beta version of GitLab run on a demo server with Fedora project on August 1 D) aim to have GitLab in production for all Fedora projects on September 1
Of course this is just a proposal. We have too little knowledge of the Fedora project to make a proper plan.
The initial plan of the GSoC proposal is to package GitLab, but since I talked about it with Sytse I thought it would be more productive to bring the discussion here and sort some things out all together.
Thank you all for your time, Axilleas
[0] https://lists.fedoraproject.org/pipermail/infrastructure/2013-March/012631.h... [1] https://lists.fedoraproject.org/pipermail/infrastructure/2013-April/012739.h... [2] https://lists.fedoraproject.org/pipermail/infrastructure/2013-April/012758.h... [3] https://lists.fedoraproject.org/pipermail/infrastructure/2013-May/012885.htm... [4] https://fedorahosted.org/fesco/ticket/810 [5] https://fedorahosted.org/fpc/ticket/148
On 03/07/13 19:57, Axilleas Pipinellis wrote:
- GitLab uses some forked gems.
These are the forked gems by GitLab which add some extra functionality or fix some bugs of the original gem:
Upstream | GitLab
grit | gitlab-grit grack | gitlab-grack gollum-lib | gitlab-gollum-lib omniauth-ldap | gitlab_omniauth-ldap pygments.rb | gitlab-pygments.rb
Vit Ondruch, my mentor, pointed me in these FESCO [4] and FPC [5] tickets, which pretty much conclude that:
"FESCo is fine with forks as long as they are parallel installable and don't interfere with each other."
and
"The FPC does not see a need for additional guidelines relating to forks at this time, they should be treated like any other package."
I also raised this issue in #fedora-devel today and they told me the same thing FESCo concluded.
I think GitLab's forks don't abide by FESCo's verdict, as both original and forked gem are called with the same library, eg. require 'grit', so there is no distinction between them.
I am cc'ing Sytse Sijbrandij from GitLab's core team to talk about what changes could be made in order for the forks to get accepted.
If upstream don't fix it themselves, couldn't you just patch gitlab-grit and gitlab so that it does "require 'gitlab-grit'" instead?
On 03/07/13 20:09, Jamie Nguyen wrote:
On 03/07/13 19:57, Axilleas Pipinellis wrote:
- GitLab uses some forked gems.
These are the forked gems by GitLab which add some extra functionality or fix some bugs of the original gem:
Upstream | GitLab
grit | gitlab-grit grack | gitlab-grack gollum-lib | gitlab-gollum-lib omniauth-ldap | gitlab_omniauth-ldap pygments.rb | gitlab-pygments.rb
Vit Ondruch, my mentor, pointed me in these FESCO [4] and FPC [5] tickets, which pretty much conclude that:
"FESCo is fine with forks as long as they are parallel installable and don't interfere with each other."
and
"The FPC does not see a need for additional guidelines relating to forks at this time, they should be treated like any other package."
I also raised this issue in #fedora-devel today and they told me the same thing FESCo concluded.
I think GitLab's forks don't abide by FESCo's verdict, as both original and forked gem are called with the same library, eg. require 'grit', so there is no distinction between them.
I am cc'ing Sytse Sijbrandij from GitLab's core team to talk about what changes could be made in order for the forks to get accepted.
If upstream don't fix it themselves, couldn't you just patch gitlab-grit and gitlab so that it does "require 'gitlab-grit'" instead?
Actually, ignore me! ;)
On Wed, Jul 03, 2013 at 09:57:23PM +0300, Axilleas Pipinellis wrote:
Dear infra team and others that this mail may concern,
As many of you know (I hope :p), one of this year's GSoC projects, is to package GitLab and all its dependencies for Fedora and later for EPEL. There have been at least 3 discussion threads about this since March [0][1][2][3].
I have been in contact with GitLab's core team and we talked about how we could all work together to make this happen and how GitLab could be eventually deployed in fedorahosted as an alternative git service. For the time being there are 2 major show-stoppers:
- GitLab uses some forked gems.
These are the forked gems by GitLab which add some extra functionality or fix some bugs of the original gem:
Upstream | GitLab
grit | gitlab-grit grack | gitlab-grack gollum-lib | gitlab-gollum-lib omniauth-ldap | gitlab_omniauth-ldap pygments.rb | gitlab-pygments.rb
Vit Ondruch, my mentor, pointed me in these FESCO [4] and FPC [5] tickets, which pretty much conclude that:
"FESCo is fine with forks as long as they are parallel installable and don't interfere with each other."
and
"The FPC does not see a need for additional guidelines relating to forks at this time, they should be treated like any other package."
I also raised this issue in #fedora-devel today and they told me the same thing FESCo concluded.
I think GitLab's forks don't abide by FESCo's verdict, as both original and forked gem are called with the same library, eg. require 'grit', so there is no distinction between them.
I am cc'ing Sytse Sijbrandij from GitLab's core team to talk about what changes could be made in order for the forks to get accepted.
You are correct. These are bundled libraries, not forks. And not just because of the same name... Forking is a bad idea unless upstreams are unable to work together. So if there's something like a bugfix that's needed, we (The Fedora Packaging Committee) would want to know why the change hasn't gone into the other package (ie: grit) as the bugfix would presumably hekp out other consumers of grit as well.
The idea is to minimize maintainance burdens long-term. if we have five separate packages which contain slightly different versions of the same code, it takes much more manpower to maintain and fix each one than if we had a single package to deal with.
just noting this to be sure people don't start abusing the concept of "forks" to mean something that FPC does not intend.
-Toshio
On 07/03/2013 10:42 PM, Toshio Kuratomi wrote:
You are correct. These are bundled libraries, not forks. And not just because of the same name... Forking is a bad idea unless upstreams are unable to work together. So if there's something like a bugfix that's needed, we (The Fedora Packaging Committee) would want to know why the change hasn't gone into the other package (ie: grit) as the bugfix would presumably hekp out other consumers of grit as well.
In the case of grit, upstream has almost 'abandoned' the project. You can see that the commit history [0]is very sparse and of the 111 issues on the issue tracker [1] more than the half of them are Pull Requests that either fix some bugs or enhance the app.
As far as I know, GitLab will switch to rugged [2], but that is not going to happen for another year as it still lacks some needed functionality. Therefore the grit fork.
[0] https://github.com/mojombo/grit/commits/master [1] https://github.com/mojombo/grit/issues [2] https://github.com/libgit2/rugged
On Thu, Jul 04, 2013 at 09:59:44AM +0300, Axilleas Pipinellis wrote:
On 07/03/2013 10:42 PM, Toshio Kuratomi wrote:
You are correct. These are bundled libraries, not forks. And not just because of the same name... Forking is a bad idea unless upstreams are unable to work together. So if there's something like a bugfix that's needed, we (The Fedora Packaging Committee) would want to know why the change hasn't gone into the other package (ie: grit) as the bugfix would presumably hekp out other consumers of grit as well.
In the case of grit, upstream has almost 'abandoned' the project. You can see that the commit history [0]is very sparse and of the 111 issues on the issue tracker [1] more than the half of them are Pull Requests that either fix some bugs or enhance the app.
As far as I know, GitLab will switch to rugged [2], but that is not going to happen for another year as it still lacks some needed functionality. Therefore the grit fork.
[0] https://github.com/mojombo/grit/commits/master [1] https://github.com/mojombo/grit/issues [2] https://github.com/libgit2/rugged
<nod> I always hate it when upstreams are active (Commits three to four months apart can be normal) but aren't dealing with bug reports with patches (ie: pull requests). OTOH, I notice that rtomayko is one of the committers, if you wanted to get code into grit we might be able to find someone who could ask him if he can grant someone else permission to merge fixes.
Anyhow, with a dead upstream and a plan to move to a different library in a definite time span it is possitble that the FPC would grant a bundled library exception for a limited time. You should be following the process outlined here: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions
-Toshio
Hi all! (Cross post of ruby-sig)
Long time no see, so I thought I dropped a line of what is achieved so far about this project. GSoC comes to an end later this month but that doesn't mean the effort is over. I will continue to work on this until it gets officially in Fedora.
I managed to deploy GitLab on a Fedora 19 machine using only installed packaged gems. Below you will find some more info as well as the url of the testing environment. Please use/test it and report any issues here [0]. If anyone needs an admin account for further testing just let me know. Just bare in mind that you might see some 500 errors as I will be trying some things :)
-------------------- OS: Fedora 19 Temp deploy: https://fedora.axilleas.me Enviromnent: using only installed packaged gems either from the official repos or my custom one [1]. Gemfile diffs: [2] and [3] Systemd services: Running without using bundler [4] --------------------
There are a lot to be done yet but that's a start.
TODO ----
*Short term - Write gitlab.spec that will glue all the dependencies together
*Long term - Commit as many specs as possible to BZ. - GitLab forks: one option is to patch upstream with GitLab's changes. second but rather avoided is to to ask FPC for an exception and package the forks as they are. - Coordinate efforts with Debian ruby team (I already contacted them) [5] - Deploy on rawhide: when GitLab supports rails 4. That depends on many dependencies gems as well.
*Longer term - port to EPEL
[0] https://github.com/axilleas/gsoc/issues [1] http://repos.fedorapeople.org/repos/axilleas/gitlab/fedora-19/ [2] https://github.com/axilleas/gsoc/blob/master/Gemfile.diff [3] https://github.com/axilleas/gsoc/blob/master/Gemfile.lock.diff [4] https://github.com/axilleas/gsoc/tree/master/systemd [5] http://debian.2.n7.nabble.com/Regarding-gitlab-td2843993.html
On Mon, 09 Sep 2013 11:28:57 +0300 Axilleas Pipinellis axilleaspi@ymail.com wrote:
Hi all! (Cross post of ruby-sig)
Long time no see, so I thought I dropped a line of what is achieved so far about this project. GSoC comes to an end later this month but that doesn't mean the effort is over. I will continue to work on this until it gets officially in Fedora.
Awesome. :)
I managed to deploy GitLab on a Fedora 19 machine using only installed packaged gems. Below you will find some more info as well as the url of the testing environment. Please use/test it and report any issues here [0]. If anyone needs an admin account for further testing just let me know. Just bare in mind that you might see some 500 errors as I will be trying some things :)
Cool.
I see there is 'public' support, but all it is is a clone url and the projects page (no commit info, etc). What was the current state of 'public' patches to it?
kevin
On 09/09/2013 08:54 PM, Kevin Fenzi wrote:
Cool.
I see there is 'public' support, but all it is is a clone url and the projects page (no commit info, etc). What was the current state of 'public' patches to it?
Currently, the only public behavior is what you saw and in order to browse the code you have to have an account... So, 'public' is public for registered users only.
As for what are their plans on making it public even for non-registered users, the issue was reported recently on their private gitlab instance (I happen to have an account there). This is something big communities want, such as Fedora or Debian where packaging efforts take place or Drupal where there has been an ongoing discussion to host their code on a gitlab instance [0].
So for now we wait. If there is a change or any info regarding this, I'll let you know asap :)
[0] https://groups.drupal.org/node/313158
On 09/10/2013 12:14 AM, Axilleas Pipinellis wrote:
On 09/09/2013 08:54 PM, Kevin Fenzi wrote:
Cool.
I see there is 'public' support, but all it is is a clone url and the projects page (no commit info, etc). What was the current state of 'public' patches to it?
Currently, the only public behavior is what you saw and in order to browse the code you have to have an account... So, 'public' is public for registered users only.
As for what are their plans on making it public even for non-registered users, the issue was reported recently on their private gitlab instance (I happen to have an account there). This is something big communities want, such as Fedora or Debian where packaging efforts take place or Drupal where there has been an ongoing discussion to host their code on a gitlab instance [0].
So for now we wait. If there is a change or any info regarding this, I'll let you know asap :)
Good news! It seems public repo access will be possible in next major version 7.0, probably some time around Christmas :)
See http://feedback.gitlab.com/forums/176466-general/suggestions/3159951-allow-p...
Seems the "pressure" from big open source organizations worked :)
On Wed, 03 Jul 2013 21:57:23 +0300 Axilleas Pipinellis axilleaspi@ymail.com wrote:
Dear infra team and others that this mail may concern,
As many of you know (I hope :p), one of this year's GSoC projects, is to package GitLab and all its dependencies for Fedora and later for EPEL. There have been at least 3 discussion threads about this since March [0][1][2][3].
Yep. ;)
I have been in contact with GitLab's core team and we talked about how we could all work together to make this happen and how GitLab could be eventually deployed in fedorahosted as an alternative git service. For the time being there are 2 major show-stoppers:
So, perhaps this was berried in one of the previous discussions, but I don't think we want to replace fedorahosted. Lets stop saying that. Any gitlab deployment I would like to see as a new service for those that would like that, folks who don't want to be bothered could just keep using fedorahosted.
So, moving forward, can we just drop any mention of fedorahosted from this discussion? Call it 'gitlab deployment' or 'gitlab instance for fedora' or something. ;) Please?
- GitLab uses some forked gems.
...snip...
I think GitLab's forks don't abide by FESCo's verdict, as both original and forked gem are called with the same library, eg. require 'grit', so there is no distinction between them.
Right. While these are forked, upstream hasn't fully forked them, they simply bundle them and make local changes. It's up to you or upstream to see if you can unbundle them.
That might include some combo of:
a) Just getting changes merged with the orig project so no bundling is needed anymore.
b) Getting upstream to finish the forking process and rename them/create releases, etc. You can then package them up.
c) Adjust gitlab to not need the changed bits, or do things in a different way.
I am cc'ing Sytse Sijbrandij from GitLab's core team to talk about what changes could be made in order for the forks to get accepted.
Great!
- The feature of public browserability for non logged in users is not
yet implemented.
This long awaited feature is the major show-stopper for getting GitLab deployed on fedorahosted. Quoting Sytse's proposal:
Of the two improvements I think that 2) is the most necessary. Without a public project UI Fedora will not switch to GitLab. There is already a public project git clone functionality in GitLab. Opening up more of the project such as issues might load to in-advert exposure of issues. Therefore we want to do it only on a major version upgrade. We started with GitLab 6.0 a week ago and would like to merge this fast so it can be included in the beta released on July 22. If Axilleas works on this then Dmitriy is prepared to coach him, this will be needed since this feature will impact the whole application.
So, would this be trying to merge functionality upstream? Or carry our own patches to handle anon stuff?
Our proposal would be to: A) Start working on the public UI immediately B arrange a online meeting between Fedora and GitLab.com people to talk about packaging C) have beta version of GitLab run on a demo server with Fedora project on August 1
We could possibly do a demo in a cloud instance depending on whats involved.
D) aim to have GitLab in production for all Fedora projects on September 1
This is...not likely. :)
a) We should not try and move all projects to it. Only folks who want to use it/opt in.
b) We have a process for bringing up a new supported service: https://fedoraproject.org/wiki/Request_For_Resources?rd=Infrastructure/RFR I'm sorry it's a bit involved and has many steps. This is to make sure we can actually support something moving forward and don't just get it dumped on us.
c) We freeze around release milestones. It's likely that Fedora 20 will be landing sometime in Aug or early Sept, so we would have to make sure not to disrupt our primary mission of producing Fedora.
Hope that helps.
kevin
On 07/03/2013 10:51 PM, Kevin Fenzi wrote:
So, perhaps this was berried in one of the previous discussions, but I don't think we want to replace fedorahosted. Lets stop saying that. Any gitlab deployment I would like to see as a new service for those that would like that, folks who don't want to be bothered could just keep using fedorahosted.
So, moving forward, can we just drop any mention of fedorahosted from this discussion? Call it 'gitlab deployment' or 'gitlab instance for fedora' or something. ;) Please?
You are right... My bad, sorry. I didn't mean to say that it will replace fedorahosted whatsoever. I pictured it being deployed under a subdomain of fedorahosted like the current gitweb. This would not change the current look and feel of fedorahosted.org. And of course that would be opt-in, noone would be compelled to change theirhabits :)
We could possibly do a demo in a cloud instance depending on whats involved.
Cool, that would be nice.
D) aim to have GitLab in production for all Fedora projects on September 1
This is...not likely. :)
a) We should not try and move all projects to it. Only folks who want to use it/opt in.
b) We have a process for bringing up a new supported service: https://fedoraproject.org/wiki/Request_For_Resources?rd=Infrastructure/RFR I'm sorry it's a bit involved and has many steps. This is to make sure we can actually support something moving forward and don't just get it dumped on us.
c) We freeze around release milestones. It's likely that Fedora 20 will be landing sometime in Aug or early Sept, so we would have to make sure not to disrupt our primary mission of producing Fedora.
Yeap, that was Sytse'sproposal without knowing much about the subject. I guess I am to blame here :p
infrastructure@lists.fedoraproject.org
-
Achilleas Pipinellis -
Jamie Nguyen -
Kevin Fenzi -
Toshio Kuratomi