12:04:50 #startmeeting Env and Stacks (2014-04-29) 12:04:50 Meeting started Tue Apr 29 12:04:50 2014 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:04:50 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:04:57 #meetingname env-and-stacks 12:04:57 The meeting name has been set to 'env-and-stacks' 12:05:03 #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano 12:05:03 Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez 12:05:07 hi anybody here this week? 12:05:23 hi, mmaslano, I'm this week 12:05:37 * pkovar is here 12:05:58 hi 12:06:03 Hi 12:07:39 with me, it's five, probably enough for discussion 12:07:56 #topic Copr and Playground plugin part of dnf-plugins-core 12:08:28 msuchy asked on devel mailing list whether Copr plugin should be a part of dnf-plugins-core 12:08:38 * juhp_ is reading the bug 12:08:40 there are arguments either way and we should decide 12:09:12 is it enabled by default? 12:09:39 not enabled but present 12:09:42 I need to find the bug 12:10:18 .bug 1090516 12:10:18 #url https://bugzilla.redhat.com/show_bug.cgi?id=1090516 12:10:21 juhp_: Bug 1090516 move the copr plugin out of the core plugins - https://bugzilla.redhat.com/1090516 12:10:58 I am still a bit unclear about the pros and cons after reading the bug... 12:11:32 maybe it is easier to maintain in a separate package? 12:12:54 imho it's up to maintainer. If he believes the package is too big, then it could live elsewhere 12:13:07 I have no strong opinion on this. I'm slightly leaned towards separate upstream and package since the plugin is quite different from other plugins 12:13:20 not in copr package, because people don't need to install copr to use repos 12:13:49 mmaslano: I agree with "not in copr" 12:14:39 right 12:14:44 One additional argument is that users that expect to extend dnf's functionality by installing dnf-plugins-core might not expect to find a tool for enabling new repositories there 12:15:24 the main question seems to me whether these plugins are installed by default or not 12:15:30 tjanez, true 12:15:30 mmaslano: but if it was part of the copr component and was able to be installed separately, that is the same as it was a separate component 12:15:49 juhp_: I'm not sure about that but I guess they are not 12:15:51 juhp_: I don't think they are installed at all. If you install yum, you also don't have all yum plugins 12:16:00 juhp, agreed. 12:16:23 mmaslano, I mean in terms of comps :) 12:16:32 And maybe it will be easier to have a separate package (or even upstream) and decide separately which to enable by default 12:16:50 but yeah it doesn't really matter where they live as long as they are in a subpackage I guess 12:16:58 yeah 12:17:59 I would leave it up to maintainer of dnf-plugin-core anyway. 12:18:36 maybe it can be packaged as dnf-plugin-playground 12:18:44 and everyone would be happy 12:20:54 mmaslano: that sounds fine for me, if it turns to be a problem, this can be changed in the future 12:21:04 mmaslano, I think the maintainer(s) tried to decide themselves but asked us for help 12:22:40 yes 12:23:02 if the source was called dnf-plugins it would make perfect sense to have a subpackage for copr/playground etc 12:24:27 From my POV it is important to make the package be found easily. something like dnf-plugins or dnf-plugin-copr seems fine for me 12:24:41 on the other hand copr.py is only 6kB 12:24:54 hhorak, yep 12:25:17 surely there will be more non-core plugins coming 12:25:39 I know paragan is planning to port yum-langpacks to dnf :) 12:26:58 #proposal Propose to maintainer he can package it as dnf-plugin-copr if he feels it's the right thing to do 12:27:30 +1 12:27:32 +1 12:28:28 -1. Do we want the Playground repository to be "hidden" as a subset of Copr? 12:28:59 tjanez: playground plugin have different code 12:29:03 I guess 12:30:47 mmaslano, for practical reasons as it shares a lot of the same code, the dnf playground command is not implemented as part of the dnf copr plugin. But from a user's POV wouldn't it be more recognizable to install dnf-plugin-playground 12:30:58 s/not/now 12:31:16 yes, it does 12:32:19 mmaslano, what do you mean with "yes, it does" 12:32:25 dunno if there could be a dnf-plugin-playground subpackage to enable it or something 12:32:42 probably need to ask msuchy 12:33:27 msuchy will appear in a minute 12:33:48 let's rather talk to developer than invent something 12:33:51 mirek-hm: hi 12:33:58 hi 12:34:18 how would you feel about dnf-plugin-copr and subpackage dnf-plugin-copr-playground? 12:34:47 or something close to such proposal 12:34:58 both separate from dnf-plugins-core? 12:35:27 separated from -core 12:35:32 technicaly I would have no problem with that 12:35:53 It would just slow down development little bit 12:36:11 hm really? 12:36:26 example: 12:38:05 last week there were changes in dnf plugins (i18n), and all changes were done en bloc for all plugins in -core (because you would just git grep and subsitute), but if it will be separate project, It will take me several days (or even week) before I acknowlidge such change and change code. 12:39:10 mirek-hm, have you discussed more with Ales? 12:39:10 so if api change I may react e.g after several day after release of new DNF, If it will be part of -core I will be notified during the change 12:39:27 juhp_: yes 12:39:35 I think it will not be long before other non-core plugins appear though 12:40:08 yes, but this is more about question how much is playground 'core' 12:40:15 true 12:40:42 and copr 12:40:50 mirek-hm, if I understood your reasoning initially, when you put the playground command into the copr plugin to have greater developer exposure and easier maintenance/contributions 12:41:10 but you intended to move it out eventually 12:42:26 well ... playground plugin is just subclass of copr class in API code - with very few changes. So it does have sense to have those two together (unless you want to duplicate code, which is always maintance nightmare) 12:43:02 but yes, I wanted bigger exposure and easier maintenance 12:43:28 Does anybody know if there is going to be something like dnf-plugins-noncore or every other plugin is expected to be maintained separately? 12:44:10 mirek-hm, agreed. Maybe we want separate packages so that users can enable/choose different functionality separately (e.g. dnf-plugin-copr, dnf-plugin-playground)? 12:45:18 hhorak, good question. I guess it will be harder to have a common upstream git repo for all noncore dnf plugins 12:45:22 mirek-hm: I don't you want to duplicate the code, so how could we split it into two complety separated packages without it 12:45:22 btw it will mean that dnf-plugin-playground would require dnf-plugin-copr 12:45:38 if it's only R necessary, then it's fine 12:45:47 yes only R 12:45:49 mirek-hm: do you package it for Fedora? I can do a review ;-) 12:46:24 if it will be your conclusion, then I can package it for Fedora in matter of hours :) 12:46:28 mmaslano, what does "R" stand for? 12:46:33 require 12:47:57 #proposal there will be dnf-plugin-copr and dnf-plugin-playground 12:48:17 mirek-hm, mmaslano, would this option mean a separate package for dnf-plugin-copr and dnf-plugin-playground or just separate subpackages? 12:48:28 tjanez: I guess even common repo makes sense, in order to have a better maintenance, like dnf-plugins-other. This would deliver both dnf-plugin-copr and dnf-plugin-playground + some other, installed separately. Some other plugins (say dnf-plugin-foo) can have own github repo and own component, that's not a problem. 12:49:22 tjanez: package dnf-plugin-copr with subpackage dnf-plugin-playground 12:49:44 hhorak, I might suggest just dnf-plugins, but something like that yes 12:49:59 or I can ask ales if I can stay in -core.git but become subpackage of -core 12:50:05 mirek-hm, ok, thanks for explaining 12:50:08 mirek-hm, right 12:50:42 I think it is really up to the dnf community to come up with the best package structure 12:50:53 mirek-hm, does copr plugin depend on anything from other plugins or just dnf? 12:51:44 tjanez: dnf and urlgrabber (IIRC) 12:53:22 mmaslano: I'd say yes for providing dnf-plugin-copr and dnf-plugin-playground RPMs. Where they are coming from (which repo, which component), it can be solved but mirek-hm + ales, just what is the best for them. 12:53:23 I agree with juhp, the dnf community should decide how to coordinate code changes for DNF's API changes and how to classify the plugins 12:53:36 but they asked us for input :) 12:54:02 right 12:54:23 for the record, I'm +1 on dnf-plugin-copr with subpackage dnf-plugin-playground 12:54:30 also +1 12:54:41 mmaslano: the input is that the copr plugin will be part of the dnf-plugin-copr, not dnf-plugin-core 12:54:53 do you feel that playground is 'core', that after installing -core should be every user be able to enable playground? 12:55:11 (hmm copr and core are quite similar;) 12:55:37 mirek-hm, no. In my opinion, 'core' refers to the type of DNF's functionality they provide 12:55:46 I need to move to another meeting, please finish it without me. I can send the minutes later. 12:56:01 juhp, you are funny :) 12:56:33 thanks 12:58:03 mirek-hm, from user's POV, it would be even more elegant and straightforward to install fedora-playground-repo, which would then Suggest dnf-plugin-playground, gnome-software-playgroud (or something) 12:58:52 aha 12:59:35 tjanez: sounds interesting 13:00:36 define fedora-playground-repo 13:00:50 it might just be a metapackage? 13:01:16 yes, as juhp_ said. 13:01:57 And if we some day convert the playground repo to a real repository, the fedora-playground-repo could carry the actual .repo file(s) 13:03:13 something like fedora-release-rawhide, which ships a repo file 13:11:20 tjanez: so if I get back to dnf-plugin, this approach would solve the request to be 'easily found' by users 13:12:42 hhorak, yes, let's get back to the dnf-plugin. 13:13:07 Would anyone else vote for mmaslano's proposal? 13:13:09 mirek-hm: is the code of the copr plugin tight to dnf so close, that it would make sense to maintain it together? If so, I'd recommend to have something like already mentioned dnf-plugins and keep it there. otherwise, we can have a new component for dnf-plugin-copr 13:14:12 and for the record, I'm also +1 on dnf-plugin-copr with subpackage dnf-plugin-playground as proposed 13:15:03 hhorak: hmm tight... yes and no, I would say :) , but the fact is that it is biggest plugins from -core set :) 13:17:36 mirek-hm, maybe that's why Ales & co. would like to get rid of maintaining it :) 13:17:57 tjanez: I do the maintenance 13:18:17 mirek-hm, ok, than that's not the reason 13:18:39 mirek-hm, what did Ales say actually? 13:19:16 juhp_: Ales supported removal from dnf-plugin-core 13:19:33 juhp_: ^ in the bug report, commen #1 13:20:12 juhp_: he does not mind to be copr.py present in -core as long as he does not need to maintain it (I promised to do it) as long as the code is good enough (which is good) and as long as I would handle incoming pull request (which I do) 13:21:06 hhorak: I understanded his comment as neutral (but I may be wrong) 13:21:43 So, if we go for a separate RPM package dnf-plugin-copr, then changing the upstream git repo is not a problem in the future 13:22:29 tjanez: upstream repo of plugin itself? no problem 13:22:57 mirek-hm, I meant moving copr.py to a new upstream git repo 13:24:04 tjanez: beside the problem I described in [14:35] , no problem 13:25:18 mirek-hm, okay 13:25:21 mirek-hm, yes, I know. But when DNF's API stabilizes and when we have more non-core DNF plugins, moving it out of dnf-plugins-core git repo will not be such a maintenance hassle anymore? 13:25:26 mirek-hm, right 13:25:55 So I guess, I'm suggesting you deffer moving it out for now. 13:26:05 I agree that it does not sound very urgent to move the code but probably good to do it for F21 13:26:10 yes 13:26:32 that sounds sane for me as well 13:26:46 specially if the plugin API is still in flux 13:27:08 Cool, then we are close to solving thisl 13:28:34 * mirek-hm agree 13:29:09 so the scenario right now looks like 'provide the copr plugin in dnf-plugin-copr package a playground plugin in dnf-plugin-playground package now, both as a part of dnf-plugin-core upstream for now and detach them to the separate upstream at a time dnf's API is stable enough' 13:29:31 #proposal: The Env and Stacks WG's suggestion to the dnf-plugins-core maintainers is to create a separate dnf-plugin-copr package with the dnf-plugin-playground subpackage. In addition, we suggest to defer moving copr.py out of the dnf-plugin-core upstream git repository until DNF's API stabilizes 13:29:36 hhorak, you beat me to it :) 13:30:11 tjanez: but your is the official proposal so you won! :D 13:30:15 +1 13:30:50 hhorak, I remembered to put a #proposal in front, that's all :) 13:30:58 +1 13:31:00 anyway, +1 13:32:20 +1 13:32:51 +1 13:34:07 #agree The Env and Stacks WG's suggestion to the dnf-plugins-core maintainers is to create a separate dnf-plugin-copr package with the dnf-plugin-playground subpackage. In addition, we suggest to defer moving copr.py out of the dnf-plugin-core upstream git repository until DNF's API stabilizes (+1:5, 0:0, -1:0) 13:34:16 #agreed: The Env and Stacks WG's suggestion to the dnf-plugins-core maintainers is to create a separate dnf-plugin-copr package with the dnf-plugin-playground subpackage. In addition, we suggest to defer moving copr.py out of the dnf-plugin-core upstream git repository until DNF's API stabilizes (+1:5, 0:0, -1:0) 13:35:14 We just passed 1.5h, do we wrap up now, or do you want to continue? 13:37:40 tjanez: I vote for closing today. 13:38:06 the other topic was about dnf playground plugin being able to exclude some package but maybe better to defer to next meeting/mailing list 13:38:15 hhorak, seconded 13:38:43 (s/package/packages/) 13:38:55 sound like an rfe for mirek-hm :) 13:39:35 and the bigger topic of deleting packages/copr from playground 13:39:42 #action: tjanez will notify the dnf-plugins-core maintainers about our today's discussion and suggestion 13:44:08 If no-one protests, I'll wrap the meeting in 1 minute 13:45:57 #endmeeting