Hello.
I would like to become a provenpackager. I'm maintaining packages with a lot of dependencies (fmt, spdlog, json) and it is very difficult to coordinate such major updates. For example, a week ago I announced an update to fmt, but most of the packages haven't yet been rebuilt.
Having provenpackager rights will help. I will be able to rebuild all dependent packages manually. Also I will be able to help with other provenpackager tasks.
I'm currently maintaining 72 packages on Fedora. I've completed 71 package reviews and sponsored 4 new maintainers to Fedora.
Disclaimer: @xvitaly is my sponsor
He has the experience and does a good job at maintaining his packages. +1 from me!
+1 of course
Announced to sponsors. Sponsors, please vote here.
FESCo members: When a new provenpackager request comes in, please don't just vote, announce it to sponsors (packager-sponsors@fedoraproject.org) first. Thanks
packager-sponsors@fedoraproject.org
Metadata Update from @churchyard: - Issue tagged with: provenpackager
+1
Honestly saying, I am disappointed at fmt update of this time - lots of packages are broken with this, as someone said the inpact of this update should have been examined first.
So for now I vote -1.
I am not convinced by the fmt update either. I've just reported dozens of bugzillas for broken packages :/
I would expect a provenpackager to know how to coordinate changes like this.
Not a strong opinion here, but consider me -0.
How do you expect Vitaly to fix the breakage without provenpackager privileges?
Once upon a time, we would automatically trust each sponsor with provenpackager privileges. These days, are we not even willing to trust an experienced packager who not only happens to be a sponsor, but has also been packaging for Fedora for 6 years?
What I said is that the impact of fmt update should have been investigated beforehand - before once breakage happened and provenpackagers are to fix these - even if the person is not provenpackager yet.
Now thanks to infra team or so, we now have copr (as someone else pointed out on devel list), or we can do koji scratch build, local mock build. Then we can check how many pkgs are going to fail beforehand, investigate the reason, submit patches on pagure, submit a bug on redhat bugzilla - even if the person is not provenpackager yet. Then if the impact of this change seems rather big, we can discuss how to deal with this beforehand.
Maintainers had 1 week to rebuild all their packages. Most did nothing.
How I can coordinate such changes without provenpackager rights? I did my best: announced it in ML, waited 1 week, asked for the provenpackager assistance multiple times both in ML and IRC/Matrix.
Both API and ABI changes ware announced.
Now thanks to infra team or so, we now have copr (as someone else pointed out on devel list), or we can do koji scratch build, local mock build.
I did it in mock locally and posted the list of packages need rebuild. Also I asked for provenpackagers assistance for doing these rebuilds.
Your "blame them, not me" approach is another reason I cannot support this request. I've seen this in the past, this is not an isolated incident.
as someone said the inpact of this update should have been examined first
1, 2, 3.
I fail to see the policy violation there. A side tag has been used. Maintainers and even provenpackagers have been asked to rebuild. Vitaly was unable to rebuild himself due to missing provenpackager privileges (which is the rationale given for this request, which makes a lot of sense to me). Should the upgrade have rotted in the side tag until the deadline for F37 was missed, pushing it back to F38?
I've seen this in the past, this is not an isolated incident.
Okay. How was I supposed to rebuild all these packages without permissions? I've rebuilt all the packages that I have access to and asked for provenpackagers assistance multiple times. No one volunteered to help me.
How was I supposed to rebuild all these packages without permissions?
You choose to completely ignore everything @mtasaka said. You were not supposed to rebuild all packages, you were supposed to coordinate the change beforehand and anticipate the impact.
I fail to see the policy violation there.
I suppose there is no policy that says "don't just break things", so probably no. This is about trust, not policy.
Should the upgrade have rotted in the side tag until the deadline for F37 was missed, pushing it back to F38?
No, it should have not been started in the first place, considering the state of the dependent packages.
You were not supposed to rebuild all packages, you were supposed to coordinate the change beforehand and anticipate the impact.
I did the following: 1. Created a side tag. 2. Posted to the mailing list. 3. Posted the list of packages for rebuild. 4. Asked for provenpackager assistance. 5. Waited for 1 week. 6. Posted the list of packages still need rebuilding. 7. Asked for provenpackager assistance again in ML and IRC/Matrix.
What else?
You choose to completely ignore everything @mtasaka said.
I followed his recommendation and pushed the side tag to Rawhide before the mass rebuild start.
Disclaimer: I simply stated that I cannot support this request, but I will not actively fight it, considering that others clearly disagree with me.
This: https://pagure.io/fesco/issue/2836#comment-807087
I did rebuilds locally and post the list in the ML. Yes, some packages failed, like Ceph. Do you want me to fix them?
Do you want me to fix them?
No.
I'm sorry for this breakage.
Checked 6/10 of failed builds. They can't be fixed easily due to removed deprecated API usage. They should be fixed by upstreams, but it will take time.
We can postpone fmt 9.x release to Fedora 38 and restore fmt 8.1.1 with epoch bump.
We could also package fmt8 compat package to unbreak things and let fmt be upgraded. However, let's break this conversation to the mailing list?
I would blame upstream a lot for this mess. They did several breaking changes that affect a lot of packages (and also make it harder to use, see the removal of the automagic streaming operator detection – the automagic might break the One Definition Rule (ODR), but it clearly worked or it would not have been used successfully by several packages, now it requires a define and will be removed entirely in the next release, they could have at least committed to maintaining the define forever). It is unfortunate that the maintainer did not anticipate this, but the underlying problem is really library upstreams not giving a darn about backwards source compatibility.
We could also package fmt8 compat package to unbreak things and let fmt be upgraded.
Great idea. Thanks. Can someone quickly review it? https://bugzilla.redhat.com/show_bug.cgi?id=2108585
However, let's break this conversation to the mailing list?
No problem.
fmt8-8.1.1-6.fc37 is in Rawhide buildroot. The compose should be fixed now.
It was my fault that I didn't provide a compatibility package due to massive breaking changes in fmt's API. Next time I will be more careful.
Many thanks to @churchyard and @mtasaka for helping me with this issue.
Unless @mtasaka wants to withdraw their vote, this now goes to FESCo voting.
Okay, with discussion here, now I change my vote to +-0.
Ok, the vote is (+9,2,-0) so this request is approved.
@xvitaly has been added to provenpackager.
Use your powers wisely.
Metadata Update from @churchyard: - Issue tagged with: pending announcement
Announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6VAM5N54Z4AJQ7XVYFSZZFC6QTG26P7H/
Metadata Update from @decathorpe: - Issue untagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.