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:
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.
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