Aloas,
I noticed that it is possible to build local srpm with the koji client on the Fedora buildsystem. Therefore I propose to change and simplify the following items from the Review Guidelines
| - MUST: The package must successfully compile and build into binary rpms on | at least one supported architecture. | - SHOULD: The reviewer should test that the package builds in mock. | - SHOULD: The package should compile and build into binary rpms on all | supported architectures. | - MUST: All build dependencies must be listed in BuildRequires, except for | any that are listed in the exceptions section of Packaging Guidelines; | inclusion of those as BuildRequires is optional. Apply common sense.
into:
- MUST: The package must be build on the Fedora Buildsystem for rawhide with {{{koji build --scratch dist-f8 package-*.src.rpm}}} and the build must succeed for at least one supported architecture.
The "dist-f8" parameter has to be changed in the Guidelines each time a newer is created or someone needs to create a rawhide alias tag, if this is possible.
The advantages of this approach is that the SHOULD items will be tested without extra work for the reviewer. Also there is no way acceptable way to verify that all needed BuildRequires are listed in the spec. Therefore a successfull build on the Fedora Buildsystem should be enough.
I have another change to propose: Change | - SHOULD: Usually, subpackages other than devel should require the base | package using a fully versioned dependency.
into: - SHOULD: Usually, subpackages other than devel should require the base package with {{{Requires: %{name} = %{version}-%{release}}}}
This makes it easier to copy and paste the required code and is easier to understand.
Regards, Till
On Fri, 07 Sep 2007 18:31:38 +0200 Till Maas opensource@till.name wrote:
into:
- MUST: The package must be build on the Fedora Buildsystem for
rawhide with {{{koji build --scratch dist-f8 package-*.src.rpm}}} and the build must succeed for at least one supported architecture.
The "dist-f8" parameter has to be changed in the Guidelines each time a newer is created or someone needs to create a rawhide alias tag, if this is possible.
The advantages of this approach is that the SHOULD items will be tested without extra work for the reviewer. Also there is no way acceptable way to verify that all needed BuildRequires are listed in the spec. Therefore a successfull build on the Fedora Buildsystem should be enough.
How should this be handled when one new package depends on another new package, both going through review at the same time? Do you effectively block the second review until the first is completely done and built into rawhide so that koji can make use of it in a buildroot? Would that introduce unreasonable delays in getting package sets in?
On Fr September 7 2007, Jesse Keating wrote:
How should this be handled when one new package depends on another new package, both going through review at the same time? Do you effectively block the second review until the first is completely done and built into rawhide so that koji can make use of it in a buildroot? Would that introduce unreasonable delays in getting package sets in?
Even with the current procedure the second package has to wait until the first is completely done in koji before it can be build for rawhide. The only difference is, that this delay will happen before the second package has been approved and not after it has been approved.
Regards, Till
On Fri, 07 Sep 2007 19:06:26 +0200 Till Maas opensource@till.name wrote:
Even with the current procedure the second package has to wait until the first is completely done in koji before it can be build for rawhide. The only difference is, that this delay will happen before the second package has been approved and not after it has been approved.
Except that if all are approved prior to, one can use chain-build to build the entire stack in one execution instead of dragging it on and on and on.
On Fr September 7 2007, Jesse Keating wrote:
Except that if all are approved prior to, one can use chain-build to build the entire stack in one execution instead of dragging it on and on and on.
How often does one really need to do this? When I look trough the open review requests the majority does not depend on another review request.
Regards, Till
On Fri, 07 Sep 2007 21:37:44 +0200 Till Maas opensource@till.name wrote:
How often does one really need to do this? When I look trough the open review requests the majority does not depend on another review request.
I don't know how often. It does happen.
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> How should this be handled when one new package depends on another JK> new package, both going through review at the same time?
Indeed, this would needlessly complicate reviews which depend on one another. It's bad enough as it is because it takes ages for the packages to actually get through the system, but at least without a "builds in koji" requirement the reviewer can put things in a local repo and get their end of the process done.
Now, sure, it would be nice if everyone tested in koji or local mock whenever possible, so it's certainly worth talking about getting some recommendations into the guidelines. It would also be nice if they posted rpmlint output from the resulting packages and explained all of the issues present. I fear that something like this is going to be required if the review process is ever going to actually work properly and we're not going to suddenly see ten times as many people reviewing packages.
- J<
On Fri, 2007-09-07 at 18:31 +0200, Till Maas wrote:
- MUST: The package must be build on the Fedora Buildsystem for
rawhide with {{{koji build --scratch dist-f8 package-*.src.rpm}}} and the build must succeed for at least one supported architecture.
I'm not sure I see the point of this. The package must be buildable on the Fedora Buildsystem anyway, to enter the package collection. Pointing out that koji can do scratch builds as an alternative to mock for testing buildability might be useful, tough.
On Fr September 7 2007, Matthias Clasen wrote:
I'm not sure I see the point of this. The package must be buildable on the Fedora Buildsystem anyway, to enter the package collection. Pointing out that koji can do scratch builds as an alternative to mock for testing buildability might be useful, tough.
It simplifies the review guidelines. Instead of at least a demanded local rpmbuild and optional builds for every architecture and in mock and verifying the BuildRequires (either with rpmdev-rmdevelrpms or mock) only one step is needed. The advantage is also that always building for every architecture ist tested.
Regards, Till
On Fri, 2007-09-07 at 19:10 +0200, Till Maas wrote:
On Fr September 7 2007, Matthias Clasen wrote:
I'm not sure I see the point of this. The package must be buildable on the Fedora Buildsystem anyway, to enter the package collection. Pointing out that koji can do scratch builds as an alternative to mock for testing buildability might be useful, tough.
It simplifies the review guidelines. Instead of at least a demanded local rpmbuild and optional builds for every architecture and in mock and verifying the BuildRequires (either with rpmdev-rmdevelrpms or mock) only one step is needed. The advantage is also that always building for every architecture ist tested.
I think that I would rather amend the Review Guidelines to state that a successful scratch build in koji is an acceptable alternative to a successful local build. Either is permissable to meet this criteria.
~spot
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Jesse Keating -
Matthias Clasen -
Till Maas -
Tom Callaway