12:01:12 <mmaslano> #startmeeting Env and Stacks (2014-04-15)
12:01:12 <zodbot> Meeting started Tue Apr 15 12:01:12 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:01:18 <mmaslano> #meetingname env-and-stacks
12:01:18 <zodbot> The meeting name has been set to 'env-and-stacks'
12:01:23 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
12:01:23 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez
12:01:30 <mmaslano> #topic init process
12:01:38 <tjanez> hi
12:01:41 <mmaslano> I'm sorry I forgot to send agenda earlier
12:01:55 <mmaslano> but I don't have any agenda anyway
12:02:46 <hhorak> hi
12:04:24 <tjanez> mmaslano, regarding agenda, we can discuss the devel ML reactions to our Change proposals
12:04:35 <mmaslano> ok
12:04:37 <juhp> hi!
12:04:49 <tjanez> yay, we are 4 :)
12:06:53 * juhp just saw "Proposed System Wide Change: Workstation: Enable Software Collections "
12:07:13 * jreznik is around to answer changes related stuff (but has 1 on 1 with his boss soon)
12:07:30 <jreznik> juhp: yeah, I just announced it - right on time :)
12:07:32 <mmaslano> juhp: yeah, Christian send it to me earlier
12:08:02 <mmaslano> I guess they would like to provide also different version of development tools in Fedora
12:08:04 <juhp> oh nm
12:08:33 <juhp> it seems a small proposal iiuc
12:08:55 <juhp> mmaslano, that was my assumption but no such mention in the Change proposal??
12:09:02 <jreznik> juhp: it's more about inclusion of scl-utils
12:09:08 <juhp> nod
12:09:11 <mmaslano> probably
12:09:33 <jreznik> then there's that question who will provide collections they need
12:09:44 <hhorak> jreznik: inclusion where? into workstation product?
12:09:46 <juhp> jreznik, is that so controversial?
12:09:58 <jreznik> hhorak: into workstation product
12:10:17 <jreznik> #link https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections
12:10:36 <hhorak> jreznik: ok, thanks.. now I probably see what is the point..
12:10:56 <juhp> hhorak: maybe you could explain then :)
12:12:30 <juhp> anyway sounds fine
12:12:40 <hhorak> juhp: I thought that the change was only about having some of the packages in the product (scl-utils) and making changes in dev-assistant, but after reading the first paragraph from the change wiki page: "The Software Collections repositories will be enabled by default. " I found that I don't understand it probably
12:13:17 <tjanez> I also read it now and it is a bit confusing.
12:13:41 <mmaslano> well, they want the repo with collections enabled by default (which was already refused by fesco in older ticket) or in main Fedora repo (won't happen because we don't have guildelines for SCL)
12:13:51 <hhorak> I mean if we can build collections only in Copr, then we would include them in the playground, which won't be enabled by default..
12:14:10 <mmaslano> exactly, currently I don't see a way how to do it
12:14:22 <mmaslano> but I guess every group should be able to say what is okay
12:14:38 <juhp> oh yes wow, enabled by default - blinks, wow
12:14:48 <hhorak> mmaslano: even if we had guidelines, we would need to add them to proper repo, right?
12:14:54 <tjanez> The "problem" is that between the lines it talks about enabling access to SCLs hosted at https://softwarecollections.org/ by default
12:14:58 <jreznik> mmaslano: and that's why there's that dependency on SCL and I think you can use it in the way - hey, you see, other WGs/Products are interested in collections, there's real use case in Fedora
12:15:13 <juhp> yes
12:15:23 <mmaslano> yes
12:16:45 <mmaslano> jwb: hi, you are saying the whole Workstation change is only about adding scl-utils? sounds like no problem
12:16:57 <mmaslano> but everybody understand the Change differently
12:19:04 <jreznik> mmaslano: one reason I let it as System Wide as mclasen proposed it that way as there are system wide deps (if it means SCl has to be part of Fedora)
12:19:20 <hhorak> mmaslano: the problem I see there is that they actually don't see some particular collection because of the functionality, but they probably need the concept ready, which means to me like something different than what I read in the proposal
12:20:34 <juhp> seems to need clarification
12:20:40 <pkovar> fwiw, the user experience section reads: Software from Software Collections that are available for Fedora 21  can be installed, and the scl utility is part of the installation.
12:21:00 <pkovar> so it talks about "SCLs in F21"
12:21:11 <juhp> but not in koji :)
12:21:34 <juhp> but yes
12:23:12 <tjanez> I sense there is an ambiguity in terminology that we use: Software Collections something refer to the technology and some times to the specific Software Collections available at https://www.softwarecollections.org/en/
12:23:26 <jwb> mmaslano, jreznik: as i understand it, the Change is just "enable SCL by default in workstation"
12:24:06 <jwb> which means it needs SCL to be approved (i think), but it isn't a major change
12:24:23 <jwb> if SCL isn't approved or isn't available, the change just doesn't happen i guess?
12:24:31 <mmaslano> okay
12:25:21 <hhorak> If I change the "enabled by default" with "be easily accessible", then having the collections from https://www.softwarecollections.org/ in playground repository should be enough to satisfy this requirement
12:25:41 <hhorak> ...which would be the scenario that would make sense to me
12:25:56 <mmaslano> feel free to propose it on mailing list
12:26:10 <hhorak> mmaslano: you be I will ;)
12:26:15 <hhorak> *you bet
12:26:29 <mmaslano> I'm fine with responding to my Changes ;-)
12:27:05 <tjanez> jwb, the summary says: "The Software Collections repositories will be enabled by default." And then the scope says:"Allow the inclusion of the software collections repositories in Fedora products". Does this refer to https://www.softwarecollections.org/en/?
12:27:56 <jwb> tjanez, i'm unclear on that as well
12:27:56 <juhp> maybe better to take that discussion to devel list :)
12:27:56 <jwb> tjanez, worth asking in the list i suppose
12:28:22 <tjanez> jwb, ok. Agreed about the ML part
12:31:46 <juhp> mmaslano, I am sorry for not mentioning earlier but I think maybe Changes/Playground_repository should state more clearly/explicitly that it is intended to be a repo of .repo's
12:31:59 <mmaslano> juhp: yes, it should
12:32:20 <tjanez> juhp, good catch.
12:32:24 <mmaslano> if someone didn't try the dnf plugin, then he can't understand how it works
12:32:30 <juhp> seemed to me that some of the feedback was confused about that
12:32:45 <tjanez> #topic Playground repository
12:33:14 <juhp> so maybe adding a bit more detail would be helpful I feel - I apologize for not finding time to review before it was announced... :-|
12:33:45 <mmaslano> jreznik found typos also in other Changes :( I fixed something yesterday in those other two
12:33:47 <tjanez> I also think the ML thread feedback shows that we need to communicate our idea better
12:33:48 <juhp> mmaslano, okay
12:34:09 <juhp> tjanez, agreed
12:34:25 <mmaslano> definitely, but I need to finally build it :)
12:34:46 <juhp> sure
12:34:54 <tjanez> I think some (long-time) contributors were a bit scared of adding another repository
12:35:10 <juhp> specially a big repo
12:36:27 <juhp> since I missed the last meeting I was waiting for others to clarify that in the thread too :)
12:36:56 <tjanez> I tried to shed light on some of the benefits and innovation that the development of the Playground repo will bring to Fedora
12:39:26 <tjanez> mmaslano, you mentioned something about finishing Open Questions and planning development tasks. Do you have the energy for that?
12:39:47 <tjanez> (To discuss that today)
12:40:18 <mmaslano> tjanez: sure. What we need to do?
12:40:24 <mmaslano> dnf plugin - done
12:40:32 <mmaslano> taskotron will somehow work
12:40:46 <mmaslano> signing of packages is very tricky from the thread I saw
12:41:10 <mmaslano> and we are missing process of how to add packages from copr into playground
12:42:26 <tjanez> ok. thanks for listing the tasks.
12:43:18 <mmaslano> I guess the most easiest way how to add packages is to add button in copr
12:43:25 <tjanez> the last item, the process of adding packages. Should it be just a request of a COPR owner?
12:43:53 <mmaslano> probably, how else could it be done?
12:43:54 <juhp> I thought msuchy was planning to add such a button from his mail?
12:44:08 <mmaslano> yes
12:44:15 <tjanez> And when we have taskotron (i.e. automatic gating/QA) in place, it could also be hooked up in the middle. But not initially.
12:44:18 <juhp> all coprs would get the button?
12:44:46 <mmaslano> probably, I don't see a way how to distinguish among repos
12:44:51 <juhp> ok
12:45:40 <juhp> I guess one way would to do that be to have some blacklist or whitelist but hopefully not needed initially
12:45:55 <juhp> s/be/would be/
12:45:56 <tjanez> What happens at the back-end. Are packages copied to some new location for the Playground repo? I'm asking because a COPR owner could delete his repo/packages...
12:46:20 <mmaslano> tjanez: no copying would mean more space on server
12:46:23 <mmaslano> it's just tagged
12:46:38 <juhp> tjanez, that's interesting one
12:47:00 <mmaslano> maybe the button should be added only for Coprs marked as stable or what is there currently
12:47:08 <juhp> even though copr disappears - users might not be happy to have the packages deleted from their machine
12:47:15 <mmaslano> ah, nothing
12:47:26 <hhorak> tjanez: good point with the package removal.
12:47:36 <hhorak> juhp: it wouldn't happen..
12:48:09 <tjanez> mmaslano, if it is copied, it could still be hardlinked to save space
12:48:15 <juhp> well there was talk of adding obsoletes to playground-repo-release but those would probably be added by hand I guess
12:48:38 <juhp> tjanez, but if copr is deleted there may be a reason
12:49:01 <juhp> might be better just to drop the .repo from playground
12:49:07 <mmaslano> tjanez: I don't understand, that's a question for msuchy
12:50:12 <tjanez> juhp, well, there may be a reason to not install the package on the system because it is broken, etc. but one would still want to have access to the package (for what ever reason)?
12:50:31 <juhp> deleted repo or unmaintained repo are slightly similar perhaps
12:50:35 <juhp> tjanez, perhaps
12:50:58 <tjanez> similarly as we can access old tagged builds in Koji now?
12:51:01 <juhp> I see your point
12:51:27 <juhp> but some of those will also get garbage collected eventually
12:52:04 <juhp> or do we prevent playground repos from being deleted?
12:52:15 <juhp> s/repos/coprs/
12:52:37 <juhp> anyway it seems an edge case to me :)
12:52:42 <tjanez> looking at it conceptually, I would like Playground to be feed by the selected COPR repos
12:52:57 <tjanez> and not to just provide links to them
12:53:23 <juhp> Playground may be slightly like rawhide at least initially
12:53:32 <tjanez> since in the former case, we can prevent "bad" (i.e. not passing automatic gating) updates into becoming part of the Playground repo
12:53:58 <juhp> unsigned, some parts may break/change/major update without announcement etc
12:54:14 <juhp> that is why it is called Playground :)
12:54:59 <juhp> tjanez, but yeah that are certainly plenty of logistic type potential problems
12:55:08 <juhp> how to minimise breakage etc
12:55:10 <tjanez> juhp, agreed about the rawhide part. The reason I started the discussion is that I see a difference in the "fed by COPRs" or "links to COPRs"
12:55:19 <juhp> okay
12:56:02 <juhp> so links would rename after copr is deleted, interesting
12:56:11 <tjanez> If we take the "fed by COPRs" approach, it will be easier to develop the automatic gating/tests later
12:56:41 <mmaslano> would someone like to write a summary on mailing list?
12:56:48 <hhorak> tjanez: can you describe what you mean by those two, "fed by COPRs" or "links to COPRs"?
12:56:50 <juhp> but then deleted copr leads to unmaintained one
12:56:51 <mmaslano> everything should be discussed with copr developers ;-)
12:57:40 <tjanez> mmaslano, I'm not up to speed about the coding parts, but we are talking about implementing Playground "inside" the Copr project?
12:58:24 <mmaslano> tjanez: there's no code, just dnf plugin downloading copr repositories marked as playground
12:58:42 * mmaslano needs to move on phone call, will be right back
12:59:23 <juhp> so actually there is no repo just a plugin?
12:59:41 <juhp> interesting I see
12:59:45 <hhorak> mmaslano: I'd like to make this clear, the dnf plugin will work only with the corps tagged as playground, right?
12:59:59 <tjanez> hhorak, sure. "fed by COPRs" means that the packages are copied into the location, where the Playground repository stores its packages
13:00:48 <juhp> tjanez, should deleted coprs stay in the Playground indefinitely?
13:00:48 <tjanez> "links to COPRs" means that the Playground repository doesn't actually have any repository of packages, just links to a selected subset of COPRs
13:01:14 <tjanez> juhp, good question
13:01:52 <hhorak> juhp: I think that there can be some misunderstanding what the playground repository is in the end.. How I understand it where we're heading now is not a repository like we know it, but only a connection of "copr repositories marked as playground" + "dnf plugin"
13:02:23 <juhp> hhorak: I am not sure - so there will be separate playground plugin?  I guess I need to try the copr plugin to understand better
13:02:44 <juhp> hhorak: right thanks - I think I finally got that
13:03:23 <juhp> somehow I had imagined a yum repo of rpms containing .repo files but that also seemed messy
13:03:50 <hhorak> juhp: I hope I'm not the only one who understands that this way. About the playground plugin -- that is a question also for me, if the plugin would work *only* with playground packages or with all copr repos
13:03:55 <tjanez> hhorak, thanks for your explanation. However, I still think it's just one possible implementation option
13:04:00 <juhp> then I understand Marcela's comment about needing to understand the plugin earlier better
13:04:40 <hhorak> tjanez: correct, that was just how I understood where the things are moving..
13:04:42 <juhp> hhorak: maybe the copr API will be extended to support playground data
13:04:54 <juhp> s/data/flag?
13:04:57 <hhorak> juhp: that would also make sense to me..
13:04:59 <juhp> mmaslano, is that the idea?
13:05:20 <juhp> or how will the copr plugin specialise to playground?
13:05:26 <mmaslano> juhp: same plugin, but it will install only packages from playground
13:05:38 <juhp> ok
13:05:39 <mmaslano> it will be dnf playground install blabla/bla
13:05:43 <juhp> aha
13:05:51 <juhp> gotcha
13:06:41 <juhp> hmm now start to wondering about naming of copr wrt to playground but probably too hard to do any mapping to simpler nicer names
13:06:46 <juhp> coprs
13:07:32 <tjanez> I'm a bit surprised by the chosen implementation. mmaslano, where did you discuss and decide to go this way?
13:07:40 <juhp> "dnf playground list/info" will be nice anyway
13:08:46 <mmaslano> tjanez: well I asked mirek-hm what's the easiest way
13:08:53 <mmaslano> feel free to propose something else
13:09:30 <mmaslano> tjanez: everyone agreed with dnf plugin, so I didn't see any harm
13:09:43 <tjanez> mmaslano, cool. Thanks for explaining.
13:10:03 <jreznik> especially all infrastrucutre is in place
13:10:24 <hhorak> tjanez: I think we decided that more small coprs instead of one big repo two weeks back. and implementing this scenario using the dnf plugin seems the easiest way now (not approved nor discussed properly yet I guess).
13:10:29 <mmaslano> tjanez: we don't need to do anything else than solve signing, test in taskotron and how to add packages into playground
13:10:58 <mmaslano> we don't need release engineering, space, nothing, so the chance is it can be used without too much fuzz
13:11:09 * jreznik is a bit guilty in setting this direction but...
13:11:36 <tjanez> jreznik, I thought the idea was to use this as an exercise for setting up a new repository
13:12:35 <tjanez> that's why I'm a bit surprised since we are actually not setting up a real repository
13:12:39 <mmaslano> yes, I thought so too
13:13:01 <juhp> it would be nice to have cli to search copr/playground though
13:13:08 <jreznik> tjanez: and if it will work, I don't see any reason to do the real repo later but I agree, this is Beta
13:13:09 <mmaslano> but maybe a way how to install from outside might be even better
13:13:26 <mmaslano> juhp: thednf plugin has search in repo
13:13:33 <juhp> ah okay
13:13:45 <mirek-hm> juhp: seaching through  coprs is already implemented, PR is waiting to be merged (after few fixes)
13:13:55 <hhorak> tjanez: yes, it won't be a real repository, but do we need it? I believe that such a scenario would fulfill the requirements as well.
13:14:09 <mirek-hm> searching through playground doest not make sense to me
13:14:30 <jreznik> hhorak: at least not for now and it it proves to be working solution, I don't see much reason to hit our infra with another set of repos
13:14:39 <juhp> mirek-hm, cool
13:15:12 <juhp> mirek-hm, why not? :)
13:15:35 <jreznik> mirek-hm: thanks for the prototype email!
13:15:36 <hhorak> mirek-hm: It does for me ;)
13:16:12 <juhp> tjanez, I think we may well still need a repo for stable ring2 repo
13:16:19 <juhp> with updates and all that stuff
13:16:28 <tjanez> hhorak, I think a real repository addresses some of the issues that we'll need to address differently now. For example: signing packages with a Playground specific key, package removal
13:16:38 <juhp> yep
13:16:55 <mirek-hm> hmm I expect (as user) that playground is something where already some selection has been made. And if I want to be on bleeding edge I just enable playground and that is all. If I search for some particular project I would just enable that one copr project.
13:17:12 <mmaslano> make sense
13:17:25 <hhorak> tjanez: good you mention the package removal -- what happens if the copr is deleted and some people already installed it? I'd say deleting playground packages shouldn't be allowed at all (made disabled as soon as the copr gets to playground), because otherwise we'd totally lost a way how to found the bits that people have installed on their machines. That would be problem imho.
13:17:46 <juhp> hmm point
13:17:53 <tjanez> hhorak, yes, exactly :)
13:18:18 <juhp> mirek-hm, I am not sure - you mean playground would enable a set of coprs?
13:18:26 <mirek-hm> hhorak: I would set up daily cron job which would call "dnf playground upgrade" (hmm it should be rather "update")
13:18:42 <mirek-hm> so old removed repos are deleted and new one fetched
13:18:56 <tjanez> What we are developing now is basically a "view" of the COPRs available at copr.fedoraproject.org
13:19:06 <juhp> seems so
13:19:15 <tjanez> and we select which packages go into this "view"
13:19:19 <juhp> or subset of them
13:19:24 <juhp> right
13:19:35 <mirek-hm> juhp: yes, but in different namespace in /etc/yum.repos.d so you still can use "dnf copr" independetly
13:20:00 <hhorak> mirek-hm: I don't follow the cron job note -- what is it for?
13:20:03 <juhp> mirek-hm, how about conflicting coprs then?
13:20:36 <mirek-hm> juhp: I provide gun, it is up to you if you shot yourself into leg
13:20:50 <juhp> well I agree that making playground a set of coprs would at least distinguish it more from current copr
13:20:56 <juhp> lol
13:21:12 <juhp> mirek-hm, I mean in terms of playground
13:21:38 <mirek-hm> hhorak: if you do "dnf playground enable" and next day is added new project to playground how you will get the updates? I suggest to run regulary "dnf playground upgrade"
13:23:51 <juhp> taskotron is only used for initial addition of copr to playground?
13:25:10 <mmaslano> I see I need to draw a picture for next time. We really need to start working on tasks, which were left
13:25:18 <mmaslano> like signing
13:25:37 <juhp> do we have to have signing for f21?
13:25:45 <mmaslano> mirek-hm: I understood signing won't happen by obs-signd because of long thread on devel
13:27:13 <hhorak> mirek-hm: I'm still not there -- this is how I understand it works: I enable repository joe/foo. The next day joe adds a new copr into playground joe/bar and builds new packages for joe/foo. Then yum/dnf updates packages correctly for joe/foo but I don't care about joe/bar at all, unless I need to install that corp. In which point I need to call dnf playground upgrade?
13:27:16 <mirek-hm> mmaslano: I do not know right now
13:28:11 * juhp noticed mirek-hm's post with example http://copr.fedoraproject.org/api/playground/list/
13:28:52 <mirek-hm> hhorak: if you run "dnf copr enable joe/foo" you do not need to run "dnf playground upgrade" that is only if you done "dnf playground enable"
13:29:25 <mirek-hm> "dnf copr" and "dnf playground" are totaly independet
13:29:56 <hhorak> mirek-hm: ah, and "dnf playground enable" enables all corps in playground, right (sorry if it is mentioned here already, I must have missed it)
13:30:06 <mirek-hm> hhorak: yes
13:30:23 <juhp> so probably we need more strict criteria for playground with that implementation - like no copr conflicts etc
13:30:32 <juhp> s/that/this/
13:30:45 <hhorak> mirek-hm: ah, now I see that in your proposal. thanks.
13:30:53 <hhorak> juhp: I don't think so.
13:32:53 <hhorak> juhp: we already discussed this and dnf should handle packages providing the same provides better than yum, so it shouldn't be problem to have say two versions of the same package in the playground.
13:33:02 <juhp> ah ok
13:33:04 <juhp> sorry
13:33:18 <juhp> will try to catch up on that
13:33:37 <juhp> interesting
13:34:04 <juhp> thanks
13:36:48 <juhp> how about signing - is it an immediate requirement?
13:38:47 <hhorak> mirek-hm: what do you think about the proposal above -- "disable option to delete coprs as soon as they get added to playground"?
13:39:37 <mirek-hm> hhorak: -1
13:39:51 <mirek-hm> hhorak: you will be less flexible
13:40:17 <mirek-hm> hhorak: if somebody orphan his work and no one stand up, then it should be removed anyway
13:40:31 <juhp> I think i agree with mirek-hm
13:41:08 <juhp> of course accidents can happen...
13:41:26 <tjanez> mirek-hm, but what if I want to still access that package for historical reasons, like trying to reproduce some problem, see what was broken etc.?
13:41:29 <hhorak> I see that as a big problem -- to have some RPMs installed and not having the source for them any longer (even on the server)
13:41:37 <juhp> maybe should be two stage - remove from playground and then delete
13:42:09 <juhp> hhorak: but it happens for rawhide too say
13:42:25 <hhorak> I don't think so
13:43:10 <hhorak> juhp: ah, now I understand, some builds get removed automatically there
13:43:16 <juhp> yeah
13:43:47 <hhorak> juhp: there is a difference though, that we have the source in the dist-git for rawhide
13:43:55 <juhp> true indeed
13:43:57 <hhorak> this is not true for copr generally
13:44:01 <mirek-hm> I can personaly can live without removed packages, but I respect that somebody else can have different opinion
13:44:03 <juhp> right
13:44:46 <juhp> it might be nice to have an srpm repo
13:44:58 <hhorak> mirek-hm: to safe some space, only srpms could be backed-up, even on some different place
13:45:02 <mirek-hm> hhorak: well keeping source or packages longer would need some storage, which we do not have right now
13:45:10 <mirek-hm> and will not have for year
13:45:15 <Southern_Gentlem> juhp for gpl you have to have a source somewhere
13:46:08 <juhp> maybe we would encourage git for playground coprs...
13:46:30 <mirek-hm> Southern_Gentlem: not true, you need to provide sources if asked, but that does not mean it must be accessible all the time (but IANAL)
13:46:33 <hhorak> mirek-hm: that wouldn't mean more space comparing to scenario that nobody decides to remove their packages, which is correct imho as soon as the package is in playground
13:47:25 <Southern_Gentlem> mirek-hm,  i stand by my comment
13:48:05 <Southern_Gentlem> i did quailify my statement
13:48:08 <mmaslano> Southern_Gentlem: how do you suggest we should solve problem with space?
13:48:24 <mirek-hm> hhorak: I'm not sure. Just be aware that we have some limits and we may hit ceiling
13:48:48 <drago01> mmaslano: just have them in fedora git
13:49:02 <mmaslano> drago01: copr packages are not stored in fedora git
13:49:16 <drago01> mmaslano: oh forgot that playground uses copr
13:49:19 <mmaslano> because you would need the review, which we didn't want, because it takes tooo much time
13:49:44 <drago01> create a "copr" git and ask people to put stuff there
13:50:07 <Southern_Gentlem> still a space issue
13:50:10 <mmaslano> ok, so now we don't have a problem with disc space, but with maintenance of git and space
13:50:33 <juhp> hehe :)
13:50:39 <drago01> ... ok ;)
13:50:39 <mmaslano> I thought people usually have some git and I don't care where they put their sources...
13:50:44 * drago01 shuts up
13:50:51 <mirek-hm> drago01: feel free to write draft of the process, contanct rel-eng that it is feasiable, write patches to fedpkg... (quite a lot of work)
13:50:54 <mmaslano> so we wouldn't have to care about maintenance
13:51:33 * juhp would not mind seeing copr git either but maybe we have to wait...
13:52:02 <juhp> I put my coprs on github...
13:52:21 <drago01> mirek-hm: we have a tool to commit to git called "git" i.e don't have to use fedpkg
13:52:45 <mirek-hm> bug dist-git use fedpkg
13:52:48 <mirek-hm> but
13:53:18 <juhp> https://github.com/fedora-haskell/common/blob/master/common.mk very low-tech :)
13:54:28 <juhp> anyway
13:54:36 <mmaslano> I would be fine with asking users to add link to git project and don't care about it anymore
13:55:47 <juhp> mirek-hm, could there be an optional git field in copr data? :)
13:56:24 <juhp> mmaslano, anyway I agree it is good enough for now
13:59:02 <juhp> noone answered my question I think about if package signing is needed sooner or later?
13:59:20 <mirek-hm> juhp: yes
13:59:36 <mirek-hm> to git field
13:59:40 <juhp> :)
13:59:58 <juhp> great
14:00:42 <juhp> does that mean later then? :-)  or did I miss that discussion?
14:01:14 <juhp> is it only a requirement for mirroring?
14:01:33 * mirek-hm do not know
14:02:11 <hhorak> I don't see any consensus about the idea about "allow to delete builds/coprs in playground or not" -- I'll add it to the open questions and will try to summarize what we said here on the mailing list, ok?
14:02:32 <juhp> hhorak: sounds okay to me, please
14:04:26 <juhp> lot of good discussion today I thought
14:04:32 <hhorak> #action hhorak will add an item to the playground open questions about deleting the packages/builds already introduced in playground and will send the summary of the irc discussion to the mailing list to continue
14:04:54 <tjanez> hhorak, thanks
14:06:07 <juhp> anyone have more or anything else?  or should we stop soon? :)
14:06:24 <juhp> and we thought was it might be a short meeting today :)
14:06:44 <tjanez> juhp, yea, a very long meeting indeed :)
14:06:49 <hhorak> juhp: :)
14:07:10 <juhp> anyway glad I am finally understanding the dnf plugin idea
14:08:19 <mmaslano> I hope someone knows what should be done ;-)
14:11:20 <hhorak> mmaslano: I'll add some info notes before closing the meeting to sum the discussion up..
14:12:48 <hhorak> #info We may follow the Workstation group's "Proposed System Wide Change: Workstation: Enable Software Collections" and discuss it on the devel list
14:15:28 <juhp> I need to re-read the Playground proposal in light of understanding the proposed implementation now
14:15:59 <hhorak> #info mirek-hm talked about "dnf playground enable" which would enable all copr repos in playground
14:16:02 <mmaslano> I guess some parts doesn't make sense with dnf plugin
14:16:36 <juhp> ok
14:18:49 <hhorak> so let's just summarize it like this: We talked about scenario that playground would be implemented by "copr with playground flag" + "dnf plugin working with such corps". No voting done. No final decisions.
14:19:57 <hhorak> #info We talked about scenario that playground would be implemented by "copr with playground flag" + "dnf plugin working with such corps". No voting done. No final decisions.
14:20:06 <hhorak> and we can go home :-D
14:20:08 <juhp> thanks hhorak
14:20:24 <hhorak> at least I go soon.. Thanks all and bye!
14:20:29 <juhp> good summary
14:20:40 <mmaslano> yeah, let's go home
14:21:35 <mmaslano> #endmeeting