[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GitLab packaging



Dear Cédric,

On Wed, Mar 26, 2014 at 3:38 PM, Cédric Boutillier
<cedric.boutillier@upmc.fr> wrote:
> Dear Sytse,
>
>
> On Tue, Mar 25, 2014 at 04:57:38PM +0100, Sytse Sijbrandij wrote:
>> Dear people,
>
>> I'm the CEO of GitLab.com and would like to offer our help to package it.
>
>> I read the conversation about packaging GitLab for Debian in:
>> Current status https://lists.debian.org/debian-ruby/2014/03/msg00027.html
>> Stepping down https://lists.debian.org/debian-ruby/2014/03/msg00030.html
>> Emoji https://lists.debian.org/debian-ruby/2014/03/msg00053.html
>> (sorry that I can't reply to these email, I just joined the list)
>
>> I wanted to let everyone know that we are really excited about this
>> packaging effort and we'll help in any way we can.
>
> Thank you very much for your message and your proposition to help. We
> are very pleased to see you interested in our packaging effort.
> Thank you also for this very nice GitLab application!
>
>> Regarding "we need to help GitLab get rid of those patches by modifing
>> GitLab or get the patches included upstream." I have two concerns:
>> 1. Some repo's are not maintained anymore by upstream, for example
>> https://github.com/mojombo/grit (and Rugged does not have all the
>> needed functionality yet).
>> 2. Most of these patches are needed, we do not fork if we can avoid it.
>
>> We hope that Debian can make some exceptions for these forks.
>
> We understand that some of the Ruby libraries are left unmaintained, and
> it is sometimes difficult to integrate changes upstream. We will do our
> best to integrate your patches into the Debian packages.
>
> Gitlab released several gitlab- versions of existing gems with some
> those changes. Often, the metadata of those gems are exactly the same as
> the original ones, (e.g. homepage). Does there exist an easy way to get
> the list of changes you applied on top of which original upstream
> version of those gems?
> Are your forks just adding functionalities, or do you expect that they
> may break other libs/programs if they're use instead of the original
> ones?
> (Apologies for not having done deeper research myself on this topic..)

We will look into this, adding the changes to the readme and updating
metadata seems doable. I'll get back to you about this.

>> There will probably also be the need to add configuration points to
>> GitLab to accommodate a different directory structure, we are open to
>> help with this.
>
> Yes, having global constants to be able to change easily the directory
> structure would be great. The main split is probably between Ruby code
> which will go in /usr/lib/ruby/vendor_ruby on Debian systems (vendordir
> in RbConfig::CONFIG) and something like /usr/share/gitlab for various
> files (artwork, and so on).

For the omnibus packages we already have a split directory structure,
see https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#directory-structure
Please let us know what else you need.

>> I think packaging a big rails app is a major undertaking and maybe we
>> can set up a mailinglist for this (similar to the Fedora list at
>> rpm-gitlab-list@lists.clefos.org).
>
> I think we can keep discussion on debian-ruby@lists.debian.org. A large
> number of packages are common to other Ruby projects, and I guess that
> discussions on Gitlab packaging will expose issues that would occur for
> the packaging of other Ruby on Rails application. Let's keep all in one
> place. I don't expect an explosion of the number of messages on this
> list.

OK, thanks, we'll keep the discussion on this mailinglist.

>> If there is any way we can get the Debian infrastructure team to test
>> GitLab while we work on packaging we think that is a win. We're sure
>> that there will be some demands for additional functionality and it
>> would be better to do this in parallel. Maybe they can use our Omnibus
>> packages https://www.gitlab.com/downloads/ to do the testing, or it
>> this out of the question?
>
> I remember having read somewhere that the Debian Sysadmins (or Alioth
> admins?) would be interested in having GitLab available. However, I am
> not sure they are ready to evaluate something on the base of those
> Omnibus packages. But I may be wrong.

Let me know if you're wrong, I hope so :-)

> There is a new version of the dependency graph for GitLab:
> http://people.debian.org/~boutil/gitlab/gitlab_deps20140326.pdf
> (green means in the Debian archive,
>  yellow is waiting to be reviewed by the FTP masters,
>  other colors mean work needed)

Cool to see there are already a lot of green gems. Are we targeting
the latest version of GitLab or a specific version?

> I will be mentoring two persons who volunteered to do some packaging
> work for GitLab for a mentoring program organised by Debian France:
>         https://wiki.debian.org/DebianFrance/NewContributorGame
> so it will provide some more manpower.

Awesome!

> We have about 7 months before the freeze of Debian Jessie. It would be
> great if we manage to finish the packaging of GitLab by then, so that
> Jessie users could just install it with apt-get.

`apt-get install gitlab` for free software made with free software, let's do it!

> Cheers,
>
> Cédric

Best regards,
Sytse


Reply to: