#1840 Better policy for mass cleanups / trivial changes for provenpackagers
Closed: Fixed 6 years ago Opened 6 years ago by ignatenkobrain.

So it's not first time when I had to do this and always there are some people who are unhappy with this. So I would like to ask FESCo to improve policy for provenpackagers for cleanups on big scale (e.g. python renaming, %ldconfig_scriptlets).

For example, having non-escaped macro in %changelog is bad and sometimes even harmful which breaks package builds and shows incorrect information to users. This is so trivial that it doesn't need to be wrapped into Change.

Having some sentence like "changes which affect more than X packages and done by automation must be carefully reviewed and pushed using provenpackager privileges with X days notice" would be helpful.


Frankly, I think current policy [https://fedoraproject.org/wiki/Mass_package_changes ] covers all those points. It says

Automated package cleanup is encouraged. If it is possible to make the relevant change in an automated fashion with a low chance of unwanted side effects then this should at least be considered, even if that can only be done for a subset of the affected packages.

and

Once you have a clear idea of the changes needed, post a clear email on changes needed to the devel-announce list. Wait at least a week to allow maintainers to make changes or ask you further questions about the change on the devel list.

I think this is a good policy, and putting more details in the policy text would just make it less flexible.

Metadata Update from @bowlofeggs:
- Issue tagged with: meeting

6 years ago

This issue will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on
irc.freenode.net.

Note that this is a change in time from the previous FESCo meeting time.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto

or run:
date -d '2018-02-16 15:00 UTC'

So it's not first time when I had to do this

HAD TO ?

Surely you jest

Your actions pushing non-time urgent changes into %changelog is a nice and clear example of abuse of PP rights

It was a cosmetic change as to expansions against "[ ]%" which offended your sensibilities (or those of 'linting' scripts.) There was no urgency what-so-ever. You just did it, and then realizing you had actually released a batch process without following existing protocol, sought forgiveness. There is a mind-set / omnipotence attitude here, and it is wrong

The change, because it was rushed through by you, without a week's notice, happened to also 'double' "[ ]%[ ]" to "[ ]%%[ ]" which could NEVER affect builds. The existing policy speaks of:

with a low chance of unwanted side effects

but no, false urgency and hubris, rather than posting a propose change script, let to such 'slipping through.'

As I say, this is, plain and simple, an abuse of ProvenPackager rights. It is directly contrary to the outcome and guidance of:

https://pagure.io/fesco/issue/1799

If PP's persist in NOT filing bugs, or reasonable asking and informing, rather than just taking actions, the outcome will be that non @redhat's will say:

  • shrug * I will either take what I am given, or I will leave. Why should I bother to spend ym time doing maintenance when others will?

Your actions like this have weakened the Fedoraproject

Except that I know it would be a vain act, I would file a bug asking that your PP rights be removed, to prevent future similar conduct

I ask that FESCO not further enable a divide between PP's and 'groundlings' and reject this proposal

AGREED: change policy to mail devel-announce instead of devel. mention in automated cleanup that a PP may do it without PRs (+5, 0, -0)

@bowlofeggs will make the documentation changes.

Metadata Update from @bowlofeggs:
- Issue untagged with: meeting
- Issue assigned to bowlofeggs

6 years ago

I have made the agreed changes.

Metadata Update from @bowlofeggs:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 years ago

I think that given we have fixed mass rebuilds in the schedule that the right way to deal with things like have been done recently is to add support to the mass rebuild scripts for the changes, Ideally by execuing stand alone tools so people can run them on their own as they see fit. The end result is we would batch up the changes into the existing mass rebuild process and reduce the churn some.

Login to comment on this ticket.

Metadata