12:04:50 <mmaslano> #startmeeting Env and Stacks (2014-04-29)
12:04:50 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:04:57 <mmaslano> #meetingname env-and-stacks
12:04:57 <zodbot> The meeting name has been set to 'env-and-stacks'
12:05:03 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
12:05:03 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez
12:05:07 <mmaslano> hi anybody here this week?
12:05:23 <tjanez> hi, mmaslano, I'm this week
12:05:37 * pkovar is here
12:05:58 <juhp_> hi
12:06:03 <hhorak> Hi
12:07:39 <mmaslano> with me, it's five, probably enough for discussion
12:07:56 <mmaslano> #topic Copr and Playground plugin part of dnf-plugins-core
12:08:28 <mmaslano> 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 <mmaslano> there are arguments either way and we should decide
12:09:12 <juhp_> is it enabled by default?
12:09:39 <mmaslano> not enabled but present
12:09:42 <mmaslano> I need to find the bug
12:10:18 <juhp_> .bug 1090516
12:10:18 <mmaslano> #url https://bugzilla.redhat.com/show_bug.cgi?id=1090516
12:10:21 <zodbot> juhp_: Bug 1090516 move the copr plugin out of the core plugins - https://bugzilla.redhat.com/1090516
12:10:58 <juhp_> I am still a bit unclear about the pros and cons after reading the bug...
12:11:32 <juhp_> maybe it is easier to maintain in a separate package? <shrug/>
12:12:54 <mmaslano> imho it's up to maintainer. If he believes the package is too big, then it could live elsewhere
12:13:07 <tjanez> 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 <mmaslano> not in copr package, because people don't need to install copr to use repos
12:13:49 <hhorak> mmaslano: I agree with "not in copr"
12:14:39 <juhp_> right
12:14:44 <tjanez> 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 <juhp_> the main question seems to me whether these plugins are installed by default or not
12:15:30 <juhp_> tjanez, true
12:15:30 <hhorak> 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 <hhorak> juhp_: I'm not sure about that but I guess they are not
12:15:51 <mmaslano> 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 <tjanez> juhp, agreed.
12:16:23 <juhp_> mmaslano, I mean in terms of comps :)
12:16:32 <tjanez> 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 <juhp_> but yeah it doesn't really matter where they live as long as they are in a subpackage I guess
12:16:58 <juhp_> yeah
12:17:59 <mmaslano> I would leave it up to maintainer of dnf-plugin-core anyway.
12:18:36 <mmaslano> maybe it can be packaged as dnf-plugin-playground
12:18:44 <mmaslano> and everyone would be happy
12:20:54 <hhorak> mmaslano: that sounds fine for me, if it turns to be a problem, this can be changed in the future
12:21:04 <tjanez> mmaslano, I think the maintainer(s) tried to decide themselves but asked us for help
12:22:40 <mmaslano> yes
12:23:02 <juhp_> if the source was called dnf-plugins it would make perfect sense to have a subpackage for copr/playground etc
12:24:27 <hhorak> 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 <juhp_> on the other hand copr.py is only 6kB
12:24:54 <juhp_> hhorak, yep
12:25:17 <juhp_> surely there will be more non-core plugins coming
12:25:39 <juhp_> I know paragan is planning to port yum-langpacks to dnf :)
12:26:58 <mmaslano> #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 <hhorak> +1
12:27:32 <juhp_> +1
12:28:28 <tjanez> -1. Do we want the Playground repository to be "hidden" as a subset of Copr?
12:28:59 <mmaslano> tjanez: playground plugin have different code
12:29:03 <mmaslano> I guess
12:30:47 <tjanez> 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 <tjanez> s/not/now
12:31:16 <mmaslano> yes, it does
12:32:19 <tjanez> mmaslano, what do you mean with "yes, it does"
12:32:25 <juhp_> dunno if there could be a dnf-plugin-playground subpackage to enable it or something
12:32:42 <juhp_> probably need to ask msuchy
12:33:27 <mmaslano> msuchy will appear in a minute
12:33:48 <mmaslano> let's rather talk to developer than invent something
12:33:51 <mmaslano> mirek-hm: hi
12:33:58 <mirek-hm> hi
12:34:18 <mmaslano> how would you feel about dnf-plugin-copr and subpackage dnf-plugin-copr-playground?
12:34:47 <mmaslano> or something close to such proposal
12:34:58 <mirek-hm> both separate from dnf-plugins-core?
12:35:27 <mmaslano> separated from -core
12:35:32 <mirek-hm> technicaly I would have no problem with that
12:35:53 <mirek-hm> It would just slow down development little bit
12:36:11 <mmaslano> hm really?
12:36:26 <mirek-hm> example:
12:38:05 <mirek-hm> 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 <juhp_> mirek-hm, have you discussed more with Ales?
12:39:10 <mirek-hm> 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 <mirek-hm> juhp_: yes
12:39:35 <juhp_> I think it will not be long before other non-core plugins appear though
12:40:08 <mirek-hm> yes, but this is more about question how much is playground 'core'
12:40:15 <juhp_> true
12:40:42 <juhp_> and copr
12:40:50 <tjanez> 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 <tjanez> but you intended to move it out eventually
12:42:26 <mirek-hm> 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 <mirek-hm> but yes, I wanted bigger exposure and easier maintenance
12:43:28 <hhorak> 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 <tjanez> 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 <tjanez> hhorak, good question. I guess it will be harder to have a common upstream git repo for all noncore dnf plugins
12:45:22 <mmaslano> 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 <mirek-hm> btw it will mean that dnf-plugin-playground would require dnf-plugin-copr
12:45:38 <mmaslano> if it's only R necessary, then it's fine
12:45:47 <mirek-hm> yes only R
12:45:49 <mmaslano> mirek-hm: do you package it for Fedora? I can do a review ;-)
12:46:24 <mirek-hm> if it will be your conclusion, then I can package it for Fedora in matter of hours :)
12:46:28 <tjanez> mmaslano, what does "R" stand for?
12:46:33 <mirek-hm> require
12:47:57 <mmaslano> #proposal there will be dnf-plugin-copr and dnf-plugin-playground
12:48:17 <tjanez> 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 <hhorak> 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 <mirek-hm> tjanez: package dnf-plugin-copr with subpackage dnf-plugin-playground
12:49:44 <juhp_> hhorak, I might suggest just dnf-plugins, but something like that yes
12:49:59 <mirek-hm> or I can ask ales if I can stay in -core.git but become subpackage of -core
12:50:05 <tjanez> mirek-hm, ok, thanks for explaining
12:50:08 <juhp_> mirek-hm, right
12:50:42 <juhp_> I think it is really up to the dnf community to come up with the best package structure
12:50:53 <tjanez> mirek-hm, does copr plugin depend on anything from other plugins or just dnf?
12:51:44 <mirek-hm> tjanez: dnf and urlgrabber (IIRC)
12:53:22 <hhorak> 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 <tjanez> 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 <mmaslano> but they asked us for input :)
12:54:02 <mirek-hm> right
12:54:23 <tjanez> for the record, I'm +1 on dnf-plugin-copr with subpackage dnf-plugin-playground
12:54:30 <juhp_> also +1
12:54:41 <hhorak> mmaslano: the input is that the copr plugin will be part of the dnf-plugin-copr, not dnf-plugin-core
12:54:53 <mirek-hm> do you feel that playground is 'core', that after installing -core should be every user be able to enable playground?
12:55:11 <juhp_> (hmm copr and core are quite similar;)
12:55:37 <tjanez> mirek-hm, no. In my opinion, 'core' refers to the type of DNF's functionality they provide
12:55:46 <mmaslano> I need to move to another meeting, please finish it without me. I can send the minutes later.
12:56:01 <tjanez> juhp, you are funny :)
12:56:33 <juhp_> thanks
12:58:03 <tjanez> 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 <juhp_> aha
12:59:35 <hhorak> tjanez: sounds interesting
13:00:36 <mirek-hm> define fedora-playground-repo
13:00:50 <juhp_> it might just be a metapackage?
13:01:16 <tjanez> yes, as juhp_ said.
13:01:57 <tjanez> 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 <tjanez> something like fedora-release-rawhide, which ships a repo file
13:11:20 <hhorak> tjanez: so if I get back to dnf-plugin, this approach would solve the request to be 'easily found' by users
13:12:42 <tjanez> hhorak, yes, let's get back to the dnf-plugin.
13:13:07 <tjanez> Would anyone else vote for mmaslano's proposal?
13:13:09 <hhorak> 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 <hhorak> and for the record, I'm also +1 on dnf-plugin-copr with subpackage dnf-plugin-playground as proposed
13:15:03 <mirek-hm> hhorak: hmm tight... yes and no, I would say :) , but the fact is that it is biggest plugins from -core set :)
13:17:36 <tjanez> mirek-hm, maybe that's why Ales & co. would like to get rid of maintaining it :)
13:17:57 <mirek-hm> tjanez: I do the maintenance
13:18:17 <tjanez> mirek-hm, ok, than that's not the reason
13:18:39 <juhp_> mirek-hm, what did Ales say actually?
13:19:16 <hhorak> juhp_: Ales supported removal from dnf-plugin-core
13:19:33 <hhorak> juhp_: ^ in the bug report, commen #1
13:20:12 <mirek-hm> 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 <mirek-hm> hhorak: I understanded his comment as neutral (but I may be wrong)
13:21:43 <tjanez> 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 <mirek-hm> tjanez: upstream repo of plugin itself? no problem
13:22:57 <tjanez> mirek-hm, I meant moving copr.py to a new upstream git repo
13:24:04 <mirek-hm> tjanez: beside the problem I described in [14:35] , no problem
13:25:18 <juhp_> mirek-hm, okay
13:25:21 <tjanez> 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 <juhp_> mirek-hm, right
13:25:55 <tjanez> So I guess, I'm suggesting you deffer moving it out for now.
13:26:05 <juhp_> I agree that it does not sound very urgent to move the code but probably good to do it for F21
13:26:10 <juhp_> yes
13:26:32 <hhorak> that sounds sane for me as well
13:26:46 <juhp_> specially if the plugin API is still in flux
13:27:08 <tjanez> Cool, then we are close to solving thisl
13:28:34 * mirek-hm agree
13:29:09 <hhorak> 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 <tjanez> #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 <tjanez> hhorak, you beat me to it :)
13:30:11 <hhorak> tjanez: but your is the official proposal so you won! :D
13:30:15 <hhorak> +1
13:30:50 <tjanez> hhorak, I remembered to put a #proposal in front, that's all :)
13:30:58 <mmaslano> +1
13:31:00 <tjanez> anyway, +1
13:32:20 <juhp_> +1
13:32:51 <pkovar> +1
13:34:07 <tjanez> #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 <tjanez> #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 <tjanez> We just passed 1.5h, do we wrap up now, or do you want to continue?
13:37:40 <hhorak> tjanez: I vote for closing today.
13:38:06 <juhp_> 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 <juhp_> hhorak, seconded
13:38:43 <juhp_> (s/package/packages/)
13:38:55 <juhp_> sound like an rfe for mirek-hm :)
13:39:35 <juhp_> and the bigger topic of deleting packages/copr from playground
13:39:42 <tjanez> #action: tjanez will notify the dnf-plugins-core maintainers about our today's discussion and suggestion
13:44:08 <tjanez> If no-one protests, I'll wrap the meeting in 1 minute
13:45:57 <tjanez> #endmeeting