12:00:42 <hhorak> #startmeeting Env and Stacks (2015-01-21)
12:00:42 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:00:42 <hhorak> #meetingname env-and-stacks
12:00:43 <hhorak> #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell
12:00:43 <zodbot> The meeting name has been set to 'env-and-stacks'
12:00:43 <zodbot> Current chairs: bkabrda hhorak juhp ncoghlan pkovar samkottler sicampbell tjanez vpavlin
12:00:53 <hhorak> Hello :)
12:01:57 <vpavlin> Hi
12:02:33 <jzeleny> hi guys
12:02:45 <juhp> hi
12:04:03 <hhorak> #topic Nominations & Elections
12:04:26 <hhorak> have you guys checked the final nominations? https://fedoraproject.org/wiki/Env_and_Stacks/Nominations
12:04:29 <hhorak> #link https://fedoraproject.org/wiki/Env_and_Stacks/Nominations
12:04:57 <hhorak> it doesn't seem like we need to set up elections actually, since there are 4 seats and 4 nominations
12:05:11 <bkabrda> hi guys
12:05:38 <vpavlin> What a success:)
12:07:05 <juhp> good
12:07:55 <juhp> darn, I was looking forward to vote for bkabrda! :-) ;)
12:08:16 <bkabrda> juhp: thanks :)
12:08:34 <hhorak> 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 <bkabrda> hhorak: yeah, I think contacting jreznik is the best course of action
12:10:06 <juhp> 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 <hhorak> vpavlin: ++ good idea
12:11:16 <juhp> I am planning to be there :)
12:11:20 <bkabrda> me too
12:11:38 <hhorak> #action hhorak will contact jreznik to let the "winners" be announced
12:11:49 <hhorak> #topic devconf
12:12:39 <hhorak> bkabrda, vplavlin: I don't think you'll be missing at devconf, right?
12:12:54 <juhp> hhorak, you're doing a presentation, right?
12:13:06 <bkabrda> hhorak: I'll be there
12:13:19 <vpavlin> hhorak: Definitely going to be there:)
12:14:37 <hhorak> 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 <juhp> ah yes discussion sorry - that's right
12:16:53 <hhorak> #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 <hhorak> #link http://devconf.cz/
12:17:02 <juhp> yes
12:17:15 <bkabrda> yeah, looking forward to it!
12:17:44 * langdon finally made it
12:18:13 <juhp> sure will be there
12:18:45 <jzeleny> and I will be there to discuss with you guys :-)
12:19:13 * vpavlin hides
12:20:08 <juhp> jzeleny, :)
12:20:09 <hhorak> I guess we may want to organize some lunch/dinner/beer on devconf?
12:20:45 <hhorak> or do we just meet at the party?
12:20:59 * vpavlin is going to miss the party:(
12:21:23 <vpavlin> So I'd welcome another opportunity to meet with the WG:)
12:22:05 <jzeleny> IIRC, the party is on Friday
12:22:24 <jzeleny> on Saturday there is supposed to be some event as well but not nearly as long as the party
12:22:30 <jzeleny> so beer is definitely an option
12:24:17 <hhorak> so what about to meet at the Saturday "event" and then go for a beer somewhere?
12:27:15 <vpavlin> +1
12:27:19 <hhorak> I don't hear any disagreement, so let's do it this way unless we plan something else :)
12:27:23 <juhp> why not :)
12:28:09 <hhorak> #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 <hhorak> #topic Ringzzz
12:30:22 * vpavlin hides again..
12:30:38 <juhp> (:
12:31:31 <bkabrda> 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 <bkabrda> 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 <bkabrda> 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 <hhorak> bkabrda: how could I missed it, I kind of hoped people will use reply-to: env&stacks :(
12:35:36 <bkabrda> 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 <bkabrda> 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 <bkabrda> 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 <bkabrda> *came down to
12:36:59 <juhp> 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 <bkabrda> uhm... any thoughts? do I need to explain it better?
12:43:56 * juhp is reading
12:44:39 <hhorak> 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 <bkabrda> 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 <bkabrda> like taskotron
12:46:19 <bkabrda> I don't see a need to diffentiate the process for ring 0/1 vs. ring 2 packages
12:46:24 <bkabrda> *differentiate
12:46:28 <juhp> I think it is good to point out that we are still just exploring the space/ideas
12:47:04 <juhp> bkabrda, true
12:47:21 <hhorak> bkabrda: right I don't see either.
12:47:43 <langdon> 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 <vpavlin> 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 <bkabrda> 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 <bkabrda> vpavlin: so what would be the advantage of having SRPM based ring 1?
12:50:34 <vpavlin> bkabrda: Easy(ier) start?
12:50:55 <vpavlin> (for rings model)
12:51:01 <bkabrda> vpavlin: I got that. my question was more like "how does it make our situation easier?"
12:51:26 <bkabrda> 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 <vpavlin> bkabrda: That we don't have to review so many packages?:)
12:51:50 <bkabrda> vpavlin: I don't understand... why would we have to review so many packages?
12:53:30 <vpavlin> 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 <bkabrda> 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 <vpavlin> bkabrda: Nevermind, I am probably talking nonsense.
12:56:27 <bkabrda> 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 <juhp> true
12:58:12 <hhorak> 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 <vpavlin> 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 <bkabrda> hhorak: I'm not sure I understand. how is this an argument for defining rings based on srpms?
13:00:50 <bkabrda> 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 <hhorak> 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 <bkabrda> hhorak: well I wasn't suggesting that packages from different rings should have different tags :)
13:01:46 <vpavlin> bkabrda: Ah...that's what you mean..hmm..
13:02:02 <juhp> bkabrda, I think your definition/criterion makes sense
13:02:11 <vpavlin> bkabrda: Don't you think that ring1 might be smaller/bigger than livecd/cloud image?
13:02:29 <bkabrda> 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 <bkabrda> vpavlin: I think it will
13:03:41 <bkabrda> 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 <bkabrda> or remove for that matter
13:04:13 <bkabrda> that's why I think that ring 1 will not be *defined*, it will be *induced*
13:04:34 <hhorak> bkabrda: then I was too far in the imagination, going one step back it make sense..
13:04:40 <juhp> of course this would make ring 1 pretty big (though smaller than current "ring 1")
13:05:13 <bkabrda> juhp: yes, and that's one of the arguments for defining groups based on RPMs, not SRPMs :)
13:05:21 <juhp> right
13:05:57 <bkabrda> so this is my perception of ring 0 vs ring 1 vs ring 2
13:07:29 <hhorak> bkabrda: that makes sense to me.
13:09:03 <hhorak> 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 <hhorak> vpavlin: Bon Voyage!
13:10:39 <bkabrda> 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 <juhp> mm yeah
13:14:51 <hhorak> bkabrda: sure, I probably switched to a bit more general thinking, you're right it's more about other rings.
13:17:28 <bkabrda> 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 <bkabrda> maybe we should have page summarizing our perception of rings?
13:18:14 <hhorak> and also what we're trying to fix?
13:19:53 <hhorak> 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 <hhorak> who is able to kick-of such a page?
13:20:46 <bkabrda> 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 <juhp> 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 <bkabrda> hhorak: good idea!
13:22:57 * langdon believes beer helps writing most things
13:24:45 <hhorak> plus we'll be able to get a nice stamp on it :)
13:24:58 <hhorak> nice round one..
13:25:17 <bkabrda> hhorak: a ring-shaped stamp! we need to do that :)
13:25:23 <juhp> +1
13:27:33 <hhorak> #info there's been discussion about our meeting minutes from the last time
13:27:33 <hhorak> #action everybody is encourage to get involved in the discussion about rings on devel ML
13:27:49 <hhorak> #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 <hhorak> #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 <hhorak> #info unless somebody finds time to write it up, we'll can do something on the beermeeting during devconf
13:29:28 <hhorak> I'm out of topics about rings, but will get involved in the ML hopefully.
13:29:36 <hhorak> anybody has some ideas?
13:29:43 <hhorak> (more)
13:31:48 <hhorak> it doesn't seem so..
13:32:10 <juhp> I will try to keep an eye on the discussion too
13:33:47 <hhorak> let me open one short topic more
13:33:47 <hhorak> #action meeting time
13:35:14 <hhorak> 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 <juhp> okay sure
13:35:38 <bkabrda> hhorak: +1
13:35:55 <hhorak> the same as we did in the beginning -- alternate on odd/even weeks
13:36:59 <juhp> ok
13:37:03 <hhorak> 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 <hhorak> #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 <hhorak> ok, I guess that's all folks, thanks!
13:40:00 <juhp> thanks!
13:40:06 <hhorak> #endmeeting