Our policy document says "[pps are] package maintainers who are experienced in a wide variety of package types and who are familiar with the packaging guidelines and package maintainer policies". Right now @trodgers is an owner on two packages :(

+1

@trodgers has outlined a set of scope limited actions related to the Boost dependent packages.

I meet with @trodgers on a regular basis and discuss upstream toolchain Fedora issues, and I trust him to make targeted change where required for Boost. There is no ABI for Boost and everything has to move forward.

The alternative is that Boost is upgraded and all dependencies break, which is not a good experience for Fedora Rawhide.

Having provenpackager will allow @trodgers to continue to practice his skills in the scope of Boost, and so I approve of his request.

+1 here. I have known @trodgers for ages and ages (not that you should hold that against him :)

I trust that he will use his powers wisely and work with the tools team and maintainers for anything in doubt.

+1 here. I have known @trodgers for ages and ages (not that you should hold that against him :)

Where 'ages and ages' is ~34(ish) years? ;->

I trust that he will use his powers wisely and work with the tools team and maintainers for anything in doubt.

Our policy document says "[pps are] package maintainers who are experienced in a wide variety of package types and who are familiar with the packaging guidelines and package maintainer policies". Right now @trodgers is an owner on two packages :(

The track record at https://src.fedoraproject.org/user/trodgers does not show much either. Do you perhaps have a public track record in a different project, such as centos (stream)?

Note that I don't doubt that @trodgers's intentions are good, but the alternative isn't that all Boost dependencies break, the alternative is that a provenpackager helps them.

Announced to sponsors, sponsors, please vote here.

I would also like to ask non-sponsors not to vote. It's ok to show your support but don't plus one this request unless you are a Fedora packager sponsor.

Non-voting support from me too. I've been mentoring Tom in order to hand over Boost maintainership for some time, but to do the rest he needs to be a provenpackager.

Our policy document says "[pps are] package maintainers who are experienced in a wide variety of package types and who are familiar with the packaging guidelines and package maintainer policies". Right now @trodgers is an owner on two packages :(

The track record at https://src.fedoraproject.org/user/trodgers does not show much either. Do you perhaps have a public track record in a different project, such as centos (stream)?

Note that I don't doubt that @trodgers's intentions are good, but the alternative isn't that all Boost dependencies break, the alternative is that a provenpackager helps them.

that is the situation as it stands now, except that that proven packager wants to hand over maintainership (as he has noted).

2 packages owned as co-maintainer. Proven packagers have too much power, so only experienced maintainers should be granted such rights.

Sorry, but I can't give a vote.

@trodgers please don't take it as a personal issue. I'm sure that you're a great person and have the best motivations.

The problem is that provenpackagers have very extensive powers in the distribution. I strongly support giving pp privileges to many people who are active and involved in many packages. But provenpackagers can also wreak a lot of havoc if they are not careful or even by misunderstanding customs and conventions used for certain packages. Even folks who have been active for years and touch hundreds of packages will regularly get something wrong and make somebody unhappy. Pps sidestep the normal package access rules, so it is important that we only give the privilege when there's a record of packaging experience, so that non-pp packagers don't feel that it is given out without good reason. Thus the requirements for experience and knowledge of packaging rules and different packages are not something that should be ignored. It's just not fair to other maintainers to go from two to ~30k packages in one step.

As Miro said above, if you have packaging experience in other contexts, please say.
I'll give a tentative -1 for now.

Well, he's run the boost changes for f34/f35... while he didn't commit to packages he (and correct me if I am wrong Tom) did test them, create patches and got everything in place for a provenpackager to commit/build.

Is there some way he could show this work in a way that you would be comfortable with?

Is there some way he could show this work in a way that you would be comfortable with?

Yes. Pinpoint the changes @trodgers have made using another provenpackager account and link them here.

E.g. in https://pagure.io/fesco/issue/2755 thrnciar explicitly mentions all changes done using my provenpackager permissions. Were all the pushes for boost changes for f34/f35 actually comitted by @trodgers?

In other words, we give provenpackager permissions to packagers who have proven their packaging skills to us. Show us the proof. If you don't have any, get some and try again later.

If you have a task at hand that requires a provenpackager, you don't necessarily need to be a provenpackager.

Inline -

Well, he's run the boost changes for f34/f35... while he didn't commit to packages he (and correct me if I am wrong Tom) did test them, create patches and got everything in place for a provenpackager to commit/build.

Is there some way he could show this work in a way that you would be comfortable with?

@kevin - Beyond the commits to rpms/boost to prepare the updated boost.spec and patches, then locally testing package builds on all Boost dependent packages in Fedora (that includes the entire dependency graph in the testing), it was @jwakely that ultimately completed the part of the process that required provenpackager status, and as Jonathan has noted previously, this has been part of a deliberate and planned transition of Boost maintainership that's been in progress for a couple of years now; me doing the rebase to the new Boost version, adjusting the patches and spec to account for whatever brokenness that the latest release might have introduced; see #113 for the most recent example of something that I've needed to fix post-upstream release (which itself raises some interesting philosophical discussion about what that 1.78.0 actually means, but that is a topic for another time/audience).

As part of that testing process, I am also specifically (as in written into your job description) responsible for notifying and working with impacted Fedora package owners during the rebase process.

Having just completed local testing earlier today for 1.78.0 (and subject to me finalizing my notes and changes to the boost package and our automated build process for dependencies by end of week), I can state that while there are several broken packages currently in rawhide which have a Boost dependency ( most of which have issues already filed against them) none of them are broken by this version of Boost and that this Boost release is ready to land in rawhide.

I have requested a side-tag into which I would like to repeat the process I just ran to completion over the past week, so that if any non-x86 platform issues arise I can work with the particular upstream before dropping 1.78.0 onto unsuspecting consumers in rawhide.

I can't do that part though, that requires provenpackager for the rpmdev-bumpsec && commit/push dance for each of the dependent packages (each of which I have already tested for a successful package build with the new Boost) to complete the process. Instead, I will hand that over to a very busy jwakely, so he can babysit a days-long run of a heavily automated make job, while he's working to get GCC12 out the door and chairing the C++ Library Working Group and other associated good and important deeds.

This will be the third such release where we've done this. I think @jwakely would acknowledge that this has been pretty hands off for him.

We also need to periodically patch broken upstream releases for non-x86_64 targets; see 9eaf760 for the most recent example. In this case Jonathan contributed the fix upstream, but as I am taking over as maintainer for Fedora, I applied this particular fix. This was still 1.76.0 so, no need for provenpackager status for this sort of maintenance.

@trodgers please don't take it as a personal issue. I'm sure that you're a great person and have the best motivations.

@zbyszek Thank you for the follow up remarks.

I guess I have a few things -

I would note that Boost is one of the larger and more complicated (and more heavily used) C++ libraries that we package for Fedora C++ developers. There are 95 rpms packaged as part of this process which impact some 900ish other rpms in Fedora. I also understand that TBB enjoys some popularity with C++ folks. I would hope to suggest that I have a suitably judicious demeanor as to 'stay in my lane' regarding provenpackager powers and attendant responsibilities.

As motivations go, I would also hope to say that I have had the best of motivations when I spent close to a year helping Intel get their donated implementation of C++17 standard parallel algorithms into a state that a C++ Standard Library could accept. I was aiming for libstdc++ but managed to also get sufficient stakeholder buy in to transition that upstream to the LLVM project and then managing the subsequent inclusion of that functionality into libstdc++.

Similarly, as part of my role as a full time libstdc++ developer, with a focus on C++ P&C concerns, I have had the best of motivations in developing the C++20 concurrency primitives (atomic waits, semaphores, latches, barriers, and osysncstream, etc.) in GCC11 with ongoing development and maintenance for GCC12, which is (as I'm sure you are aware) the system compiler for Fedora37, and is my 'daily driver' on Fedora.

As @codonell noted, we meet approximately weekly on forward looking P&C work which spans GCC, glibc, and libstdc++ and WG21 work, much of which has been prototyped within Boost and for which I am actively in contact with the original upstream authors.

The problem is that provenpackagers have very extensive powers in the distribution. I strongly support giving pp privileges to many people who are active and involved in many packages. But provenpackagers can also wreak a lot of havoc if they are not careful or even by misunderstanding customs and conventions used for certain packages. Even folks who have been active for years and touch hundreds of packages will regularly get something wrong and make somebody unhappy. Pps sidestep the normal package access rules, so it is important that we only give the privilege when there's a record of packaging experience, so that non-pp packagers don't feel that it is given out without good reason. Thus the requirements for experience and knowledge of packaging rules and different packages are not something that should be ignored. It's just not fair to other maintainers to go from two to ~30k packages in one step.

Understood, and I agree, it is a problem. I wish there were a finer grained mechanism for making this sort of thing work.

I assure you, I have very little interest or input into Fedora packaging outside of Boost, TBB, and my work within the Red Hat Platform Tools team to develop P&C support as driven by the C++ Standard (which I actively contribute to developing and proving out within in libstdc++) . I am also reasonably well positioned in that role to diagnose and help Boost and TBB dependent package owners with issues that arise as the platform compiler, standard library, Boost and TBB libraries continue to evolve.

Which is to say, I would use provenpackager with care and precision and entirely focused on the two fairly (I think you would admit) fundamental building blocks for C++ developers on Fedora.

As Miro said above, if you have packaging experience in other contexts, please say.
I'll give a tentative -1 for now.

Is there some way he could show this work in a way that you would be comfortable with?

Yes. Pinpoint the changes @trodgers have made using another provenpackager account and link them here.

E.g. in https://pagure.io/fesco/issue/2755 thrnciar explicitly mentions all changes done using my provenpackager permissions. Were all the pushes for boost changes for f34/f35 actually comitted by @trodgers?

I have not 'used' @jwakely 's provenpackeger permissions, he ran the Makefile. Sure, I can link up the commits that required him to do that process, I had hoped that they were implicit in the two completed system-wide change proposals for Boost, but I can be more precise.

In other words, we give provenpackager permissions to packagers who have proven their packaging skills to us. Show us the proof. If you don't have any, get some and try again later.

If you have a task at hand that requires a provenpackager, you don't necessarily need to be a provenpackager.

Fair enough; but that process requires provenpackagers signed up to help when I do this. I assume I can count you in?

In other words, we give provenpackager permissions to packagers who have proven their packaging skills to us. Show us the proof. If you don't have any, get some and try again later.

If you have a task at hand that requires a provenpackager, you don't necessarily need to be a provenpackager.

Fair enough; but that process requires provenpackagers signed up to help when I do this. I assume I can count you in?

@churchyard having thought a bit about it, this is a great opportunity to test your proposed approach. I understand you are updating Python for f37 and there have been non-trivial Boost+Python issues in the past, as you noted in email. I would like to work on making the automated process robust enough that it can be handed off to somebody else to run. We should do this.

I assume I can count you in?

Sure thing. I've scheduled something in your RH calendar for today, but feel free to contact me on IRC/Matrix if the time does not work for you.

A week has passed and this request has not reached the requested +3 votes by sponsors, it received only +1.

According to the policy, FESCo will now vote.

As FESCo member, I vote -1 to prevent auto-approval. wish we had a more fine-grained ACL model than a boolean provenpackger, but we don't and I don't feel like the criteria for provenpackager is met here. Sorry.

I am in contact with @trodgers and will help them push the boost changes.

@churchyard ok. Would this cycles boost change work with @trodgers be enough to change your vote? and/or is there some way you both can share this work publicly so Tom can show he would be a good provenpackager? Thanks.

I will commit the changes on their behalf, so you will see them at https://src.fedoraproject.org/user/trodgers

Honestly, I would probably not change my vote after one targeted rebuild where the only changes are bumps. I suspect over the next ~year, before the next boost is released, @trodgers will get their hands dirtier and create a track record of being "experienced in a wide variety of package types and familiar with the packaging guidelines and package maintainer policies", so when this request is repeated, they will gain support by sponsors.

Ack. I'd be happy to redo the vote in one year. -1 for now for all the procedural reasons that were discussed above.

One way to solve this particular problem is maybe having a Boost SIG and giving it commit access to the reverse dependencies of boost?

For now, -1 for reasons discussed. Sorry. :frowning:

One way to solve this particular problem is maybe having a Boost SIG and giving it commit access to the reverse dependencies of boost?

If only we had a mechanism to enforce this and to keep it in sync with reality. See how @decathorpe desperately tries to enroll all Rust packages under the Rust SIG umbrella.

https://meetbot.fedoraproject.org/fedora-meeting/2022-04-05/fesco.2022-04-05-17.00.html

trodgers withdraws their provenpackager request for now, and will retry later