13:00:25 <hhorak> #startmeeting Env and Stacks (2015-03-12)
13:00:25 <zodbot> Meeting started Thu Mar 12 13:00:25 2015 UTC.  The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:30 <hhorak> #meetingname env-and-stacks
13:00:30 <zodbot> The meeting name has been set to 'env-and-stacks'
13:00:34 <hhorak> #chair bkabrda hhorak juhp ncoghlan vpavlin sicampbell walters ttomecek phracek
13:00:34 <zodbot> Current chairs: bkabrda hhorak juhp ncoghlan phracek sicampbell ttomecek vpavlin walters
13:00:46 <hhorak> hello, who do we have here today?
13:00:52 <bkabrda> hi!
13:03:04 <ttomecek> I'm here too, hello
13:05:33 <hhorak> #topic Dockerfiles recommended tips
13:06:27 <langdon> .hello langdon
13:06:28 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
13:06:35 <hhorak> it seems to me like nobody things having the tips in the tool is a brilliant idea and as ttomecek stated, we'll better see as soon as we'll have some concrete data
13:07:22 <hhorak> #proposal let's start with separate git repo for the guidelines and include it into dockerfile_lint if it turns to be good idea later..
13:07:51 <ttomecek> +1
13:07:52 <ncoghlan> +1
13:08:11 <hhorak> langdon: btw. any info about the possible movement of dockerfile_lint to projectatomic space?
13:08:11 <bkabrda> hhorak: I'm sorry, I didn't have that much time to catch up... what guidelines are we talking about?
13:08:28 <hhorak> dockerfile guidelines/best practices..
13:08:52 <ttomecek> would be fine to prefer rules in guidelines which are easy to check by the linter
13:09:25 <langdon> hhorak, no.. sorry.. havent followed up (had/have a release this week and have been distracted)
13:09:32 <bkabrda> ttomecek: +1. people are much more likely to react to warnings/errors than read a document about how things should be done
13:10:11 <langdon> bkabrda, i think we are not talking about "guidelines" in the fpc sense.. more the generic definition, correct y'all?
13:10:13 <hhorak> langdon: never mind..
13:10:20 <bkabrda> preferrably, the linter should say "warning: this and that is bad, have a look at the long explanation in guidelines to see why"
13:10:40 <ttomecek> bkabrda, definitely; would be also awesome if we built universal rules usable by anyone (thus making the tool to be "the linter" for dockerfiles)
13:10:46 <langdon> bkabrda, it actually displays a little message which could have a link now.. i believe
13:12:00 <bkabrda> sounds good
13:12:16 <hhorak> #info people are much more likely to react to warnings/errors than read a document about how things should be done
13:12:16 <hhorak> #info the linter should say "warning: this and that is bad, have a look at the long explanation in guidelines to see why"
13:12:16 <hhorak> #info the linter should (maybe already does) display a little message which could have a link now
13:13:01 <langdon> hhorak, ooo.. i have email about it.. i can read it soon'ish and see status..
13:14:05 <ncoghlan> we have some experience with this kind of tooling in the form of rpmgrill & rpmdiff
13:14:26 <ncoghlan> (the names are a lie, they actually analyse full koji builds)
13:15:03 <ncoghlan> is there someone I can put those folks in touch with to see if there's a good way for us to offer advice?
13:15:10 <ncoghlan> and perhaps contribute
13:15:42 * dgilmore notes Dockerfiles for F22 need ported to dnf
13:15:51 <ncoghlan> roman has been chatting to tflink on qa-devel re rpmgrill
13:16:15 <ncoghlan> I'm just not sure where best to point him for dockerfile_lint
13:16:41 <hhorak> dgilmore: good point, thanks..
13:16:41 <hhorak> #info dockerfiles for F22 need ported to dnf
13:17:37 <ncoghlan> bkabrda: in terms of lessons learned, have a numeric error catalog from the start
13:17:58 <ncoghlan> not number your warnings/error messages/guidelines = recipe for future pain
13:18:17 <ncoghlan> because you have no way to configure it sensibly
13:18:43 <bkabrda> ncoghlan: good point
13:18:57 <ncoghlan> bkabrda: this is why I want to know where to direct rjoost
13:19:06 <ncoghlan> because we can tell you all sorts of things *not* to do :)
13:19:10 <hhorak> ncoghlan: do we have a better contact than github user account? https://github.com/lphiri
13:19:17 <hhorak> or langdon? ^
13:19:31 <bkabrda> ncoghlan: well, it's not like I'm volunteering to work on this.. ;)
13:20:04 <hhorak> ncoghlan: very true about the error catalog -- fortunately there is at least error label now.. do you think it is enough?
13:20:25 <ncoghlan> well, we're also wondering if we might be better advised to put off some of our work on making the older build analysis tools easier to use
13:20:50 <ncoghlan> and put some of those lessons learned into the docker analysis tools from early on
13:21:34 <ncoghlan> maybe the place to start is for me to suggest to Roman & Sunil that they join the envs & stacks list
13:22:10 <hhorak> ncoghlan: sounds good
13:22:23 <ncoghlan> specifically to provide feedback on the dockerfile_lint side of things
13:22:51 <ncoghlan> #action ncoghlan to suggest to rpmgrill devs that they join Envs & Stacks to discuss dockerfile_lint
13:23:58 <ncoghlan> hhorak: re error label vs error catalog, I don't know, hence why I think it may be a good idea to invite the rpmgrill folks to participate directly
13:23:59 <hhorak> one more point about the documentation part -- what I'm still struggling with is a structure -- thinking more about to base it on *use cases*... rather than set of guidelines that packaging guidelines in fedora do..
13:24:14 <hhorak> ncoghlan: ok
13:27:12 <ttomecek> hhorak, makes sense to me; but the thing is if we provide it in form of use cases, it will be hard to search in it
13:27:19 <langdon> hhorak, sorry.. bus-> office transition
13:27:21 * langdon reading scrollback
13:29:27 <hhorak> ttomecek: true.. so what the usage should look like actually from user's PoV? (thinking loudly) say I want to write a dockerfile for apache.. I read some "always true guidelines" and then what?
13:29:34 <hhorak> some chapter about daemons...?
13:29:49 <langdon> ncoghlan, im trying to get the people who own the linter project to move it under projectatomic.. have some emails about it that i need to reply too..
13:30:20 <langdon> but i second hhorak's suggestion
13:31:24 <ttomecek> hhorak, and there would be also section for web apps, desktop apps, dynamic languages, probably stuff specifically for ruby/python/...
13:33:54 <hhorak> nice, it starts to have some real shapes now
13:35:21 <hhorak> however, there will be things that may be common for more (but not all) of the scenarios (like handling with passwords given by env. variables).. these stuff should have some common (general) place probably... and just use linking from scenarios, where it is expected..
13:35:38 <ncoghlan> it's probably best to start with specific use cases
13:35:59 <ncoghlan> and then factor them out into more general cases
13:36:02 <ttomecek> hhorak, yep, there should definitely be a "general" section
13:36:15 <ncoghlan> as we identify patterns
13:38:29 <ttomecek> plus one to what Nick is saying
13:40:53 <hhorak> Anybody has something more about dockerfiles?
13:42:27 <hhorak> #info the documentation about dockerfiles practices/guidelines should be based on use cases (what am I creating the dockerfile for) and some general sections..
13:42:40 <hhorak> #topic Playground repo revisiting
13:43:35 <hhorak> it's been a long time we talked about this idea and there was a blocker (signing copr packages) that seems to be fixed now (thanks copr guys!)
13:44:17 <hhorak> btw. for anybody who is not familiar with this idea, just read:
13:44:17 <hhorak> #link https://fedoraproject.org/wiki/Changes/Playground_repository
13:44:17 <hhorak> #link https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29
13:45:56 <hhorak> what seems to need some polishing (or write-up) is how it should work from user's side..
13:46:33 <walters> interesting
13:46:48 <hhorak> after re-reading the two pages above it seems to me like everything users would need is:
13:46:48 <hhorak> dnf enable playground
13:46:48 <hhorak> dnf install nice-play-pkg
13:48:18 <ncoghlan> I'm still not clear myself
13:48:19 <hhorak> I'm not sure if dnf plugin is required after we decided to enable the copr repos by installing all the repo files by one package... (https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29#SOLVED_-_1_Big_repo_vs_multiple_small_ones)
13:48:48 <hhorak> so maybe the first part wouldn't be `dnf enable playground`, but just `dnf install playground-repo`?
13:48:58 <ncoghlan> ah, so there's one "playground-repos" package in Fedora?
13:49:25 <ncoghlan> and submitting a new COPR for inclusion means respinning that package?
13:49:34 <ncoghlan> (likewise for removing a COPR)
13:50:15 <ncoghlan> I think the change proposal and/or draft may need to be updated with some more technical specifics
13:50:20 <ncoghlan> on the user experience side
13:51:02 * bkabrda needs to reread the proposal...
13:52:13 <hhorak> so we can leave this topic for the next meeting to have some more time for re-reading it...
13:52:17 <bkabrda> ok, so if we're going with "repo of repos", wouldn't it suffice to use a "dnf copr enable"-like approach?
13:52:40 <ncoghlan> I'm re-reading the vote, and I don't think it decide the question of the how the playground UX would work in Fedora
13:52:56 <hhorak> bkabrda: but that would mean we don't need playground at all, right?
13:53:18 <ncoghlan> it just decided that it's *contents* would be determined by flagging COPR repos as part of the Playground
13:53:30 <bkabrda> hhorak: well, the playground is meant to have certain guarantees compared to "just a copr"
13:53:42 <ncoghlan> however, I think there's a good case to be made for "all the Playground COPR repos"
13:54:08 <ncoghlan> because if you just want one COPR... then there's already "dnf copr enable <name>"
13:54:20 <ncoghlan> and that works regardless of whether its in the playground or not
13:54:24 <hhorak> so it would work the same as dnf copr plugin, it would just work with "better" copr projects only?
13:54:34 <langdon> bkabrda, +1 ... i personally definitely think there are two levels.. as proven by my non-updated corebird repo from ryanlerch :)
13:55:21 <bkabrda> hhorak: well, yeah. I don't see how you could make it any more simple than how "dnf copr enable" works, anyway...
13:55:48 <ncoghlan> bkabrda: I'm picturing something more along the lines of EPEL-for-Fedora or RPMFusion
13:56:16 <ncoghlan> a selection of non-conflicting COPRs with cool stuff in them
13:56:36 <ncoghlan> so if something is in Playground, you can just install it and expect regular updates
13:56:48 <ncoghlan> but not the same stability guarantees you'd get from the main repo
13:57:37 <hhorak> bkabrda: it could be easier in a sense that you don't need to pick the copr ... you would just have all the nice packages available as soon as you enable the playground repo..
13:58:05 <bkabrda> then the real question is whether the "non-conflicting" part is or is not a problem for playground
13:58:36 <bkabrda> I always thought we'd allow conflicting repos, but I do agree that this may get ugly pretty quickly when people enable more of them...
13:58:38 <ncoghlan> one possible way of looking at it: Playground is where you'll find all the stuff we'd like to have in the main repos, but doesn't meet packaging policy guidelines
13:58:53 <ncoghlan> bkabrda: I don't see any need, as COPR already handles that
13:59:00 <bkabrda> yeah, I guess I just need to change my perception :)
13:59:13 <bkabrda> *perspective
13:59:25 <ncoghlan> since we can't get any simpler than "dnf copr enable" for potentially conflicting stuff
13:59:35 <bkabrda> ncoghlan: true
13:59:53 <ncoghlan> whereas its easy to make non-policy compliant stuff like chromium nonconflicting
13:59:56 <langdon> ncoghlan, i disagree... not in the point ... but in that you dont need both.. copr is janky.. playground is "wants to grow up to be main, but not ready yet"
14:00:10 <ncoghlan> langdon: you do need both
14:00:38 <langdon> ncoghlan, maybe i misunderstood your remark then?
14:00:42 <ncoghlan> I was about to continue on to "dnf install playground && dnf install chromium" is a workflow we want to enable
14:01:11 <langdon> ncoghlan, i will say, i like the "enable" language better.. i think it implies more affiliation with fedora..
14:01:30 <bkabrda> I'd probably just suggest "dnf playground enable" than "dnf install playground"
14:01:41 <ncoghlan> where you can swap "chromium" for any other "can't be in main for reasons that end users probably don't care about"
14:01:50 <ncoghlan> yeah, I don't mind the command name
14:02:34 <ncoghlan> I was just assuming a normal package, but a specific subcommand works too
14:03:32 <ncoghlan> let me have another go at explain my viewpoint:
14:03:42 <hhorak> bkabrda: actually we can offer both, right? if there is a set of nice coprs -- people either may enable them one by one or enable them all -- so we can support both "dnf playground enable somecopr" and "dnf install playground" (enables all coprs from playground)
14:04:15 <ncoghlan> COPR: anything goes (except legally), buyer beware, may eat your data if it's truly an experimental build
14:04:24 <bkabrda> hhorak: assuming none of them conflict, I don't see why we'd need "dnf playground enable somecopr"
14:04:54 <ncoghlan> Playground: software itself is good enough for main, but it can't be in main yet for distro policy reasons
14:05:28 <ncoghlan> right, I don't think we need selectivity for playground, because copr is already selective
14:06:03 <ncoghlan> that means we can make playground a "almost main, but not quite" pool of software
14:06:46 * ncoghlan looks at time
14:07:00 <langdon> just a thought.. when you say "non-conflicting" .. do you mean "no newer versions"? or "no conflicts with main even if a newer version"? (or, older, potentially, as well)
14:07:12 <ncoghlan> I have to be up earlyish folks, so I'm going to head to bed - g'night
14:08:26 <bkabrda> langdon: I'm not sure, I really have to reread the proposal again and make up my mind about what exactly I want :)
14:08:38 <hhorak> There is one nice comment in the end of the current version of the draft: "Possible conflicts are between features. It's not ideal but that way  there *can* be conflicts and they are not catastrophic. People who want  to test django do not necessarily want to test Chromium (or other way  around) "
14:08:39 <langdon> bkabrda, ha
14:12:46 <hhorak> so, to summarize it -- we haven't agreed yet if conflicts within playground repo are fine and if possibility to install coprs selectively is necessary, right?
14:12:46 <hhorak> does allowing conflicts requires selective install btw.?
14:13:10 <hhorak> imho it does not ^
14:13:49 <hhorak> (well, if conflicts are caused by just a newer version, then it actually does)
14:13:54 <bkabrda> hhorak: well I'm not sure how the tools that will put all the coprs into one big repo would handle X different versions of package Y
14:15:55 <hhorak> bkabrda: me neither, that's probably the reason why we talked about "repo of repos" approach few months back
14:17:17 <bkabrda> hhorak: in other words, we can either have one big repo composed of N non-conflicting repos or a bunch of (possibly conflicting) repos
14:17:35 * hhorak proposing to close this topic for today and refresh the discussion we had few months back from logs/the links above (draft, change proposal), so we don't invent the same square wheels again :)
14:18:00 <bkabrda> hhorak: agreed, let's take some time to reread the proposal and think before deciding :)
14:18:23 <hhorak> bkabrda: yes, that our probably our options.. while the second option enables more content..
14:19:06 <hhorak> #action all to refresh the discussion we had few months back from logs/the links above (draft, change proposal), so we don't invent the same square wheels again.. and let's continue on ML/next meeting..
14:19:24 <hhorak> #info so far it seems we can either have one big repo composed of N non-conflicting repos or a bunch of (possibly conflicting) repos
14:19:30 <hhorak> #topic open floor
14:19:41 <hhorak> if anybody has something more, speak up!
14:23:27 <hhorak> it doesn't seem that somebody has something ...
14:23:30 <hhorak> thanks all!
14:23:33 <hhorak> #endmeeting