On Wed, Jul 11, 2018 at 12:47:40PM -0700, Kevin Fenzi wrote:
The guidelines currently say:
"Fedora's git repository is the canonical location for Fedora spec
files. Maintainers MUST expect that other maintainers and automated
tooling will make changes to their packages, potentially without
communicating prior to doing so (though communication is always
encouraged). If some maintainers are also attempting to keep copies of a
spec in an outside repository, they MUST be prepared to merge changes
made to the spec in Fedora's repository, and MUST NOT overwrite those
changes with a copy from an external repository or using fedpkg import."
I think this guideline is bad and counterproduuctive, since many
packages clearly ignore it.
It would be "counterproductive" if it
increased the occurrence of the
unwanted thing. If it's sometimes ignored, sometimes not, it's not
counterproductive, but maybe not as effective as (some) would like.
So what do we do? Take the package away from
(most likely) upstream developers? Tell them no no no very sternly so
they can ignore us?
Actually I think this setup is more often used by projects that
Fedora-only or RHEL-and-Fedora-only, than fully independent upstream
projects. So we do have leverage.
How about adopting a convention for these spec files? A way to
them and provide a channel of communication for changes? A comment with
# Canonicalspec: https//pagure.io/blah/blah.spec
# ChangesPR: ...path to pr interface
# ChangesTicket: ...path to just filing a ticket about changes?
This was tried and
rejected in https://fedorahosted.org/fpc/ticket/613
Not that this decision is forever.
Alternately we could look at something in
to mark them somehow, or try and identify them and make a README.spec
file for each of them or soemthing.
Barring that, I think we will just continue to have people make changes
and them get overwritten.
... or we can encourage those people to follow the
guidelines. It seems
that it's just a handful of packages.