On 1 December 2015 at 11:53, Ranjan Maitra <maitra.mbox.ignored(a)inbox.com>
wrote:
Hi,
Some time ago, circa May 2015, there was a long thread called "Biting the
Bullet" [1] where some others complained about the lack of pdftk on F21 and
later. (This complaint also manifested itself sometime later.)
In response, and with both general and more specific help from those more
experienced, I was able to put together an RPM for pdf-stapler as an
alternative to pdftk. I submitted to a black hole called Fedora packaging
where there was some churn, some more suggestions (a few contradicting the
other) which I duly implemented but no one actually able to move the
process forward. However, it sits here:
https://bugzilla.redhat.com/show_bug.cgi?id=1234210
unassigned. It has passed through rpmlint (no errors, only a few
nonsensical spelling warnings) and whatever else it was supposed to pass as
per packaging guidelines. So also is the case of sylfilter which I packaged
separately, and no one has even bothered to comment on:
https://bugzilla.redhat.com/show_bug.cgi?id=1265685
Now, I understand that quality control is an important part of the Fedora
packaging which is what makes it a good product (and I am no great
RPM-maker, witness my questions on the subject), and there is a dearth of
enough people eligible to assign to, but surely, there must be some better
way to handle new proposed packages. For instance, if automated setups
clear a package, perhaps it would be better to move it to the top of the
list or even clear it for testing and see what happens? Otherwise, there
will be frustration and the pool of packagers will not grow. Not to mention
that if packages sit like this this for months before being acted upon,
then the original packager will have lost context and memory and moved on
(certainly it would be frustrating and more onerous on him/her than it
would be if it were acted upon sooner). Otherwise, people will move on.
I don't need these packages because I have them for myself. Indeed, I
could be more sloppy in creating these rpms (or not even bothering to do
so), but the reason for putting this out is benefit to the community which
has also benefited me/us. This is especially true for niche packages such
as sylfilter, etc which may not even have much users who would be willing
to test it.
I have some experience with submitting packages for R. My experience there
is that if it passes all the tests, it is by and large through, but if it
does not (surprisingly, Macs are the killers in most cases), it is not, and
feedback is fairly quick.
Perhaps, it would be worthwhile to think about how to streamline the
process. At this point, I am fully expecting the familiar notice for EOL
eventually.
Best wishes,
Ranjan
There has been recent discussion on this on the fedora-devel mailing list
(which if you want to be a packager you really should join).
I'd suggest catching up on this thread:
The short version is any current packager can now review your new package
rather than only a sponsor, but you still need to find a sponsor as pointed
out in comment #6 of your bug, in addition you don't appear to have
addressed the issue in comment #16 which will put off anyone getting
involved until FAS and bugzilla line up at the least.
As for your other package review request I'd suggest that given the state
of the first no one feels like diving into the second - for instance on the
second you have not blocked it against FE_NEEDSPONSOR or mention that you
need on in the bug.
Have a read through this doc on how to join the package maintainers again:
The if you want to proceed take the following steps:
1. Fix up your bugzilla/FAS accounts
2. Join the fedora devel mailing list
3. Introduce yourself on fedora-devel - include that you need a sponsor.
4. Wait a little while and if you don't have any sponsors respond to you be
proactive - polite emails to those on the Fedora wiki indicating they are
sponsors willing to help bring in a new contributor... demonstrate what you
have done to get acquainted with packaging and that you understand what the
guidelines entail.
Please note that "it passes tests" is not sufficient to be approved to be
added to the fedora repositories.