-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, 2018-01-20 at 13:52 +0100, Fabio Valentini wrote: > I find it hard to track changes to the Packaging Guidelines, and when those > changes are made, they sometimes only apply to certain branches (or only to > rawhide), and it's no longer clear which Guidelines apply to other branches. Few folks proposed to switch guidelines to git[0]. I think if we would have el6/el7/f26/f27/master branches of guidelines, that would help with this. [0] https://pagure.io/packaging-committee/issue/727 > It would be really useful to have a wiki page outlining where the > Guidelines for stable branches are different to the most recent version of > the Packaging Guidelines (if such a page already exists, please ignore this > and point me to it). I think Jason Tibbs said somewhere that packaging guidelines are targeting only rawhide. But I'm not sure if there is sentence written somewhere. > With this information as an authoritative source (current Guidelines for > rawhide branch, and exceptions/adaptations for other branches and EPEL), we > could start pointing out where .spec files (regardless of the branch) don't > comply (anymore) with the applicable "version" of the Guidelines, and start > to remove conditionals where they can be removed, and to report / fix > issues - with little to no room for differences in "taste" or > "interpretation". Hmm, we could start versioning guidelines and ask people writing in first line of spec which guidelines they were complying to. And probably some lints in fedora-review for this... I don't this is possible to do in short period of time, but might be good idea for far future. > Conditionals for current fedora releases aside, checks for releases that > have reached EOL should be cleaned up as soon as possible anyway (I still > find .spec files referencing fedora 21 or earlier sometimes) ... A lot of Python packages reference F>=12. > TL;DR: > We need an authoritative source that tells us packagers which Guidelines > apply to which branch (or what has to be done differently - or can be done > better - in, for example, f26 when compared to the current Packaging > Guidelines). > With this information, we can start cleaning up unneccessary or outdated > conditionals in .spec files, and can probably remove all conditionals > (depending on %{?fedora}) altogether - since IMO the maintenance burden and > error-prone-ness of "compatibility" between branches is way greater than > the benefit of being able to "merge" (caveat changelogs, Release tags, > other changes) from newer to older releases. > This will, over time (as changes to rawhide trickle down into what will > become fedora 28/29 and fedora 29/30), lead to much simpler, less > error-prone, and more easily maintainable .spec files (which benefits > maintainers, co-maintainers, provenpackagers, and users). > Independently, I think conditionals for releases older than N-2 > (currently: 24 and earlier) should be removed either way, and checks for > fedora < N-1 should be removed after the corresponding release reaches EOL. Fully agree with what you are saying here! - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpjRHYACgkQaVcUvRu8 X0whzg/+IdCX5KJkVPiRm3R0JcRe8j87KIr12F2gROLiZ6KQcCeIgTJzGV2pnF95 fMv4FRCiPo8VbRMtY8oIxsEbUYEYrmsZ+VBkSYz7RLQPnJYI0t1q57CP/ACiaWyS G7ZPykOZaIevO1YLtYVkkcBjH/V7omrF0+W4a99ACBTPVX5IbZHkBdw4qRavznhF mLV8scfYQnAEFW5TGoVMe+ZczKV2vxhE+VEx5S8yFxznJqGUwlXh5N3FvdLt8yUx WlZVbTYTHmmNgJtLygB9CwF53KHLDeija9YTOX2jkWs2FQGIVTATzn4+XJ7c7s6C lpUWNz4kd2EIMAjdUKzFLzZUrH8V8Al4N79PAGx/2kwBzF+1LdIWfdkHpB+qyQ2T EYUP4XcDhWb+/gF+UEEqfarm76trQc2kgEvTDsVaOQP5AlouemE2r31ERqZFVjoA IC6S1OgMeM83xmg25SAxvSW82OQNeLK3X/ksDhdlyd5tWaMk7S5kdZGJepujEKsd x57RAYZP3Z3Z0KU+1J6Gjx+WMEeLStiNLo58jJGZGUza08rjvd2OHZrZlahX5cEg mZJGEbR+cZcQp8JdnaPgWwvhvCUynO6pRFjgBfkVQ+Hmk5e3OahDvxtO0ulBrWwH QuOziTbjKY/V5zhM1+4/Vbw+TjJhQgxZSX2xonox1Kz0s7Lf2bI= =9cBz -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
