On 07/11/2018 10:39 AM, Ben Rosser wrote:
On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer
> Because nobody is communicating with upstream and fixing it there. In
> some cases it'll be met with a shrug (like changelogs). In many, it
> might actually result in upstream making a similar fix.
What is "upstream", though? Some repository the packager uses to hold
the spec files? The actual upstream project that's being packaged?
Some other distribution's package repository? Presumably the people
doing automated cleanups would need to know this information, somehow.
Yep. I think most commonly it's the upstream project being packaged.
And if an automated cleanup involves hundreds or thousands of
packages, is it realistic to have the person doing that cleanup look
up and contact various different upstreams manually for all of these?
Doesn't this make it harder, not easier, to do automated package
Sadly it would indeed.
We have been telling people for a while now that they don't
their packages. Making it easier for people to maintain their packages
outside of dist-git and (effectively) ignore changes from
proven-packagers seems to take us in the opposite direction.
If this is really something that's necessary, maybe it would be good
to require someone's approval (FESCo? FPC?) to maintain a package
outside of Fedora dist-git. Then at least the number of such packages
could be hopefully kept low.
The problem here is there's competing interests here and Fedora has
limited leverage. On the one hand it makes automated changes harder,
which I think is a bad thing, but on the other hand some upstreams want
to manage their spec file in the same scm that they manage the project
in so they can easily make changes when upstream does so.
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. 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?
How about adopting a convention for these spec files? A way to identify
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?
Alternately we could look at something in pagure/src.fedoraproject.org
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.