19:03:28 <smooge> #startmeeting gitlab discussion
19:03:28 <zodbot> Meeting started Thu Mar 20 19:03:28 2014 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:03:36 <orc_fedo> perhaps with ops it can be co-erced to do it
19:03:43 <orc_fedo> ahh
19:03:44 <smooge> #chair orc_fedo axil42
19:03:44 <zodbot> Current chairs: axil42 orc_fedo smooge
19:03:47 <orc_fedo> ty
19:03:58 <smooge> #topic roll call
19:04:09 <pingou> it just did :)
19:04:15 * pingou 
19:04:15 * orc_fedo is here
19:04:17 <smooge> please state who is here for the meeting and what you are here for
19:04:18 * jchristi is here
19:04:26 * axil42 here
19:04:31 * dhenry is here
19:04:53 * tflink is here
19:04:55 * dhenry is here for gitlab discussion
19:05:08 <jchristi> I work for an IT team within Red Hat. We are using GitLab on my team for code reviews. I am interested in RPMs for RHEL7 so that we can setup a supported instance for all of Red Hat IT org
19:05:17 * threebean is here
19:05:31 <orc_fedo> #info reference URL https://fedoraproject.org/wiki/User:Axilleas/GitLab
19:05:37 <dhenry> same as jchristi
19:06:18 <smooge> since axil42 is the caller of this meeting I will turn over the chair to him. use #topic to change topic
19:06:26 <orc_fedo> my desire for moving to gitlab is to get away from the unacceptible github indemnification clause
19:06:46 <axil42> ok not too familiar with zodbot's commands but anyway :)
19:07:08 <axil42> so
19:07:12 * ausmarton is here
19:07:34 <jchristi> orc_fedo: "unacceptible github indemnification clause" ? elaborate?
19:08:00 <orc_fedo> jchristi: lemme get their TOS URL
19:08:25 <orc_fedo> I have spoken w their support on this, this week, again, but they have bigger issues internally ;)
19:09:39 <orc_fedo> #link https://help.github.com/articles/github-terms-of-service at F3
19:09:56 <orc_fedo> flood coming
19:09:59 <orc_fedo> You shall defend GitHub against any claim, demand, suit or proceeding made or brought against GitHub by a third party alleging that Your Content, or Your use of the Service in violation of this Agreement, infringes or misappropriates the intellectual property rights of a third party or violates applicable law, and shall indemnify GitHub for any damages finally awarded against, and for reasonable attorney’s fees incurred by, GitHub in connection with
19:10:23 <axil42> do you want me to tell a few words where we stand with the packaging process so far?
19:10:32 <orc_fedo> as background, they HAVE commenced litigation against users
19:10:36 <orc_fedo> axil42: Plesae do
19:10:40 <axil42> ok
19:10:49 <orc_fedo> #topic history of the effort
19:11:53 <axil42> so, last september I reached to a point where I had packaged all the dependencies (all ~100 of them...) and set up an instance on a Fedora 19 VPS
19:13:04 <axil42> the main rails app was installed like gitlab officially documents, not packaged to follow FHS
19:13:19 <axil42> anyhow, it seemed to play nice
19:14:00 <axil42> now
19:14:11 <axil42> the main problem is to get it officially packaged
19:14:11 <orc_fedo> axil42: I was unaware of that last ... you had SRPMs for all complete build closure?
19:14:24 <orc_fedo> the status page is stale them?
19:14:59 <axil42> orc_fedo, yes in a repo here http://repos.fedorapeople.org/repos/axilleas/gitlab/fedora-19/
19:15:14 <axil42> these are all deps needed at that time
19:15:25 <orc_fedo> thank you
19:15:41 <orc_fedo> I'll mirror and turn a goal seeking builder loose at it
19:16:14 <axil42> that's cool but bare in mind that was for gitlab 6.0 I think
19:16:25 <orc_fedo> axil42: so the next stage would be getting package reviews done, and comforming to Fedora engineering desires for Rawhide entry?
19:16:27 <axil42> 6 months have passed since
19:16:35 <axil42> yeap
19:16:44 <orc_fedo> wonderful
19:16:50 <axil42> but of course there are certain issues
19:17:27 <jchristi> and what of FHS compliance? i assume that will come up through review?
19:17:29 <axil42> perhaps I should compile a list with all the discussion in MLs
19:17:38 <axil42> about FHS
19:17:46 <orc_fedo> jchristi: yes but addressing that is doable
19:18:25 <tflink> does gitlab support anonymous viewing of content and checkouts of code?
19:18:47 <orc_fedo> tflink: there was an RFE to that effect over a year ago.  I think it god done
19:19:20 <jchristi> you can mark a repo as public so it can be viewed publicly. cloning i'm not sure about (may have been implemented by now)
19:19:43 <axil42> yes that's doable since version 6.1 i think
19:20:00 <axil42> view public repos and clone via http
19:20:14 <sytse_> GitLab.com CEO here, public http cloning and viewing is possible
19:20:31 <axil42> hey sytse_ :)
19:20:32 <orc_fedo> sytse_: welcome ... could you please also state your name
19:20:49 <sytse_> Sorry, Sytse Sijbrandij
19:20:55 <orc_fedo> thank you
19:20:57 <threebean> oo, another question -> can gitlab handle openid authentication?
19:21:03 <threebean> (maybe off-topic..?)
19:21:15 <sytse_> Not yet, but http://eric.van-der-vlist.com/blog/2013/11/23/how-to-customize-gitlab-to-support-openid-authentication/
19:21:23 <threebean> thanks
19:22:03 <orc_fedo> axil42: tactically, simply getting all packages into the Fedora Review process seems to be the current stop point
19:22:17 <orc_fedo> getting OUT of the process w FHS compliance, and such will follow
19:22:40 <tflink> how are ACLs managed? Would we need to move current ACLs from FAS groups?
19:22:52 <axil42> well conforming to FHS is not the main problem :)
19:22:53 <tflink> I supose I could start reading the docs, though :)
19:23:15 <axil42> tflink, have no idea about that
19:23:18 <orc_fedo> axil42: what is the #1 blocker?
19:23:42 <threebean> tflink: yeah, there's many phases here/discussions here.  one is about packaging gitlab for fedora.  another is about deploying gitlab as a replacement for the aging fedorahosted.org
19:25:07 <docent> Hi guys; just a side note; together with couple of guys we're working on Docker containers based on Fedora (https://git.fedorahosted.org/cgit/dockerfiles.git/tree/). One of the current project is GitLab; not sure if that could be useful for you (maybe for testing or poking around with GitLab); If you'd be interested I think we could focus on that (matter of days I suppose)
19:25:46 <tflink> threebean: ah, I misunderstood the purpose. I thought it was more general than just packaging
19:25:47 <axil42> orc_fedo, last time we discussed it, the problem was gitlab's forks https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile#L33
19:26:25 <orc_fedo> axil42: this is a functional problem?
19:27:06 <axil42> orc_fedo, let me find the discussion in ML
19:27:14 <axil42> that would shed more ligt
19:27:19 <orc_fedo> no immediate need ... until the procedural entry of all needed packages is in RawHide, we cannot reach that
19:27:46 <orc_fedo> axil42: as I recall you had a lost of packages not yet in review
19:28:03 <orc_fedo> how hard would updating that list be, and then pointing to your private archive with a link
19:28:16 <axil42> not too hard
19:28:39 <orc_fedo> that way, docent's team could sarm on adding every one for review
19:28:45 <orc_fedo> swarm*
19:29:03 <axil42> i can dedicate 1-2 days and update it
19:29:09 <orc_fedo> second pass, swarm on the review and fixup
19:29:15 <orc_fedo> axil42: that would be great
19:29:38 <orc_fedo> #action axil42 to update https://github.com/axilleas/gsoc/blob/master/rubygems_missing ?
19:30:47 <orc_fedo> axil42: as I was reading that output, I was thinking that adding a ^#YYYYmmdd so it can be parsed as to when it was last run would be an obvious RFE
19:31:01 <orc_fedo> do I recall a script builds that?
19:31:39 <orc_fedo> my notes indicate: https://github.com/axilleas/fedora/blob/master/gitlab-deps/gemfile.py
19:31:43 <orc_fedo> and https://github.com/axilleas/fedora/blob/master/gitlab-deps/rubysearch.sh
19:31:46 <orc_fedo> and https://github.com/gitlabhq/gitlabhq/blob/master/Gemfile.lock
19:32:15 <axil42> yes some really hasty scripts I wrote
19:32:24 <orc_fedo> axil42: much better than zero
19:32:24 <axil42> I plan to rewrite them
19:32:32 <orc_fedo> axil42: later ;)
19:32:51 <axil42> also
19:32:58 <axil42> there's now polisher gem https://github.com/ManageIQ/polisher
19:33:38 <axil42> and in particular https://github.com/ManageIQ/polisher/blob/master/bin/gem_dependency_checker.rb
19:33:51 <axil42> with useful output
19:35:36 <orc_fedo> axil42: what help from those present would you like to have?
19:36:48 <orc_fedo> I suppose you would like sytse_ and his team to help with a FHS tweak, as the upstream
19:37:01 <axil42> firstly we must get the remaining gems packaged, reviewed and pushed to rawhide
19:37:22 <orc_fedo> axil42: is there a reason NOT to parallelize this process
19:37:48 <orc_fedo> that is add what is on hand but not in review at once
19:37:54 <orc_fedo> and then fill the holes?
19:38:10 <axil42> sure
19:38:13 <orc_fedo> sytse_: do you have a handy link to the 'gitlab's forks'
19:38:23 <orc_fedo> problem thich axil42 mentioned?
19:38:36 <orc_fedo> can you fill in what is in play and the approach to solving it?
19:38:56 <sytse_> The forks contain the word gitlab in https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile.lock
19:39:18 <orc_fedo> sytse_: how is that a problem?
19:39:22 <oddshocks> Is the gitlab meeting going down now, or not started yet? I hate timezones
19:39:33 * oddshocks just got out of a midterm but wants to lurk
19:39:37 <orc_fedo> oddshocks: it is runing per /topic
19:39:42 * oddshocks doh
19:39:44 <axil42> oddshocks, it's happening right now :)
19:39:48 <oddshocks> ;)
19:39:48 <sytse_> As you can see we don't fork often, but sometimes the upstream repo is not maintained or does not want to merge.
19:40:01 <orc_fedo> sytse_: * nod *  I have seen that elsewhere
19:40:14 <orc_fedo> sytse_: also there is mention of a 'pinning' problem on older versions
19:40:35 <orc_fedo> that is, older gems are used when later releases exist
19:41:10 <sytse_> Notorious are gollum and grit
19:41:18 <orc_fedo> if there is a specific ABI needed, but not present later, I see that would be a problem
19:41:22 <sytse_> We try to update the gem on every major release
19:41:42 <sytse_> Yeah, it mostly is about needing more functionality
19:41:44 <orc_fedo> #topic current tactical discussion continues
19:42:25 <orc_fedo> sytse_: do any other action items upstream come to mind?
19:43:56 <sytse_> Debian asked us to get rid of gemoji due to licensing so we will replace that tomorrow
19:44:09 <orc_fedo> ahh
19:44:18 <axil42> good news :)
19:44:23 <orc_fedo> license matters much fo Fedora as well, of course
19:44:42 <orc_fedo> sytse_: it will be checked in the package review process
19:45:01 <orc_fedo> what are the problem packags there other than gemoji?
19:45:10 <sytse_> License matters to us and our subscribers too :-0
19:45:12 <orc_fedo> #info gemoji has license issues
19:45:39 <orc_fedo> sytse_: ;)
19:45:48 <sytse_> All the forked gems are things we can't easily get rid of, otherwise we would have done so already.
19:46:38 <orc_fedo> sytse_: can the forked gems be partitioned into sub-parts and  the free parts let go, and the encumbered re-written, or is it a monolithic mess?
19:47:28 <sytse_> axil42, what do you think about that?
19:48:14 <axil42> orc_fedo, about forks and why there is a problem with Fedora you can read in the discussion raised some months ago here https://lists.fedoraproject.org/pipermail/infrastructure/2013-July/013203.html
19:48:33 <orc_fedo> #link https://lists.fedoraproject.org/pipermail/infrastructure/2013-July/013203.html  fork issue at gitlab
19:48:42 <orc_fedo> axil42: ty
19:49:05 <axil42> but we could get probably get an exception if we ask it
19:49:32 <abadger1999> sytse_: When it gets reviewed (and likely post-review as well if you're like many other projects), the FPC will have to evaluate the bundling to see if they can get an exception.
19:49:43 <abadger1999> For so many forks, the process will likely be long and painful.
19:49:50 <abadger1999> Just a pre-warning :-/
19:50:11 <orc_fedo> abadger1999: the glass is half full, not half empty ;)
19:50:32 <abadger1999> sytse_: Some things FPC would consider are why aren't the changes upstream (so some correspondence/tickets that show the library wasn't interested in it)
19:50:39 <orc_fedo> docent: do any other approaches on encumbered content, beyond a re-write come to mind?
19:50:44 <abadger1999> stahnma: and also -- why the fork isn't just made public.
19:51:00 <abadger1999> ie: instead of bundling, make it a fork that other projects can benefit from as well.
19:51:14 <sytse_> I think our forks are public
19:51:17 <abadger1999> stahnma: sorry... hit tab and didn't look up.
19:51:33 <axil42> they're public yes
19:51:37 <orc_fedo> tab completion FTW
19:52:02 <abadger1999> sytse_: Okay -- meaning, that I can get your forked versions and use them in my program?
19:52:19 <abadger1999> and report bugs to you about the forked versions as used in my program?
19:52:38 <akovari> axil42, hello, I'm sorry, have I missed the party completely or is it still in progress?
19:52:38 <sytse_> Of course, and for example https://gitlab.com/gitlab-org/gitlab-grit/blob/master/README.md is much more up to date than upstream
19:52:50 <axil42> akovari, still talking :)
19:52:53 <akovari> ok :)
19:52:57 <abadger1999> (bonus points if I can download the forked versions without the rest of gitlab but  I think FPC would approve an exception without that addition).
19:53:13 <sytse_> https://github.com/mojombo/grit/commits/master vs. https://gitlab.com/gitlab-org/gitlab-grit/commits/master
19:53:37 <threebean> that's a good sign :)
19:53:58 <sytse_> you can download the forked versions without the rest of gitlab and projects also do this
19:54:06 <abadger1999> sytse_: Cool.  Then yeah, with proper information about that in the FPC ticket, there's a good chance of getting it approved as an independent fork rather than bundling.
19:54:20 <sytse_> #link https://twitter.com/mojavelinux/status/440985920477470720
19:55:04 <axil42> also there is an effort to replace grit with rugged, right?
19:55:12 <sytse_> good to hear that
19:55:15 <sytse_> yes there is
19:55:40 <abadger1999> axil4, sytse_: One thing that might be worth considering is whether to package the forks.
19:55:48 <orc_fedo> #info in process: grit -> rugged conversion effort in process
19:55:51 <abadger1999> that way there would be no questions about bundling at all.
19:56:07 <abadger1999> the code would be in separate packages, come from separate tarballs, etc.
19:56:49 <sytse_> that sounds like a great idea
19:57:17 <sytse_> can't we package all the gem as tarballs? https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
19:58:27 <orc_fedo> sytse_: the purpose here is to use the RPM packaging system
19:59:21 <sytse_> I love packages but I'm worried that no other project managed to packages a large amount of gems before
20:00:01 <axil42> abadger1999, what do you mean by "the code would be in separate packages, come from separate tarballs, etc."? The forks ar fundumental for gitlab to work, shouldn't they be proper packaged?
20:00:30 <axil42> pff excuse my typos
20:00:36 <orc_fedo> we are at an hour break .. is anyone behind us in this channel?
20:00:44 <abadger1999> axil42: Yes, they should -- I was originally thinking that hte forks would be part of the gitlab tarball.
20:00:58 <axil42> ah I see
20:01:06 <abadger1999> axil42: but if they're separate tarballs and separately packaged, that's a better way to go.
20:02:16 <abadger1999> orc_fedo: Nope -- this is infrastructure's "working channel" rather than a meeting channel.  (and ifnra has other channels that we can use)
20:02:29 <sytse_> hte forks? I don't understand what package would contain the tarballs, gitlab-forked-gems?
20:02:29 <orc_fedo> abadger1999: * nod * thank you
20:02:30 <abadger1999> we as in infra... so meeting can continue here.
20:02:53 <axil42> I guess we have nothing to lose to ask for permission about the forks while in parallel packaging the "easy" ones
20:03:06 <abadger1999> sytse_: ideally, each individual fork has its own tarball upstream and package downstream (in fedora).
20:03:46 <abadger1999> (I'm assuming that they're parallel installable with the non-forked versions of the library sicne I saw some comments about renaming?)
20:04:19 <abadger1999> sytse_: We can wander some distance away from the ideal if we have to... it depends on the situation.
20:04:25 <sytse_> all our forks have a different gem name so I don't think other apps are affected
20:04:33 <abadger1999> excellent.
20:04:43 <sytse_> great to hear there is some wiggle room
20:05:10 <docent> quaid: orc_fedo hmm - we could try building from any branch it this is the case
20:05:25 <docent> s/quaid://
20:05:58 <sytse_> This will be a long grind, is there someone that can manage this process or can we start with a dirty solution that we gradually clean up?
20:07:30 <orc_fedo> sytse_: with the permission of axil42 , I can spearhead collating, testing (prolly will set up a CI instance)
20:08:07 <orc_fedo> do we need separate ML facilities?
20:08:10 <sytse_> I think that would be great, what do you think axil42 ?
20:08:13 <orc_fedo> I can set up trivially
20:08:28 <axil42> sure thing any help you need I'm here
20:08:35 <axil42> also what sytse_ said before about the large amount of gems to be packaged and keep up to date is an issue
20:09:06 <sytse_> what does separate ML facilities' mean?
20:09:13 <axil42> but since a number of people expressed interest we can work together
20:09:14 <orc_fedo> anyone interested please send an email to: herrold owlriver com with the subject line goitlab effort  and I will advice when the infra is set up
20:09:18 <orc_fedo> sytse_: mailing list
20:09:32 <orc_fedo> gitlab*
20:10:46 <orc_fedo> docent: anything else come to mind as needed to be answered for your team to know?
20:10:59 <orc_fedo> #topic next meeting, going forward
20:11:45 <orc_fedo> #info people interested in being on a tactical mailing list to solve this please send an email to herrold owlriver com subject: gitlab effort
20:12:47 <docent> orc_fedo: I think we're good for now; We can try building from whatever you'd like - that's not an issue as far as it will be doable
20:12:56 <orc_fedo> docent: * nod *  thank you
20:13:15 <docent> n/p :)
20:13:22 <orc_fedo> axil42: any thought on when we should next meet?
20:13:25 <threebean> a thought about the next meeting -> you can hold these meetings in #fedora-meeting instead of here, if you like.  more people might expect to find you there.
20:13:29 <axil42> also FYI with the new ruby macros it will be much easier write specs for Fedora and EPEL in one go
20:13:42 <orc_fedo> threebean: getting a slot can be a challenge there
20:13:43 <axil42> threebean, i agree
20:13:46 <threebean> also, you can publicly schedule the meeting at https://apps.fedoraproject.org/calendar after you have decided on details and a time
20:14:00 <axil42> orc_fedo, not really
20:14:05 <threebean> orc_fedo: there is no-one meeting there now.. ;)
20:14:06 <axil42> if you check fedocal
20:14:23 <orc_fedo> pingou did that, right?
20:14:41 <axil42> after the infa meeting every thursday there's an empty slot ;)
20:14:44 <orc_fedo> axil42: how about open floor for  a bit and then close the meeting?
20:14:53 <orc_fedo> axil42: yup as to the slot
20:15:04 <orc_fedo> #topic open floor
20:15:21 <axil42> whom should we approach for the meeting slot?
20:15:21 <orc_fedo> oddshocks: tflink: anyting else come to mind?
20:15:38 <orc_fedo> axil42: I think abadger1999 controls that ;)
20:15:46 <threebean> axil42: oh, you can just claim it and add yourself to that calendar
20:15:58 <abadger1999> yeah, what threebean said :-)
20:16:21 <axil42> cool i will do then
20:17:28 <jchristi> orc_fedo: can you elaborate on the CI environment you intended to create?
20:17:58 <orc_fedo> jchristi: prolly buildbot mediated chroot builder
20:18:10 <jchristi> orc_fedo: that would be for packaging the gems?
20:18:13 <orc_fedo> I prefer to avoid Java, and it prefers that I do
20:18:31 <orc_fedo> jchristi: as I understand it, they are all packaged and just need wteaking
20:18:34 <orc_fedo> tweaking
20:19:02 <axil42> orc_fedo, not really, some might not be needed, some not packaged
20:19:09 <axil42> I'll make a full list
20:19:10 <orc_fedo> axil42: we shall see
20:19:32 <orc_fedo> axil42: I would like to get this back to EPEL 6 -- may I make you co admin on a VM to that effect?\
20:19:41 <axil42> sure
20:20:03 <orc_fedo> ci environment will live at: gitlab-mirror.lsbtest.net
20:20:12 <orc_fedo> box is deployed and can run the ML ..
20:20:18 <orc_fedo> I need to run soon
20:20:52 <jchristi> axil42: as our interest (akovari, dhenry, mchappel, and I) is in packaging for EPEL/RHEL7, let us know what we can do to help
20:20:52 <sytse_> orc_fedo Thanks for your help!
20:21:10 <jchristi> axil42: limited availability, but we'll do what we can :)
20:21:20 <axil42> jchristi, yeap thanks for that!
20:21:42 <sytse_> jchristu: will you join the ML?
20:21:53 <jchristi> sytse_: yes, i've sent a request already
20:22:11 <orc_fedo> jchristi: could you be list wrangler?
20:22:21 <axil42> first i shall write the rubygem packaging guide for anyone unfamiliar with the progress
20:22:32 <sytse_> jchristi: cool! also, consider emailing me at sytse gitlab com to talk about GitLab at RedHat, I'm all ears
20:22:34 <jchristi> orc_fedo: define wrangler
20:22:46 <akovari> jchristi, indeed
20:22:56 <orc_fedo> jchristi: gelp the less cleuful sove getting subscribed, de-subd
20:23:00 <orc_fedo> help*
20:23:04 <orc_fedo> that is about it
20:23:16 <dhenry> like herding cats?
20:23:21 <jchristi> orc_fedo: sure
20:23:25 <orc_fedo> dhenry: less rewarding
20:23:30 <axil42> lol
20:23:38 <orc_fedo> so many cats, so few good recipies -- Alf
20:24:23 <orc_fedo> ... last call before closing meeting
20:25:06 <orc_fedo> second last call
20:25:15 <sytse_> LOL
20:25:23 <sytse_> thanks again orc_fedo
20:25:24 <orc_fedo> going going ....
20:25:29 <orc_fedo> sytse_: a pleasure
20:25:29 <dhenry> thanks all
20:25:38 <orc_fedo> #endmeeting