Regarding gitlab

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Per Andersson-3
On Sun, Mar 3, 2013 at 9:29 PM, Daniel Martí <[hidden email]> wrote:

> On Sun, Mar 03, 2013 at 20:33:09 +0100, Daniel Martí wrote:
>
>> We use patched libraries because we need some fixes and improvements over
>> native one.
>
> I asked whether he tried merging those changes into their respective
> upstream repositories.
>
>> I can build a gems like `gitlab-grit` or something if it saves you a lot of
>> efforts.
>
> Would this be a valid workaround? AFAIK the gems would not conflict with
> the original ones. It wouldn't be the cleanest of the solutions, but it
> might just work (if the "merge the changes into the gems" option is not
> possible).

What are the changes that are incompatible with original upstream?

I suppose I would rather patch gitlab to use vanilla grit, if possible.


--
Per


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CABYrXSRj-82T=r70BSj1qk0wgnbYk9N35QaM5p+NYAY3auHoeg@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
(You don't need to CC me, I am already in the debian ruby lists)

On Wed, Mar 13, 2013 at 10:24:52 +0100, Per Andersson wrote:
> What are the changes that are incompatible with original upstream?

As he said, "fixes and improvements". I did ask him if he could include
them upstream, but got no reply so far. Will try again.

Anyway, the changes are on github if you want to see them.

> I suppose I would rather patch gitlab to use vanilla grit, if possible.

Patching gitlab would be too much effort on our part IMHO, which would
be replaced by a cooperative upstream. Thus why we're talking to Dmitriy
:)

I'll keep you posted.

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Per Andersson-3
In reply to this post by Cédric Boutillier
Reviving the GitLab packaging effort!

On Wed, Jan 23, 2013 at 11:22 PM, Cédric Boutillier
<[hidden email]> wrote:

> Hi,
>
> On Wed, Jan 23, 2013 at 11:40:40AM -0300, Antonio Terceiro wrote:
>
> Thanks Antonio for this cleaned Gemfile.
> I extracted from it the names of the gems, and generated a new graph
>
>   http://people.debian.org/~boutil/gitlab/gitlab_deps20130123.pdf
>
> which looks (a bit) less intimidating than the previous one.
>
> The legend is still the same:
>> > green is in Debian
>> > yellow is waiting in NEW
>> > orange is ITP
>> > purple is RFP

Could we generate a new graph and see what is missing and left to do?


Best,
Per


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CABYrXSRRP1zgd3Ar80UzhoOWqkyM4uEU=GsJ1GWc_ADdboizuw@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Per Andersson-3
In reply to this post by Daniel Martí-2
On Wed, Mar 13, 2013 at 11:15 AM, Daniel Martí <[hidden email]> wrote:

> (You don't need to CC me, I am already in the debian ruby lists)
>
> On Wed, Mar 13, 2013 at 10:24:52 +0100, Per Andersson wrote:
>> What are the changes that are incompatible with original upstream?
>
> As he said, "fixes and improvements". I did ask him if he could include
> them upstream, but got no reply so far. Will try again.
>
> Anyway, the changes are on github if you want to see them.
>
>> I suppose I would rather patch gitlab to use vanilla grit, if possible.
>
> Patching gitlab would be too much effort on our part IMHO, which would
> be replaced by a cooperative upstream. Thus why we're talking to Dmitriy
> :)
>
> I'll keep you posted.

Any update on this?


Best,
Per


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CABYrXSRCtWk+Jkfxv0oeHwTFoXJX28yQzBVTBtnSOq-u-NAv2A@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
In reply to this post by Per Andersson-3
It's not dead :)

I'll be requesting sponsorship for ruby-stamp soon, one of the deps.

On Sun, Jun 09, 2013 at 18:13:28 +0200, Per Andersson wrote:
> Could we generate a new graph and see what is missing and left to do?

+1! There's lots to do. Certainly help would be welcome.

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
In reply to this post by Per Andersson-3
We didn't come to much of an agreement, but there has been some
progress:

> # Extracting information from a git repository
> # Provide access to Gitlab::Git library
> gem 'gitlab_git', '~> 1.3.0'

> # Ruby/Rack Git Smart-HTTP Server Handler
> gem 'gitlab-grack', '~> 1.0.0', require: 'grack'

