Description of problem: I just noticed that copr plugin is in the dnf plugins core. I do believe that this plugin is not a "core" plugin and it will make more sense to keep it in a package like fedpkg. Version-Release number of selected component (if applicable): latest git (2014-04-23)
Miroslav, as I said earlier, I share the reporter's opinion here.
Can you elaborate on: "I do believe that this plugin is not a "core" plugin..." ? AFAIK the definition of "core" is very vague and means plugins that: * target wider audience (which is true for copr and playground) * have good code quality so DNF team is willing to ship it and support it I asked for inclusion of this plugin in dnf-plugins-core because: * it reach more people which otherwise will not heard about it * it easy maintanance (same changes are done across all plugins) * it seems to me overkill to ship one file in its own package I personally see no disadvantages. Do you see some? Why the split make sense to you?
(In reply to Miroslav Suchý from comment #2) > Can you elaborate on: > "I do believe that this plugin is not a "core" plugin..." > ? - sure, please see my answer below > > AFAIK the definition of "core" is very vague and means plugins that: > * target wider audience (which is true for copr and playground) > * have good code quality so DNF team is willing to ship it and support it > - so the only requirement is actually good code quality, because "wider audience" can be anything > I asked for inclusion of this plugin in dnf-plugins-core because: > * it reach more people which otherwise will not heard about it > * it easy maintanance (same changes are done across all plugins) > * it seems to me overkill to ship one file in its own package > > I personally see no disadvantages. Do you see some? - disadvantages: bloated "core" packages, according to this logic we could squeeze a lot of Fedora packages > Why the split make sense > to you? - because I see core plugins as plugins for ordinary users who don't care about copr repos, they just want to work with the default repositories. And I didn't say a separate package with just one file, I suggested a different package which seems to me more appropriate given the target audience: "...and it will make more sense to keep it in a package like fedpkg"
Maybe the right place should be the copr package itself? The copr audience are developers using Copr, that is a a different thing than the general Fedora audience.
From todays meeting: [15:34] <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) So I will keep it in dnf-plugins-core package (and git). And once DNF stabilize (probably when it replace yum) - and the idea of playground will stabilize as well - I will reopen this bug and likely move it to separate package. Until then I defer it as suggested by The Env and Stacks WG
DNF 1.0.0 have been released. So, the last blocker is the playground.