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