GitLab packaging progress and discussion about deployment on fedorahosted

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130703/b662c54e/attachment.sig>