On 07/11/2018 10:39 AM, Ben Rosser wrote: > On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >> 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 > cleanups? Sadly it would indeed. > We have been telling people for a while now that they don't "own" > 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: https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity "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. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/KZFCBTJIHV7MJGCISVWUYYGPZRWPGOCE/
