List of packages he maintain:
https://admin.fedoraproject.org/pkgdb/packager/jdieter/

Reviews he done:
https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&component=Package%20Review&email1=jdieter%40lesbg.com&emailassigned_to1=1&emailtype1=substring&list_id=3731850&product=Fedora&query_format=advanced

+1 from me.

Only https://bugzilla.rpmfusion.org/show_bug.cgi?id=1030 from the year 2010 qualifies as a non-trivial review. Jonathan has had the luck to work with fellow packagers who know their stuff.

The list of reviews in Fedora bugzilla is short and years old. Only one review in 2015. A font package. None in 2014.

From a teacher I would like to see more attempts at guiding. Even if it boils down to asking for feedback on one of Fedora's mailing-lists. Looking up the guidelines and pointing at individual sections would be a plus.

That would avoid comments like https://bugzilla.redhat.com/860352#c4 -- yes, unversioned .so files have been a problem for other packagers, too, and we've enhanced the packaging guidelines a few years ago to be even more clear with regard to distinguishing between runtime and build-time libs.

https://bugzilla.redhat.com/844090 (Box2D) -- very short -- the wrong Group tag for runtime libs has been missed. The base Requires should be arch-specific for some time (probably not in 2012). No idea why the package has not been updated by the maintainer since then. %license is not used yet either.

Summary: A 2D Physics Engine for Games

It seems we're not pulling on the same rope yet here. Are there still reviewers, who consider leading articles "A" and "An" more readable than headline-style summaries?

https://fedoraproject.org/wiki/Examples_of_good_package_summaries

In package tools and distribution installers, most leading articles in the package summaries decrease readability and make a summary less concise. The uppercase spelling of "Games" and "Physics Engine" is unusual, too.

No immediate +1 or -1 from me. I'm not opposed to letting Jonathan give a try at sponsoring new packagers. It's just not much input to decide on.

Michael, I wouldn't disagree with most of what you wrote. Most of my reviews have been pretty easy (which is why I highlighted the RPM Fusion one), and you could make the argument that most of them don't clear the 'trivial' bar.

Your critisms on the Box2D review were spot on (especially the missing arch-specific base Requires, which actually was in the guidelines in 2012 and I just missed it), but I do want to clarify the following issue that you raised on the farstream02 review:

Replying to [comment:3 mschwendt]:

From a teacher I would like to see more attempts at guiding. Even if it boils down to asking for feedback on one of Fedora's mailing-lists. Looking up the guidelines and pointing at individual sections would be a plus.

That would avoid comments like https://bugzilla.redhat.com/860352#c4 -- yes, unversioned .so files have been a problem for other packagers, too, and we've enhanced the packaging guidelines a few years ago to be even more clear with regard to distinguishing between runtime and build-time libs.

The unversioned .so files were gstreamer plugins, not libraries. The only thing the guidelines at the time said about them was that plugins didn't need to be included in -devel packages. (See https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=301383#Devel_Packages, second paragraph after the bullet points.)

Even the current guidelines seem to indicate that unversioned .so files are only forbidden if they're for libraries, not plugins. (See https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning, first sentence.)

The unversioned .so files were gstreamer plugins, not libraries.

Yes, they are libraries.

DSOs loaded as plugins (or "extension modules") from a directory not within runtime linker's search path. Some for GStreamer, others for farstream itself.

[!]: Development (unversioned) .so files in -devel subpackage, if present.
Note: Unversioned so-files in private %_libdir subdirectory (see
attachment).
I'm not sure what to do with this. Are these supposed to be unversioned?

This was the earlier question. Brian gave the hint that they are used as plugins. But nobody commented on the automatic Provides. If the libraries had versioned SONAMEs, that would be a problem, because filtering those out may be necessary to avoid conflicts with other shared libs.

The links to the guidelines you've posted here are what I'd like to see in reviews like that. Not for every detail in a package, which may be right or wrong, but as you were unsure about those libraries, that would have been a perfect opportunity to dig in the guidelines and look for confirmation.

So, it's been a week and only +1.

Would you care to resubmit again later after some more recent reviews?

Ok. Michael, thanks for the detailed feedback. I'll be doing some more non-trivial reviews and then resubmit.