> # LDAP Auth
> gem 'gitlab_omniauth-ldap', '1.0.2', require: "omniauth-ldap"

> # Syntax highlighter
> gem "gitlab-pygments.rb", '~> 0.3.2', require: 'pygments.rb'

> # Git Wiki
> gem "gitlab-gollum-lib", "~> 1.0.0", require: 'gollum-lib'

> gem "raphael-rails",    git: "https://github.com/gitlabhq/raphael-rails.git"

These are the only patched dependencies left. They told me they would
create separate ruby gems for all of them, so that we would be able to
package them separately from the original gems (i.e. having ruby-grack
and then gitlab-ruby-grack). raphael-rails hasn't had such conversion
yet, it seems.

Would that situation suffice? I've just written the team another mail,
asking how difficult would it be to use the original libs (adapting
gitlab to them), seeing how gitlab has changed so much as of late.

On Sun, Jun 09, 2013 at 18:14:32 +0200, Per Andersson wrote:

> On Wed, Mar 13, 2013 at 11:15 AM, Daniel Martí <[hidden email]> wrote:
> > (You don't need to CC me, I am already in the debian ruby lists)
> >
> > On Wed, Mar 13, 2013 at 10:24:52 +0100, Per Andersson wrote:
> >> What are the changes that are incompatible with original upstream?
> >
> > As he said, "fixes and improvements". I did ask him if he could include
> > them upstream, but got no reply so far. Will try again.
> >
> > Anyway, the changes are on github if you want to see them.
> >
> >> I suppose I would rather patch gitlab to use vanilla grit, if possible.
> >
> > Patching gitlab would be too much effort on our part IMHO, which would
> > be replaced by a cooperative upstream. Thus why we're talking to Dmitriy
> > :)
> >
> > I'll keep you posted.
>
> Any update on this?
>
> Best,
> Per
--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Ondřej Surý-4
AFAIRemember I have packaged most (if not all) the gems with gitlab patches under standard package names.

I did review gitlab patches and they are not much intrusive, so this should work as is.

I would very much like to avoid to do the double packaging just for few lines of patched code.

Ondřej Surý

On 9. 6. 2013, at 18:32, Daniel Martí <[hidden email]> wrote:

> We didn't come to much of an agreement, but there has been some
> progress:
>
>> # Extracting information from a git repository
>> # Provide access to Gitlab::Git library
>> gem 'gitlab_git', '~> 1.3.0'
>
>> # Ruby/Rack Git Smart-HTTP Server Handler
>> gem 'gitlab-grack', '~> 1.0.0', require: 'grack'
>
>> # LDAP Auth
>> gem 'gitlab_omniauth-ldap', '1.0.2', require: "omniauth-ldap"
>
>> # Syntax highlighter
>> gem "gitlab-pygments.rb", '~> 0.3.2', require: 'pygments.rb'
>
>> # Git Wiki
>> gem "gitlab-gollum-lib", "~> 1.0.0", require: 'gollum-lib'
>
>> gem "raphael-rails",    git: "https://github.com/gitlabhq/raphael-rails.git"
>
> These are the only patched dependencies left. They told me they would
> create separate ruby gems for all of them, so that we would be able to
> package them separately from the original gems (i.e. having ruby-grack
> and then gitlab-ruby-grack). raphael-rails hasn't had such conversion
> yet, it seems.
>
> Would that situation suffice? I've just written the team another mail,
> asking how difficult would it be to use the original libs (adapting
> gitlab to them), seeing how gitlab has changed so much as of late.
>
> On Sun, Jun 09, 2013 at 18:14:32 +0200, Per Andersson wrote:
>> On Wed, Mar 13, 2013 at 11:15 AM, Daniel Martí <[hidden email]> wrote:
>>> (You don't need to CC me, I am already in the debian ruby lists)
>>>
>>> On Wed, Mar 13, 2013 at 10:24:52 +0100, Per Andersson wrote:
>>>> What are the changes that are incompatible with original upstream?
>>>
>>> As he said, "fixes and improvements". I did ask him if he could include
>>> them upstream, but got no reply so far. Will try again.
>>>
>>> Anyway, the changes are on github if you want to see them.
>>>
>>>> I suppose I would rather patch gitlab to use vanilla grit, if possible.
>>>
>>> Patching gitlab would be too much effort on our part IMHO, which would
>>> be replaced by a cooperative upstream. Thus why we're talking to Dmitriy
>>> :)
>>>
>>> I'll keep you posted.
>>
>> Any update on this?
>>
>> Best,
>> Per
>
> --
> Daniel Martí - [hidden email] - GPG 0x58BF72C3


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/74761BE4-1383-494E-B683-05F1096E50A3@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
Fair enough, thanks for the info.

