13:00:34 #startmeeting Env and Stacks (2014-09-02) 13:00:34 Meeting started Tue Sep 2 13:00:34 2014 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:41 #meetingname env-and-stacks 13:00:41 The meeting name has been set to 'env-and-stacks' 13:00:48 #chair pkovar tjanez samkottler bkabrda hhorak juhp mmaslano vpavlin sicampbell 13:00:48 Current chairs: bkabrda hhorak juhp mmaslano pkovar samkottler sicampbell tjanez vpavlin 13:00:59 hi 13:01:05 Hi 13:01:19 Hey 13:02:30 * tflink is lurking 13:02:40 #topic init process 13:03:27 #topic how hhorak's idea about summary from each WG worked 13:03:44 hhorak: I read the whole conversation. So, cross posting didn't work 13:04:00 yeah, it did not work very much :) 13:04:37 hm 13:04:41 It seems like we haven't moved anywhere except we should try to utilize irc commands during meeting more.. 13:04:59 yes. And put those notes as blogpost on planet 13:05:38 how did the conversation go? :) (sorry I didn't read any of it) 13:06:44 juhp_: long story short, cross posting a short summary to all groups is not a good idea, but using more #info and stuff during meeting could make the meeting logs more readable 13:07:08 okay, fair enough I suppose 13:07:41 hhorak: do you agree or would you like to do more about it? 13:07:43 maybe there should be a fedora-wg-list? 13:08:13 but maybe minutes are the limit for now anyway :) 13:08:27 juhp_: well, I will try to come up with new ideas, but do not have anything particular on my mind right now.. I'd definitly like to make it a bit differently, than we do it now (everybody needs to look at more resources right now) 13:08:28 juhp_: not another list please:) 13:08:32 haha 13:08:59 hhorak, okay 13:09:25 * langdon lurking as well 13:10:41 #info cross posting a short summary to all groups is not a good idea, but using more #info and stuff during meeting could make the meeting logs more readable 13:10:42 A good thing is that there was quite a consensus that somebody from a group should take some time (minutes, not hours) to convert either meeting minutes or ML discussions and publish it.. The only missing part is how this info bring to all WGs members efficiently.. 13:11:13 subscribe the blog :) 13:11:24 imho problem is to find a person who would write those minutes 13:11:27 (by convert I meant summarize) 13:11:33 yeah 13:11:44 right 13:11:51 ok, I can start with it today 13:12:03 my apologies for my delay 13:12:06 hi everyone, sorry I'm late; I was coding so hard I didn't notice what time it was :) 13:12:13 mmaslano: great, thanks! 13:12:41 smooge, thanks for joining - we didn't get to epel/epic yet :) 13:12:45 #info mmaslano will process meeting minutes on her blog (shared on fedora.planet) 13:13:53 personally I would prefer to read something on devel list but that is just my 2c :) 13:14:12 there are already meeting minutes. 13:14:15 yes 13:15:54 hhorak: I guess we won't persuade other WGs to do it too 13:16:18 mmaslano: we could at least ask :) 13:16:29 hhorak: do you want it as action item? 13:16:44 I guess the problem is the meeting minutes are too terse and the logs too long to trawl through... so guess there is consensus around that :) 13:18:41 mmaslano: I'll make a bit more general AI :) 13:18:41 #action hhorak will keep trying to get summary of working groups' discussion (ML, meetings) to other groups' members 13:19:04 What about having one person on meeting dedicated to create meeting minutes (using irc bot commands os course)? 13:19:22 vpavlin: that's me here :) 13:19:36 Hmm..true:) 13:19:37 problem is people don't put all information into info and action :) 13:19:44 people and me too 13:19:50 move on to epic? 13:19:51 right 13:19:52 apologies for being late 13:20:02 vpavlin: still that would cover only meetings, not all interesting info is mentioned on meetings. (but let's move forward) 13:20:09 still on time for epic/epel 13:20:17 #topic epel/epic proposal - chat with smoodge 13:20:21 but maybe having a secretary (rotating) is a good idea 13:20:31 smooge: argh I didn't get the nick right 13:20:56 juhp_: it is especially I found out it's already Tuesday and I don't have agenda 13:21:06 hehe 13:21:16 hhorak: right, sorry, I am talking to several other people atm, so not really focused...:) 13:21:22 juhp_: smooge: did you speak? thanks for mail about the proposal 13:21:43 I had some communication about epic/epel 13:21:51 smooge: If I understand correctly EPEL will have three repos. 13:22:10 we are still working that out 13:22:11 though I think the epel group didn't discuss it much on Friday from my reading of the log at least 13:22:46 s/I had/we had/ 13:22:51 we are going to be discussing it this week in email as various peoples schedules were a bit broken last week 13:23:00 cool 13:23:50 smooge: sounds as good thing for me if I think about Python3... 13:23:58 our first steps will be policy discussions then technical discussions. 13:24:03 sure 13:24:16 I just wanted to say that :) although it very much relies on the policies 13:24:40 but we know about some packages, which don't fit well into EPEL 13:25:01 well a lot of packages don't :). RHEL keeps getting longer lived :) 13:25:15 so as I understand the current suggestion is to have the stable epel repo, a new epel-rolling(?) repo (more relaxed than current epel policy), and a epel-fast repo (closer to latest upstream) releases or something along those lines 13:26:06 yes that is what is currently out there 13:26:52 smooge: is there some kind of draft that one can read through? 13:26:53 the epel-fast and epel-rolling might be combined into one repo depending on how releng sees the amount of work needed to do each one 13:27:07 which would be a good improvement over the single repo 13:27:14 bkabrda, nothing beyond what juhp just said 13:27:16 okay - yes I could see that happening 13:27:51 bkabrda, we are wanting to clarify existing procedures and issues first 13:27:58 smooge: ok. I just want to keep an eye on this, since depending on the policies, this may or may not be *the* place to put python3 for epel 13:28:21 I understand. 13:28:44 smooge, certainly agreed good to take the discussion slowly and consider options carefully 13:29:11 smooge: ok, we will follow up the meeting minutes 13:29:18 smooge: do you need anything from us? 13:29:43 I still feel over 7 years though the gap between epel and epel-rolling can get too large for some packages 13:29:49 At our present speed and people needing to work on Fedora 20 I expect we will be shooting after the release for the extra repos 13:30:17 so I would suggest that people follow the discussion on epel-devel 13:30:22 sure 13:30:34 and feed back issues they see with proposals and such 13:30:56 okay 13:31:05 and wish us luck :) 13:31:07 smooge: thanks, I'll join that list and that discussion 13:31:46 and will try to keep on eye on the discussions too and contribute input 13:32:01 smooge: one question more -- https://fedoraproject.org/wiki/EPEL-faster-repo-ideas speaks about different position about overlapping packages, how come it could be combined at some point? (or is this page not up2date?) 13:32:20 smooge: good luck 13:32:29 #url https://fedoraproject.org/wiki/EPEL-faster-repo-ideas 13:32:50 hhorak, could you explain what you you see as an issue? [Its way early and my brain is not as fast as it should be.] 13:33:22 #info faster EPEL is only proposal now. Members of Env and Stack should follow epel-devel for discussion about the proposal. 13:34:22 smooge: I meant repos epel-rolling and epel-edge -- overlaps allowed only in edge; supposing this should be the same as fast and as you have mentioned the repos could be combined into one repo, it does not make sense to me 13:34:53 hhorak, maybe it means overlaps of epel-fast with rhel 13:35:14 smooge: but I might overthink it in this early phase and will be totally fine with "this will be sorted out" answer 13:36:08 yes I think things are still pretty much up in the air :) 13:36:51 hhorak that is a 'anything goes proposal' stage at the moment.. 13:37:19 so one proposal is that they would allow overlaps but it hasn't been discussed that we would allow that at all. 13:38:11 hhorak, erm nm - yes to be decided I guess 13:39:10 we are at the throw stuff at the wall stage and that page is meant to be a collection of all the various ideas. We will be going through various parts to get them cleared up. 13:39:18 :) 13:39:30 smooge: ok, all right. 13:40:21 One thing I'd like to see stated on the page above though -- what problem are we trying to solve? I guess I know the answer, but somebody with no background could be wondering what is the proposal going to solve actually. 13:42:08 hhorak, ok thanks I will add that to the discussion to make sure we have a consensus on that 13:42:24 hhorak: current epel policies basically don't allow rebasing with major changes (e.g. if we put python 3.4 in there, we'd have to maintain in for the rest of days of epel 7 repo) 13:42:35 smooge: thanks a lot 13:42:45 at least that's my painpoint :) 13:42:47 true - I think one of the major things is currently some package updates break epel's official stability policy, due to epel long life 13:43:08 hhorak, ^ 13:43:09 bkabrda, well actually no. we would just have a 'this is no longer supported upstream and we are removing it from the repo' 13:43:53 it has been done for various packages in the past.. but it leaves people wanting the old stuff still and the new stuff possibly breaking the new 13:44:05 smooge, exactly 13:44:26 right so we should make both or more available 13:44:30 so we try to avoid it as much as possible.. which makes your life harder because people issues :) 13:46:31 anyway I will add that to the page shortly 13:46:57 smooge: ok, thanks 13:49:52 next topic? 13:50:48 smooge, thanks so much for joining the meeting - I know it is early for you 13:51:09 smooge: thanks! 13:51:21 it has helped to clarify my thinking on this too 13:51:38 sicampbell: didn't you have some action item from previous meetings? 13:52:00 Yes - it was to update the wiki and it's done 13:52:30 ah, thanks 13:52:41 #topic openfloor 13:52:58 if you want to speak about rotating chairman, that would be good 13:53:46 mmaslano: What does "rotating chairman" mean? 13:54:10 vpavlin: it means I'm not doing agenda and meeting minutes every week :) 13:54:31 fesco is picking new chairman every week on the end of meeting 13:54:38 mmaslano: +1 for that idea (chairman + secretary) 13:54:40 but it depends if you are willing to do it 13:55:12 I think it is a good idea 13:55:43 I'd like to just say that I talked to Matěj Stuchlík about Fedora Docker build service. bkabrda you ok with him working on that? 13:55:43 I pointed him to Pulp/Crane and quay.io which is very nic implementation of Docker registry and a lot more stuff. 13:56:09 mmaslano: +1 13:57:15 Is this for building the base containers ? 13:57:44 sicampbell: No, base images will be (are) built in Koji 13:57:58 I'll take it as consensus. Who will do chairman next? 13:58:15 This should be for Fedora users to build and host their layered images 13:58:42 #info chairman for next meeting will be picked at end of the current meeting 13:59:12 I can be the chairman the next week. 13:59:14 mmaslano, shall we have a rotating secretary too? 13:59:34 it's usually one person 13:59:42 it would make sense to me that charmain would do the secretary work as well... 13:59:48 okay 13:59:54 #action hhorak will be chairman and secretary next week 13:59:57 hhorak: thanks 14:00:34 bkabrda: could you verify if it's okay to bother Matej about Fedora Docker? 14:00:46 mmaslano: thanks to you for being chair(wo)man today 14:01:20 mmaslano: I guess it's ok 14:01:31 vpavlin: will you be looking at security/findability aspects of the docker infra? 14:02:00 * langdon uses "chairperson" ;) 14:03:02 langdon: I will have to look at it. I still think we should set up registry with the build service and store the results there - the same way quay work 14:03:11 #action mstuchli will work on Fedora Docker build service 14:03:35 langdon: We can then let have some switch which will mark the build stable enough to be pushed to hub.docker.io 14:04:10 vpavlin: how about a write up? :) that way i (may) understand ;) 14:04:25 Pulp guys are already looking at doing automtic build with help of Jenkins 14:04:52 langdon: I've sent it to you (I hope) 14:06:08 * langdon digs through email 14:07:53 langdon: 2014-8-26 Fedora Docker Build service and Registry 14:07:56 * langdon found it, will reply 14:09:46 Thanks;) 14:13:03 That's probably all from me... 14:13:39 #info We need to figure out whether we want private Docker registry or not 14:15:47 openfloor or end? 14:16:29 can we end? :) 14:17:14 thanks guys 14:17:17 #endmeeting