15:00:31 <mmaslano> #startmeeting Env and Stacks (2014-04-08)
15:00:31 <zodbot> Meeting started Tue Apr  8 15:00:31 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:37 <mmaslano> #meetingname env-and-stacks
15:00:37 <zodbot> The meeting name has been set to 'env-and-stacks'
15:00:42 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
15:00:42 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez
15:00:47 <mmaslano> hi
15:00:52 <hhorak> Hi!
15:02:11 <tjanez> hi
15:02:31 <mmaslano> that's what I call attendance :)
15:02:47 <mmaslano> #topic init process
15:02:59 <tjanez> mmaslano, maybe we'll have a shorter meeting then :)
15:03:12 <mmaslano> so what do you think about Changes?
15:03:39 <tjanez> #topic Change proposal: Playground
15:04:14 <tjanez> I was looking through the Playgroud repo Change proposal today
15:04:51 <drieden> Hi
15:04:52 <tjanez> and I've just submitted the first part of my edits on the Wiki
15:05:09 <Kevin_Kofler> NOTICE: The KDE SIG meeting is in #fedora-meeting-1. Sorry for the interruption and back to scheduled programming. ;-)
15:05:09 <tjanez> Overall, I think it is OK.
15:05:53 <tjanez> mmaslano, is it enough that you and msuchy are listed as owners?
15:06:13 <tjanez> I guess me and other WG members can always help
15:06:20 <hhorak> mmaslano: I like it, good job.
15:06:49 <hhorak> mmaslano: maybe some POV of user installing packages from playground could be added into "User Experience"
15:07:23 <mmaslano> tjanez: wow, great job
15:07:33 <mmaslano> tjanez: I just skimmed your changes
15:07:43 <tjanez> mmaslano, thanks :)
15:08:11 <tjanez> I hope to get through the second part and also do some overall improvements
15:08:37 <drieden> tjanez The wiki looks great
15:08:48 <mmaslano> I already marked it as Ready for Wrangler
15:09:05 <mmaslano> it wouldn't be good if you touch it after jreznik sent it
15:09:20 <tjanez> mmaslano, ok, good to know
15:09:24 * masta looks in, lurks
15:09:50 <mmaslano> tjanez: and deadline is today, so I don't want to switch it back :)
15:10:02 <tjanez> so if I understand correctly, we can still make changes before jreznik sents out an email announcement
15:10:04 <hhorak> mmaslano: some really minor changes should be OK or is any touching illegal after midnight?
15:10:04 <jreznik> if you want any changes, do it
15:10:33 <jreznik> hhorak: after announcement, you should send a notice to list there were changes...
15:10:42 <mmaslano> ok
15:10:47 <jreznik> it's living document but it has to be communicated
15:10:50 <mmaslano> tjanez: so feel free to edit it
15:10:54 <tjanez> ok, cool
15:11:08 <mmaslano> hhorak: yes, how to use dnf would be good. I wrote article on my blog
15:11:22 <mmaslano> tjanez: also dnf is normally available in Fedora repo, it's just not default
15:11:27 <jreznik> btw. mmaslano for Playground one - Proposal owner in Scope section does not mean Env & Stacks WG but what you have to do to get that change done
15:12:44 <mmaslano> wasn't there my name before?
15:12:51 <mmaslano> maybe in different change
15:13:15 <tjanez> mmaslano, regarding DNF, you think that part is wrongly written in my edit?
15:13:42 <mmaslano> tjanez: um I don't think it's needed to point out what is dnf, but maybe it's not known to everyone yet
15:13:53 <tjanez> jreznik, could you explain again what is wrong with Proposal owners: Env and Stacks WG in the Scope section?
15:14:00 <mmaslano> hhorak: do you think I should link the dnf plugin to original Mirek's post about it?
15:15:06 <tjanez> mmaslano, aha, ok. Maybe some people still don't know it :)
15:15:20 <hhorak> mmaslano: I'm not sure what you're asking now ;)
15:15:21 <jreznik> tjanez: it is not who should do the work but what has to be done
15:15:31 <jreznik> in a Scope section
15:15:54 <mmaslano> hhorak: so nothing to do, fine
15:16:19 <mmaslano> jreznik: I get it
15:16:23 <mmaslano> tjanez: I'll update it
15:16:45 <tjanez> jreznik, ok, I understand now
15:16:50 <tjanez> thanks for clearing it up
15:17:29 <tflink> apologies for being late, but just to make sure I understand - all the coprs in playground should be installable at the same time?
15:17:51 <tjanez> tflink, no
15:17:54 <tflink> on a side note, wasn't the meeting supposed to be at 16:00 UTC?
15:18:16 <mmaslano> now everyone will read how dnf plugin is working :)
15:18:16 <tjanez> we decided to go with the multiple (conflicting) repositories on the last meeting
15:18:21 <mmaslano> #info http://mmaslano.livejournal.com/10322.html
15:18:41 <tjanez> tflink, 16.00 UTC was a mistake
15:19:03 <tjanez> we switched to 15.00 UTC when Europe switched to DST
15:19:14 <tjanez> sorry about that
15:19:20 <mmaslano> aha! you are right
15:19:26 <tflink> no worries, I'm just glad I noticed the meeting started
15:19:31 <mmaslano> and I have it wrong
15:20:18 <tflink> I've seen a desire for some automated checks of the playground repos, are the sub-repo conflicts declared somewhere?
15:20:22 <tflink> going to be, rather
15:20:41 <mmaslano> maybe later, we didn't define any check yet
15:20:43 <tflink> or are we assuming that folks will only use one playground sub-repo at a time?
15:21:06 <mmaslano> but I guess for next Fedora we could have another repo, that play nicely
15:21:16 <tjanez> tflink, the idea is that the users will be knowledgeable enough to select the subset of non-conflicts repos from the Playground
15:21:26 <mmaslano> tflink: I assume people who can install dnf plugin know what they are doing
15:21:28 <tflink> ok, so the current proposal is for f21 only?
15:21:34 <mmaslano> no
15:21:38 <mmaslano> I would leave it as is
15:21:50 <mmaslano> but maybe some beter shaped repositories for F22+
15:21:52 <tjanez> or be able recover when they see unrecoverable dependency problems
15:21:54 <tflink> I'm mostly interested in how we'd handle dependency checks on playground
15:22:19 <mmaslano> tflink: do you have anything ready?
15:22:36 <mmaslano> tflink: like could we set it up and send info to maintainers bout broken dependencies?
15:22:37 <tflink> for today, no. for f21, maybe
15:22:42 <tjanez> tflink, currently we decided to implement the Playground repository so we don't have to enforce any dependency or other checks
15:23:07 <tflink> it depends on some of the details of how playground is implemented, to be honest
15:23:26 <mmaslano> tflink: it's not a real repository
15:23:44 <mmaslano> tflink: I'm not sure if you are able to run checks on many small repos on copr
15:24:14 <tflink> mmaslano: I don't see why it couldn't work if each copr repo is isolated
15:24:26 <mmaslano> tflink: fine, so it can be done
15:24:39 <tjanez> There is one important open question still: What about conflicts with packages in the main repository? And how to check for that?
15:25:01 <tjanez> tflink, do you have any pointers on how to automatically check for that?
15:25:25 <tflink> finding conflicts with the main repo would be a matter of adding the main repos to the dep checking tool
15:25:57 <tjanez> hmm, you mean adding the COPR repos?
15:26:28 <tflink> it'd be running the standard release, updates, updates-testing repos in addition to whichever copr repo is currently under test
15:27:03 <tjanez> tflink, ok, that sound reasonable
15:27:18 <tflink> that should be do-able for f21
15:27:34 <tflink> the complication would be checking between copr repos
15:27:38 <tjanez> but if I understand correctly, we would have to test each COPR in turn, since we don't want to check for inter-COPR dependency errors?
15:28:17 <tflink> yeah, that's how I'm understanding playground
15:28:54 <mmaslano> yes
15:28:56 <tjanez> tflink, ok, perfect
15:29:38 <tflink> assuming that there are fedmsgs we can listen for and filter properly, it should be possible to run the standard package and repo-level checks on the COPR repos that are part of playground
15:29:51 <tflink> assuming that all the checks are desired, anyways
15:30:07 * tflink isn't sure if upgradepath is desired in this case
15:30:26 <tjanez> tflink, that would be very cool :)
15:30:50 <tjanez> well, I guess we can have the conflicts with main repo check mandatory and others can be of informative nature
15:31:59 <tjanez> tflink, we talked about "non-blocking review service" that would inform the packagers and the users about which test the package(s) passed/failed
15:32:19 <tjanez> on the last IRC meeting
15:32:34 <hhorak> tjanez: I guess that's how dep checking tool works
15:33:28 <tjanez> hhorak, yes, I glad it will work nicely with our plan
15:33:32 <tflink> ah, I figured that reviews were similar to the current package review process for inclusion in the main repos
15:34:14 <tjanez> tflink, nope, we are aiming for basically no review, just some simple automatic gating
15:35:05 <tjanez> the "review" would be the automatic service which would check the packages and put the results on some we page
15:35:09 <tjanez> s/we/web
15:35:23 <tjanez> but it would be non-blocking
15:35:35 <tflink> for taskotron, the results are stored in a webservice that also has a more human-friendly frontend
15:35:53 <tflink> the current plan is to emit fedmsgs with results as well
15:36:33 <tflink> but we don't have any concrete plans for implementing build/update gating for the main repos based on taskotron results yet
15:37:26 <tjanez> tflink, maybe we could use the Playground as a guinea pig for such build/update gating?
15:37:39 <tflink> but the consequence of false positives or negatives are much less for playground than the main repos, so it shouldn't be as big of a deal
15:38:46 <tflink> tjanez: yeah, I'd at least be interested in getting some more concrete numbers on how often there are errors
15:39:01 <tflink> ie, builds pushed when they shouldn't be or builds blocked when they shouldn't have been
15:39:33 <tjanez> tflink, yes I understand. I think Playground Beta could be a good testing ground for that
15:41:52 <tflink> yeah, that sounds like it would work well. not quite the same since bodhi wouldn't be involved, but useful none the less
15:42:33 <tjanez> sounds like a plan :)
15:43:02 <tjanez> mmaslano, this could answer our next open question: Do we allow conflicts with packages in the main repo?
15:43:22 <hhorak> tflink: tjanez: sounds interesting and I like that approach
15:43:34 <mmaslano> tjanez: no, it would say how can you check it
15:43:34 <tjanez> tflink, one more question
15:44:04 <tjanez> will taskotron also be able to check if some COPR package replaces some package in the main repo?
15:44:51 <tflink> taskotron is just a system for running checks, so in a way, yes but I don't think that is the answer you were looking for
15:45:02 <tjanez> mmaslano, agreed. But at least we have a means on how to do it, if we decide to go with yes.
15:45:05 <tflink> I'm not sure I understand what you mean by "replaces some package"
15:45:48 <mmaslano> tflink: update them
15:46:09 <tflink> are you talking about packages that would conflict with main by definition? or just newer than what's currently in main as a test
15:46:23 <tflink> like a newer version of ruby, python etc.?
15:46:32 <hhorak> tjanez: from what I know about that, replacing can be done either by having "the same package name with higher version" available or explicity define "obsoletes"
15:46:51 <hhorak> tjanez: so it should be possible to write a script that would check that
15:47:17 <tjanez> tflink, I was thinking of a scenario that hhorak described
15:47:21 <tflink> we don't have any checks for what hhorak is talking about, no
15:47:33 <tflink> but that doesn't mean that they couldn't be run
15:48:07 <tjanez> ok, I see. But hhorak's reasoning would be easy to implement
15:48:42 <tflink> once we get the initial version of taskotron released, we'll have docs on how to write additional checks that can be run
15:49:00 <mmaslano> tflink: great, so we can test it
15:49:24 <tflink> there are some other technical hurdles that we need to deal with before accepting too many other checks but supporting that use case was one of the primary reasons for creating taskotron instead of just fixing autoqa
15:49:25 <tjanez> tflink, great!
15:50:12 <mmaslano> does anyone have comments to other Changes?
15:50:21 <mmaslano> I'm slowly moving on my next meeting
15:50:56 <tflink> just to make sure I'm not accidentally promising anything: the dep checking of coprs should be possible for f21, the support for an additional check for package replacement may happen for f21 but that may end up being later
15:51:24 <tjanez> mmaslano, I hadn't had the time to read them yet
15:51:27 <tflink> my guess is later on the additional checks
15:51:59 <tjanez> #info taskotron dep checking of coprs should be possible for f21, the support for an additional check for package replacement may happen for f21 but that may end up being later
15:52:14 <tjanez> tflink, understood
15:54:03 <tjanez> mmaslano, we can decide on the remaining Playground open questions later, right?
15:55:01 <hhorak> mmaslano: regarding the SCL change .. /opt/fedora is now used as an example or that is not set in stone yet? I mean if SCL is part of playground, that would make sense.. but coprs generally can have a different prefix..
15:55:24 <mmaslano> tjanez: right
15:55:33 <mmaslano> hhorak: I need to ask spot how far is it
15:55:40 <hhorak> mmaslano: ok
15:55:48 <mmaslano> hhorak: I thought Fedora owns the directory, but it's not registered
15:56:04 <mmaslano> and I don't want to register another directory on me :)
15:56:35 <hhorak> mmaslano: understood
15:57:07 <mmaslano> #action mmaslano will find out how far is registration of /opt/fedora
15:59:37 <mmaslano> could I close it?
16:00:13 <tjanez> mmaslano, yea, I think we should wrap up
16:00:31 <mmaslano> #endmeeting