Re: GitLab packaging
Hi Cédric,
For our forks we would add the changes to the readme and update the
metadata. We just updated the readme for GitLab Grit:
https://github.com/gitlabhq/grit/compare/aa09ee7131dbe8338b0a27ed1c96f74d824c8911...master
(the metadata was already up to date)
What do you think?
Best regards,
Sytse
On Wed, Mar 26, 2014 at 4:06 PM, Sytse Sijbrandij <sytse@gitlab.com> wrote:
> 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: