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 <sy...@gitlab.com> wrote: > Dear Cédric, > > On Wed, Mar 26, 2014 at 3:38 PM, Cédric Boutillier > <cedric.boutill...@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-l...@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 -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAEG31mMYPrJFGuuFN1J7HNzbjCPhkH+kr=cuicpfhjrhkf3...@mail.gmail.com
