+1 from me

• 1 from me.

+1 from me.

+1 from me
For the record fabbione is not in the sponsor group, so from this point, votes are +3

+1 from me.

+1

https://admin.fedoraproject.org/pkgdb/packager/beekhof/ 7 POCs

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=CLOSED&classification=Fedora&component=Package%20Review&email1=andrew%40beekhof.net&emailassigned_to1=1&emailtype1=exact&list_id=3972530&product=Fedora&query_format=advanced

shows one review from 2009. That doesn't seem to meet the requirements here: https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Becoming_a_Fedora_Package_Collection_Sponsor

Strange that people just jumped here and started giving +1 without checking our policies. I even don't know if we have any other policy to just ignore existing policy or override it and add requester to sponsor group that made above +1 by other people.

Anyway based on policy rules, -1 to this request.

I voted (and maintain my vote) for Andrew because I've worked with him (eg. on mingw stuff), and that beats some policy stuff which is impossible to find out unless you know some arcane URLs anyway. Also as myself a sponsor of some 16 people in Fedora, and having had to turn down many people for sponsorship, I'm acutely aware of how desperately we need willing sponsors.

I saw that he had only done one formal review, but I know from my interactions with him that he knows packaging and guidelines and would make a great sponsor.

If folks would prefer holding to that review limit, we could ask him to go do some more reviews I suppose.

I agree we should ask him to do more reviews. Basing on what other folks say about somebody's work instead of actual proof in formal reviews is not the way to go here.

-1 from me.

I'll clarify that I'm not opposed to Andrew becoming a sponsor if others have direct experience with his work. But I certainly don't have enough to go on.

-1

Please revise the Howto become a packagersponsor guidelines, if you want the process to be replaced with a popularity contest. Delete all the vague "should" items and the comments on them. It would simplify the process a lot.

I'm not familiar with Java and MinGW packages, and I don't know "beekhof".
So, I have skimmed over beekhof's POC package spec files. Very briefly. No full re-reviews:

libqb

Not a single %changelog entry is from "beekhof".
Doesn't follow the arch-specific base Requires guidelines.
Doesn't follow: https://fedoraproject.org/wiki/Packaging:Guidelines#Patch_Guidelines
Duplicates license file. Doesn't follow the subpackage licensing guidelines.
Hasn't been built for EL, but contains old stuff in the spec file that's not needed anymore (such as explicit dependency on pkgconfig). => A packagersponsor ought to know that there are automatic dependencies for pkgconfig files and .pc file inter-dependencies for a long time. And with minimal buildroots, a "!BuildRequires: pkgconfig" in the spec file can be more important than a redundant explicit "Requires: pkgconfig" in a -develsubpackage.

sigar

Doesn't follow the git snapshot package versioning guidelines.
Doesn't follow the patch status guidelines.
Group tag only in the -devel package.

pacemaker

Huge spec file!
Directory ownership is unclear. Should be re-reviewed. E.g. what owns %_libexecdir/pacemaker?
Doesn't follow the snapshot versioning guidelines either ( http://koji.fedoraproject.org/koji/packageinfo?packageID=8931 ).
Patch madness. Lots of the patch files include a comment they are "cherry picked commits", but several don't.

sbd

Review in https://bugzilla.redhat.com/1135151
Copied from SUSE.
$RPM_BUILD_ROOT vs. %buildroot
No patch status comments.
%_mandir is in {{{%__docdir_path}}} for a very long time.
Should be re-reviewed.
Btw, typically the review is assigned to the reviewer, not the submitter.

Providing links to those spec files:

http://pkgs.fedoraproject.org/cgit/libqb.git/tree/libqb.spec

http://pkgs.fedoraproject.org/cgit/sigar.git/tree/sigar.spec

http://pkgs.fedoraproject.org/cgit/pacemaker.git/tree/pacemaker.spec

http://pkgs.fedoraproject.org/cgit/sbd.git/tree/sbd.spec

I disagree that these are poorly packaged. Sure there are some detailed things that may be wrong. I mean, how many major packages in Fedora have directory ownership problems? - something that RPM should just deal with automatically.

I think its good to have some amendment to existing policy for cases like this where people want to favour unrecorded(I mean can i find it somewhere?) work of the requester.

@rjones

"Poorly packaged" is your choice of words.

I also didn't claim that all other spec files in Fedora's package collection would be without mistakes or up-to-date with regard to the most recent guidelines. Some such mistakes don't stop the binary rpms from working. So what? The snapshot versioning guidelines are also too much, IMO, for anyone who understands the upgrade path problem and RPM version comparison. And yet we face increasingly complex (and sometimes confusing or ambiguous) guidelines we often need to discuss with package submitters during review.

With only one simple review done in 2009 (a re-review of a retired package actually!), there is not enough input to decide about beekhof's interest in the packaging guidelines and about what quality of reviewing to expect. He may be a cool guy and such, but there hasn't been a single Java or MinGW review from him.

something that RPM should just deal with automatically.

It doesn't. And there are no automatic -- and reliable, safe -- version upgrades of packages available either.

If only more guys are needed to push a button in FAS, all these vague guidelines, policies and review processes could be removed from the Wiki to make many things easier.

I don't know if I'm supposed to comment on my own sponsorship request, if not please disregard the following.

I was aware of the review requirement for sponsors, however I thought it worth seeing if extensive practical experience might be sufficient.

