I think that an amendment like that would be equivalent to forbidding mass changes. Many mass changes touch hundreds or thousands of packages. Proven packagers don't have an office that'd take care of opening communication with a thousand maintainers. And for a single person that'd be full time job — hundreds of hours of mostly pointless work.

There's strong asymmetry in feedback from such changes: the "silent majority" is OK or doesn't care, a few people will issue a ++ on IRC on make an aside on the mailing list, but if someone doesn't like the changes, they'll open a big thread on the mailing list or ticket. So despite some high-profile discussions, I think that the number of people unhappy with current process is very low. In fact on the recent thread on the mailing list most of the replies were very dismissive of the concerns against mass fixups.

Another thing to consider is that if the policy was amended in the proposed way, a lot of people would be unhappy about "spam" (e.g. multiple bugzilla e-mails about a trivial change to a spec file). So it's possible that not only would there be a huge extra amount of work for the people doing the changes, it's likely that this extra work would only annoy more people.

-1 on the proposal.

We'll discuss this proposal in this week's FESCo meeting on December 8th.

I won't make it to the meeting this week. I'm personally -1 on this proposal.

We already have a process for dealing with the rare cases where a provenpackager "abuses" their power and makes unsafe changes. However, as a general rule, I think that the whole point of the provenpackager status is that these people are trusted. They may lose that trust, but for as long as they have this designation, I think they should be presumed to be acting in the best interest of Fedora (even where this may disagree with the package maintainers' personal opinions).

I see this ticket filed yesterday got tagged for this week's meeting ... and some negative 'absentee' votes dropped on it. I am fine with holding it over a week to let it be more thoughtfully considered

Fedoraproject has a 'culture problem' of racing non-urgent items through to its detriment

Within the last three months:

1. Fonts retirement 'dropped on a thoughtful maintainer' who was in process updating the area
2. unanswered objections on wrappers
3. non-responsive maintainers as to a seeming redesign of the work-flow on SElinux

The assertion of 'rare' seems disingenuous

David Kaspar [Dee'Kej]
Monday, 4 December 2017
Proven packagers - stop messing with other people packages!!

Kaspar post

By definition, this is simply speculation. Dissatisfied people in FOSS projects simply move on

the "silent majority" is OK or doesn't care

The issue is not unsafe changes, but 'not cleared with easily find-able maintainer -- Bugzilla' changes simply dropped in with no urgency

the rare cases where a provenpackager "abuses" their power and makes unsafe changes

I think that an amendment like that would be equivalent to forbidding mass changes. Many mass changes touch hundreds or thousands of packages. Proven packagers don't have an office that'd take care of opening communication with a thousand maintainers. And for a single person that'd be full time job — hundreds of hours of mostly pointless work.
On massive rebuilds I agree... if something gets in the way of those build should be fixed

All that proposal is asking is to document the change that has to be maded
and try to notify maintainer... what is wrong with that?

Another thing to consider is that if the policy was amended in the proposed way, a lot of people would be unhappy about "spam" (e.g. multiple bugzilla e-mails about a trivial change to a spec file). So it's possible that not only would there be a huge extra amount of work for the people doing the changes, it's likely that this extra work would only annoy more people.
That's what mail filters are for...

I justs don't understand for non-massive changes the maintainer should not be notivied???

Obvious +1 on the proposal (assuming I get a vote ;-) )

I won't make it to the meeting this week. I'm personally -1 on this proposal.
We already have a process for dealing with the rare cases where a provenpackager "abuses" their power and makes unsafe changes. However, as a general rule, I think that the whole point of the provenpackager status is that these people are trusted. They may lose that trust, but for as long as they have this designation, I think they should be presumed to be acting in the best interest of Fedora (even where this may disagree with the package maintainers' personal opinions).

Rare? Its happen to me twice in last two months! This why I'm making such a fuss...
People are making changes because they "feel "its the right thing to do... very worrisome.

I just don't' understand why there can not be some type of boundary on people
make non-critical, non-massive changes? Like using the pull-replay mechanism...

Decided during today's meeting (2017-12-08):

agreed delay a week to discuss this and allow the proposal to be refined (+7, 0, 0)

https://meetbot.fedoraproject.org/fedora-meeting/2017-12-08/fesco.2017-12-08-16.05.log.html#l-76

From today's meeting:

16:17:37 we could also decide to explicitly state in the policy that small mass changes can applied when e.g. two provenpackagers agree or something

so, wordsmithing based on what I saw in the meeting, and see on the mailing list so far (and I am speaking of updates to ONLY that sentence quoted up top):

= Proposal (revision as of 2017 12 08)

The quoted sentence be revised to end the prior sentence paragraph, and start a new paragraph of replacement content:

There is a qualitative difference between 'urgent' and 'routine' commits by a ProvenPackager A routine cases is 'clean-up' work such as in the interstitial time when deadlines are not looming. Examples include mass package changes or rebuilds to accommodate an SOname bump, which may have pervasive scope, but are not urgent of the character. Compare, contra: ** 'there is an active and ongoing impairment of a desired service ** , to that of a lesser degree: ** the absence of this commit blocks an expressed desire to proceed along a given work-plan**. Notice that this looks a lot like an unplanned, vs. a planned event. In the case of routine pre-planned matter, the proponent of using ProvenPackager rights to push through a change shall open a public tracking bug in Bugzilla usually against RawHide, which 1) summarizes the proposed change, and 2) links to any 'trail-head' [discussion or authorization](https://bugzilla.redhat.com/show_bug.cgi?id=1495181#c2) for an example. To that bug, then the proponent shall add a chain of 'per package' Blocker Bugs pointing to the initial Bug number (see that same bug at the top). Adding the ** Whiteboard: ChangeAcceptedF28, SystemWideChange ** notation as appropriate is also useful, but is not mandatory The proponent ProvenPackager should monitor that first bug, and substantively respond to any ** NeedInfo ** which is raised, and in the routine case once any questions are addressed, may then and without further notice proceed to use such ProvenPackager rights after the expiration of seven days, or such other longer time as that PP may have mentioned in the bug (i.e., in the case of a 'ChangeAcceptedF28' or such, which have longer lead times, and indeed, may themselves be created and themselves blocked against the release tracking bug for the blocking event). Once done, the initial tracking bug would of course also Closed, but not the child Blockers (they are simply ** advisory ** at that point, however, and the package owner may indeed read and internalize and respond to the change, and then close their child bug if not already done. If a 'urgent' unilateral commit is thought to exist by a ProvenPackager necessitating immediate action, the Changelog or commit message must reference a durable URI describing the issue (failed build log link, etc.), and note the communication and approval of that action by a second ProvenPackager. If the matter is security embargoed, a private bug must be filed, timely adding the package owner in the CC list to avoid ACL problems (which addition may be AFTER the patch was applied),. After the embargo date passes, the bug shall be made generally non-private. It is sufficient to rely solely upon an IRC dialog (not message, a dialog with an ACK, and so avoiding surprise, and giving the maintainer an ability to point out any problem which might be caused). A simple 'UDP-type' IRC send of a message is not sufficient. Neither is a post into a mailing list sufficient, without also specific addition of a 'cc' to the underlying Maintainer

New content ends -- I welcome constructive feedback here or privately by email as the reader may deem proper

an explicit blockquote seemingly disables other ** emphasis ** mechanisms ... sorry

Reference is made to:

ML thread on a SOname bump error by a seeming PP

in which a seeming PP, seemingly missed 'hearing' a upstream notice as to a API change, and breaks matter . The 'notice' was given to a mailing list over a weekend, and applied on short notice. I infer it had the capacity to break at least 34 packages

The subject line is one I might skim over and not open the underlying email, in doing Monday morning clearances. Oops, too late

Really, if the proponent can identify packages with explicit BRs, they can file bugs using one of the automated tools.

Second query:

I don't see that the poster was ever considered according to the documented procedure to become a PP

To become a member of the 'provenpackager' group, the procedure is the following:

File a ticket in the FESCo issue tracker indicating why you wish to become a provenpackager.

I have heard, but do not see documented, that certain users in select email domains 'automatically' are PP's ... If indeed this is true, this also needs to be documented

So near as I can tell, from just re-reading the thread, the first bug findable on this particular use of PP permissions came two days later (Tuesday)

AGREED: Table ProvenPackager rubric discussion until we have a larger FESCo population available to discuss (5:0:0) (dgilmore, 16:10:26)

there is no email domains that automatically grant any rights to people, not even packager rights

I have heard, but do not see documented, that certain users in select email domains 'automatically' are PP's

I have to say that I find such insinuations tiring. Don't hide behind somebody else ("I have heard") and do provide enough substance to be meaningful (which packagers, what "other domains"?). If a specific pp got the rights without due process, name that person and open a ticket. Chances are, it'll turn out that either processes was followed, or it all happened way back before current rules were established.

@zbyszek

I find such insinuations tiring

Please do not attack the messenger. I made no such 'insinuation', but rather stated what I had heard, and what I know -- in the past the Red Hat Bugzilla had special rights for selected co-vendors

This continues. Consider: It appears that parts of a special Fedora / Red Hat IRC cloak process is documented in the Fedoraproject materials. I have no problem with this, but do have a problem in not being able to see potential un-documented magic rights

Does the PP system have similar carve-outs? I do not know. You too seem to have heard the same murmurings as I, to get tired of them ;)

I personally find the culture at Fedoraproject of 'offense taking', and use of off-topic rhetorical devices and distractions to avoid confronting issues off-putting. But I am trying to write neutral tone bugs to get better documentation

Rather, document the matter (see FESCo bug #1877 ), where I break this request out directly, to just that effect, and then it is answerable. The rumors are then able to be squelched

Here is a perfect example of where the PP system could really screw things up...

Now I just made change to an SONAME number and did the push but not
the build it would have broken some packages. I privately reached
out to the other maintainers to figure out how not to break rawhide.

Now enter Mr Supper PP that removes some packaging crust or better
yet changes something for some undefined bug (rpcbind commit 714e2e90)

They do the build and boom! rawhide is broke and the maintainer, not the
supper PP, gets the blame...

It is just mind boggling that this type of actively is allow to so many people!

A few people being be able to have access to all packages... Find that would
be reasonable.... But hundreds of people having access.... People that did
not go through the current vetting... That is just insane... IMHO...

@steved, I think this is inappropriate. What if rebuild will happen, be that mass rebuild or some other requirement of rebuild?

Now I just made change to an SONAME number and did the push

Sounds like this should be handled using a pagure PR [1]. Requests comments on the PR, apply the commits once ready. Much better then leaving master in a state which should not be built.

Even apart from PPs and mass rebuilds, a security issue could pop up, and you or a co-maintainer might need to build the package quickly with some patch. First reverting the half-baked changes, then doing the quick build, and then restoring the half-baked changes is rather ugly.

[1] All that said, I recently had a very similar situation with systemd, and instead of doing what I suggest here, I did exactly the thing you did, i.e. pushed to master with some comments like "don't build that". The reason was that our CI uses the distgit master branch, so pushing to the master branch is the way to solve CI problems. We'll need to figure out some better way.

@steved, I think this is inappropriate. What if rebuild will happen, be that mass rebuild or some other requirement of rebuild?
massive rebuilds... yes... that would be bad luck...

I'm talking about tweaking to packages unknown to the maintainers... that's what I'm talking about.

In today's FESCo meeting, we agreed that FESCo should make no changes to the provenpackager process, but reiterate that provenpackagers should exercise judgment and communication skills when making changes to packages, especially in release branches.

In today's FESCo meeting, we agreed that FESCo should make no changes to the provenpackager process, but reiterate that provenpackagers should exercise judgment and communication skills when making changes to packages, especially in release branches.

Yeah, I understand... Taking power away from people is never popular. ;-)

Since you are basically not going to anything but relying on the PP to play nice...
Maybe it makes sense to take a look at the current list of PP and have them
justify why they should continue to be on the list?

Its my understanding there over hundreds PP on the list and some were added
before a proper vetting process was in place...

If that is true... Does there really need to over hundred of these PPs?
The lesser amount of PPs thebetter chance they will play nice and less chance
of a rough PP.

Why can't 25 PPs handle the load of rebuilds and twiddling the packages
behind the maintainers back? (oops did I say that out loud? 8-) ) (It's a Joke!).

Seriously, bring the group of PPs down to a more reasonable number...
which will make that group more reasonable... IMHO.

Also vetting the list is something that should be done on a yearly bases... again IMHO.