12:00:42 #startmeeting Env and Stacks (2015-01-21) 12:00:42 Meeting started Wed Jan 21 12:00:42 2015 UTC. The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:00:42 #meetingname env-and-stacks 12:00:43 #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell 12:00:43 The meeting name has been set to 'env-and-stacks' 12:00:43 Current chairs: bkabrda hhorak juhp ncoghlan pkovar samkottler sicampbell tjanez vpavlin 12:00:53 Hello :) 12:01:57 Hi 12:02:33 hi guys 12:02:45 hi 12:04:03 #topic Nominations & Elections 12:04:26 have you guys checked the final nominations? https://fedoraproject.org/wiki/Env_and_Stacks/Nominations 12:04:29 #link https://fedoraproject.org/wiki/Env_and_Stacks/Nominations 12:04:57 it doesn't seem like we need to set up elections actually, since there are 4 seats and 4 nominations 12:05:11 hi guys 12:05:38 What a success:) 12:07:05 good 12:07:55 darn, I was looking forward to vote for bkabrda! :-) ;) 12:08:16 juhp: thanks :) 12:08:34 it's not said how to move on if this happens, so I'd say we can contact jreznik and somehow announce new members. or has anybody a different idea? 12:09:25 hhorak: yeah, I think contacting jreznik is the best course of action 12:10:06 sounds right 12:10:50 * vpavlin thinks who from this WG will be present at DevConf, so that we can trow a party for newcomers 12:11:09 vpavlin: ++ good idea 12:11:16 I am planning to be there :) 12:11:20 me too 12:11:38 #action hhorak will contact jreznik to let the "winners" be announced 12:11:49 #topic devconf 12:12:39 bkabrda, vplavlin: I don't think you'll be missing at devconf, right? 12:12:54 hhorak, you're doing a presentation, right? 12:13:06 hhorak: I'll be there 12:13:19 hhorak: Definitely going to be there:) 12:14:37 juhp: yes, there is gonna be a discussion with us :) and I hope you'll be there on Sunday 12:30 - 13:10 local (Brno) time if possible 12:15:10 * hhorak hoped you'll join the discussion at least :) 12:16:53 ah yes discussion sorry - that's right 12:16:53 #info juhp, bkabrda, vpavlin will be on devconf, brno and hopefully we'll all meet on the panel discussion on Sunday 12:30 local (Brno) time 12:16:53 #link http://devconf.cz/ 12:17:02 yes 12:17:15 yeah, looking forward to it! 12:17:44 * langdon finally made it 12:18:13 sure will be there 12:18:45 and I will be there to discuss with you guys :-) 12:19:13 * vpavlin hides 12:20:08 jzeleny, :) 12:20:09 I guess we may want to organize some lunch/dinner/beer on devconf? 12:20:45 or do we just meet at the party? 12:20:59 * vpavlin is going to miss the party:( 12:21:23 So I'd welcome another opportunity to meet with the WG:) 12:22:05 IIRC, the party is on Friday 12:22:24 on Saturday there is supposed to be some event as well but not nearly as long as the party 12:22:30 so beer is definitely an option 12:24:17 so what about to meet at the Saturday "event" and then go for a beer somewhere? 12:27:15 +1 12:27:19 I don't hear any disagreement, so let's do it this way unless we plan something else :) 12:27:23 why not :) 12:28:09 #info Env&Stacks members and friends beer meeting: we'll meet at the Saturday's "event" and then will go for a beer somewhere 12:30:10 #topic Ringzzz 12:30:22 * vpavlin hides again.. 12:30:38 (: 12:31:31 so I don't know if you've been following devel ML lately, but there's been discussion about our meeting minutes from last time and I'd really appreciate if someone else than me also chimed in 12:32:21 the biggest issue seems to be the fear of reintroducing the "fedora core" pain, which is not something what we want to do and I've been trying to explain that - we should formalize that somehow and vote on that 12:34:17 my thinking is, that we don't want to follow different packaging/bugfixing process for ring 0/1 packages. just provide additional integration tests/QE 12:34:19 bkabrda: how could I missed it, I kind of hoped people will use reply-to: env&stacks :( 12:35:36 and then there's this issue with RPM/SRPM - are rings 0/1 defined by RPMs (meaning that some RPMs from a single SRPM can be in 1 and some in 2) or SRPMs (meaning that if one RPM from SRPM falls into 1, then we just add the rest) 12:36:11 since I don't suggest any changes to the packaging process, I think we can safely have SRPMs that generate both ring 1 and ring 2 packages 12:36:35 that's pretty much what it came down and how I proposed to solve it. I'd like to hear your opinions now :) 12:36:41 *came down to 12:36:59 sorry I should have mentioned Fedora Core last week 12:37:02 * bkabrda hopes he's saying it in an understandable way 12:38:55 * jreznik is here, re-reading backlog 12:43:02 uhm... any thoughts? do I need to explain it better? 12:43:56 * juhp is reading 12:44:39 bkabrda: thanks for getting involved there, I think what you said made sense. what's more, it doesn't seem very important to me if there will be one or all of the packages in ring 1.. allowing to have one subpackage there and another there would decrease the size of ring 1 though. 12:45:39 hhorak: exactly. but it only makes sense if ring 1 packages still have the same process as ring 2 packages (which makes sense to me) - we can always attach additional QA "externally" to important packages from rings 0/1 12:45:46 like taskotron 12:46:19 I don't see a need to diffentiate the process for ring 0/1 vs. ring 2 packages 12:46:24 *differentiate 12:46:28 I think it is good to point out that we are still just exploring the space/ideas 12:47:04 bkabrda, true 12:47:21 bkabrda: right I don't see either. 12:47:43 bkabrda, i think the difference might be in "requirement" as in ... if you are in r0/1 you *must* have taskotron testing vs r2 you can not? 12:47:49 Maybe start with SRPM based ring labeling and if there is a push on minimization of rings switch to RPMs and higher granularity division.. 12:49:06 langdon: I don't think it should be hard requirement... one of the reasons is that I think that packagers won't necesarilly be the ones writing the taskotron tests 12:49:23 vpavlin: so what would be the advantage of having SRPM based ring 1? 12:50:34 bkabrda: Easy(ier) start? 12:50:55 (for rings model) 12:51:01 vpavlin: I got that. my question was more like "how does it make our situation easier?" 12:51:26 I think these tests will be developed and improved continuously and will probably be (co-)developed by Fedora QA - this should IMO be an additional community effort, not hard requirement 12:51:30 bkabrda: That we don't have to review so many packages?:) 12:51:50 vpavlin: I don't understand... why would we have to review so many packages? 12:53:30 bkabrda: Hmm..I am probably confused now..Somebody will have to say which package goes to ring1, right? And the person/team will either have to work with (a smaller) set of SRPMs or a (wider) set of RPMS 12:55:09 vpavlin: we'll have a list of RPMs from LiveCDs or cloud images - based on kickstart or something like that. from that, we can easily get the list of binary RPMs and/or their corresponding SRPMs. I still don't see where the problem is 12:56:10 bkabrda: Nevermind, I am probably talking nonsense. 12:56:27 vpavlin: I think it makes sense to do the taskotron testing RPM based, not SRPM based, since you want to concentrate the effort on creating tests for the minimal set of components 12:57:04 true 12:58:12 another reason to keep rings sets on srpm-level for beginning is that we'll need to work with koji (based on dennis' response, that nothing build outside of koji can be considered 'the fedora') and personally I don't know how good koji is when it comes to granularity of picking packages to repositories.. 12:59:01 bkabrda: Yes, I agree..I wasn't talking about taskotron...I meant just the assigment of packages to rings..But I might have missed something, or I am just explaining my thought too...hmm...chaotically:) 12:59:12 hhorak: I'm not sure I understand. how is this an argument for defining rings based on srpms? 13:00:50 vpavlin: yeah, but the assignment is IMO "automatic" in the sense that packages in ring 1 are defined by livecds/cloud images. I think it shouldn't be the other way round, i.e. defining ring 1 and then constructing livecd/cloud image out of it 13:01:07 bkabrda: i may be wrong but koji tags packages on build-level, so all subpackages are tagged into the same tag always. 13:01:31 hhorak: well I wasn't suggesting that packages from different rings should have different tags :) 13:01:46 bkabrda: Ah...that's what you mean..hmm.. 13:02:02 bkabrda, I think your definition/criterion makes sense 13:02:11 bkabrda: Don't you think that ring1 might be smaller/bigger than livecd/cloud image? 13:02:29 vpavlin: because imagine a situation when new upstream version gets a new dependency. that's something that we can't influence, this package will automatically have to be made part of ring 1 13:02:40 vpavlin: I think it will 13:03:41 another case when ring 1 will change will be when Workstation WG/Server WG/... needs/wants to add a package to livecd/cloud image 13:03:49 or remove for that matter 13:04:13 that's why I think that ring 1 will not be *defined*, it will be *induced* 13:04:34 bkabrda: then I was too far in the imagination, going one step back it make sense.. 13:04:40 of course this would make ring 1 pretty big (though smaller than current "ring 1") 13:05:13 juhp: yes, and that's one of the arguments for defining groups based on RPMs, not SRPMs :) 13:05:21 right 13:05:57 so this is my perception of ring 0 vs ring 1 vs ring 2 13:07:29 bkabrda: that makes sense to me. 13:09:03 anyway, I guess what we might miss here is to explain what it brings for users. maybe even sync on that topic between ourselves, since my imagination is not clear at all. 13:09:06 * vpavlin is sorry but needs to go to catch a bus to Prague 13:09:37 vpavlin: Bon Voyage! 13:10:39 hhorak: I don't think that our perception of rings 1 and 2 brings something material to users :) we need it to be able to categorize our future work... which I think lies mostly in rigns 3 and 4 as we talked about them last time 13:13:19 mm yeah 13:14:51 bkabrda: sure, I probably switched to a bit more general thinking, you're right it's more about other rings. 13:17:28 yeah, I thought it'd be a good idea to make this very clear - that we're not trying to reintroduce fedora-core again... because people were seriously concerned 13:17:54 maybe we should have page summarizing our perception of rings? 13:18:14 and also what we're trying to fix? 13:19:53 yeah, the page seems like a good idea, ideally there can be also some sample scenarios (personas) about what the rings model changes on the users' side? 13:20:10 who is able to kick-of such a page? 13:20:46 I have to say I'm now completely snowed under with the Python 3 switch, Python 3 in EPEL and other Python related work... and also devpi 13:21:35 I am kind of busy with GHC78 Change right now 13:22:20 * hhorak is not in a better situation but if nobody starts we can bring a paper and a pen for our beer meeting and draw/write something there :) 13:22:29 hhorak: good idea! 13:22:57 * langdon believes beer helps writing most things 13:24:45 plus we'll be able to get a nice stamp on it :) 13:24:58 nice round one.. 13:25:17 hhorak: a ring-shaped stamp! we need to do that :) 13:25:23 +1 13:27:33 #info there's been discussion about our meeting minutes from the last time 13:27:33 #action everybody is encourage to get involved in the discussion about rings on devel ML 13:27:49 #info it's not clear if separation of packages in ring 1 and 2 should be made on SRPM level or on RPM level. the later option would produce smaller set of packages in ring 1, there are no specific advantages of the former option 13:28:40 #info we need to summarize the ideas about rings on a page, where we will cover: our perception of rings, some sample scenarios (personas) about what the rings model changes for the maintainers and what for the users 13:28:58 #info unless somebody finds time to write it up, we'll can do something on the beermeeting during devconf 13:29:28 I'm out of topics about rings, but will get involved in the ML hopefully. 13:29:36 anybody has some ideas? 13:29:43 (more) 13:31:48 it doesn't seem so.. 13:32:10 I will try to keep an eye on the discussion too 13:33:47 let me open one short topic more 13:33:47 #action meeting time 13:35:14 Since we practically have 3 new members now and quite a few people asked to move the meeting to some more us-friendly time, I think we should do the when-is-good again and set up two meeting slots, one east-friendly, another west-friendly.. 13:35:37 okay sure 13:35:38 hhorak: +1 13:35:55 the same as we did in the beginning -- alternate on odd/even weeks 13:36:59 ok 13:37:03 I'll send a link to our ML, but let's do the next week's meeting still in the current slot, for the last time :) 13:37:16 * langdon gotta take off.. conflicts... 13:38:38 #action hhorak will send a link to when-is-good to pick up a new timeslot for the Env&Stacks meeting, we may setup two time slots, one east-friendly, another west-friendly.. and alternate on odd/even weeks 13:38:57 ok, I guess that's all folks, thanks! 13:40:00 thanks! 13:40:06 #endmeeting