As I mentioned, I've been packaging much of the cluster stack in Fedora for over 6 years, working directly with rjones, sdake, kevin and others along the way. I'm sure they'd be offended if anyone suggested their votes were based on anything other than their knowledge of my work.

Prior to Fedora, I maintained the entire cluster stack in opensuse for 7 years.

More recently I have mentored new RH hires on the internal packaging process, which obviously draws influence from the requirements and processes used by Fedora. I have also been part of sponsorship-by-proxy arrangements where I have brought new packagers on as co-maintainers of cluster packages.

My involvement (or lack of) in libqb was specifically called out, to which I should probably account for myself.

Much of the work I do is in the background via others. The previous packager essentially worked for me and pacemaker is one of the primary consumers of libqb, so I had much input in how it was packaged and the frequency of updates. When David left RH, I was the one that made sure it and his other packages had an active packager assigned to it (prior to official enquiries). I worked closely with Angus when he was creating libqb and he drew plenty of inspiration from build processes I put in place for pacemaker. The current update was made at my request, the fixing of the upstream SONAME versioning scheme was also at my request.

WRT the current pacemaker packaging, while we could have grabbed the latest from upstream I asked Jan to backport exactly what was in RHEL because it has been tested much more extensively. This is why there are so many patches and messier than I would like. Once upstream does another release they will all go away (since all our patches originate upstream). Further, I believe they satisfy the spirit of the Patch Guidelines in that the upstream commit comment and hash is preserved in the patch files - allowing them to be searched for and/or cross-referenced.

I'm certainly happy to hear about other changes people think are needed to any packages I'm involved in.
Note however that Pacemaker's use of snapshots pre-dates the Fedora policy by quite some years, so while I appear to have changed the upstream specfile to use 'shortcommit' back in 2014 - it appears I forgot to suck it back into Fedora. Probably it wasn't a good time to update the packages there.

I have spent the better part of a month discussing the ramifications of spec file changes upstream (to avoid pulling in often unnecessary packages):
https://github.com/ClusterLabs/pacemaker/pull/803#issuecomment-148588307

As well as resisting the temptation to rubberstamp a backport of openssl for EPEL:

https://bugzilla.redhat.com/show_bug.cgi?id=1223990

Unfortunately other commitments have prevented me from finishing yet.
Although I make sure to re-read every criteria for each review, my rgmanager review was apparently perceived as shallow, if someone can suggest an alternate format I will use it here too.

Note that these pre-date this request by some weeks - I am constantly involved with and thinking about packaging, even if it is not widely visible.

I hope this explains why I submitted this request without the normal number of reviews.
Given my long history of caring about packaging, Fedora, and the mentoring of new folks - it seemed redundant to once again do sponsorship-by-proxy.

As far as I'm concerned, I have mentored most of the packagers (either from Red Hat or not) around the OpenStack ecosystem over the last 18 months. Andrew's team maintain some of critical components for OpenStack HA (RabbitMQ, Galera, MariaDB, etc.), so I personally welcome his offer to bring new comaintainers that he will be closely mentoring.

Andrew is a responsible guy and has a fairly deep packaging experience from his OpenSuse days, hence my positive vote.

And yet we're "burning" other community members, requiring them to do a few high-quality nontrivial package reviews as a matter of demonstration. Same for new contributors, who may also have a certain background and prior years of experience, but still can only be judged upon if completing the few prerequisites in the package review queue. For Red Hat employees, the door is wide open already for a long time via the join-as-co-maintainer process.

My voice here may not count much. I lose faith in all these guidelines/procedures/policies and the additional bureaucracy, if everything remains so vague and therefore is open to unwritten exceptions.

The "five high quality, nontrivial package reviews" are missing. There is only one simple re-review done in 2009. Not a single public review since 2009.

I can't follow your explanations with regard to pacemaker. The list of builds in Fedora koji clearly shows that it doesn't adhere to the snapshot versioning guidelines. And the upstream spec file doesn't either. Fedora's focus is on the YYYYMMDD checkout date in %{release}, not the shortened commit hash. It is like that for a very long time. Easy to adhere to. In theory. However, with 492 KB large patches such as http://pkgs.fedoraproject.org/cgit/pacemaker.git/plain/pacemaker-rollup-7-1-3d781d3.patch (and that's just one of several dozens), the %version, %release and %checkout details are pretty much meaningless and irrelevant.

It even passed review with a wrong snapshot %release ( https://bugzilla.redhat.com/511246 ):
pacemaker-1.0.5-0.6.c9120a53a6ae.hg.fc12

It's not a world-ending problem. I only haven't found any reviews done by you to see packaging guidelines related comments/mentoring from you.

Oh, my bad, I thought you meant the Source0 line from github.

Is doing a 5 high quality review is tough task? If that is the case then how can such mentor even evaluate mentee's work? They will prefer that I know some person personally why should I need to follow https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Convincing_someone_to_sponsor_you and can sponsor them in packager directly.

Beekhof, please understand my comments are not against you but the time we invest as a community member or any fedora governing body member to work on creating/following policies is waste then.

ok. It's been a week. There are positive and negative votes here, but I think it's clear that folks want more information to go on, so:

Beekof: Can you please do some more reviews and resubmit once you have done so?

Feel free to reapply anytime you like.