12:02:21 <mmaslano> #startmeeting Env and Stacks (2014-04-01)
12:02:21 <zodbot> Meeting started Tue Apr  1 12:02:21 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:02:25 <mmaslano> #meetingname env-and-stacks
12:02:25 <zodbot> The meeting name has been set to 'env-and-stacks'
12:02:32 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
12:02:32 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez
12:02:38 <mmaslano> #topic init process
12:02:43 <hhorak> Hi everybody!
12:02:46 <mmaslano> hi
12:02:51 <juhp_> hi!
12:03:35 <tjanez> hi everyone
12:03:46 <bkabrda1> hey
12:03:48 <drieden> Hi
12:04:05 <mmaslano> let's start with question from mailing list
12:04:12 <mmaslano> #topic Open Questions - Playground: Signing
12:04:16 <mmaslano> any objections?
12:04:39 <hhorak> +1 for obs solution, if it seems easier
12:04:45 <mmaslano> #proposal I propose using obs-signd for Copr packages hosted in Playground repo. The obs-signd won't be much work. I'd like to volunteer Josef, who is working on his thesis OBS in Fedora, to work on it sooner than on other packages.
12:04:53 <mmaslano> +1
12:05:33 <bkabrda1> +1
12:05:37 <juhp_> +1
12:05:43 <tjanez> +1
12:06:41 <mmaslano> #approved obs-signd for Copr packages will be used (+5,-0,0)
12:06:52 <mmaslano> #topic Open Questions - Playground: Provenpackagers
12:07:17 <mmaslano> #proposal
12:07:18 <mmaslano> Yes, there must be commaintainers and provenpackagers.
12:07:20 <mmaslano> If we use softwarecollections.org software we might be able to add to one copr repo more users who can maintain it. We can just copy Fedora provenpackagers list.
12:08:24 <mmaslano> I guess we can add Playground specific provenpackagers later
12:08:38 <tjanez> +1. In the future, we might consider Playground provenpackagers
12:09:04 <mmaslano> I also would like to point out that provenpackagers don't block this feature.
12:09:19 <bkabrda1> tjanez: +1, let's not make provenpackagers a blocker for now and think about them in the future
12:09:47 <juhp_> sorry I am slightly unclear on what the proposal is?
12:10:24 <mmaslano> juhp_: proposal is we need some commaintainers and provenpackagers
12:11:19 <juhp_> need means? :)
12:11:21 <tjanez> #proposal: Yes, there must be commaintainers and provenpackagers. If we use softwarecollections.org software we might be able to add to
12:11:21 <tjanez> one copr repo more users who can maintain it. We can just copy Fedora provenpackagers list. In the future, we might consider Playground provenpackagers.
12:11:54 * tjanez tried to put it into one #proposal line and failed :)
12:12:07 <juhp_> and I can't access my email for some reason
12:12:41 <hhorak> +1 (I don't even think we need to copy whole Fedora provenpackagers list, just add users who ask should be enough)
12:12:59 <juhp_> ah I think I understand
12:13:02 <mmaslano> I would solve details later, we just need something to put into Change proposals ;-)
12:13:22 <juhp_> juhp_, perhaps
12:13:37 <mmaslano> +1 to my or tjanez proposal ;-)
12:13:58 <mmaslano> agreed?
12:14:14 <juhp_> so this is about copr?
12:14:17 <bkabrda1> (I already wrote my +1, so just repeating it :))
12:14:21 <tjanez> mmaslano, currently +4
12:14:54 <juhp_> no objections - I just don't really understand the details of the requirement - probably I missed that thread sorry
12:14:57 <mmaslano> juhp_: this is about commaintainers of copr repositories inside Playground repo
12:15:05 <juhp_> okay +1
12:15:21 <juhp_> so no git requirement, I guess
12:15:43 <mmaslano> #agreed let's have comaintainers and provenpackagers in Playground repo (+5,-0,0)
12:15:46 <mmaslano> no
12:15:55 <juhp_> cool
12:16:12 <mmaslano> #topic Open Questions - distinguish packages
12:16:26 <mmaslano> #proposal Do not try to distinguish them. Rpmfusion packages also don't have different dist tag. You can find out if really want to by rpm -something or check key, which will be also different.
12:16:42 <mmaslano> I'm not sure if this proposal passed on list or not
12:18:13 <hhorak> if not passed yet, giving my +1
12:18:28 <mmaslano> +1 to my own proposal
12:18:31 <bkabrda1> +1
12:18:43 <tjanez> repeating my +1 from the ML thread
12:19:50 <juhp_> +1
12:20:21 <mmaslano> #agreed don't distinguish packages from Fedora and Playground (+5,-0,0)
12:20:33 <juhp_> It may be Ring 2 but it is still part of wider Fedora Project
12:20:46 <mmaslano> yes
12:20:52 <mmaslano> #topic Open Questions - Playground: reviews
12:21:08 <mmaslano> #topic subtopic Are conflicts inside Playground repository allowed?
12:21:19 <mmaslano> we spoke about it many times, but on list we still argue about it
12:21:32 <mmaslano> let's solve it for Playground and we can fight in other repos for different rules
12:22:25 <bkabrda1> I think that if we use the "multiple small repos approach", we don't have to care about conflicts
12:22:48 <juhp_> right
12:22:58 <tjanez> bkabrda1, there is still a problem with conflicts with package in the main repo
12:23:05 <bkabrda1> we can just say that repos may conflict with each other and it's expected that this can happen
12:23:14 <bkabrda1> tjanez: I would allow even that
12:23:49 <tjanez> bkabrda, I'm -1 on that
12:23:55 <bkabrda1> tjanez: e.g. providing the newest version of gnome in a playground repo is a valid use-case and I think it falls into definition of "conflicts with main repo"
12:24:45 <tjanez> bkabrda1, ok, nice concrete example. I disagree with a GNOME update being in the Playground repo
12:25:01 <bkabrda1> tjanez: ok, then we agree to disagree :)
12:25:11 <tjanez> I think GNOME maintainers should provide a COPR for it or they should update it in the main repo
12:25:13 <hhorak> I can't find right now if we already agreed on "many small repos approach" -- that should be decided first I guess, since it matters when thinking about rules for reviews.
12:25:17 <mmaslano> tjanez: you don't need to allow to use this one repo of repos
12:25:35 <mmaslano> hhorak: you are right
12:25:51 <tjanez> bkabrda1, yes, +1 :)
12:26:07 <bkabrda1> IMO latest builds of <your-favourite-software> are one of the use cases that playground should support
12:26:37 <tjanez> hhorak, +1
12:26:53 <mmaslano> #topic 1 Big repo vs multiple small ones
12:27:01 <mmaslano> ok, let's solve this one
12:27:01 <tjanez> As mmaslano said in the email, sometimes it appears we are running in circles
12:27:02 <bkabrda1> so let's first solve the 1 big vs. N small :)
12:27:26 <hhorak> I'm also tempted to allow more in the beginning, then change if it really turns to PITA
12:27:26 <mmaslano> as I understand we have plugin for dnf, which can pick only one repo from all those repos
12:27:56 <bkabrda1> +1 for multiple small repos
12:27:58 <tjanez> I have no problem with disagreement I just want to clearly present my arguments and then let everyone vote on them
12:28:06 <juhp_> :)
12:28:17 <hhorak> +1 for multiple small
12:29:36 <mmaslano> tjanez: I can say +1 for multiple small, but that doesn't solve anything :)
12:29:51 <mmaslano> tjanez: could you some up why you don't like this idea?
12:30:19 <tjanez> mmaslano, I guess it's a question of the purpose of the Playground repo
12:30:33 <juhp_> I also feel that it will be simpler in turns of infrastructure and workflow to start with multiple small repos (or repo of copr repos)
12:30:44 <juhp_> erm turns = terms
12:30:53 <tjanez> and I see it as a non-goal to provide the latest builds of <your-favourite-software> in the Playground repo
12:31:06 <tjanez> I see COPRs better fit for that
12:31:28 <juhp_> hmm - that could also be
12:31:52 <mmaslano> yes, but you can't have all those cool latest  thing on one place. You have to know about some Coprs, their location and manually add every of them
12:31:58 <juhp_> the coprs will be there anyway - just a question of how we expose them in the Playground repo(s)
12:32:14 <mmaslano> tjanez: I guess the main problem is eveyone would like to see different usecases for Playground
12:32:17 <drieden> I have to go, I am putting my children on the bus for school.
12:33:02 <tjanez> mmaslano, exactly, we agree on some use cases and disagree on some
12:33:51 <juhp_> many small repos seems more flexible overall, but of course slightly more awkward to use
12:34:22 <juhp_> you don't know locally what packages are in the copr repo until you add it
12:34:22 <tjanez> In my opinion the primary use case for the Playground would be incubation, then exceptions (e.g. chromium)
12:34:52 <tjanez> (like stated in jreznik email yesterday)
12:35:33 <tjanez> I would have another mechanism for exposing/starring/promoting selected COPRs
12:35:34 <mmaslano> tjanez: I read it differently
12:36:35 <juhp_> tjanez's repo seems closer to curated Playground or stable Ring 2 repo perhaps - whereas multi-repo repo is closer to current coprs
12:37:04 <tjanez> juhp_, +1. So the question is what to choose initially?
12:38:21 <tjanez> What I would like to solve in my vision of the Playground repo is to have some middle guidelines between current FPG and no-guidelines (COPRs) and to have a substantially faster review mechanism that the current review
12:38:48 <bkabrda1> tjanez: I don't think we want *any* kind of review for playground
12:38:55 <hhorak> my feeling is that we want something flexible, so rather the copr approach
12:39:01 <mmaslano> I don't want any guidelines either
12:39:10 <jreznik> hhorak: +1
12:39:22 <mmaslano> guidelines are reason why packaging take so long, maintenance of guidelines is LOT of work
12:39:31 <tjanez> bkabrda1, not even an automatic one?
12:39:38 <juhp_> I think minimal guidelines almost forces repo of copr repos
12:39:50 <jreznik> tjanez: I'm in favour of minimal automatic sanity checking
12:39:56 <bkabrda1> tjanez: automatic reviews are not 100 %
12:40:02 <mmaslano> ok, let's speak aobut minimal minimal guidelines
12:40:10 <jreznik> bkabrda1: sanity checking, not a full blown review
12:40:22 <mmaslano> because all "automatic" reviews didn't work. At least I didn't see any working well
12:40:23 <jreznik> the first question is - who should be our user?
12:40:41 <bkabrda1> tjanez: so you can provide them "as a service" for maintainers, so that they can look and see what they should improve; but I wouldn't want to make any kind of automatic checking mandatory
12:40:58 <bkabrda1> (mandatory in the sense that the package has to pass a test in order to get to playground)
12:41:09 <tjanez> jreznik, +1 about some sanity checking at least
12:41:47 <jreznik> high quality packages that do not fulfil our even higher quality rules (for example bundling - Chromium) - it's suitable for all users
12:41:47 <juhp_> bkabrda1, I tend to agree - that sounds more attractive if we want to make it easy to contribute
12:42:07 <jreznik> incubation? I'd say not suitable for all users unless they know how to deal with issues
12:42:07 <tjanez> bkabrda1, ok, I like the "as a service" thing
12:42:31 <jreznik> for a) Fedora Guidelines should be applied with exceptions like bundling...
12:42:34 <juhp_> jreznik, you mean consumers of the repo right?
12:42:36 <jreznik> for b) sanity checking
12:42:38 <tjanez> if we have that mechanism, the packager and the user can see which things passed/failed
12:43:07 <jreznik> another question - how many packages similar to Chromium do we have?
12:44:09 <hhorak> jreznik: from what I know about Java packages -- a lot. Bungling is very popular in Java.
12:44:49 <tjanez> jreznik, in Python scientific landscape, it is very common to bundle some C libraries, e.g. sympy, scikit-learn
12:45:27 <tjanez> they are currently in the main Fedora repo, but they have a lot of issues since it is "unnatural" to unbundle those dependencies
12:45:47 <jreznik> good catch
12:46:01 <bkabrda1> tjanez: ok, so can we agree on "there should be no blocking automatic review for playground packages"?
12:46:01 <juhp_> I think we are agree bundling is fine in Playground anyway
12:46:22 <hhorak> juhp_: correct.
12:46:31 <tjanez> bkabrda1, if we would have the "checks as a service" available, it would we easy to later flip some checks as being mandatory and some only as a warning
12:46:38 <jreznik> and I think the initial idea behind Playground was - let's try one repo, with lower level, probably not suitable for everyone but open the possibility to fork it into several use case specific repositories
12:47:09 <mmaslano> tjanez: I can assure you that we are using some automatic checks, and they simply didn't work
12:47:10 <jreznik> juhp_: bundling is one of the main reasons behind Playground
12:47:23 <bkabrda1> tjanez: since automatic checks are never 100% successful and they find false positives, I'm reluctant to making them mandatory
12:48:16 <tjanez> bkabrda1, but wouldn't it be easy to them have some-one look at that particular package that failed that particular test and white-list it for the future?
12:48:30 <juhp_> tjanez, I read the service as meaning it is something you would point at your repo/packages - ie opt in
12:48:41 <hhorak> tjanez: +1 for turning some tests in the future (in case it seems to be a good idea), starting with voluntary "service"
12:48:45 <tjanez> Or is not going to be scalable enough?
12:48:46 <juhp_> a la rpmlint
12:48:50 <jreznik> and I think collections of Coprs would allow us that flexibility to create more "repos" in the style we would need, from what I talked with msuchy, it's mostly implemented (so no need to setup the whole infrastructure for another repository)
12:49:01 <juhp_> hhorak, +1
12:49:18 <juhp_> jreznik, right
12:49:27 <jreznik> but let's start with loose policy playground, to learn how to do it
12:49:46 <bkabrda1> tjanez: I think that right now we can agree on providing some kind of "non-blocking review service" and later we can talk about whether we should make it mandatory or not.
12:50:01 <jreznik> all in one collection - warn users that it's Beta
12:50:34 <mmaslano> I would be fine with checks and guidelines as nice to have, which can be implemented later
12:50:34 <bkabrda1> tjanez: if we have something that proves to have *very* low rate of false positives, we can reopen
12:50:40 <juhp_> jreznik, a repo of repo files?
12:50:43 <tjanez> bkabrda1, +1. I wouldn't like it to be opt-in though, I would want to have it run for all packages heading to the Playground repo
12:51:03 <bkabrda1> tjanez: if it's not blocking, I'm not against that
12:51:06 <juhp_> tjanez, sounds reasonable
12:51:18 <juhp_> then people can go there and check status of packages/repos
12:51:39 <tjanez> bkabrda1, my reasoning is that users can then themselves look at the results and decide if they want the package that has the noted failures or not
12:51:53 <juhp_> another problem is a that copr web has poor UI for browsing packages
12:51:53 <tjanez> juhp, exactly :)
12:52:20 <hhorak> I can imagine the checks being run against all copr builds, not only playground candidates, just to give users some feedback, what can be better.
12:52:35 <juhp_> hhorak, yes
12:52:50 <bkabrda1> hhorak: if copr has enough cycles to do this, why not
12:52:54 <mmaslano> I'm proposing easy to implement repo
12:53:08 <mmaslano> tjanez: what are you proposing sounds like years of work
12:53:10 <bkabrda1> also, someone will actually has to implement this :)
12:53:11 <tjanez> hhorak, maybe. But maybe we should start with just Playground (needs less resources)
12:53:47 <tjanez> mmaslano, which part :)?
12:53:58 <mmaslano> tjanez: automatic checks, guidelines,..
12:54:15 <mmaslano> tjanez: Playground repo could be ready for F21 if we don't invent a wheel
12:55:10 <tjanez> Well, I think having Playground being a collection of selected COPRs is not really a lot of added value
12:55:23 <jreznik> tjanez: why?
12:55:34 <mmaslano> exactly
12:55:35 <jreznik> mmaslano: exactly, it could be ready within weeks
12:56:09 <jreznik> tjanez: it's about infrastructure... one is mostly done, another would have to be setup first
12:56:10 <tjanez> jreznik, ok, then let's do this kind of Playground in two weeks and then start planning Playground++
12:56:25 <mmaslano> tjanez: so we agree on less rules for now?
12:56:29 <bkabrda1> tjanez: +1
12:56:38 <tjanez> jreznik, we started with something in the middle between COPRs and current main repo
12:56:39 <jreznik> tjanez: I'm not saying in two weeks :)
12:56:40 <hhorak> Let's be concrete -- imagine we already have the repo; what is the criterion for including one copr into playground in the beginning?
12:56:58 <tjanez> jreznik, and my perception of "middle" seems to be something else that what others think
12:57:01 <jreznik> tjanez: and you would end there - not main repo, not a single copr repository - something in between
12:57:20 <jreznik> well I think you think the same as I think (thinking about it)
12:57:37 <tjanez> jreznik :)
12:57:37 <jreznik> this is more about implementation - keep it simple
12:58:22 * mmaslano needs to go to next meeting again
12:58:25 <juhp_> hhorak, that's a good question
12:58:29 <mmaslano> see you in few minutes
12:58:40 <jreznik> that question if it would have own infrastructure being own repository or collection of coprs should be answered by folks who would implement imho
12:59:23 <tjanez> hhorak, +1 on your question
12:59:39 <juhp_> well I think eventually we certainly want a stable Ring 2 repo with sanity check and some guidelines
13:00:09 <tjanez> hhorak, from my understanding of others, there would be none, except for packager's wish to expose it
13:00:26 <juhp_> so just a button click/checkbox?
13:00:39 <tjanez> juhp, that was my intention with my idea for the Playground repo also
13:01:07 <juhp_> tjanez, right maybe it is a question of degree
13:01:54 <mmaslano> did you agreed on something? it would be good to have somenote about it
13:02:16 <hhorak> my proposal for my question: having in mind that copr builds already had to pass some legal requirements (license), then it would be only provenpackager's decission, like "the package looks sane and works somehow"
13:02:18 <juhp_> will the packages in the repo of coprs just take there name from the copr name?   playground-<user>-<reponame> ?
13:02:22 <juhp_> their
13:03:27 <hhorak> mmaslano: not yet
13:04:02 <juhp_> s/reponame/project/
13:04:03 <jreznik> juhp_: stable Ring 2 repo with sanity check and some guidelines - yep but in the beginning I'd say playground could be more relaxed, that stable ring 2 would be evolution
13:04:20 <juhp_> jreznik, right
13:04:22 <jreznik> maybe in the end with more repos - but again, later
13:04:35 <tjanez> I think we reached some agreement.
13:04:43 <jreznik> set up infra, start it, see the adoption, see how people really use it...
13:05:34 <juhp_> agree
13:06:05 <mmaslano> could you add it into info somehow?
13:06:18 <tjanez> #proposal: Playground will be a collection of selected COPRs.
13:06:59 <hhorak> I don't think we need to vote about 1 big repo vs. multiple coprs, since nobody argued for the first one, but FTR my +1 for collection of selected COPRs
13:07:26 <juhp_> hhorak, well I thought tjanez did :)
13:07:41 <mmaslano> hhorak: +1
13:07:43 * jreznik does not have voting rights but it's is in favour of it as a first step
13:07:52 <tjanez> hhorak, juhp, yes, I tried to :)
13:07:56 <bkabrda> hhorak: +1
13:08:17 <juhp_> I think we have to vote :)
13:08:27 <hhorak> juhp_: I thought the difference in opinion was in the rules :)
13:08:34 <mmaslano> yes, vote please. we have a week until deadline for Changes
13:08:36 <juhp_> both :)
13:08:51 <hhorak> so let's rather vote for the proposal ;)
13:08:55 <hhorak> +1
13:09:05 <mmaslano> +1
13:09:15 <juhp_> +1
13:09:27 <tjanez> +1. As jreznik said, let's kick of such a playground repo and then plan from there
13:10:15 <bkabrda> +1
13:10:30 <juhp_> seems most realistic to me though slightly relunctant to let go of the original idea and also sympathize with tjanez's idea
13:10:55 <mmaslano> juhp_: we can start with other more strict repos, but not now
13:11:01 <juhp_> yep :)
13:11:39 <tjanez> juhp, thanks. Also, if more man-power is needed I'm still available for hire :)
13:12:39 <juhp_> I think it is probably wise to start with small steps :)
13:14:10 <mmaslano> now it would be good to go back to previous topic
13:14:21 <tjanez> hhorak, I think it's time to answer your question: What COPRs will go to the Playground repo
13:14:36 <mmaslano> but I guess reviews solved themselves by the discussion, doens't it?
13:15:54 <tjanez> mmaslano, it would be good to note some points from that discussion
13:16:14 <juhp_> right - probably we would start with no constraints beyond what copr imposes?
13:17:03 <juhp_> though open question how coprs get selected?
13:17:16 <tjanez> So, did we agree on: "We will provide a kind of "non-blocking review service" and later we will talk about whether we should make it mandatory or not."?
13:17:23 <mmaslano> tjanez: I read it as no reviews needed, am I right?
13:17:27 <mmaslano> juhp_: good one
13:17:52 <tjanez> Or is that for Playground++?
13:18:08 <juhp_> tjanez, are you volunteering? :-)
13:18:27 <juhp_> certainly feel it would be valuable
13:18:59 <tjanez> juhp, if there would be interest and agreement that it is useful, I could look into it
13:19:34 <tjanez> also, I would have to talk to pingou and sochotny what they think about it
13:19:59 <juhp_> cool - good idea
13:20:14 <hhorak> tjanez: I'd add "Coprs won't be blocked by reviews results in the beginning." to your proposal and vote.
13:21:32 <juhp_> hhorak, +1
13:21:53 <tjanez> hhorak, go for it, make a proposal
13:22:10 <hhorak> #proposal: We will provide a kind of "non-blocking review service" and later we will talk about whether we should make it mandatory or not. Coprs won't be blocked by reviews results in the beginning.
13:22:20 <hhorak> +1
13:22:23 <juhp_> +1
13:22:34 <tjanez> +1
13:22:41 <mmaslano> +1
13:23:01 <bkabrda> +1
13:23:35 * tjanez is happy that we are agreeing on this
13:23:43 <juhp_> :)
13:24:04 <hhorak> #agreed We will provide a kind of "non-blocking review service" and later we will talk about whether we should make it mandatory or not. Coprs won't be blocked by reviews results in the beginning. (+5,-0,0)
13:24:26 <hhorak> we did not summarize the previous voting I guess, will fix now
13:24:56 <hhorak> #agreed Playground will be a collection of selected COPRs. (+5,-0,0)
13:25:00 <mmaslano> we need to finis change proposal until next week!
13:25:02 <tjanez> hhorak, good catch, thanks for fixing it
13:25:11 <mmaslano> #info https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Playground_repository
13:25:27 <mmaslano> I guess if I put todays notes into it, it's final
13:25:31 <juhp_> mmaslano, beginning of next week?
13:26:00 <samkottler> sorry, I'm bad at time zones - here now
13:26:05 <mmaslano> True 8th April
13:26:14 <juhp_> ok
13:26:28 <mmaslano> sooo, if I add those notes into Change, could you review it?
13:26:40 <juhp_> samkottler, welcome to EU Summertime :)
13:26:46 <juhp_> yes
13:27:02 <tjanez> mmaslano, sure
13:27:22 <mmaslano> I guess we don't need to fill everything
13:27:26 <mmaslano> but most of the features
13:28:11 <hhorak> mmaslano: let's make an action item from that (anybody has meetbot cheatsheet near?)
13:28:33 <mmaslano> #action review Change proposal - Playground repository
13:28:43 <hhorak> mmaslano: thanks
13:28:54 <mmaslano> if you look also on SCL, that would be good
13:29:07 <mmaslano> #info https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/SCL
13:29:08 <juhp_> okay
13:29:20 <tjanez> mmaslano, how concrete do the Change proposals need to be?
13:29:49 <tjanez> Also, what if some subfeature (e.g. "non-blocking review service") isn't ready in time?
13:30:04 <tjanez> "in time" meaning for Fedora 21
13:30:06 <hhorak> tjanez: I think we are allowed to change add/change details even later, so I'd expect only basic info is necessary
13:30:11 <juhp_> tjanez, I would say enough for Fesco to be able to understand the overall details
13:30:12 <juhp_> right
13:30:37 <mmaslano> tjanez: i usually write the main goal there and work on details later
13:30:49 <mmaslano> people are usually not interested in details if it doesn't break the whole Fedora
13:30:51 <juhp_> tjanez, it probably doesn't have to block the Change
13:31:09 <mmaslano> also processes can be defined during development phase
13:31:14 <tjanez> Ok, cool. I just wanted to clear that before I review the Change proposal
13:31:55 <mmaslano> the important thing is to send it before deadline :)
13:32:04 <juhp_> right
13:32:05 <mmaslano> it can be enhanced in next weeks
13:32:23 <tjanez> I would like to note that some things might turn out to be inconsistent now
13:32:38 <tjanez> that we decided to go with multiple small repos
13:32:50 <juhp_> right some changes needed
13:33:38 <mmaslano> sure, i didn't put it there
13:33:40 <mmaslano> yet
13:33:47 <mmaslano> I mean could you review it tomorrow? :)
13:33:56 <tjanez> For example, https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_(draft)#How_the_repository_works, section "How do the updates work?" talks about one yum/dnf repo per Fedora release-arch
13:34:45 <juhp_> maybe we should fork a copy of that page for future Playground++ repo ?
13:35:09 <tjanez> mmaslano, no problem. I just wanted to note it here so that people are aware of it since we made those decisions in the beginning
13:35:19 <tjanez> juhp, +1
13:35:42 <mmaslano> tjanez: I review todays meeting and update Open Questions, so we can continue and add decisions into Change proposal
13:35:51 <juhp_> though it is in the wiki history anyway at least
13:36:35 <tjanez> mmaslano, ok
13:36:43 <juhp_> great
13:38:25 <juhp_> are we done? :)
13:38:37 <mmaslano> I guess so
13:38:41 <mmaslano> #endmeeting