I'd like to request the following packaging policy:
[...]
If a packager uses something with the same effect than
%define debug_package %{nil}
which disables the automatically built "debuginfo" package, the spec file MUST contain a comment that explains why this is done.
On Thu, 2006-10-19 at 23:40 +0200, Michael Schwendt wrote:
I'd like to request the following packaging policy:
[...]
If a packager uses something with the same effect than
%define debug_package %{nil}
which disables the automatically built "debuginfo" package, the spec file MUST contain a comment that explains why this is done.
+1
~spot
On 10/19/06, Michael Schwendt bugs.michael@gmx.net wrote:
I'd like to request the following packaging policy:
[...]
If a packager uses something with the same effect than
%define debug_package %{nil}
which disables the automatically built "debuginfo" package, the spec file MUST contain a comment that explains why this is done.
This goes without saying. Infact why be so specific? The rule should be that if anything is done that is out of the ordinary a comment must be added that explains why.
On Thu, 19 Oct 2006 15:16:41 -0700, Christopher Stone wrote:
I'd like to request the following packaging policy:
[...]
If a packager uses something with the same effect than
%define debug_package %{nil}
which disables the automatically built "debuginfo" package, the spec file MUST contain a comment that explains why this is done.
This goes without saying. Infact why be so specific? The rule should be that if anything is done that is out of the ordinary a comment must be added that explains why.
What is "anything that is out of the ordinary"? Where does it start? Where does it stop? You could call some BuildRequires "out of the ordinary", too, but a packager might consider them as ordinary.
Some things in spec files must be enforced in order to sharpen the package maintainer's sense for adding explanatory comments.
We want debuginfo packages where possible. And where they are disabled, we want to learn about the reason.
On 10/20/06, Michael Schwendt bugs.michael@gmx.net wrote:
On Thu, 19 Oct 2006 15:16:41 -0700, Christopher Stone wrote:
I'd like to request the following packaging policy:
[...]
If a packager uses something with the same effect than
%define debug_package %{nil}
which disables the automatically built "debuginfo" package, the spec file MUST contain a comment that explains why this is done.
This goes without saying. Infact why be so specific? The rule should be that if anything is done that is out of the ordinary a comment must be added that explains why.
What is "anything that is out of the ordinary"? Where does it start? Where does it stop? You could call some BuildRequires "out of the ordinary", too, but a packager might consider them as ordinary.
It's very simple. You use your own judgement. When in doubt, add a comment. If there is ever any disagreement between packager and reviewer, the default is to add a comment.
On Fri, 20 Oct 2006 11:07:23 -0700, Christopher Stone wrote:
On Thu, 19 Oct 2006 15:16:41 -0700, Christopher Stone wrote:
I'd like to request the following packaging policy:
[...]
If a packager uses something with the same effect than
%define debug_package %{nil}
which disables the automatically built "debuginfo" package, the spec file MUST contain a comment that explains why this is done.
This goes without saying. Infact why be so specific? The rule should be that if anything is done that is out of the ordinary a comment must be added that explains why.
What is "anything that is out of the ordinary"? Where does it start? Where does it stop? You could call some BuildRequires "out of the ordinary", too, but a packager might consider them as ordinary.
It's very simple. You use your own judgement. When in doubt, add a comment. If there is ever any disagreement between packager and reviewer, the default is to add a comment.
??? Then something in our process is broken, because there are spec files used in Extras where debuginfo packages are disabled _without_ a comment.
Further, we don't apply any formal post-approval reviewing (or QA), so policies (or guidelines) for the post-approval life-time of a package are needed. These are the same than during review, at least. But they don't cover debuginfo packages yet.
I'm talking about _enforcing_ an explanatory comment in the spec file.
I'm talking about _enforcing_ an explanatory comment in the spec file.
Having specific enforcements for comments is a bad idea in my opinion.
If you see a package and think it needs a comment, you should just be able to go in and add the comment to the spec file yourself, no questions asked.
As long as you use good judgement, I don't see any problem with allowing people to do this. If a reviewer is being over-zealous of comment use such as "# use three spaces after Requries:" then this person's judgement can be called into question here.
On Fri, 20 Oct 2006 12:04:13 -0700, Christopher Stone wrote:
I'm talking about _enforcing_ an explanatory comment in the spec file.
Having specific enforcements for comments is a bad idea in my opinion.
If you see a package and think it needs a comment, you should just be able to go in and add the comment to the spec file yourself, no questions asked.
As long as you use good judgement, I don't see any problem with allowing people to do this. If a reviewer is being over-zealous of comment use such as "# use three spaces after Requries:" then this person's judgement can be called into question here.
How about we delete our ReviewGuidelines Wiki page and substitute the entire review process with a single guideline?
* Use good judgement.
And then we apply additional judgement when the package enters CVS.
Okay, this thread has found an end for me.
On 10/20/06, Michael Schwendt bugs.michael@gmx.net wrote:
On Fri, 20 Oct 2006 12:04:13 -0700, Christopher Stone wrote:
I'm talking about _enforcing_ an explanatory comment in the spec file.
Having specific enforcements for comments is a bad idea in my opinion.
If you see a package and think it needs a comment, you should just be able to go in and add the comment to the spec file yourself, no questions asked.
As long as you use good judgement, I don't see any problem with allowing people to do this. If a reviewer is being over-zealous of comment use such as "# use three spaces after Requries:" then this person's judgement can be called into question here.
How about we delete our ReviewGuidelines Wiki page and substitute the entire review process with a single guideline?
- Use good judgement.
I think this is a very bad idea. There is a difference between benign aspects of a spec file such as comments, and aspects that actually affect the outcome of the RPM.
Ofcourse *adding* a line to the guidelines that says you should try to use good judgement when something is in question I would encourage.
On Thu, 2006-10-19 at 23:40 +0200, Michael Schwendt wrote:
I'd like to request the following packaging policy:
[...]
If a packager uses something with the same effect than
%define debug_package %{nil}
which disables the automatically built "debuginfo" package, the spec file MUST contain a comment that explains why this is done.
+1
packaging@lists.fedoraproject.org
-
Christopher Stone -
Michael Schwendt -
Tom Callaway -
Ville Skyttä