I submitted my software for review through bugzilla in order to contribute the software to RedHat. A guy who checked the script told me to fix some problems. I fixed all problems that he mentioned and sent him new links of the software in the same bug report. I haven't heard anything from him since April 16. Here is a question: do I need to submit new links as a new bug report? if no...how long does it usually take to review the software?
Thanks, Anton
I submitted my software for review through bugzilla in order to contribute the software to RedHat. A guy who checked the script told me to fix some problems. I fixed all problems that he mentioned and sent him new links of the software in the same bug report. I haven't heard anything from him since April 16. Here is a question: do I need to submit new links as a new bug report? if no...how long does it usually take to review the software?
Everyone: Anton is referring to Bug #236486 [1]
Anton: Manuel Wolfshant who was kind enough to point out a few problems is not obligated to review it officially, he might have just noticed your entry, and had a quick look. These are pre-reviews.
As you need someone to sponsor you, that limits the number of people that can accept for package into fedora down to roughly 50 (last time I looked). I'm not absolutely sure but I don't think Manuel is one of them.
Some tips however: * Do a couple of well rounded out pre-reviews, for an example [2] is one I did while waiting for a sponsor. * Look into what other packages you can prepare * Have patience, you submitted your package on the 14th and from experience it can take a good 2+ weeks.
Thanks, Anton
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236486 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235802#c1
Regards,
N.J.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 04/27/2007 04:00 AM, Nigel Jones wrote:
I submitted my software for review through bugzilla in order to contribute the software to RedHat. A guy who checked the script told me to fix some problems. I fixed all problems that he mentioned and sent him new links of the software in the same bug report. I haven't heard anything from him since April 16. Here is a question: do I need to submit new links as a new bug report? if no...how long does it usually take to review the software?
Everyone: Anton is referring to Bug #236486 [1]
Anton: Manuel Wolfshant who was kind enough to point out a few problems is not obligated to review it officially, he might have just noticed your entry, and had a quick look. These are pre-reviews.
FWIW: I wanted to continue the pre-review at the time but despite the announcement of the new version, it was not available online. And I did not assign the review to myself because I am not a sponsor, as Nigel has correctly said.
Anton: after a new quick glance over your spec (my test machine is currently offline so I cannot test in mock): it lacks changelog entries (for -3 at least)
On Thu, Apr 26, 2007 at 08:18:54PM -0400, Anton Kuznetsov wrote:
him new links of the software in the same bug report. I haven't heard anything from him since April 16. Here is a question: do I need to submit new links as a new bug report? if no...how long does it usually take to review the software?
You should understand that in the Fedora project (just like in free software) contributors are (in general) benevolent. And in general, when they are not they are overwhelemed. So a review and sponsorship pending may take very few time to be looked at if it is of interest for a sponsor and/or a reviewer. But it may also take a great amount of time for many reasons, like lack of interest from the reviewers, not enough time to review, and any other reason you can imagine. Currently the review queue is quite big because all the package formerly in core has to be reviewed. But even before the merge review there were reviews that were some years old.
-- Pat
Patrice Dumas wrote:
Currently the review queue
is quite big because all the package formerly in core has to be reviewed. But even before the merge review there were reviews that were some years old.
Do we really have reviews stalled for years? We should probably have a policy in place that reviews over a few months get closed.
Rahul
On Fri, Apr 27, 2007 at 12:49:24PM +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
Currently the review queue
is quite big because all the package formerly in core has to be reviewed. But even before the merge review there were reviews that were some years old.
Do we really have reviews stalled for years? We should probably have a policy in place that reviews over a few months get closed.
Why? We have the stalled review policy that covers this subject fine, in my opinion. And yes I have at least months old or years submissions but I can't see why they should be closed. Same for submissions I am reviewing and that are stuck for whatever reason.
-- Pat
Patrice Dumas wrote:
On Fri, Apr 27, 2007 at 12:49:24PM +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
Currently the review queue
is quite big because all the package formerly in core has to be reviewed. But even before the merge review there were reviews that were some years old.
Do we really have reviews stalled for years? We should probably have a policy in place that reviews over a few months get closed.
Why? We have the stalled review policy that covers this subject fine, in my opinion. And yes I have at least months old or years submissions but I can't see why they should be closed. Same for submissions I am reviewing and that are stuck for whatever reason.
If no one is interested in reviewing a package for years together then it is just hogging up the queue without the benefits. If a package has been submitted over say 6 months back then that submission is useless is most cases since newer software would have been released that makes the software as well as associated reviews obsolete.
Rahul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rahul Sundaram wrote:
Patrice Dumas wrote:
On Fri, Apr 27, 2007 at 12:49:24PM +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
Currently the review queue
is quite big because all the package formerly in core has to be reviewed. But even before the merge review there were reviews that were some years old.
Do we really have reviews stalled for years? We should probably have a policy in place that reviews over a few months get closed.
Why? We have the stalled review policy that covers this subject fine, in my opinion. And yes I have at least months old or years submissions but I can't see why they should be closed. Same for submissions I am reviewing and that are stuck for whatever reason.
If no one is interested in reviewing a package for years together then it is just hogging up the queue without the benefits. If a package has been submitted over say 6 months back then that submission is useless is most cases since newer software would have been released that makes the software as well as associated reviews obsolete.
A submitted review, can be held up due to other dependencies that continuously get added, or because of the continued great work of maintainers (and reviewers alike), that are working well on bettering themselves at packaging and insuring Fedora keeps to a reasonable minimum standard, while proceeding through the review process.
'Good things take time'
- -- N.J.
Rahul
On Fri, Apr 27, 2007 at 01:02:45PM +0530, Rahul Sundaram wrote:
If no one is interested in reviewing a package for years together then it is just hogging up the queue without the benefits. If a package has been submitted over say 6 months back then that submission is useless is most cases since newer software would have been released that makes the software as well as associated reviews obsolete.
Not necessarily. It should be judged on a case by case by submitters. And even if there is a new version, the review should be continued in the same ticket. The history of a submission may be interesting on its own, closing tickets and reopening new unnecessarily makes things hard to follow. Moreover removing tickets from the queue while they are not reviewed is wrong and gives a false view on the number and the packages waiting for a review. Stalled reviews (for good or bad reasons) should be in the needinfo state (although it is possible that the meaning of needinfo has changed with the new review process). Last reason to keep them is that sometimes the upstream is informed about the submission and closing without reason means having to recontact them when a new review is done (it is the case for 2 old reviews of me, one not so old, the other very old).
-- Pat
"RS" == Rahul Sundaram sundaram@fedoraproject.org writes:
RS> If no one is interested in reviewing a package for years together RS> then it is just hogging up the queue without the benefits.
I wasn't aware that there was some limit on the queue size.
RS> If a package has been submitted over say 6 months back then that RS> submission is useless is most cases since newer software would RS> have been released that makes the software as well as associated RS> reviews obsolete.
This is far from true in many circumstances.
What we have now works fine; I haven't noticed the people who review the packages complaining about the submissions. Anyone is welcome to drop pings on those old reviews to make sure the submitters are still around. However, you can't really expect them to provide updates unless there's some chance that someone will actually review the packages, so it would be preferable if such pings come with an offer to review. This is what I do. (And really, I do intend to start reviewing again soon.)
- J<
On Friday 27 April 2007 8:19:24 am Rahul Sundaram wrote:
Patrice Dumas wrote:
Currently the review queue
is quite big because all the package formerly in core has to be reviewed. But even before the merge review there were reviews that were some years old.
Do we really have reviews stalled for years? We should probably have a policy in place that reviews over a few months get closed.
No need for that, we have dealt with most cases in a reasonable way, including reviews that were open for several months for any reason.
At present the process is a bit slow because there are more reviews to do (some due to Core merge) and others, always a good sign.
Rahul
On Fri, 2007-04-27 at 12:49 +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
Currently the review queue
is quite big because all the package formerly in core has to be reviewed. But even before the merge review there were reviews that were some years old.
Do we really have reviews stalled for years?
Yes, I withdrew two packages of mine after they had been lingering around in the queue for 14 months and turned away from fedora to shipping them via a 3rd party repo, instead.
We should probably have a policy in place that reviews over a few months get closed.
In my cases, the reasons probably, was the packages being beyond the capability of most "review monkeys" and being too specialized to be interesting to the masses. For such cases, a "time out" is inappropriate.
Ralf
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> Yes, I withdrew two packages of mine after they had been lingering RC> around in the queue for 14 months and turned away from fedora to RC> shipping them via a 3rd party repo, instead.
Well, you certainly understand the reasons behind those. I don't think we have many packages currently blocked on guidelines, so those packages surely aren't typical.
- J<
On Fri, 2007-04-27 at 14:53 -0500, Jason L Tibbitts III wrote:
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> Yes, I withdrew two packages of mine after they had been lingering RC> around in the queue for 14 months and turned away from fedora to RC> shipping them via a 3rd party repo, instead.
Well, you certainly understand the reasons behind those.
As I see it, the reasons were (in decreasing order):
1. rpm/rpmbuilds's brokenness 2. Package complexity, mostly being introduced by 1.) 3. Reviewers' lack of competence to understand the need of the complexity. 4. Highly specialized packages with small userbase/audience. 5. GuideLines incompleteliness (The packages are touching areas the guidelines don't cover). ..
I don't think we have many packages currently blocked on guidelines, so those packages surely aren't typical.
Agreed, my packages were outside the "usual class of packages" Fedora can handle.
As I see it, community contributed Fedora is only able to handle "trivial, mass-market" packages. I'd presume that most "non-trivial packages", which currently are part of Core and 100% under RH control (E.g. GCC, kernel, glibc, perl ...) would have never made it into FE.
Ralf
On Sat, Apr 28, 2007 at 05:01:07AM +0200, Ralf Corsepius wrote:
As I see it, community contributed Fedora is only able to handle "trivial, mass-market" packages. I'd presume that most "non-trivial packages", which currently are part of Core and 100% under RH control (E.g. GCC, kernel, glibc, perl ...) would have never made it into FE.
That's not so obvious since, although they are very complicated packages they are also very widely used.
-- Pat
On Mon, 2007-04-30 at 11:19 +0200, Patrice Dumas wrote:
On Sat, Apr 28, 2007 at 05:01:07AM +0200, Ralf Corsepius wrote:
As I see it, community contributed Fedora is only able to handle "trivial, mass-market" packages. I'd presume that most "non-trivial packages", which currently are part of Core and 100% under RH control (E.g. GCC, kernel, glibc, perl ...) would have never made it into FE.
That's not so obvious since, although they are very complicated packages they are also very widely used.
Are you seriously telling me you would accept a package which has 30 or more patches applied?
You would tell the maintainer to tell upstream to fix them.
Ralf
Ralf Corsepius wrote:
On Mon, 2007-04-30 at 11:19 +0200, Patrice Dumas wrote:
On Sat, Apr 28, 2007 at 05:01:07AM +0200, Ralf Corsepius wrote:
As I see it, community contributed Fedora is only able to handle "trivial, mass-market" packages. I'd presume that most "non-trivial packages", which currently are part of Core and 100% under RH control (E.g. GCC, kernel, glibc, perl ...) would have never made it into FE.
That's not so obvious since, although they are very complicated packages they are also very widely used.
Are you seriously telling me you would accept a package which has 30 or more patches applied?
You would tell the maintainer to tell upstream to fix them.
Not in all cases. Sometimes there are valid reasons to patch. Nobody wants to adds patches and creates additional maintenance work for themselves for fun. Many patches Any critical package in your list would have definitely passed review in FE because of their critical nature and popularity.
You can see many such packages going through merge review. Complication in the packages might slow down the review process but it would happen nevertheless. For obscure packages the reviews might just not happen at all.
Rahul
On Mon, 2007-04-30 at 17:49 +0530, Rahul Sundaram wrote:
Ralf Corsepius wrote:
On Mon, 2007-04-30 at 11:19 +0200, Patrice Dumas wrote:
On Sat, Apr 28, 2007 at 05:01:07AM +0200, Ralf Corsepius wrote:
As I see it, community contributed Fedora is only able to handle "trivial, mass-market" packages. I'd presume that most "non-trivial packages", which currently are part of Core and 100% under RH control (E.g. GCC, kernel, glibc, perl ...) would have never made it into FE.
That's not so obvious since, although they are very complicated packages they are also very widely used.
Are you seriously telling me you would accept a package which has 30 or more patches applied?
You would tell the maintainer to tell upstream to fix them.
Not in all cases. Sometimes there are valid reasons to patch.
The only legitimate reason to patch is time-lags between upstream and current version.
If this isn't reason, then patching is a strong indication for something about the development model not being functional.
Ralf Corsepius wrote: .
The only legitimate reason to patch is time-lags between upstream and current version.
Not true. There are licensing reasons, difference in defaults, differences in approaches between upstream and distributions etc.
If this isn't reason, then patching is a strong indication for something about the development model not being functional.
It could also be indicative of that. Encouraging patches to be submitted upstream is a good thing but the number of patches are not indicated as a review blocker and won't stop a package from being included in Fedora.
Rahul
On 2007-04-30, 10:30 GMT, Ralf Corsepius wrote:
Are you seriously telling me you would accept a package which has 30 or more patches applied?
[matej@hubmaier ~]$ rpm2cpio vim-7.0.109-3.src.rpm \ | cpio --quiet -vt | grep .patch | wc -l 20 [matej@hubmaier ~]$
I know it is still just 20 patches, but I am quite sure that Bram won't stop here -- remember vim package with 100+ patches.
Matěj
Ralf Corsepius <rc040203 <at> freenet.de> writes:
Are you seriously telling me you would accept a package which has 30 or more patches applied?
Why not? In fact, there are already such packages in Extras. For example, look at the ATLAS package. That one uses the "one big patch" approach, because there would be too many otherwise: there's a Debian gzipped patch applied which is 3.8 MB _compressed_ (!) and then there's a 972 byte Fedora patch on top of that to use gfortran instead of g77. Some packages have upstreams which are either defunct or (as is probably the case of ATLAS) don't care about packaging and packagers' requirements, so there's no other solution there. Sure, if the patches could go upstream, it would be better, but if not, I don't see why having many or big patches would be a reason not to approve the packages.
Also, for a package like rtems-binutils, upstream is really RTEMS, not the FSF. So the big patch to get from FSF Binutils to RTEMS Binutils is not really a packager patch, it's just how upstream distributes its source code. Getting their local patches merged into the FSF source is something upstream would have to deal with, not the Fedora packager. TIGCC works similarly. (I currently have a 318 KB GCC patch and a 61 KB GNU as patch.)
Kevin Kofler
On Mon, Apr 30, 2007 at 12:30:29PM +0200, Ralf Corsepius wrote:
Are you seriously telling me you would accept a package which has 30 or more patches applied?
You would tell the maintainer to tell upstream to fix them.
In the cernlib there are about 100 patches, most of them coming from debian, some I have submitted to the debian maintainer. Upstream still do some releases but don't care about shared libraries, FHS, distributing code violating the GPL, code already in other packages...
-- Pat
On Monday 30 April 2007 10:19:52 Patrice Dumas wrote:
On Sat, Apr 28, 2007 at 05:01:07AM +0200, Ralf Corsepius wrote:
As I see it, community contributed Fedora is only able to handle "trivial, mass-market" packages. I'd presume that most "non-trivial packages", which currently are part of Core and 100% under RH control (E.g. GCC, kernel, glibc, perl ...) would have never made it into FE.
That's not so obvious since, although they are very complicated packages they are also very widely used.
Sure, I find it hard to understand how it would be possible to build a linux distribution without the kernel, glibc and gcc. ;-)
-- Pat
Ralf Corsepius wrote:
On Fri, 2007-04-27 at 12:49 +0530, Rahul Sundaram wrote:
Do we really have reviews stalled for years?
Yes, I withdrew two packages of mine after they had been lingering around in the queue for 14 months and turned away from fedora to shipping them via a 3rd party repo, instead.
I can attest that doing so (3rd party repo) can greatly help the process because the packages get more users, field-testing, feedback. These same users may end up being interested enough in helping with a formal review.
-- Rex
On Fri, 2007-04-27 at 21:53 -0500, Rex Dieter wrote:
Ralf Corsepius wrote:
On Fri, 2007-04-27 at 12:49 +0530, Rahul Sundaram wrote:
Do we really have reviews stalled for years?
Yes, I withdrew two packages of mine after they had been lingering around in the queue for 14 months and turned away from fedora to shipping them via a 3rd party repo, instead.
I can attest that doing so (3rd party repo) can greatly help the process because the packages get more users, field-testing, feedback. These same users may end up being interested enough in helping with a formal review.
The problem for me is: 1) 3rd party repos mean a tremendous effort 2) 3rd party repos means not being able to ship them for all Fedora architectures. 3) The packages also have a Windows based user-base.
Having them in Fedora would have avoided 1), 2).
It also would have helped the upstream projects behind the packages and would have helped to decrease 3) - Fedora missed this opportunity.
Ralf
Ralf Corsepius <rc040203 <at> freenet.de> writes:
Yes, I withdrew two packages of mine after they had been lingering around in the queue for 14 months and turned away from fedora to shipping them via a 3rd party repo, instead.
Are you referring to the rtems cross-compilers? I'm willing to get these through review for you (I can review packages from people who don't need a sponsor now that I own a package) if you do the same with my tigcc cross-toolchain package once I submit it. (It needs some work: I need to change the prefix away from /usr/local/tigcc to something more in line with the FHS and improve the way I get the binaries into the PATH (TIGCC only needs 2 binaries in the path, both with unique names: tigcc and tprbuilder), and I need to zap the optional non-Free A68k assembler from the tarball. That's why I haven't submitted it yet.) I'm currently also using the "third-party repository" solution: http://repo.calcforge.org
I just hope nobody will complain about policies not being enforced during the reviews. I do think cross-compiler packages should also follow policies where possible. But one area where it's not possible is bending the FHS with the separate prefix, which has already been agreed upon by pretty much all the people interested in cross compilers. There could be more, but I need to look at your packages to tell.
Speaking of the prefix: would /usr/tigcc be acceptable or should I use something like /usr/m68k-ti-tigcc? The patched GCC and GNU as in TIGCC don't care either way, nor do the other components in the toolchain (all non-GNU Free Software).
Kevin Kofler
On Sat, 2007-04-28 at 15:37 +0000, Kevin Kofler wrote:
Ralf Corsepius <rc040203 <at> freenet.de> writes:
Yes, I withdrew two packages of mine after they had been lingering around in the queue for 14 months and turned away from fedora to shipping them via a 3rd party repo, instead.
Are you referring to the rtems cross-compilers?
Yes, these are two packages I am referring to.
They we "probes" for many more cross tool chains I have. I was aware getting these through reviews would be hard and a lot of effort (and was willing to cope with it) in advance, but the feedback had been so "overwhelming" that I could not avoid concluding Fedora not to be a suitable platform for cross-toolchains and more generally speaking, for any "complex packages with a small user base".
I'm willing to get these through review for you (I can review packages from people who don't need a sponsor now that I own a package) if you do the same with my tigcc cross-toolchain package once I submit it.
Hmm, I must have missed it in all these bugzilla traffic.
URL? All I can find in bugzilla is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225120 which probably isn't what you are referring to.
Ralf
Ralf Corsepius <rc040203 <at> freenet.de> writes:
I'm willing to get these through review for you (I can review packages from people who don't need a sponsor now that I own a package) if you do the same with my tigcc cross-toolchain package once I submit it.
Hmm, I must have missed it in all these bugzilla traffic.
URL? All I can find in bugzilla is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225120 which probably isn't what you are referring to.
As I said in the previous e-mail, I haven't submitted it yet. If you want to look at my current SRPMs, you can get my current packages at http://repo.calcforge.org/ , but these are NOT ready for submittal (especially TIGCC needs to have tigcc-a68k built from a separate tarball and zapped from the main tigcc SRPM, because the A68k license is not acceptable for Fedora - luckily, TIGCC is perfectly usable without A68k, as there's the GNU assembler, you just can't assemble legacy assembly programs written for A68k without it).
Kevin Kofler
Replying to myself here, because I have to add something:
Kevin Kofler <kevin.kofler <at> chello.at> writes:
Are you referring to the rtems cross-compilers? I'm willing to get these through review for you (I can review packages from people who don't need a sponsor now that I own a package) if you do the same with my tigcc cross-toolchain package once I submit it.
However, I see these currently block FE-GUIDELINES, so this is not just a case of respecting existing guidelines as your original post sounded like, but the problem is that someone thinks specific guidelines for cross-compiling are needed. I've also noticed you regularly attend the Fedora Packaging Committee meetings, why didn't you bring this up there?
Looking more closely at the situation, I now think the only way we can get these reviewed without violating policies is to either get a clear statement from FPC that no specific guidelines are needed (so the FE-GUIDELINES can be removed) or to get the specific guidelines voted.
Kevin Kofler
On Tue, 2007-05-01 at 03:20 +0000, Kevin Kofler wrote:
Replying to myself here, because I have to add something:
Kevin Kofler <kevin.kofler <at> chello.at> writes:
Are you referring to the rtems cross-compilers? I'm willing to get these through review for you (I can review packages from people who don't need a sponsor now that I own a package) if you do the same with my tigcc cross-toolchain package once I submit it.
However, I see these currently block FE-GUIDELINES, so this is not just a case of respecting existing guidelines as your original post sounded like, but the problem is that someone thinks specific guidelines for cross-compiling are needed. I've also noticed you regularly attend the Fedora Packaging Committee meetings, why didn't you bring this up there?
I am a member of the FPC.
The topic had been brought up there a very long time ago, but it was shot down. Other FPC members could not refrain from insisting on "change upstream". Anyway, this topic meanwhile had come up repeatedly on various Fedora lists, resulting into the "embedded SIG" http://fedoraproject.org/wiki//SIGs/Embedded, which collaborated into producing a precedence (avr-binutils), pragmatically focusing on the actual issues, to not further close out cross-toolchains from Fedora.
Ralf
Ralf Corsepius <rc040203 <at> freenet.de> writes:
The topic had been brought up there a very long time ago, but it was shot down. Other FPC members could not refrain from insisting on "change upstream". Anyway, this topic meanwhile had come up repeatedly on various Fedora lists, resulting into the "embedded SIG" http://fedoraproject.org/wiki//SIGs/Embedded, which collaborated into producing a precedence (avr-binutils), pragmatically focusing on the actual issues, to not further close out cross-toolchains from Fedora.
So this means we can take your review requests out of FE-GUIDELINES? If so, I'll be glad to review them. I do need your latest SRPMs though. In particular, the GCC SRPM link is broken.
Kevin Kofler
-
Anton Kuznetsov -
Jason L Tibbitts III -
José Abílio Matos -
Kevin Kofler -
Manuel Wolfshant -
Matej Cepl -
Nigel Jones -
Patrice Dumas -
Rahul Sundaram -
Ralf Corsepius -
Rex Dieter