12:01:12 #startmeeting Env and Stacks (2014-04-15) 12:01:12 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:01:18 #meetingname env-and-stacks 12:01:18 The meeting name has been set to 'env-and-stacks' 12:01:23 #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano 12:01:23 Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez 12:01:30 #topic init process 12:01:38 hi 12:01:41 I'm sorry I forgot to send agenda earlier 12:01:55 but I don't have any agenda anyway 12:02:46 hi 12:04:24 mmaslano, regarding agenda, we can discuss the devel ML reactions to our Change proposals 12:04:35 ok 12:04:37 hi! 12:04:49 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 juhp: yeah, I just announced it - right on time :) 12:07:32 juhp: yeah, Christian send it to me earlier 12:08:02 I guess they would like to provide also different version of development tools in Fedora 12:08:04 oh nm 12:08:33 it seems a small proposal iiuc 12:08:55 mmaslano, that was my assumption but no such mention in the Change proposal?? 12:09:02 juhp: it's more about inclusion of scl-utils 12:09:08 nod 12:09:11 probably 12:09:33 then there's that question who will provide collections they need 12:09:44 jreznik: inclusion where? into workstation product? 12:09:46 jreznik, is that so controversial? 12:09:58 hhorak: into workstation product 12:10:17 #link https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections 12:10:36 jreznik: ok, thanks.. now I probably see what is the point.. 12:10:56 hhorak: maybe you could explain then :) 12:12:30 anyway sounds fine 12:12:40 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 I also read it now and it is a bit confusing. 12:13:41 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 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 exactly, currently I don't see a way how to do it 12:14:22 but I guess every group should be able to say what is okay 12:14:38 oh yes wow, enabled by default - blinks, wow 12:14:48 mmaslano: even if we had guidelines, we would need to add them to proper repo, right? 12:14:54 The "problem" is that between the lines it talks about enabling access to SCLs hosted at https://softwarecollections.org/ by default 12:14:58 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 yes 12:15:23 yes 12:16:45 jwb: hi, you are saying the whole Workstation change is only about adding scl-utils? sounds like no problem 12:16:57 but everybody understand the Change differently 12:19:04 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 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 seems to need clarification 12:20:40 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 so it talks about "SCLs in F21" 12:21:11 but not in koji :) 12:21:34 but yes 12:23:12 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 mmaslano, jreznik: as i understand it, the Change is just "enable SCL by default in workstation" 12:24:06 which means it needs SCL to be approved (i think), but it isn't a major change 12:24:23 if SCL isn't approved or isn't available, the change just doesn't happen i guess? 12:24:31 okay 12:25:21 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 ...which would be the scenario that would make sense to me 12:25:56 feel free to propose it on mailing list 12:26:10 mmaslano: you be I will ;) 12:26:15 *you bet 12:26:29 I'm fine with responding to my Changes ;-) 12:27:05 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 tjanez, i'm unclear on that as well 12:27:56 maybe better to take that discussion to devel list :) 12:27:56 tjanez, worth asking in the list i suppose 12:28:22 jwb, ok. Agreed about the ML part 12:31:46 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 juhp: yes, it should 12:32:20 juhp, good catch. 12:32:24 if someone didn't try the dnf plugin, then he can't understand how it works 12:32:30 seemed to me that some of the feedback was confused about that 12:32:45 #topic Playground repository 12:33:14 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 jreznik found typos also in other Changes :( I fixed something yesterday in those other two 12:33:47 I also think the ML thread feedback shows that we need to communicate our idea better 12:33:48 mmaslano, okay 12:34:09 tjanez, agreed 12:34:25 definitely, but I need to finally build it :) 12:34:46 sure 12:34:54 I think some (long-time) contributors were a bit scared of adding another repository 12:35:10 specially a big repo 12:36:27 since I missed the last meeting I was waiting for others to clarify that in the thread too :) 12:36:56 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 mmaslano, you mentioned something about finishing Open Questions and planning development tasks. Do you have the energy for that? 12:39:47 (To discuss that today) 12:40:18 tjanez: sure. What we need to do? 12:40:24 dnf plugin - done 12:40:32 taskotron will somehow work 12:40:46 signing of packages is very tricky from the thread I saw 12:41:10 and we are missing process of how to add packages from copr into playground 12:42:26 ok. thanks for listing the tasks. 12:43:18 I guess the most easiest way how to add packages is to add button in copr 12:43:25 the last item, the process of adding packages. Should it be just a request of a COPR owner? 12:43:53 probably, how else could it be done? 12:43:54 I thought msuchy was planning to add such a button from his mail? 12:44:08 yes 12:44:15 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 all coprs would get the button? 12:44:46 probably, I don't see a way how to distinguish among repos 12:44:51 ok 12:45:40 I guess one way would to do that be to have some blacklist or whitelist but hopefully not needed initially 12:45:55 s/be/would be/ 12:45:56 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 tjanez: no copying would mean more space on server 12:46:23 it's just tagged 12:46:38 tjanez, that's interesting one 12:47:00 maybe the button should be added only for Coprs marked as stable or what is there currently 12:47:08 even though copr disappears - users might not be happy to have the packages deleted from their machine 12:47:15 ah, nothing 12:47:26 tjanez: good point with the package removal. 12:47:36 juhp: it wouldn't happen.. 12:48:09 mmaslano, if it is copied, it could still be hardlinked to save space 12:48:15 well there was talk of adding obsoletes to playground-repo-release but those would probably be added by hand I guess 12:48:38 tjanez, but if copr is deleted there may be a reason 12:49:01 might be better just to drop the .repo from playground 12:49:07 tjanez: I don't understand, that's a question for msuchy 12:50:12 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 deleted repo or unmaintained repo are slightly similar perhaps 12:50:35 tjanez, perhaps 12:50:58 similarly as we can access old tagged builds in Koji now? 12:51:01 I see your point 12:51:27 but some of those will also get garbage collected eventually 12:52:04 or do we prevent playground repos from being deleted? 12:52:15 s/repos/coprs/ 12:52:37 anyway it seems an edge case to me :) 12:52:42 looking at it conceptually, I would like Playground to be feed by the selected COPR repos 12:52:57 and not to just provide links to them 12:53:23 Playground may be slightly like rawhide at least initially 12:53:32 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 unsigned, some parts may break/change/major update without announcement etc 12:54:14 that is why it is called Playground :) 12:54:59 tjanez, but yeah that are certainly plenty of logistic type potential problems 12:55:08 how to minimise breakage etc 12:55:10 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 okay 12:56:02 so links would rename after copr is deleted, interesting 12:56:11 If we take the "fed by COPRs" approach, it will be easier to develop the automatic gating/tests later 12:56:41 would someone like to write a summary on mailing list? 12:56:48 tjanez: can you describe what you mean by those two, "fed by COPRs" or "links to COPRs"? 12:56:50 but then deleted copr leads to unmaintained one 12:56:51 everything should be discussed with copr developers ;-) 12:57:40 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 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 so actually there is no repo just a plugin? 12:59:41 interesting I see 12:59:45 mmaslano: I'd like to make this clear, the dnf plugin will work only with the corps tagged as playground, right? 12:59:59 hhorak, sure. "fed by COPRs" means that the packages are copied into the location, where the Playground repository stores its packages 13:00:48 tjanez, should deleted coprs stay in the Playground indefinitely? 13:00:48 "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 juhp, good question 13:01:52 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 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 hhorak: right thanks - I think I finally got that 13:03:23 somehow I had imagined a yum repo of rpms containing .repo files but that also seemed messy 13:03:50 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 hhorak, thanks for your explanation. However, I still think it's just one possible implementation option 13:04:00 then I understand Marcela's comment about needing to understand the plugin earlier better 13:04:40 tjanez: correct, that was just how I understood where the things are moving.. 13:04:42 hhorak: maybe the copr API will be extended to support playground data 13:04:54 s/data/flag? 13:04:57 juhp: that would also make sense to me.. 13:04:59 mmaslano, is that the idea? 13:05:20 or how will the copr plugin specialise to playground? 13:05:26 juhp: same plugin, but it will install only packages from playground 13:05:38 ok 13:05:39 it will be dnf playground install blabla/bla 13:05:43 aha 13:05:51 gotcha 13:06:41 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 coprs 13:07:32 I'm a bit surprised by the chosen implementation. mmaslano, where did you discuss and decide to go this way? 13:07:40 "dnf playground list/info" will be nice anyway 13:08:46 tjanez: well I asked mirek-hm what's the easiest way 13:08:53 feel free to propose something else 13:09:30 tjanez: everyone agreed with dnf plugin, so I didn't see any harm 13:09:43 mmaslano, cool. Thanks for explaining. 13:10:03 especially all infrastrucutre is in place 13:10:24 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 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 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 jreznik, I thought the idea was to use this as an exercise for setting up a new repository 13:12:35 that's why I'm a bit surprised since we are actually not setting up a real repository 13:12:39 yes, I thought so too 13:13:01 it would be nice to have cli to search copr/playground though 13:13:08 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 but maybe a way how to install from outside might be even better 13:13:26 juhp: thednf plugin has search in repo 13:13:33 ah okay 13:13:45 juhp: seaching through coprs is already implemented, PR is waiting to be merged (after few fixes) 13:13:55 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 searching through playground doest not make sense to me 13:14:30 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 mirek-hm, cool 13:15:12 mirek-hm, why not? :) 13:15:35 mirek-hm: thanks for the prototype email! 13:15:36 mirek-hm: It does for me ;) 13:16:12 tjanez, I think we may well still need a repo for stable ring2 repo 13:16:19 with updates and all that stuff 13:16:28 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 yep 13:16:55 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 make sense 13:17:25 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 hmm point 13:17:53 hhorak, yes, exactly :) 13:18:18 mirek-hm, I am not sure - you mean playground would enable a set of coprs? 13:18:26 hhorak: I would set up daily cron job which would call "dnf playground upgrade" (hmm it should be rather "update") 13:18:42 so old removed repos are deleted and new one fetched 13:18:56 What we are developing now is basically a "view" of the COPRs available at copr.fedoraproject.org 13:19:06 seems so 13:19:15 and we select which packages go into this "view" 13:19:19 or subset of them 13:19:24 right 13:19:35 juhp: yes, but in different namespace in /etc/yum.repos.d so you still can use "dnf copr" independetly 13:20:00 mirek-hm: I don't follow the cron job note -- what is it for? 13:20:03 mirek-hm, how about conflicting coprs then? 13:20:36 juhp: I provide gun, it is up to you if you shot yourself into leg 13:20:50 well I agree that making playground a set of coprs would at least distinguish it more from current copr 13:20:56 lol 13:21:12 mirek-hm, I mean in terms of playground 13:21:38 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 taskotron is only used for initial addition of copr to playground? 13:25:10 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 like signing 13:25:37 do we have to have signing for f21? 13:25:45 mirek-hm: I understood signing won't happen by obs-signd because of long thread on devel 13:27:13 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 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 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 "dnf copr" and "dnf playground" are totaly independet 13:29:56 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 hhorak: yes 13:30:23 so probably we need more strict criteria for playground with that implementation - like no copr conflicts etc 13:30:32 s/that/this/ 13:30:45 mirek-hm: ah, now I see that in your proposal. thanks. 13:30:53 juhp: I don't think so. 13:32:53 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 ah ok 13:33:04 sorry 13:33:18 will try to catch up on that 13:33:37 interesting 13:34:04 thanks 13:36:48 how about signing - is it an immediate requirement? 13:38:47 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 hhorak: -1 13:39:51 hhorak: you will be less flexible 13:40:17 hhorak: if somebody orphan his work and no one stand up, then it should be removed anyway 13:40:31 I think i agree with mirek-hm 13:41:08 of course accidents can happen... 13:41:26 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 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 maybe should be two stage - remove from playground and then delete 13:42:09 hhorak: but it happens for rawhide too say 13:42:25 I don't think so 13:43:10 juhp: ah, now I understand, some builds get removed automatically there 13:43:16 yeah 13:43:47 juhp: there is a difference though, that we have the source in the dist-git for rawhide 13:43:55 true indeed 13:43:57 this is not true for copr generally 13:44:01 I can personaly can live without removed packages, but I respect that somebody else can have different opinion 13:44:03 right 13:44:46 it might be nice to have an srpm repo 13:44:58 mirek-hm: to safe some space, only srpms could be backed-up, even on some different place 13:45:02 hhorak: well keeping source or packages longer would need some storage, which we do not have right now 13:45:10 and will not have for year 13:45:15 juhp for gpl you have to have a source somewhere 13:46:08 maybe we would encourage git for playground coprs... 13:46:30 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 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 mirek-hm, i stand by my comment 13:48:05 i did quailify my statement 13:48:08 Southern_Gentlem: how do you suggest we should solve problem with space? 13:48:24 hhorak: I'm not sure. Just be aware that we have some limits and we may hit ceiling 13:48:48 mmaslano: just have them in fedora git 13:49:02 drago01: copr packages are not stored in fedora git 13:49:16 mmaslano: oh forgot that playground uses copr 13:49:19 because you would need the review, which we didn't want, because it takes tooo much time 13:49:44 create a "copr" git and ask people to put stuff there 13:50:07 still a space issue 13:50:10 ok, so now we don't have a problem with disc space, but with maintenance of git and space 13:50:33 hehe :) 13:50:39 ... ok ;) 13:50:39 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 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 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 I put my coprs on github... 13:52:21 mirek-hm: we have a tool to commit to git called "git" i.e don't have to use fedpkg 13:52:45 bug dist-git use fedpkg 13:52:48 but 13:53:18 https://github.com/fedora-haskell/common/blob/master/common.mk very low-tech :) 13:54:28 anyway 13:54:36 I would be fine with asking users to add link to git project and don't care about it anymore 13:55:47 mirek-hm, could there be an optional git field in copr data? :) 13:56:24 mmaslano, anyway I agree it is good enough for now 13:59:02 noone answered my question I think about if package signing is needed sooner or later? 13:59:20 juhp: yes 13:59:36 to git field 13:59:40 :) 13:59:58 great 14:00:42 does that mean later then? :-) or did I miss that discussion? 14:01:14 is it only a requirement for mirroring? 14:01:33 * mirek-hm do not know 14:02:11 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 hhorak: sounds okay to me, please 14:04:26 lot of good discussion today I thought 14:04:32 #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 hhorak, thanks 14:06:07 anyone have more or anything else? or should we stop soon? :) 14:06:24 and we thought was it might be a short meeting today :) 14:06:44 juhp, yea, a very long meeting indeed :) 14:06:49 juhp: :) 14:07:10 anyway glad I am finally understanding the dnf plugin idea 14:08:19 I hope someone knows what should be done ;-) 14:11:20 mmaslano: I'll add some info notes before closing the meeting to sum the discussion up.. 14:12:48 #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 I need to re-read the Playground proposal in light of understanding the proposed implementation now 14:15:59 #info mirek-hm talked about "dnf playground enable" which would enable all copr repos in playground 14:16:02 I guess some parts doesn't make sense with dnf plugin 14:16:36 ok 14:18:49 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 #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 and we can go home :-D 14:20:08 thanks hhorak 14:20:24 at least I go soon.. Thanks all and bye! 14:20:29 good summary 14:20:40 yeah, let's go home 14:21:35 #endmeeting