13:02:31 <hhorak> #startmeeting Env and Stacks (2014-10-21)
13:02:31 <zodbot> Meeting started Tue Oct 21 13:02:31 2014 UTC.  The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:35 <hhorak> #meetingname env-and-stacks
13:02:35 <zodbot> The meeting name has been set to 'env-and-stacks'
13:02:48 <hhorak> #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell
13:02:48 <hhorak> #topic init process
13:02:49 <zodbot> Current chairs: bkabrda hhorak juhp ncoghlan pkovar samkottler sicampbell tjanez vpavlin
13:03:08 <juhp> hi
13:03:29 <bkabrda> hey
13:04:16 <hhorak> Hi
13:04:46 <hhorak> #topic Follow-up -- Docker docs
13:04:48 <nphilipp> Hi
13:05:47 <hhorak> The last time we kind of agreed on what we want to do, but nobody had time to assign himself to do it. Is it better today? Did anybody buy some extra hours somewhere? (let me know where)
13:06:56 <ncoghlan> hey folks - not actually here, just realised I forgot to send an email saying I couldn't make it to the WG meeting this week
13:07:14 <hhorak> ncoghlan: ok, np :)
13:07:23 <ncoghlan> and now for the actually not being here part... :)
13:07:27 * ncoghlan waves
13:09:48 * juhp would like to know where too :) ;)
13:11:27 <hhorak> that seems like we still have other things to do, so at least I'll sum up what we agreed the last time
13:12:02 <hhorak> #action hhorak will sum up what we agreed the last time on Docker doc and will write it on the wiki for someone who picks it
13:12:41 <juhp> cool
13:13:33 <hhorak> #topic Integration tests for packages alias Per-component integration tests in Fedora
13:14:24 <hhorak> Well, I admin I was pretty tired when I was sending the agenda and probably include one item twice :)
13:15:19 <hhorak> this is mostly about the proposal I sent also yesterday
13:16:01 <hhorak> it is about possibility to have some non-unit tests for components in Fedora
13:17:14 <hhorak> Taskotron might be responsible for running them as soon as it has the necessary features, but we may start preparing the other infrastructure (where and how to keep tests) before that
13:17:33 * juhp reads
13:18:03 <hhorak> and the pretty long mail was supposed to sum up some ideas that we may polish and then consult on @devel
13:18:32 <nphilipp> :w
13:18:35 <nphilipp> oops
13:20:09 <bkabrda> hhorak: I like the general idea, my fear is that packagers have too little time to actually learn something like beaker and write tests
13:20:32 <bkabrda> integration tests can be a pain to write...
13:20:59 <juhp> hmm
13:21:36 <hhorak> bkabrda: I would like to take beakerlib (just the framework for writing tests, no infrastructure) only as a suggested approach, but let anything to be used
13:22:16 <hhorak> bkabrda: right, if nobody is interested in writing complicated tests, no tests will exist, but we should have a way to write at least simple tests
13:23:54 <bkabrda> hhorak: could you please exaplain "let anything to be used"? like any testing framework, ...?
13:25:53 <hhorak> bkabrda: yes, be it python testing framework or just a bash script... it just needs to report something useable by taskotron, which might be the issue a bit
13:27:45 <hhorak> the idea was to first come up with some tests delivered somehow and solve the running part later.. I see benefit even in having a place for such tests and let volunteers or package maintainers to run them on their own...
13:28:03 <juhp> hhorak, +1
13:28:20 <bkabrda> hhorak: I'm just thinking whether allowing writing tests in any possible way is a good idea. on one hand, people will be more likely to write tests this way, but on the other hand if someone else than $owner needs to fix a failing test, it can be problematic if $owner chooses an obscure language/framework
13:29:17 <juhp> I don't really have strong opinion about pkg git tests/ vs tests-git
13:29:30 <juhp> tests-git maybe seems more flexible
13:29:48 <hhorak> #idea we can divide the complex issue into smaller pieces delivered independently -- first have method/rules to keep tests somewhere and write them somehow and later solve how to run them automatically in proper environment
13:29:56 <bkabrda> as for git, I would rather see a separate git. it's more flexible and wouldn't make mess of dist-git
13:31:18 <nphilipp> From the sidelines: I'm also in favor of having tests separate from dist-git, but there would need to be a way to specify that e.g. some tests are only to be run for certain versions
13:31:23 <juhp> bkabrda, yeah I tend to agree, though of course separate tests repo could lead to bit rot in some cases
13:32:14 <hhorak> bkabrda: right, that makes sense, but still I see bigger benefit in opportunity to use any framework than having more people able to fix broken builds
13:33:05 <nphilipp> juhp: if someone doesn't care that much about tests, they will rot in dist-git as well
13:33:18 <bkabrda> hhorak: I'm kind of undecided in this matter, I'm just thinking aloud here
13:33:22 <juhp> having them in the same repo might make it easier to keep things in sync but of course it may break down for cross/multi package testing
13:33:27 <juhp> nphilipp, yeah
13:34:44 <hhorak> nphilipp: in other words we need some aparathus to say that some object is valid only on some condition (version) -- that's where RPM macros could be used if we choose to package tests as RPMs.. (actually RPM can solve quite a few of the issues but still it's again the old ugly RPM :) )
13:35:04 <juhp> hhorak, yes
13:35:48 <nphilipp> hhorak: hmm, not sure how RPMs help you distinguish between versions of the component you're testing and auxiliary stuff
13:35:51 <juhp> would it be too much to support 1a, 1b, tests/ and tests-git? :)
13:36:41 <hhorak> nphilipp: I meant if you have %if %fedora > 20 then you can include only some tests into the RPM, so RPM for F21 will contain some tests above F20 and so on..
13:37:17 <juhp> or tests branches perhaps?
13:37:27 <hhorak> juhp: actually that's something we should think of as well, we cannot pretend one size does fit all..
13:37:47 <nphilipp> hhorak: you mean a "foo-int-tests" package that would apply to all versions of "foo"?
13:38:52 <hhorak> #idea we might consider not to support only one way to define tests, since different use cases need something different and one size does not fit all
13:40:29 <hhorak> nphilipp: well, not sure if we think the same -- I meant that the result would be foo-int-tests-1.1.fc20 that would include tests for foo-1.1.fc20 and foo-int-tests-1.1.fc21 would include tests for foo-1.1.fc21
13:41:29 <nphilipp> hhorak: hmm, I was thinking in terms of the spec file
13:43:34 <hhorak> nphilipp: ah, right. well, not sure about that, different packages use different approaches right now for components as well -- some maintainers keep specs in different versions the same and include '%if %fedora' stuff and some prefer different content in different branches and clean spec files.
13:43:45 <nphilipp> hhorak: yes
13:44:43 <hhorak> if we are able to stay flexible in that as well with tests and just are able to provide some sane recommendation -- that would be great.
13:47:09 <hhorak> #info various Fedora maintainers use different approaches right now for components -- some maintainers keep specs in different branches the same and include '%if %fedora' stuff and some prefer different content in different branches and rather have clean spec files
13:47:09 <hhorak> #idea it might be fine if we are able to stay flexible in that regard as well with tests and just are able to provide some sane recommendation
13:47:36 <sicampbell> And for software collections - i presume the tests would just be part of the collection ?
13:48:04 <juhp> hhorak, +1
13:48:05 <hhorak> sicampbell: that would make great sense to me
13:49:20 <hhorak> #idea for software collections -- the tests would just be part of the collection
13:50:59 <hhorak> anyway, if nobody stops me and tells me this idea is bullshit, I'll integrate some of the feedback so far (thanks for it) and will send some proposal to the @devel list.
13:51:11 <juhp> sounds good
13:51:23 <hhorak> #action hhorak will send proposal about integration tests to the devel list
13:55:31 <hhorak> well, to be honest, I had some more crazy ideas how integration testing could work in open-source world :)
13:55:31 <hhorak> if we take the packages with tests as fedora components -- why not maintain them in upstream fashion, on github for example? then fedora and also other distros could contribute.. And the crazy idea also included some open hub to submit those tests, but it is probably too much :)
13:56:00 <nphilipp> not so crazy after all, upstreaming of some sort
13:56:01 <juhp> aha
13:56:32 <bkabrda> I think that's a very good idea
13:56:52 <nphilipp> would need a fair level of abstraction though, e.g. rpm vs. deb -- yum/dnf vs. apt -- different build systems
13:57:15 <juhp> yeah - not sure packaging is the best approach for that
13:57:47 <hhorak> nphilipp: exactly, something a bit bigger than what I have resources for :)
13:57:56 <nphilipp> heh
13:58:45 <nphilipp> we could still aim for it, in terms of not losing it out of sight
13:59:08 <hhorak> nphilipp: yeah, why not
13:59:29 <hhorak> anyway, anybody has some experiences with openqa from opensuse?
13:59:41 <nphilipp> as in: not spread concrete calls to rpm/yum/dnf/whatever else is distro specific all over the place
13:59:55 <bkabrda> I've gotta run for today. sorry. see you guys
14:00:02 <nphilipp> take care
14:02:18 <sicampbell> I like the idea
14:02:39 <hhorak> nphilipp: that is probably one part we might recommend for writing tests -- do it using some level of abstraction (already mentioned beakerlib has such abstraction), so we won't touch any concrete too, just say "InstallPackage httpd"
14:03:06 <juhp> ah
14:03:12 <nphilipp> hhorak: hehe, there's the tiny issue of that packages are named differently between distros :)
14:03:27 <nphilipp> sometimes
14:03:37 <hhorak> nphilipp: yeah, not that tiny actually, not sure how we could solve this..
14:04:24 <hhorak> well, we still need to do some downstream patching, sine we do not live in perfect world, so that might be the answer in that case..
14:04:53 <nphilipp> hhorak: hm, either do some "if (%opensuse >= ...) InstallPackage suses-name-for-httpd else ...", or something like attempt to install the one, if that fails, try the other...
14:05:22 <sicampbell> How do people on places like the opensuse build service deal with the different names per distro ?
14:05:45 <nphilipp> sicampbell: I imagine the different distros are self-contained namespaces
14:06:03 <nphilipp> sicampbell: so if you build for Fedora, you get Fedora names
14:06:22 <nphilipp> I'd be surprised if they abstracted name differences away, cause that way lies madness
14:07:29 <hhorak> #idea if we are able to provide the integration tests as real upstream projects that other distros could benefit from as well, we can start some nice collaboration and benefit all from that (pretty challenging idea, but might be worth keep in mind)
14:09:31 <hhorak> ok, let's see how it evolves on @devel list..
14:10:23 <sicampbell> nphilipp: just quickly looking at some packages on obs - looks like if you build rpm - you get one name, and deb you get a different name - so the logic is in the spec/control files.
14:10:43 <nphilipp> sicampbell: ok, it's madness then :D
14:11:00 <sicampbell> nphilipp: :-)
14:11:07 <nphilipp> sicampbell: unless they simply have separate spec and deb control files
14:11:24 <sicampbell> nphilipp: They do.
14:11:28 <nphilipp> then it's a bit more work to keep it consistent, but at least not ugly
14:11:57 <nphilipp> sicampbell: that's what I meant -- they probably have separate specs/deb control files for each distro
14:13:43 <juhp> ok
14:15:13 <hhorak> if we're done on this topic, let's move to the most favorite one.. :)
14:15:13 <hhorak> #topic Picking chairman for the next meeting
14:15:34 <hhorak> #info hhorak is actually not available the next week..
14:16:37 <hhorak> bkabrda, vpavlin and pkovar might also be unavailable, since we have public holiday here :)
14:17:10 <juhp> ah
14:17:23 <juhp> or should we skip next meeting then?
14:17:40 <hhorak> yeah, might make sense
14:17:50 <sicampbell> I think if most people are not here it make sense to skip
14:18:00 <juhp> of course still need chair for following week ;)
14:18:14 <juhp> :)
14:18:44 <juhp> (s/meeting/week/)
14:19:40 <hhorak> #info let's skip the next week's meeting, since many of use won't be here
14:20:16 <juhp> when does EU Summer Time end btw?
14:21:12 <sicampbell> Last weekend in October I think ?
14:21:32 <sicampbell> And Nov 2 in the US
14:22:37 <nphilipp> EU: last sunday in oct
14:22:52 <sicampbell> Just checked - Sunday, October 26
14:22:57 <juhp> thanks
14:23:54 <juhp> do we plan to follow that for the meeting time btw?
14:24:24 <juhp> I think US is changing the following weekend
14:25:17 <nphilipp> Meeting times are documented in UTC, so it would move the time from 3pm to 2pm for Central Europe
14:25:42 <sicampbell> nphilipp: And to 8am for me :-(
14:25:55 <juhp> sicampbell, only for one week
14:26:00 <sicampbell> indeed!
14:26:07 <juhp> where we won't have a meeting I guess :)
14:26:30 <hhorak> thanks for pointing to that, but since we skip the next week we should have all the same time again the 4th Nov, right?
14:26:46 <juhp> yes - except me :-)
14:27:09 <juhp> starting earlier will be better for me anyway :)
14:27:09 <sicampbell> Now that sounds like excellent planning
14:27:20 <sicampbell> jhup: where are you in the world ?
14:27:25 <juhp> Japan
14:27:29 <hhorak> juhp: there is no Summer time at your place?
14:27:34 <juhp> no :)
14:27:51 <sicampbell> Or is it just summer all the time? :-)
14:27:59 <juhp> haha if you like
14:28:24 <juhp> hmm actually I am not good at calculating - does it mean later for me...?
14:28:29 <juhp> anyway...
14:28:37 <juhp> sorry to change the topic
14:29:06 <hhorak> juhp: yeah I'm afraid it means later for you, how bad is it?
14:29:08 <juhp> seems so perhaps
14:29:34 <juhp> well it is not great but not as bad at the Workstation WG ;)
14:30:40 <hhorak> juhp: so can we keep the EU/US timing?
14:31:20 <hhorak> it's always touch, nick has the opposite issue, so moving would just make issues to someone else but won't solve much..
14:31:21 <juhp> hhorak, well I suppose for now - of course starting earlier would be more attractive for me
14:32:19 <juhp> hhorak, isn't same issue really for Nick?  (though of course he has opposite DST)
14:32:43 <juhp> ah no DST in BNE
14:32:46 <juhp> anyway
14:33:16 <nphilipp> hhorak: why would nick have the opposite issue in BNE?
14:33:50 <nphilipp> hhorak: conflicting meetings?
14:34:01 <hhorak> nphilipp: sorry, scratch that, forgot that Nick is in BNE :)
14:34:04 <nphilipp> otherwise I'd imagine sooner is better for .au
14:34:10 <juhp> yeah
14:34:28 <juhp> so the time change will affect he adversely too I fear
14:34:43 <juhp> or should we stick with the UTC time? :)
14:34:58 <Southern_Gentlem> stick with utc and be done
14:35:38 <juhp> it will be early for sicampbell though
14:35:56 <juhp> s/he/him/
14:36:21 <sicampbell> juhp: he/him
14:36:45 <sicampbell> juhp: Stuart
14:37:11 <nphilipp> sicampbell: juhp meant "substitute "he" with "him" :)
14:37:36 <sicampbell> Sorry - obviously not enough coffee this morning yet! :-)
14:37:41 <nphilipp> sicampbell: "juhp> so the time change will affect he adversely too I fear"
14:37:51 <nphilipp> heh
14:38:00 <juhp> he = Nick :)
14:38:04 <juhp> anyway
14:38:43 <juhp> or when good do another whenisgood on the mailing list, dunno...
14:39:04 <juhp> I think I can live with the new time if necessary
14:39:12 <juhp> ugh tired
14:39:23 <juhp> or we can do another whenisgood on the mailing list, dunno...
14:39:31 <juhp> !
14:40:18 <hhorak> #info let's leave picking a new time to ML discussion and try a new whenisgood
14:40:27 <juhp> okay
14:40:58 <sicampbell> Sorry - got to run to another meeting.  bye.
14:40:59 <juhp> we might be less constrained now perhaps
14:41:12 <hhorak> and I should be ready to chair the meeting in two weeks..
14:41:23 <hhorak> #action hhorak will chair the meeting in two weeks..
14:41:31 <juhp> :)
14:41:38 <hhorak> I guess we're done anyway, so thanks a lot!
14:43:35 <hhorak> #endmeeting