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