I like this change, but one thing to note here is that it will break all downstream clients. It would be nice to have a guide for migrating. As far as I can tell, these steps are needed:

• update kojiconfig to kojiprofile in settings (instead of path there should be name of config section)
• argument should be similarly renamed for Commands.__init__ and Commands.container_build_koji (probably not necessary, but would be nice to keep it consistent)

Also we should make sure at packaging level that people don't install incompatible versions (new rpkg conflicts with current fedpkg).

@pbabinca pointed out that it would be nice to do this in a phased approach: we should support both the old config and the new, and report deprecation warnings on the old one. Only after a some time should the old config be removed.

Also, I don't think this needs to be merged immediatelly. As far as I know, it shouldn't block anything, so we can get a release out with current fixes and finish this work afterwards.

it does need to be rebased before it could be merged

@pbabinca @lsedlar

This is required by https://pagure.io/fedpkg/issue/97

May I ask what is the background to do it in phased approach? AFAIK, Koji profile is usable in either Fedora with koji (the CLI) and internal with brewkoji.

This PR aims to make an internal changes that would only useful for downstream client tool developers to update their code if necessary, and end-users should feel nothing changed. Deprecation warnings could not help too much in this case.

The reason for the phased approach is that it would allow downstream maintainers to update their clients on their own timeline.

Example scenario: a user upgrades pyrpkg and fedpkg both updated to use the profile, but e.g. rfpkg is not updated yet and thus it does not work. The user then has no way of having both fedpkg and rfpkg usable at the same time. They would need to upgrade and downgrade pyrpkg.

In general, it would be good to let downstream maintainers know coming changes before release, so that they would have time frame to update their project if necessary. I'm not sure if there is a way to "notify" them whatever via a IRC channel, mailing list e.g. devel@lists.fp.o, or something else. Is this doable for us to communicate? What do you think?

I don't know of any channel to reach out to all downstream clients (I don't even know how many there are).

But even if they know about the change in advance, it means the updates have to be coordinated and possibly reverted (if there's a bug etc.) all at once.

Indeed. Ok, let's do it in a phased approach.

In addition, I would give a 6 months time frame for potential downstream maintainers to update their projects, and this deprecation will be mentioned in release note. This could be a general way to handle other deprecations (if there is) in the future.

Ready for review again.

typo: unborken → unbroken

@lsedlar typo is fixed.

Should the default value be just config? I don't see kojiconfig used anywhere else. Also it may be useful to add the new argument at the end, if there is someone relying on the order of the named arguments (but there probably isn't anyone doing that).

Looks good to me. I think the warning should be logged explicitly via logging module (to make sure it's always displayed), but that should be done in another PR (probably in updated #221).