16:00:00 <mmaslano> #startmeeting Env and Stacks (2014-02-11)
16:00:00 <zodbot> Meeting started Tue Feb 11 16:00:00 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:05 <mmaslano> #meetingname env-and-stacks
16:00:05 <zodbot> The meeting name has been set to 'env-and-stacks'
16:00:19 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
16:00:19 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez
16:00:26 <mmaslano> #topic init process
16:00:35 <samkottler> .hellomynameis skottler
16:00:36 <hhorak> Hi guys!
16:00:36 <zodbot> samkottler: skottler 'Sam Kottler' <skottler@redhat.com>
16:00:45 <tjanez> Hey
16:00:48 <abadger1999> Good evening, day, morning :-)
16:01:02 <drieden> Hello!
16:01:07 <mmaslano> .hellomynameis mmaslano
16:01:08 <zodbot> mmaslano: mmaslano 'Marcela Mašláňová' <mmaslano@redhat.com>
16:01:14 <mmaslano> wow it works
16:01:46 <mmaslano> #topic vission statement
16:02:02 <mmaslano> there was proposal on list
16:02:09 <mmaslano> #proposal
16:02:11 <mmaslano> Fedora is the preferred platform for software development and
16:02:12 <mmaslano> deployment in any language or application stack.
16:02:42 <mmaslano> There was only one +1
16:02:49 <mmaslano> do you want to change it or accept it as is?
16:03:32 <tjanez> I don't know if it counts, but on last meeting, bkabrda and juhp_ were +1 on it
16:03:42 <mmaslano> okay
16:03:46 <mmaslano> some -1?
16:03:46 <drieden> +1
16:03:47 <tjanez> we just wanted everyone to vote on it
16:03:50 * mmaslano +1
16:03:59 <pkovar> let me add my +1 then
16:04:05 <tjanez> since we felt it was such an integral part of our WG
16:04:33 <abadger1999> +1
16:05:27 <mmaslano> samkottler: do you agree with Vision?
16:05:32 <mmaslano> otherwise it's +8
16:05:44 <samkottler> +1 on the vision
16:06:24 <mmaslano> #agreed New Vision: Fedora is the preferred platform for software development and deployment in any language or application stack. (+9,-0,0)
16:06:28 <hhorak> mmaslano: hope you count my +1 from mail (still valid)
16:06:38 <mmaslano> hhorak: yeah, from mailing list
16:06:49 <mmaslano> #topic irc-channel
16:07:00 <mmaslano> #info Debi already set channel
16:07:27 <drieden> Yes, irc is #fedora-stacks
16:07:33 <tjanez> drieden, thanks for setting it up!
16:07:36 <mmaslano> #info everyone interested in op should ask her
16:07:39 <mmaslano> drieden: thank you
16:08:00 <drieden> tjanez mmaslano You are welcome.  Glad to help out.
16:08:26 <mmaslano> now complicated issues
16:08:34 <mmaslano> #topic working on tasks from PRD (finally)
16:09:04 <mmaslano> I picked two topic, but I'm afraid we won't have enough time
16:09:40 <mmaslano> #topic 3rd party repositories
16:10:19 <mmaslano> I gues it's related to mailing thread
16:10:24 <mmaslano> #info half baked idea for further baking: "fedora-ugly" repo
16:11:34 <jreznik> I hope you read my idea of approved set of coprs being used instead for fedora-ugly :)
16:11:48 <tjanez> I don't know if you had the time to read the thread yet, there's been some good discussion already
16:12:27 <tjanez> jreznik, I approved your two emails, since you haven't subscribed to the env-and-stacks ML yet
16:12:33 <jreznik> oa, probably on the another list
16:12:50 * jreznik is going to subscribe
16:13:36 <jreznik> cross posting between lists will kill me one day :)
16:13:59 <mmaslano> jreznik: I see you proposed using more coprs repositories instead of one
16:14:05 <mmaslano> what's the gain?
16:14:36 <mmaslano> also what if user wants to add perl, python34, nodejs and 10 more?
16:14:37 <jreznik> mmaslano: coprs are there, no need for a really new workflow
16:14:53 <jreznik> mmaslano: would this go to ugly? I think these are more scl
16:15:14 <mmaslano> jreznik: some SCL currently have interSCL dependencies
16:16:05 <jreznik> and the only rule for being that approved set of copr would be co-installability
16:16:17 <jreznik> then software installer will pick up these
16:16:24 <mmaslano> how?
16:16:39 <jreznik> and in the result you have one repository (for users) created from several coprs
16:16:44 <mmaslano> someone will say these coprs are nice and that's it?
16:16:50 <tjanez> jreznik, I dislike your proposal
16:17:07 <mmaslano> jreznik: ok, so now we are getting somewhere
16:17:26 <mmaslano> tjanez: could you elaborate?
16:17:30 <tjanez> I think we need some kind of another layer around core
16:17:40 <tjanez> by core meaning Fedora's current main repo
16:17:43 <jreznik> tjanez: and this would be that layer
16:18:05 <jreznik> instead of creating another layer between core and coprs
16:18:10 <tjanez> jreznik, this layer could be feed from COPRs
16:18:15 <jreznik> with new rules, new maintainance overhead etc.
16:18:43 <tjanez> jreznik, you still need some rules on which COPRs you'll pick
16:18:43 <pingou> so one .repo files including multiples repo definition in it
16:18:44 <jreznik> tjanez: yes, that's what I'm talking about - just do not feed, union them (maybe union could be feeding this "repository")
16:18:46 <mmaslano> I don't see much difference between your opinions
16:18:54 <jreznik> tjanez: some rules, yes, but minimal
16:19:13 <jreznik> I think that conflict rule is the most important one, could be done in taskotron
16:19:33 <jreznik> but otherwise let copr maintainers decide if they are going to be really ugly
16:19:42 <jreznik> or incubators for inclussion in inner layer
16:19:55 <tjanez> jreznik, did you have the time to read the thread yet
16:20:00 <tjanez> some good ideas were there
16:20:07 <jreznik> tjanez: not yet, will read it
16:20:28 <mmaslano> jreznik: ad taskotron. Does it work?
16:20:35 <jreznik> sorry for disturbing your meeting without reading it before I read it, /me is going to silent mode
16:20:38 <mmaslano> can we really use it right now?
16:20:51 <tjanez> jreznik, I think we are not that far away in our opinions
16:21:11 <jreznik> tjanez: I think we actually talk about the same, just with a bit different implementation
16:21:20 <mmaslano> yes
16:21:25 <jreznik> good to hear :)
16:23:22 <jreznik> tjanez: I just read message from mattdm - it's what we talked about at devconf with that difference he's no more "feed", I'm still more convinced in "union" :)
16:24:27 <tjanez> jreznik, what did you mean with "he's no more "feed""?
16:24:45 <jreznik> tjanez: ah, "he's more for..."
16:25:00 <jreznik> sorry, not feeling very well, should go to the bed
16:25:13 <jreznik> that signing problem could be an issue
16:26:59 <jreznik> mmaslano: taskotron is under development, tflink should have actual status
16:27:03 <hhorak> I'm not sure what the difference between feed and union is -- feed is composed by user, while union is composed by distribution?
16:27:17 <tjanez> jreznik, well, I think mattm's idea was to have some middle ground between wilderness of COPRs and current "castle" that is Fedora's main repo
16:28:05 <jreznik> tjanez: yeah, seems like
16:28:13 <tjanez> I guess how to actually populate this "ugly" repo is still open, but I think it will be whatever packagers put in that meets a set of minimal requirements
16:28:47 <tjanez> and by minimal, I really want a small, but enforcable policy
16:29:13 <mmaslano> conflicts, license?
16:29:20 <jreznik> tjanez: it probably doesn't matter if you do that union of coprs at build system level (that check) or by creating a list of currated repos unioned later... so the idea is very same
16:29:29 <jreznik> tjanez: definitely
16:29:33 <jreznik> mmaslano: yes
16:29:35 <tjanez> mmaslano, +1, I would add not over-ride main repo
16:29:56 <jreznik> if that ugly repo is going to be feed, I'm ok with that this way
16:30:16 <mmaslano> #info union/feed repository can't contain conflicts, wrong licenses, and do not over-ride main repo
16:30:17 <jreznik> just I'd like to avoid having another repo with own workflow, tooling, rules, governance
16:30:29 <abadger1999> I think one copr repo or a union of copr repos (or even built in other buildsystem than copr) are implementation.... so I'd say, whoever works on this should decide that aspect.
16:30:32 <samkottler> where do we create the line for overriding, though?
16:30:32 <mmaslano> jreznik: no, that sounds like too much work
16:30:36 <tjanez> jreznik, I think you understand rel-eng way better than me, so I'll listen to you on implementational ideas
16:30:39 <samkottler> what about providing more recent versions?
16:30:42 <abadger1999> mmaslano: Hmm... about overriding main repo...
16:30:50 <mmaslano> samkottler: new version go into SCL :)
16:30:51 <abadger1999> Don't we want a place for that as well?
16:31:05 <samkottler> mmaslano: that doesn't really work for system libraries, though
16:31:16 <mmaslano> do you mean by overriding package-1.1 will be updated to package-1.2?
16:31:24 <samkottler> mmaslano: yep
16:31:31 <mmaslano> samkottler: it's harder to do :)
16:31:32 <jreznik> abadger1999: yes, it's implementation and I think we're now on the same boat :)
16:32:31 <jreznik> samkottler: then copr, scl... we should set some expectation what you get when you enable that repo
16:33:12 <mmaslano> for example: does cloud WG want to install from there?
16:33:13 <jreznik> and I understand it as "make it easier for packages that do not need full strict rules we have in fedora" to help people include stuff in fedora
16:33:14 <samkottler> jreznik: I agree, it's just that when I enable the 'dirty' repo I also expect there to be some unexpected issues, too
16:33:19 <mmaslano> like depend on it?
16:33:32 <samkottler> mmaslano: nope, the cloud WG probably wouldn't do that
16:33:37 <jreznik> samkottler: then let's don't call it dirty/ugly - it's all about message
16:33:58 <abadger1999> Just re-read mattdm's initial fedora-ugly  proposal... I'm not sure if it is useful or if we truly need a more wilderness-y copr type thing.
16:34:06 <samkottler> jreznik: I'm not talking about the name, I'm talking about the concept. the packages are inherently low quality
16:34:08 <hhorak> right, the name ugly is ugly
16:34:11 <abadger1999> But somehow "more accessible"
16:34:54 <tjanez> regarding the naming of the repo and setting users' expectations, please read my email
16:34:59 <mmaslano> samkottler: they don't have to be lower quality. Just not accepted in Fedora for various reasons
16:35:10 <jreznik> mmaslano: yep
16:35:43 <samkottler> a training ground for packagers is going to be inherently of lower quality
16:35:43 <tjanez> for the reference: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-February/000197.html
16:36:15 <jreznik> and that's why I'd more like to see standalone units/repos being merged together as some people would like to be that ugly, never going to fedora main repo (thus ugly), some people would like to use it as incubator (to be included in inner circles)...
16:36:32 <jreznik> samkottler: training ground are coprs
16:36:40 <tjanez> samkottler, yes, it will be lower quality
16:36:55 <tjanez> but it will let way more people "play" with us
16:37:04 <samkottler> yes, I understand the point
16:37:22 <samkottler> I'm just questioning not being able to provide updates in the repo
16:37:54 <tjanez> samkottler, so there's been some ideas regarding the lifecycle of this new (ugly) repo
16:38:29 <tjanez> I tend to lean towards following the Fedora main repo's lifecycle
16:38:49 <tjanez> (I know this will change with the new products)
16:42:10 <mmaslano> tjanez: current SCLs in copr can be stable for more years or exists just for testing
16:42:31 <mmaslano> We should verify by automatic testing if coprs in repo are still working with new release
16:43:23 <tjanez> mmaslano, so these COPRs could be included/feed into more versions of the "ugly" repo
16:43:43 <mmaslano> tjanez: yes
16:44:02 <tjanez> like Python2.6SCL in ugly-f20, ugly-f21, ugly-f22, ...
16:44:08 <mmaslano> there's lot of ideas. Does someone want to write them down and prepare proposal?
16:46:26 <tjanez> mmaslano, I would suggest we discuss it on the ML and when some things clear up/converge, someone writes a proposal
16:46:43 <mmaslano> fine
16:46:45 <tjanez> or do you feel, it has already converged to something?
16:46:57 <mmaslano> not yet :) but we will run out of time
16:47:04 <tjanez> mmaslano, roger :)
16:51:03 <mmaslano> still 10 minutes :)
16:51:20 <mmaslano> I would start with name or we end up with ugly
16:52:18 <drieden> I would prefer a different name than ugly, but don't have a suggestion atm.
16:53:04 <hhorak> so far the proposals were: ugly, incubator, staging
16:53:16 <hhorak> I have also playground on my mind..
16:53:17 <mmaslano> #action on mailing list will be discussed better name than ugly (incubator, staging, ...)
16:53:20 <abadger1999> I guess part of it depends on what the purpose is...
16:53:24 <mmaslano> hhorak: also good one
16:53:29 <mmaslano> abadger1999: yes
16:53:37 <tjanez> hhorak, plus my two: Fedora Easy(TM) or Fedora Mantle
16:53:41 <abadger1999> i think mattdm accurately pointed at why staging might not be a good name.
16:53:43 <mmaslano> abadger1999: we might need input from other products
16:54:02 <abadger1999> but it depends on how closely the repo's purpose conforms to what he was asking for.
16:54:19 <mmaslano> #info name for new repo: incubator, Fedora Easy(TM) or Fedora Mantle, playground
16:54:39 <abadger1999> in the playground vein: sandbox
16:55:43 <mmaslano> #info name for new repo: sandbox
16:56:21 <mmaslano> okay, so I can ask other WGs what would be their usecases
16:56:30 <mmaslano> and let's decide about the name next week
16:56:40 <mmaslano> we can continue in discussion how to do it on list
16:57:43 <tjanez> mmaslano, +1
16:58:28 <drieden> +1
16:58:37 <jreznik> easy sounds good :) even you can get it much more troubles when you start using it :D
16:59:07 <mmaslano> #action mmaslano will ask other WGs for their usecases of new repo
16:59:30 <tjanez> jreznik, if something breaks for users, we'll just say: "Take it easy" :)
16:59:53 <jreznik> :)))
17:00:12 <drieden> :)
17:03:26 <mmaslano> #endmeeting