So I suppose we'll be patching gitlab to use the original libs, were the
changes to these libs important for gitlab's functionality?

On Sun, Jun 09, 2013 at 18:48:20 +0200, Ondřej Surý wrote:
> AFAIRemember I have packaged most (if not all) the gems with gitlab patches under standard package names.
>
> I did review gitlab patches and they are not much intrusive, so this should work as is.
>
> I would very much like to avoid to do the double packaging just for few lines of patched code.
>
> Ondřej Surý

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Ondřej Surý-4
On Sun, Jun 9, 2013 at 6:52 PM, Daniel Martí <[hidden email]> wrote:
Fair enough, thanks for the info.

So I suppose we'll be patching gitlab to use the original libs, were the
changes to these libs important for gitlab's functionality?

Honestly I don't remember. But I think it would be far easier to use patched versions if they don't break compatibility with vanilla versions. It wouldn't be the first nor the last time we would do this in Debian.
 
Ondrej
--
Ondřej Surý <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Cédric Boutillier
In reply to this post by Per Andersson-3
On Sun, Jun 09, 2013 at 06:13:28PM +0200, Per Andersson wrote:
> Reviving the GitLab packaging effort!

> Could we generate a new graph and see what is missing and left to do?

I've just generated a new graph this afternoon. It is now available from:
http://people.debian.org/~boutil/gitlab/gitlab_deps20130609.pdf

Cheers,

Cédric

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Per Andersson-3
On Sun, Jun 9, 2013 at 7:15 PM, Cédric Boutillier
<[hidden email]> wrote:
> On Sun, Jun 09, 2013 at 06:13:28PM +0200, Per Andersson wrote:
>> Reviving the GitLab packaging effort!
>
>> Could we generate a new graph and see what is missing and left to do?
>
> I've just generated a new graph this afternoon. It is now available from:
> http://people.debian.org/~boutil/gitlab/gitlab_deps20130609.pdf

Neat!

I uploaded github-markup and dependencies, they are currently in NEW.

Working on ruby-foreman now, will push in a few days.


Regarding gitlab-pygments.rb, I have already uploaded ruby-pygments.rb
which is also in NEW. When it is uploaded we can switch upstream to
gitlab-pygments.rb and see if that works.


--
Per


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CABYrXSRp+y5XL6c79aexcth5AsRK-ed9vE1+gA01KTP1mLOp-w@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Per Andersson-3
On Sun, Jun 9, 2013 at 9:12 PM, Per Andersson <[hidden email]> wrote:

> On Sun, Jun 9, 2013 at 7:15 PM, Cédric Boutillier
> <[hidden email]> wrote:
>> On Sun, Jun 09, 2013 at 06:13:28PM +0200, Per Andersson wrote:
>>> Reviving the GitLab packaging effort!
>>
>>> Could we generate a new graph and see what is missing and left to do?
>>
>> I've just generated a new graph this afternoon. It is now available from:
>> http://people.debian.org/~boutil/gitlab/gitlab_deps20130609.pdf
>
> Neat!
>
> I uploaded github-markup and dependencies, they are currently in NEW.
>
> Working on ruby-foreman now, will push in a few days.

Pushed and uploaded.


> Regarding gitlab-pygments.rb, I have already uploaded ruby-pygments.rb
> which is also in NEW. When it is uploaded we can switch upstream to
> gitlab-pygments.rb and see if that works.

Related upstream discussion

    https://github.com/gitlabhq/pygments.rb/commit/d946a6067cbf9dd1be74e5d2ffcba1d8ef7f6c45


I also found that the rubygem gemoji is "Copyright All Rights Reserved" and
hence not free software.

    https://github.com/github/gemoji/blob/master/LICENSE

This means that we have options

