Re: Regarding gitlab
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
Reply to: