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
[1] https://lists.fedoraproject.org/pipermail/users/2015-May/460623.html
On 1 December 2015 at 11:53, Ranjan Maitra maitra.mbox.ignored@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: https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.or...
This was the FESCO ticket involved: https://fedorahosted.org/fesco/ticket/1499
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: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
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.
On Tue, 1 Dec 2015 13:08:29 +0000, James Hogarth wrote:
The if you want to proceed take the following steps:
- Fix up your bugzilla/FAS accounts
Really do enter your real name in bugzilla and package %changelogs, too, and avoid using pseudonyms/aliases even if you find them "cool" or anything like that. There are enough fellow contributors, who are put off by silly names like that.
On Tue, 1 Dec 2015 14:21:59 +0100 Michael Schwendt mschwendt@gmail.com wrote:
On Tue, 1 Dec 2015 13:08:29 +0000, James Hogarth wrote:
The if you want to proceed take the following steps:
- Fix up your bugzilla/FAS accounts
Really do enter your real name in bugzilla and package %changelogs, too, and avoid using pseudonyms/aliases even if you find them "cool" or anything like that. There are enough fellow contributors, who are put off by silly names like that.
The changelog (in the spec file?) and the FAS account has my real name (and e-mail address, FWIW). My BZ account goes back in time -- I have been quite active in submitting and testing bug reports for almost ten years -- so it has a different e-mail address (when more mailing lists plastered your e-mail address and name unfiltered). I don't quite understand why this should be an issue, and I note also that BZ makes the e-mail address widely available to everybody, therefore I was reluctant to change it. I will think about what to do.
Best wishes, Ranjan
____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
On 1 December 2015 at 14:25, Ranjan Maitra maitra.mbox.ignored@inbox.com wrote:
On Tue, 1 Dec 2015 14:21:59 +0100 Michael Schwendt mschwendt@gmail.com wrote:
On Tue, 1 Dec 2015 13:08:29 +0000, James Hogarth wrote:
The if you want to proceed take the following steps:
- Fix up your bugzilla/FAS accounts
Really do enter your real name in bugzilla and package %changelogs, too, and avoid using pseudonyms/aliases even if you find them "cool" or anything like that. There are enough fellow contributors, who are put off by silly names like that.
The changelog (in the spec file?) and the FAS account has my real name (and e-mail address, FWIW). My BZ account goes back in time -- I have been quite active in submitting and testing bug reports for almost ten years -- so it has a different e-mail address (when more mailing lists plastered your e-mail address and name unfiltered). I don't quite understand why this should be an issue, and I note also that BZ makes the e-mail address widely available to everybody, therefore I was reluctant to change it. I will think about what to do.
I pointed you to this: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Have you read it yet?
Note that the mailing list bears no relation to the address in FAS ... this is what we are talking about (ignoring the preference for real name over pseudonym in bugzilla).
Although adjusting spec as per direction from others you don't appear to be making an effort on the process/people side of things.
I laid out clear steps for you to follow - they are not complicated.
If you aren't willing to do the modicum amount of work to actually take part in packagers group and seek a sponsor then I'm not willing to take time out of my day to go through fedora-review on your packaging request.
Incidentally the 'EOL' notice you're expecting won't happen with a packaging request as that's targeted against rawhide and not a specific fedora revision.
On Tue, 1 Dec 2015 15:37:15 +0000 James Hogarth james.hogarth@gmail.com wrote:
I pointed you to this: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Have you read it yet?
I read it and other documents when I submitted, and then found that there were steps (running rpmlint) that had to be taken which was not mentioned anywhere then.
Note that the mailing list bears no relation to the address in FAS ... this is what we are talking about (ignoring the preference for real name over pseudonym in bugzilla).
OK, I fixed this, I hope!
Although adjusting spec as per direction from others you don't appear to be making an effort on the process/people side of things.
But should a volunteer effort be so complicated? That is the question. Yes, we can always point to voluminous, sometimes outdated, sometimes inconsistent writeups, but therein lies the problem.
I laid out clear steps for you to follow - they are not complicated.
Perhaps not to someone familiar with the process. But volunteer efforts, on all sides, should be streamlined as far as possible. I certainly feel it is not.
If you aren't willing to do the modicum amount of work to actually take part in packagers group and seek a sponsor then I'm not willing to take time out of my day to go through fedora-review on your packaging request.
But what did I not look into that you(?) or someone else asked me to?
Incidentally the 'EOL' notice you're expecting won't happen with a packaging request as that's targeted against rawhide and not a specific fedora revision.
I see, that is good to know. Incidentally, all these RPMs have been running on my systems for years (sylfilter)/months(pdf-stapler).
Thanks, Ranjan
On Tue, 1 Dec 2015 09:56:39 -0600, Ranjan Maitra wrote:
On Tue, 1 Dec 2015 15:37:15 +0000 James Hogarth wrote:
Although adjusting spec as per direction from others you don't appear to be making an effort on the process/people side of things.
But should a volunteer effort be so complicated? That is the question. Yes, we can always point to voluminous, sometimes outdated, sometimes inconsistent writeups, but therein lies the problem.
To put it bluntly -- and the Fedora Project has done a good job at teaching people to be more blunt -- if you're so reluctant with regard to many simple things/tasks, one alternative is to sit and wait and offer your packages somewhere else. Such as Fedora Copr. Or hope that Fedora leadership will move away from current procedures more quickly -- if that still is what they would like to do. Then, however, much will be different, and it is hard to say whether "the distribution" will still be popular at all.
It cannot be repeated often enough: The package review queue is publicly visible. If a package in the queue(s) is not evaluated by anyone at all in the community, that means that there is no interest in the package or no interest in maintaining the package with the package collection. For quite some people it is less effort to run with selfmade packages in a private local repo than becoming a volunteer package maintainer with interest in team work (for example).
I laid out clear steps for you to follow - they are not complicated.
Perhaps not to someone familiar with the process. But volunteer efforts, on all sides, should be streamlined as far as possible. I certainly feel it is not.
A good first step would have been to discuss the unclear things then.
Hi,
To put it bluntly -- and the Fedora Project has done a good job at teaching people to be more blunt -- if you're so reluctant with regard to many simple things/tasks, one alternative is to sit and wait and offer your packages somewhere else. Such as Fedora Copr. Or hope that Fedora leadership will move away from current procedures more quickly -- if that still is what they would like to do. Then, however, much will be different, and it is hard to say whether "the distribution" will still be popular at all.
OK, thank you for being "blunt" but my general point is that putting in a package for review is needlessly bureaucratic and does no justice to the volunteers on either side. For example, creating the spec file (with the evolution that seems to be happening all the time) could better be automated by some script on a website. At the very least, have it suggest a skeleton. Doing so will also leave out extended review discussions. Once a package is submitted, let it go through rpmlint, etc. (and fix rpmlint to not warn on nonsensical spelling errors) doing the automated checks and speed up the process. Do you feel that it is productive for an expert to inform a submitter of basic errors which could have been caught by some auto-checking mechanism. This would reduce their loads. (R, which btw, is a far more used software, does something similar, though of course, a distribution running an entire computer can not be equated with one software package.)
It cannot be repeated often enough: The package review queue is publicly visible. If a package in the queue(s) is not evaluated by anyone at all in the community, that means that there is no interest in the package or no interest in maintaining the package with the package collection.
So do you think that packages should be included only if they are in demand by multitudes? It sort of defeats the purpose of Linux. Ideally, if only two people have need for a package, and if the first person is the packager (say), then how likely is it for the second user to actually be a member of BZ and the review set, rather than go off to some other distribution (AUR, say) where things are easier to come by? (Of course, Arch is notoriously complicated to install but Antergos does get around the burden quite a bit.)
For quite some people it is less effort to run with selfmade packages in a private local repo than becoming a volunteer package maintainer with interest in team work (for example).
Agreed! But do you want that to happen? You will then lose the ability to have more software packages then. Better to have a stringent but automated process for evaluation: if the submitter passes all the steps, let his package in or at least put it on probation. Or put it to the top of the list. Otherwise, if he has non-standard requirements, send it to BZ.
A good first step would have been to discuss the unclear things then.
Agreed.
Thanks again for responding and the discussion!
Best wishes, Ranjan
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
It's time to take this discussion off-line
On Tue, Dec 1, 2015 at 4:49 PM, Ranjan Maitra <maitra.mbox.ignored@inbox.com
wrote:
Hi,
To put it bluntly -- and the Fedora Project has done a good job at
teaching
people to be more blunt -- if you're so reluctant with regard to many
simple
things/tasks, one alternative is to sit and wait and offer your packages somewhere else. Such as Fedora Copr. Or hope that Fedora leadership will move away from current procedures more quickly -- if that still is what they would like to do. Then, however, much will be different, and it is hard to say whether "the distribution" will still be popular at all.
OK, thank you for being "blunt" but my general point is that putting in a package for review is needlessly bureaucratic and does no justice to the volunteers on either side. For example, creating the spec file (with the evolution that seems to be happening all the time) could better be automated by some script on a website. At the very least, have it suggest a skeleton. Doing so will also leave out extended review discussions. Once a package is submitted, let it go through rpmlint, etc. (and fix rpmlint to not warn on nonsensical spelling errors) doing the automated checks and speed up the process. Do you feel that it is productive for an expert to inform a submitter of basic errors which could have been caught by some auto-checking mechanism. This would reduce their loads. (R, which btw, is a far more used software, does something similar, though of course, a distribution running an entire computer can not be equated with one software package.)
It cannot be repeated often enough: The package review queue is publicly visible. If a package in the queue(s) is not evaluated by anyone at all in the community, that means that there is no interest in the package or no interest in maintaining the package with the package collection.
So do you think that packages should be included only if they are in demand by multitudes? It sort of defeats the purpose of Linux. Ideally, if only two people have need for a package, and if the first person is the packager (say), then how likely is it for the second user to actually be a member of BZ and the review set, rather than go off to some other distribution (AUR, say) where things are easier to come by? (Of course, Arch is notoriously complicated to install but Antergos does get around the burden quite a bit.)
For quite some people it is less effort to run with selfmade packages in a private local repo than becoming a volunteer package maintainer with interest in team work (for example).
Agreed! But do you want that to happen? You will then lose the ability to have more software packages then. Better to have a stringent but automated process for evaluation: if the submitter passes all the steps, let his package in or at least put it on probation. Or put it to the top of the list. Otherwise, if he has non-standard requirements, send it to BZ.
A good first step would have been to discuss the unclear things then.
Agreed.
Thanks again for responding and the discussion!
Best wishes, Ranjan
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-- Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses.
Receive Notifications of Incoming Messages Easily monitor multiple email accounts & access them with a click. Visit http://www.inbox.com/notifier and check it out!
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 12/01/2015 03:13 PM, Michael Schwendt wrote:
On Tue, 1 Dec 2015 16:56:40 -0500, Terry Polzin wrote:
It's time to take this discussion off-line
That's a strange point of view.
For a user trying to sign up as Fedora packager is is okay to use this list for a discussion.
I don't agree that this one is appropriate. This is users list, and really is intended for users. For packagers, I'd suggest using the developer list since packaging is more of a development job and there's lots of talk about "upstream" packages there.
Maybe we need a new "packagers@lists.fedoraproject.org" for this sort of thing. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Polygon: A dead parrot (With apologies to John Cleese) - ----------------------------------------------------------------------
On Tue, 1 Dec 2015 17:47:04 -0800, Rick Stevens wrote:
Maybe we need a new "packagers@lists.fedoraproject.org" for this sort of thing.
We don't need even more lists:
https://admin.fedoraproject.org/mailman/listinfo
There are too many already. There are too many with "no description available", too.
This one is scary:
https://admin.fedoraproject.org/mailman/listinfo/relicensing
No description and only spam since Oct 2011.
There is packaging@ list, but it's more about packaging techniques and packaging guidelines rather than the review process or its problems. There's some overlap with devel@ list, too.
More lists usually means that subscribers, who could help, are harder to find, because they are not subscribed everywhere.
There are enough off-topic threads on this list, so a bit more tolerance for this tiny thread would be appreciated. Afterall, it has been opened by a _user_, who is looking into becoming a packager. I know that there are users with the same interest, but they are just too shy to even try submitting a package for review.
On Tue, 1 Dec 2015 15:49:20 -0600, Ranjan Maitra wrote:
OK, thank you for being "blunt" but my general point is that putting in a package for review is needlessly bureaucratic and does no justice to the volunteers on either side.
If at all, the bureaucracy that could be removed is the review process for packages from existing members of the packager group, who have demonstrated before that they know their stuff.
There are some, who could be highly productive and could pipe out a higher number of packages (e.g. needed dependencies), if they didn't need to wait for a second pair of eyes to check even trivial packages.
Unfortunately, the review queue (including the needsponsor queue) contains too many examples of people, who just want to dump a package into the package collection without real interest in RPM packaging and maintenance of the package. That isn't anything like a basis for "a distribution" of packages. There must be a little bit of effort with regard to building packages in a sane way as well as trying to respond to feedback from the package users.
For example, creating the spec file (with the evolution that seems to be happening all the time) could better be automated by some script on a website.
"Could, could, could". That's always the same cheap talk. Over the years there have been various tools to automate RPM packaging *including* determining BuildRequires and explicit Requires. Where is the tool that's sufficiently complete and safe to use? It's still much easier for human packagers to do it right and use custom tools to automate some tasks.
At the very least, have it suggest a skeleton.
A skeleton for what? Do you realize how much packages can differ? For example, packages for Java stuff vs. packages for Perl or Python?
There's the template generate "rpmdev-newspec" in the rpmdevtools package. It creates a spec file for building and packaging a typical Autotools based program.
Doing so will also leave out extended review discussions. Once a package is submitted, let it go through rpmlint, etc. (and fix rpmlint to not warn on nonsensical spelling errors)
It's *so* simple to ignore those warnings (where rpmlint fails because of poor dictionaries or related issues). Why do you continue to blame rpmlint for some of its false positives?
doing the automated checks and speed up the process.
Have you run the fedora-review tool on your packages and/or bugzilla review tickets yet?
Do you feel that it is productive for an expert to inform a submitter of basic errors which could have been caught by some auto-checking mechanism.
It's "necessary evil" as long as (1) the package submitters care a lot less about their packages than the reviewers, and (2) there is no tool that can perform fully automated reviews. Some package submitters have the bad habit of disagreeing with tools, either ignoring findings, claiming that the tool is mistaken or coming up with strange rationales if a reviewers asks.
This would reduce their loads.
There is much higher load for the submitters, provided that they really want to maintain the package and not only dump it into a repository.
Anyone, who thinks that the review process is too high a hurdle, has never practised package maintainance before. Not with personal packages in some private repo, and not with a public personal repo either. Certainly not for a period of let's say a year or so. Or multiple years in RHEL/EPEL-style.
Of course, in a personal repo you could create packages in a way that would not only be poorly or wrongly packaged but even "forbidden" at Fedora.
So do you think that packages should be included only if they are in demand by multitudes?
A single reviewer is needed. A single person with interest in the package to build the smallest possible team of two. Either that or "review swapping", which has been advertized/suggested often enough.
Yes, it is a major disappointment, if there is nobody else to even post runtime test reports for a new package. And if potential users of the package -- members of the distribution's community (!) -- prefer compiling from source tarball instead without contributing anything.
It sort of defeats the purpose of Linux.
Please elaborate. What do you have in mind here?
Ideally, if only two people have need for a package, and if the first person is the packager (say), then how likely is it for the second user to actually be a member of BZ and the review set, rather than go off to some other distribution (AUR, say) where things are easier to come by?
Pardon? Do you intend to play the "attempted blackmail" card here? That's quite common for so-called "distro-hoppers", who would switch back and forth between distributions for every pet peeve they come up with. ;-)
If there's a distribution doing also everything else better *and* not only offering that certain package that's oh-so-mission-critical for somebody, hey, great! Let's hope it somehow will lead to making the upstream software even better, since often it's easy enough to build from source.
Eventually, there will be substantial interest in offering packages and corresponding maintenance.
For quite some people it is less effort to run with selfmade packages in a private local repo than becoming a volunteer package maintainer with interest in team work (for example).
Agreed! But do you want that to happen? You will then lose the ability to have more software packages then.
That smells like the "quantity instead of quality" card.
There are hundreds of packages in the collection, which are not used by anyone. They are in the collection, because a _single_ submitter added the packages. Sometimes they don't even work anymore or have never worked well before. Nobody notices, not even the packager. In other cases there are bug reports, but without a response from the packager => users give up trying to use the packages, spend a bit of time on following build instructions and build from source. Eventually, the broken packages are discovered, or the inactive/non-responsive packager is discovered, and somebody needs to spend additional time on cleaning up the mess (such as removing and retiring packages).
If you want quantity, start with increasing the number of loyal contributors that will lead to an increase of happy and loyal users, who may become contributors (if a minimum of interest in that is present).
Better to have a stringent but automated process for evaluation: if the submitter passes all the steps, let his package in or at least put it on probation. Or put it to the top of the list. Otherwise, if he has non-standard requirements, send it to BZ.
You may want to read up on what controversial plans some people have come up with, such as staging repos, outer and inner rings, playgrounds or dumping grounds for unreviewed packages.
Some of the plans may become fruitful, but require that the contributors are willing to leave the dumping ground level by offering a bit more than a src.rpm that seems to build. As soon as some packagers receive a first batch of bugzilla reports from frustrated package users that have started using a package, they hide somewhere.
I do not also agree that this ML is not appropriate for bringing up points of general interest to all Fedora users. But I think my comments will be becoming repetitive soon so unless something new pops up, there is not much point in rehashing the points.
Thanks to Michael for the extended and animated discussion.
On Wed, 2 Dec 2015 00:00:23 +0100 Michael Schwendt mschwendt@gmail.com wrote:
If at all, the bureaucracy that could be removed is the review process for packages from existing members of the packager group, who have demonstrated before that they know their stuff.
There are some, who could be highly productive and could pipe out a higher number of packages (e.g. needed dependencies), if they didn't need to wait for a second pair of eyes to check even trivial packages.
:-)
I was not talking of removing the "bureaucracy", but making the process a bit less bureaucratic. But you are right: I am sure that these things have been thought over by people more experienced and knowledgeable than me.
"Could, could, could". That's always the same cheap talk. Over the years there have been various tools to automate RPM packaging *including* determining BuildRequires and explicit Requires. Where is the tool that's sufficiently complete and safe to use? It's still much easier for human packagers to do it right and use custom tools to automate some tasks.
Probably nothing, but perhaps could be a good starting point.
At the very least, have it suggest a skeleton.
A skeleton for what? Do you realize how much packages can differ? For example, packages for Java stuff vs. packages for Perl or Python?
Yes, but there would be skeletons for each of the different main types. Can be done perhaps, perhaps not. Just an idea.
There's the template generate "rpmdev-newspec" in the rpmdevtools package. It creates a spec file for building and packaging a typical Autotools based program.
I find python far more difficult to handle than any of the others.
It's *so* simple to ignore those warnings (where rpmlint fails because of poor dictionaries or related issues). Why do you continue to blame rpmlint for some of its false positives?
Well, if we want to end up with a more automated process, then reducing false flags is a must.
Have you run the fedora-review tool on your packages and/or bugzilla review tickets yet?
I have not run the fedora-review tool, but I did run the koji build tool (some time ago and even now, on f22, f23, rawhide) and it passed for both packages. Is this not adequate?
There is much higher load for the submitters, provided that they really want to maintain the package and not only dump it into a repository.
OK.
Anyone, who thinks that the review process is too high a hurdle, has never practised package maintainance before. Not with personal packages in some private repo, and not with a public personal repo either. Certainly not for a period of let's say a year or so. Or multiple years in RHEL/EPEL-style.
Agreed: I have no prior experience.
It sort of defeats the purpose of Linux.
Please elaborate. What do you have in mind here?
Simply that niche packages are going to be in less demand and would hurt those users who have unusual likes. Not every one should have to be a programmer to want stuff that they would like to use. Sylfilter, for instance, is extremely lightweight, and does an extremely good job. I have packaged it for my use, but others may find the hurdle too high to compile from source or to evaluate a package submitted to BZ.
Ideally, if only two people have need for a package, and if the first person is the packager (say), then how likely is it for the second user to actually be a member of BZ and the review set, rather than go off to some other distribution (AUR, say) where things are easier to come by?
Pardon? Do you intend to play the "attempted blackmail" card here? That's quite common for so-called "distro-hoppers", who would switch back and forth between distributions for every pet peeve they come up with. ;-)
I have used and contributed to Fedora from the days of Fedora 1 (RH7 and RH9, actually). I don't think I can be accused of whatever you think you are accusing me of. I have come to, however, also appreciate Arch's fabulous documentation on, well, almost everything, and also like its rolling-release model. But I have invested in and benefited too much from the community here to give it up.
.......
Some of the plans may become fruitful, but require that the contributors are willing to leave the dumping ground level by offering a bit more than a src.rpm that seems to build. As soon as some packagers receive a first batch of bugzilla reports from frustrated package users that have started using a package, they hide somewhere.
It is a good point. But the packager is only responsible for the packaging, generally not for upstream issues. I tend to think that most of the issues I have found are from upstream.
Anyway, thanks again for the discussion!
Best wishes, Ranjan
____________________________________________________________ FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more!
On Tue, 1 Dec 2015 22:16:09 -0600, Ranjan Maitra wrote:
Have you run the fedora-review tool on your packages and/or bugzilla review tickets yet?
I have not run the fedora-review tool, but I did run the koji build tool (some time ago and even now, on f22, f23, rawhide) and it passed for both packages. Is this not adequate?
No. It's not sufficient that something "seems to build". It must be verified that the source code is configured correctly and compiled with right options, too, in order to activate security related protections and to generate a usable -debuginfo package, for example.
Yesterday I ran into a review request that packaged a precompiled executable, which perhaps did not even match the source files and could contain a trojan/backdoor/whatever.
It sort of defeats the purpose of Linux.
Please elaborate. What do you have in mind here?
Simply that niche packages are going to be in less demand and would hurt those users who have unusual likes. Not every one should have to be a programmer to want stuff that they would like to use. Sylfilter, for instance, is extremely lightweight, and does an extremely good job. I have packaged it for my use, but others may find the hurdle too high to compile from source or to evaluate a package submitted to BZ.
I don't think that users find the very common
./configure && make && make install
sequence of commands too difficult.
Everywhere you can meet users of a distribution that ships prebuilt packages, and still they run their self-compiled software. Even if only to get the very latest minor version of something.
Packaging that up is a bit more difficult. Sure. And package maintenance then increases the difficulty even further.
It could be that some of those, who manage to create packages, would benefit from a playing ground where they could offer their packages and get feedback from actual users. Based on that they could improve their skills, their packages, and advance to maintainers of those packages. I'm just not sure a real dumping ground will shine. It reminds me too much of Red Hat's old contrib.redhat.com FTP server where people uploaded the weirdest contents without any peer review. That increases the risks for users too much, too.
But the packager is only responsible for the packaging, generally not for upstream issues. I tend to think that most of the issues I have found are from upstream.
Still upstream needs to be informed about those issues. And it might be that the software is miscompiled or that it's a dependency that's broken. Watch all those cases where upstream cannot reproduce the problem.
*Somebody* needs to investigate the problem *and* respond to bug reports, too. It just doesn't work, if users file bug reports and nobody responds. That is reason #1 for many a user to leave frustrated and look into trying out a different product.
On Tue, 1 Dec 2015 08:25:28 -0600, Ranjan Maitra wrote:
My BZ account goes back in time -- I have been quite active in submitting and testing bug reports for almost ten years -- so it has a different e-mail address (when more mailing lists plastered your e-mail address and name unfiltered). I don't quite understand why this should be an issue, and I note also that BZ makes the e-mail address widely available to everybody, therefore I was reluctant to change it. I will think about what to do.
???
How is that even relevant? Your real name in bugzilla is a separate field in the preferences. You don't need to change the email address.
For your bugzilla account to work correctly with FAS, the email address in bugzilla must be the same as in FAS. Or else your bugzilla account doesn't receive privileges you gain via group membership in FAS.
On Tue, 1 Dec 2015 05:53:13 -0600, Ranjan Maitra wrote:
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:
No drama, please.
So many words in this mail of yours. The time could have been spent better on swapping reviews, reading the process documentation and fixing the bugzilla tickets, too. Waiting passively leads to something seldomly.
The ticket has not even been visible in the needsponsor queue because the fedora-review flag set to '?' means there is a reviewer working on it.
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:
Here you could also have added the needsponsor flag as per the process guide.
The various review queues are quite crowded: http://fedoraproject.org/PackageReviewStatus/
What else?
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
On Tue, 1 Dec 2015 14:18:38 +0100 Michael Schwendt mschwendt@gmail.com wrote:
On Tue, 1 Dec 2015 05:53:13 -0600, Ranjan Maitra wrote:
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:
No drama, please.
I am sorry, but whatever said is just my statement of fact.
So many words in this mail of yours. The time could have been spent better on swapping reviews, reading the process documentation and fixing the bugzilla tickets, too. Waiting passively leads to something seldomly.
I don't know if I was waiting passively. But if a process is so intricate and involved, then it needs to be simplified.
The ticket has not even been visible in the needsponsor queue because the fedora-review flag set to '?' means there is a reviewer working on it.
OK, I missed this. But should this not be set as the default? What is the point of setting it as something else, when a review request means that it is looking for a sponsor/reviewer? Anyway, I noticed that you have changed it now: thanks!!
Best wishes, Ranjan
____________________________________________________________ FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more!
On Tue, 1 Dec 2015 08:20:45 -0600, Ranjan Maitra wrote:
The ticket has not even been visible in the needsponsor queue because the fedora-review flag set to '?' means there is a reviewer working on it.
OK, I missed this. But should this not be set as the default? What is the point of setting it as something else, when a review request means that it is looking for a sponsor/reviewer?
New packages don't need "sponsorship", but new contributors do.
It's step 3 here: https://fedoraproject.org/wiki/Package_Review_Process#Contributor
There are many more new packages added to the queue than new contributors.
Btw, I'm not in any position to do anything about this process. If anyone wants to suggest improvements, open a thread on devel@ list, for example.
-
James Hogarth -
Michael Schwendt -
Ranjan Maitra -
Rick Stevens -
Terry Polzin