Currently I would like to build the rpm dependeny chain of gtk4 for Fedora 31.
(pyhton-anytree -> gtk-doc -> gtk4 (Beta))

Just curious, why do you need to be provenpackager for this?

I've sent a link to this ticket to sponsors. Sponsors, please vote here.

Currently I would like to build the rpm dependeny chain of gtk4 for Fedora 31.
(pyhton-anytree -> gtk-doc -> gtk4 (Beta))

Just curious, why do you need to be provenpackager for this?

I'm curious as well. gtk-doc and gtk4 are already available on fedora 31, and I don't think introducing big changes to gtk-doc on a stable release is a good idea anyway

Currently I would like to build the rpm dependeny chain of gtk4 for Fedora 31.
(pyhton-anytree -> gtk-doc -> gtk4 (Beta))

Just curious, why do you need to be provenpackager for this?

I would like to update gtk4-3.96.0 to gtk4-3.98.0 in F31 and I am not owner of this packages.

I've got the archives of devel list going back to 2016 and I don't believe you've ever posted there. Did you post from a different email address than the one linked to your FAS account?

Currently I would like to build the rpm dependeny chain of gtk4 for Fedora 31.
(pyhton-anytree -> gtk-doc -> gtk4 (Beta))
Just curious, why do you need to be provenpackager for this?

I would like to update gtk4-3.96.0 to gtk4-3.98.0 in F31 and I am not owner of this packages.

You can request commit access to single packages through pagure.

Currently I would like to build the rpm dependeny chain of gtk4 for Fedora 31.
(pyhton-anytree -> gtk-doc -> gtk4 (Beta))
Just curious, why do you need to be provenpackager for this?
I would like to update gtk4-3.96.0 to gtk4-3.98.0 in F31 and I am not owner of this packages.

You can request commit access to single packages through pagure.

The packages are owned by different persons so this is a long way.

If I'm understanding correctly, you want access to 3 packages, so this doesn't seem like a large burden even if they're owned by 3 different people. In any case even if you were a PP you would need to discuss your proposal with the package owners before rebasing their package in an old branch, so the actual work involved is no different.

-1 based on the previous comments.

You don't need to be provenpackager to do this, and from my POV you shouldn't update gtk4 in fedora 31 anyway.

I'm -1 based on the motivation. That means I don't say whether @gerd would be a good or bad provenpackager, but I say that pushing the described change via the provenpackager powers is not how provenpackagers are supposed to work, neither it requires being a provenpackager in the first place.

https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/
https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages

-1 based on motivation for the reasons @churchyard stated.

-1 here. (This is, in legal terminology, "without prejudice", meaning that I'm not making a judgement on whether gerd is a good packager or not, only that the justification given in this bug is insufficient so far).

-1

-1

-1 at the moment too.

@gerd : as others have pointed out, proven packagers are not meant to use their powers to build others packages without their knowledge. Have the gtk4 maintainers (the gnome sig) expressed an interest in updating to a newer release here? I expect the gnome-sig already has proven packagers that manage their mass gnome updates, so we don't need to step in to update their packages for them.

Since this is F31, the updates policy for stable releases also applies:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

If there are critical bugfixes in the new version, you must file the appropriate bugs to bring these to the maintainers' attention and encourage them to update the Fedora package. However, they decide how to proceed.

(As the others have also said, this does not comment on your packaging skills at all)

So, I'm not sure I understand the listed reasoning either ( @gerd perhaps you could expand or provide more details on the gtk4 work? ), but Gerd has been very helpful in the Xfce space, as well as working on weston and lightdm. I'd be +1 to adding him so he could help out accros the collection.

I'm only weakly aware of the work that @gerd has been doing, but it seems to be the general quiet, reliable maintenance work. @kevin's endorsement is a strong recommendation too.

Being a proven packager allows the packager to engage in Fedora more productively, in various ways that are impossible to plan in advance. PPs are useful because they can fix unexpected breakage and react to cross-package problems and other unpredicted issues. The justification for getting PP powers stops mattering very soon if the PP becomes more active. While I'd like to see a better justification / a better statement of the initial scope of PP power use, I consider previous record much more important.

+1

@gerd I'm sure that a lot of people will reconsider their -1 if you provide better rationale. At least I would.

May be I should introduce myself and explaining my intention better.

Introduce myself:

I am working at the computer center at the University Siegen in Germany.
There I am the administrator of the HPC cluster that is working at CentOS and responsible for some other services.

At my desktop and at home I am using Fedora.

Years ago (may be 2009) I wanted to get Perl6 in Fedora as package. So I started packaging and get the VM Parrot as rpm in Feodra sponsored by Chrithop Wickert.
Since four years he is not active any more.
I followed the change of the VM to Moar and still keep the Rakudo packages up to date in Fedora.

In the meantime I have already done some work on other packages and things.
I am interested in what is going on at the development of Wayland, Xfce and weston.

Explaining my intention better:
My general intention is to help out across the collection.

Updating gtk4 for Fedora 31 should only be an example for this.
Indeed it is not the best example.

Currently I am already an admin member of the package 'python-anytree' and have done the first builds for F31 and F33.

My general intention is to help out across the collection.

The part I don't follow is this: Why do you need to be a provenpackager to do that?

You must get at least 3 positive votes from sponsors with no negative votes, over a one week review period, to be approved.

If you haven’t been approved after one week, FESCo will vote (normal FESCo voting machanism applies).

My FESCo vote is -0 (I still don't understand the reasoning, but won't actively block it).

I'm agreeing with the general response here. The work @gerd wants to do doesn't require provenpackager status. The followup comment did not clarify much more for me beyond the initial request. I would feel more comfortable if any of the owners of packages mentioned they were comfortable with this and supported it.

I am a -1, but am willing to reconsider if we get more information or take it up in a meeting.

Tagging with meeting because of a negative vote.

I consider that perhaps libtommath could be updated in rawhide (1.1.0 -> 1.2.0)

dnf repoquery --alldeps --whatrequires libtommath
firebird-0:3.0.4.33054-4.fc31.x86_64
firebird-0:3.0.4.33054-5.fc31.x86_64
libfbclient2-0:3.0.4.33054-4.fc31.i686
libfbclient2-0:3.0.4.33054-4.fc31.x86_64
libfbclient2-0:3.0.4.33054-5.fc31.i686
libfbclient2-0:3.0.4.33054-5.fc31.x86_64
libtomcrypt-0:1.18.2-4.fc31.i686
libtomcrypt-0:1.18.2-4.fc31.x86_64
libtommath-devel-0:1.0.1-10.fc31.i686
libtommath-devel-0:1.0.1-10.fc31.x86_64
moarvm-0:0.2019.03-2.fc31.i686
moarvm-0:0.2019.03-2.fc31.x86_64
rb_libtorrent-0:1.1.13-4.fc31.i686
rb_libtorrent-0:1.1.13-4.fc31.x86_64
rb_libtorrent-examples-0:1.1.13-4.fc31.x86_64

But I am busy with a new project and have currently not much time.

We discussed this during today's FESCo meeting (23/03/2020):
AGREED: Close request and ask reporter to come back when they hit specific issues that they need provenpackager status to solve (+8, 0, 0)

@gerd please see the meeting notes [1] for the discussion. The general sentiment is that provenpackager privs should be given as a tool to enable the packager to do some specific work that would not be possible with just normal pull requests and asking for package acls, and that this should be described in the request.

[1] https://meetbot.fedoraproject.org/fedora-meeting-1/2020-03-23/fesco.2020-03-23-15.00.log.html