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
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", i think.
There are other reasons too. Some projects might keep the original spec file somewhere
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ý <msuchy@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