1. Just don't use gemoji with gitlab in Debian,
2. distribute ruby-gemoji in non-free, which means that gitlab must be
in contrib,
   (since it depends on non-free software but is free itself), or
3. repackage gemoji to exclude the non-free images, maybe replacing them with
   free ones,
4. something entirely else. Hack gitlab to output Unicode-characters instead?


--
Per


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CABYrXSQeMu85BfqtVv2eVh+notq9pa8o2Bd0nDo5_XPrLgpu8A@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Per Andersson-3
In reply to this post by Daniel Martí-2
On Sun, Jun 9, 2013 at 6:32 PM, Daniel Martí <[hidden email]> wrote:

> We didn't come to much of an agreement, but there has been some
> progress:
>
>> # Extracting information from a git repository
>> # Provide access to Gitlab::Git library
>> gem 'gitlab_git', '~> 1.3.0'
>
>> # Ruby/Rack Git Smart-HTTP Server Handler
>> gem 'gitlab-grack', '~> 1.0.0', require: 'grack'
>
>> # LDAP Auth
>> gem 'gitlab_omniauth-ldap', '1.0.2', require: "omniauth-ldap"
>
>> # Syntax highlighter
>> gem "gitlab-pygments.rb", '~> 0.3.2', require: 'pygments.rb'
>
>> # Git Wiki
>> gem "gitlab-gollum-lib", "~> 1.0.0", require: 'gollum-lib'
>
>> gem "raphael-rails",    git: "https://github.com/gitlabhq/raphael-rails.git"
>
> These are the only patched dependencies left. They told me they would
> create separate ruby gems for all of them, so that we would be able to
> package them separately from the original gems (i.e. having ruby-grack
> and then gitlab-ruby-grack). raphael-rails hasn't had such conversion
> yet, it seems.
>
> Would that situation suffice? I've just written the team another mail,
> asking how difficult would it be to use the original libs (adapting
> gitlab to them), seeing how gitlab has changed so much as of late.

The changes I have seen doesn't justify yet another package.

For pygments.rb the only interesting change is one patch to add the
GitLab formatter. I have asked gitlab upstream why they just don't pull
request the original upstream but haven't got any answer yet. There is
also a change for changing the python shebang to from python to
python2, but we don't want that.


--
Per


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CABYrXSRthpJR+cK3Ba5RdzLW2oQJtefN_d5sWEGbJfLf4w46Kw@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Ondřej Surý-4
In reply to this post by Per Andersson-3
On Tue, Jun 11, 2013 at 11:45 AM, Per Andersson <[hidden email]> wrote:
I also found that the rubygem gemoji is "Copyright All Rights Reserved" and
hence not free software.

    https://github.com/github/gemoji/blob/master/LICENSE

This means that we have options

1. Just don't use gemoji with gitlab in Debian,

This should be fairly easy, we could patch-out this code in markdown.rb:

    # Private: Checks if an emoji icon exists in the image asset directory                                                                                                                            
    #                                                                                                                                                                                                 
    # emoji - Identifier of the emoji as a string (e.g., "+1", "heart")                                                                                                                               
    #                                                                                                                                                                                                 
    # Returns boolean                                                                                                                                                                                 
    def valid_emoji?(emoji)
      Emoji.names.include? emoji
    end
 
2. distribute ruby-gemoji in non-free, which means that gitlab must be
in contrib,
   (since it depends on non-free software but is free itself), or

No, it's already too complicated.
 
3. repackage gemoji to exclude the non-free images, maybe replacing them with
   free ones,

That's nice pet project nobody would have time to do :)

4. something entirely else. Hack gitlab to output Unicode-characters instead?

This might be doable by replacing:

    def parse_emoji(text)
      # parse emoji                                                                                                                                                                                   
      text.gsub!(EMOJI_PATTERN) do |match|
        if valid_emoji?($2)
          image_tag(url_to_image("emoji/#{$2}.png"), class: 'emoji', title: $1, alt: $1, size: "20x20")
        else
          match
        end
      end
    end

