I feel PRs are better for this sort of stuff. Mainly because people are informed why exactly this change is made, they can read the guidelines and then merge the change when they are sure they understand it. It helps spreading knowledge and keeping community involved. Python team did it very well in their "Fedora's Switch to Python 3 effort <https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3>", i think.
There are other reasons too. Some projects might keep the original spec file somewhere else than in DistGit and they need to port those changes back to the original spec files. It is much more pleasant to have those changes placed in a PR with a relevant description, which will also give them a proper notification. Otherwise, they might end up solving some unexpected conflicts next time they import their new spec files into DistGit. Maybe it would be nice if proven packagers had some tooling for doing those changes. clime On Thu, Feb 15, 2018 at 9:34 AM, Miroslav Suchý <msu...@redhat.com> wrote: > Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a): > > On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote: > >> On 02/14/2018 11:44 AM, Remi Collet wrote: > >>> - abuse proven packager privileges > >> +1 > +1 > > > Please, read policy[0] once more. > > > >> Sometimes there are situations where it's simply a lot easier to fix > stuff > > directly in Git than via bugzilla and the proper maintainers. So much > easier > > that we should leave this path open. These situations shouldn't arise > that > > often. Some examples of situations were bypassing the proper maintained > is > > considered fine: > >> […] > >> * small fixes or adjustments for new or modified packaging > > guidelines can be done directly in Git after being announced some days > > in advance. > > > > I just missed waiting for few days (kinda intentionally), because it > would not > > help anyone and will just disturb maintainers to do the actual work > whereas it > > doesn't make any sense because cleanup is automated. > > It state: > fixes or adjustments for **new or modified** packaging guidelines > > This is obviously meant for changes, which would block progress. Change of > BuildRoot tag is pretty old. It could wait > few more days just fine. > > > Miroslav > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