with the code which would use unicode characters where it make sense and the unicode character exists (http://www.emoji-cheat-sheet.com/) instead of using emoji.

O.
--
Ondřej Surý <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
Thank you for the detailed options, Ondřej. I'd go for #4 and, if it's
too difficult to implement, fall back to #1.

Cédric, could you please generate another graph?

Regards.

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Cédric Boutillier
Hi,

On Sun, Jun 23, 2013 at 01:59:22PM +0200, Daniel Martí wrote:

> Cédric, could you please generate another graph?

I set up a cron job to generate the dependency graph daily.
(some may be missing because of network failure, like thoose since
June 16). You can find them at
http://people.debian.org/~boutil/gitlab/

(the one for today, should appear there in a dozen of minutes, if
everything goes fine).

They are still based on the Gemfile cleaned by Antonio some months ago.
If needed, provide me an update Gemfile (or tell me what to change), and
I'll give it to the script.

Cheers,

Cédric

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Regarding gitlab

axil
In reply to this post by Per Andersson-3
Hello team! Hope my reply will reach the correct thread...

My name is Axilleas Pipinellis, a student from Greece currently involved
in a GSoC project and that is to package GitLab for Fedora[0].

I just found out you are making efforts to accomplish the same thing for
Debian, so I would like to share what I have done so far and if possible
to coordinate our efforts for a better upstream support.

I will try to split it into sections.

== Forked gems

The only big stopper for now is the forked gems, as you already know.
 From what I got by your discussion is that you are going to patch the
upstream gems with GitLab's forks. May I ask in what stage this process
is by now?

In Fedora there are some guidelines that state that "packaging forks is
fine as long as they are parallel installable and don't interfere with
each other." which unfortunately isn't the case with GitLab. So either I
will ask for a

See a discussion about it in Fedora infra ML [1].

I also compiled a list of the forked gems and their differences of
upstream [2], it may be of help.


== What version of GitLab do you plan to support

Given that a new one comes out every month and some gems may be added or
updated, there should be an ongoing process of packaging if we want to
have the latest version.

Also, how do you plan to package GitLab itself? I mean how are you going
to follow the FHS?


== Version mismatch

This is also one big problem we have to encounter. There is the upstream
version, the one GitLab uses (may be pinned to an older one), and then
there is the distro's version.

In Fedora we try to package the latest version but in the case of GitLab
that is not always the case [3].

Here [4] is a table of all these versions specifically compared to
Fedora (I compare with the devel repo named Rawhide). I compiled this
list by using this hacky method [5]. If that would be easy for you to
traverse the gems, I saved them in json format, see my github repo [6].

What are your plans on this matter?


== Testing GitLab with packaged gems

How are you going to do this? I was thinking to remove one gem from the
Gemfile at a time and use the one I packaged instead and test if that
works. But that would require a lot of testing and time to do.

Or what my mentor suggested, maybe use "bundle install --local" which
prefers local gems instead of remote and also check on bundler_ext[7],
which tries to workaround some bundler issues with rpm/deb packages.


== Getting close to GitLab devs

There is a campfire chat channel for GitLab contributors, maybe one of
you could request an invite as a representative. That way we could talk
on the fly and you could ask questions to devs directly.


That's all that comes to mind right now, if I think of something else
I'll let you know :) Hope we can work on this somehow.

------------------------------

[0]
https://fedoraproject.org/wiki/GSOC_2013/Student_Application_Axilleas/Gitlab%28463%29
[1]
https://lists.fedoraproject.org/pipermail/infrastructure/2013-July/013203.html
[2]
https://github.com/axilleas/gsoc/blob/master/packaging.md#gem-packaging-on-gitlab-forks
[3] https://gemnasium.com/gitlabhq/gitlabhq
[4] https://fedoraproject.org/wiki/User:Axilleas/GitLab#Packages
[5]
http://axilleas.me/en/blog/2013/gsoc-weekly-update-1/#list-of-gems-to-package
[6] https://github.com/axilleas/gsoc
[7] https://github.com/bundlerext/bundler_ext


--
FAS : axilleas
GPG : 0xABF99BE5
Blog: http://axilleas.me


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/5211E187.5040409@...

Reply | Threaded
Open this post in threaded view
|

Re: Re: Regarding gitlab

Daniel Martí-2
Hello Axilleas,

On Mon, Aug 19, 2013 at 12:12:39 +0300, Axilleas Pipinellis wrote:
> Hello team! Hope my reply will reach the correct thread...

It did :)

> My name is Axilleas Pipinellis, a student from Greece currently
> involved in a GSoC project and that is to package GitLab for
> Fedora[0].
>
> I just found out you are making efforts to accomplish the same thing
> for Debian, so I would like to share what I have done so far and if
> possible to coordinate our efforts for a better upstream support.

Sure! Thank you for getting in touch with us.

> == Forked gems
>
> The only big stopper for now is the forked gems, as you already
> know. From what I got by your discussion is that you are going to
> patch the upstream gems with GitLab's forks. May I ask in what stage
> this process is by now?

As far as I know we're still busy packaging all the other gems. You can
have a look at updated graphs here:

http://people.debian.org/~boutil/gitlab/

Last one is broken, but this one is accurate:
http://people.debian.org/~boutil/gitlab/gitlab_deps20130821.pdf

> In Fedora there are some guidelines that state that "packaging forks
> is fine as long as they are parallel installable and don't interfere
> with each other." which unfortunately isn't the case with GitLab. So
> either I will ask for a
>
> See a discussion about it in Fedora infra ML [1].

Yeah, our approach is quite similar. We cannot package their gems
separately, so we thought that as long as the changes do not differ too
much from their original counterparts, we could package them as a
replacement.

> I also compiled a list of the forked gems and their differences of
> upstream [2], it may be of help.

Thank you, much appreciated!

> == What version of GitLab do you plan to support
>
> Given that a new one comes out every month and some gems may be
> added or updated, there should be an ongoing process of packaging if
> we want to have the latest version.

I suppose we could focus on a stable release for the first package, and
then work from that. If we are to change our objective every time a new
release is out with new or different dependencies, we might not make it
in some time.

> Also, how do you plan to package GitLab itself? I mean how are you
> going to follow the FHS?

As far as I know all packages must, or at least should, follow it. So
yes, that's what we'll do.

> == Version mismatch
>
> This is also one big problem we have to encounter. There is the
> upstream version, the one GitLab uses (may be pinned to an older
> one), and then there is the distro's version.
>
> In Fedora we try to package the latest version but in the case of
> GitLab that is not always the case [3].
>
> Here [4] is a table of all these versions specifically compared to
> Fedora (I compare with the devel repo named Rawhide). I compiled
> this list by using this hacky method [5]. If that would be easy for
> you to traverse the gems, I saved them in json format, see my github
> repo [6].
>
> What are your plans on this matter?
I don't think there's any easy solution to this. Obviously what would be
best is for upstream to keep his software up to date with the stable
releases of its dependencies, but perhaps they cannot do so without some
lag. Have you asked him about it?

Another thing that comes to mind is that, if gitlab was to require
versions of ruby lib X no newer than Y, that would mean that gitlab
would be locking several packages from being updated. And that would not
be good at all. In the simplest case, because another package might need
newer versions.

> == Testing GitLab with packaged gems
>
> How are you going to do this? I was thinking to remove one gem from
> the Gemfile at a time and use the one I packaged instead and test if
> that works. But that would require a lot of testing and time to do.

Indeed it would. If you were confident enough you could replace them all
at once and list bugs/errors as you found them, which could take less
time if most of it was to work out of the box but could also be a
nightmare if there are many issues to fix.

> Or what my mentor suggested, maybe use "bundle install --local"
> which prefers local gems instead of remote and also check on
> bundler_ext[7], which tries to workaround some bundler issues with
> rpm/deb packages.

Sounds like a better idea. This would also concern replacing the gems by
packaged libraries progressively, correct?

> == Getting close to GitLab devs
>
> There is a campfire chat channel for GitLab contributors, maybe one
> of you could request an invite as a representative. That way we
> could talk on the fly and you could ask questions to devs directly.

Sorry, what's a campfire chat channel?

If they offered an official/developer IRC channel I'd join, but I
haven't seen any yet.

> That's all that comes to mind right now, if I think of something
> else I'll let you know :) Hope we can work on this somehow.

Again, thanks for getting in touch. Packaging gitlab will be easier if
we can talk to each other and share our work.

Regards.

--
Daniel Martí - [hidden email] - GPG 0x4348041C

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

axil
First of all I subscribed to this list, so no need to cc me :)

On 08/23/2013 04:51 PM, Daniel Martí wrote:

> Hello Axilleas,
>
>> In Fedora there are some guidelines that state that "packaging forks
>> is fine as long as they are parallel installable and don't interfere
>> with each other." which unfortunately isn't the case with GitLab. So
>> either I will ask for a
>>
>> See a discussion about it in Fedora infra ML [1].
>
> Yeah, our approach is quite similar. We cannot package their gems
> separately, so we thought that as long as the changes do not differ too
> much from their original counterparts, we could package them as a
> replacement.
>

Oops, seems I didn't complete my sentence above. I meant that I will
either ask for an exception and if accepted I will package the forks as
are, or patch the original ones. For now and for testing purposes, I
have packaged the forks and I will continue with them.

>
>> == Version mismatch
>>
>> This is also one big problem we have to encounter. There is the
>> upstream version, the one GitLab uses (may be pinned to an older
>> one), and then there is the distro's version.
>>
>> In Fedora we try to package the latest version but in the case of
>> GitLab that is not always the case [3].
>>
>> Here [4] is a table of all these versions specifically compared to
>> Fedora (I compare with the devel repo named Rawhide). I compiled
>> this list by using this hacky method [5]. If that would be easy for
>> you to traverse the gems, I saved them in json format, see my github
>> repo [6].
>>
>> What are your plans on this matter?
>
> I don't think there's any easy solution to this. Obviously what would be
> best is for upstream to keep his software up to date with the stable
> releases of its dependencies, but perhaps they cannot do so without some
> lag. Have you asked him about it?
>
> Another thing that comes to mind is that, if gitlab was to require
> versions of ruby lib X no newer than Y, that would mean that gitlab
> would be locking several packages from being updated. And that would not
> be good at all. In the simplest case, because another package might need
> newer versions.
>

I updated the wiki table with a column that shows if GitLab == Upstream
[0]. Some gems GitLab is using are quite old compared to their upstream
and that might mean breakage if updated, so that needs also testing. I
will compile a list of gems that could be updated without implications
(eg, those whose difference is the minor version). Then by updating the
Gemfile we could run the test suite to see if something breaks.

>> == Testing GitLab with packaged gems
>>
>> How are you going to do this? I was thinking to remove one gem from
>> the Gemfile at a time and use the one I packaged instead and test if
>> that works. But that would require a lot of testing and time to do.
>
> Indeed it would. If you were confident enough you could replace them all
> at once and list bugs/errors as you found them, which could take less
> time if most of it was to work out of the box but could also be a
> nightmare if there are many issues to fix.
>

That would be a good case, but first I should try to update as many gems
as possible to their latest upstream in order to eliminate possible
incompatibility issues. See above.

>> Or what my mentor suggested, maybe use "bundle install --local"
>> which prefers local gems instead of remote and also check on
>> bundler_ext[7], which tries to workaround some bundler issues with
>> rpm/deb packages.
>
> Sounds like a better idea. This would also concern replacing the gems by
> packaged libraries progressively, correct?
>

Yes, replace the gems in Gemfile progressively. I'll start working on
this tomorrow and let you know how that goes.

>> == Getting close to GitLab devs
>>
>> There is a campfire chat channel for GitLab contributors, maybe one
>> of you could request an invite as a representative. That way we
>> could talk on the fly and you could ask questions to devs directly.
>
> Sorry, what's a campfire chat channel?
>
> If they offered an official/developer IRC channel I'd join, but I
> haven't seen any yet.

Sorry I didn't explain. campfire [1] is a chat room and they have set up
one for the contributors. I don't know any other official means of
communication, there is the #gitlab on freenode but that is unofficial
and you won't find any dev lurking there.

[0] https://fedoraproject.org/wiki/User:Axilleas/GitLab#Runtime_gems
[1] https://campfirenow.com/


--
FAS : axilleas
GPG : 0xABF99BE5
Blog: http://axilleas.me


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/521BC6EC.1030802@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

axil
Just letting you guys know that real public repositories will be
supported shortly. In fact this feature comes with 6.2 on October 22 :)

https://github.com/gitlabhq/gitlabhq/commit/f1fd47875c19bf4bd9b5bbd2975f99209f1c282e

http://feedback.gitlab.com/forums/176466-general/suggestions/3159951-allow-public-repositories

--
FAS : axilleas
GPG : 0xABF99BE5
Blog: http://axilleas.me


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/5243D8F6.3050202@...

123