Will there be any review of COPRs/packages that will become part of the Playground repository?
Proposal: Let's add a button 'Raise legal flag' or used this button from Copr page.
Let's use the same system, which we used for approval of Playground repo: mirroring. No disapproval on mailing list means approval on next meeting.
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft...
On Wed, 2014-03-26 at 15:11 -0400, Marcela Mašláňová wrote:
Will there be any review of COPRs/packages that will become part of the Playground repository?
Proposal: Let's add a button 'Raise legal flag' or used this button from Copr page.
I disagree. Surely we want to review the packages that will become part of the Playground repository? Otherwise, how are we going to reach the goal of creating a middle ground between current main repo and COPRs?
We should define a small policy/guidelines for the Playground repository that all the packages will have to adhere to and then develop (semi)automated way to check and enforce it. This will be a much faster and light-weight review than the current manual review process, but it will still allows us to provide packages of higher quality that those from some "random" COPRs.
Tadej
On 03/26/2014 05:17 PM, Tadej Janež wrote:
On Wed, 2014-03-26 at 15:11 -0400, Marcela Mašláňová wrote:
Will there be any review of COPRs/packages that will become part of the Playground repository?
Proposal: Let's add a button 'Raise legal flag' or used this button from Copr page.
I disagree. Surely we want to review the packages that will become part of the Playground repository? Otherwise, how are we going to reach the goal of creating a middle ground between current main repo and COPRs?
We should define a small policy/guidelines for the Playground repository that all the packages will have to adhere to and then develop (semi)automated way to check and enforce it. This will be a much faster and light-weight review than the current manual review process, but it will still allows us to provide packages of higher quality that those from some "random" COPRs.
Tadej
env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
Do you have more concrete proposal? What should we exactly check?
Marcela
On Wed, 2014-03-26 at 17:21 -0400, Marcela Mašláňová wrote:
Do you have more concrete proposal? What should we exactly check?
I would go for things that are easy to check automatically, but will nevertheless ensure better packaging quality.
1) The first set of checks could be automatic single-package checks already implemented in FedoraReview. In case of ambiguities, a check could require an additional manual review. - The spec file name must match the base package %{name} in the format %{name}.spec. An exception will require manual review. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n..., https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - Packages must not own files or directories already owned by other packages. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - A package must not list a file more than once in the spec file's % files listings. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - Permissions on files must be set properly. Executables should be set with executable permissions, for example. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - There should be no config files under /usr (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - All filenames in rpm packages must be valid UTF-8. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - The SPEC file shouldn't contain "illegal" tags (i.e. Packager, Vendor, PreReq, Copyright) (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - A package must use either %{buildroot} or $RPM_BUILD_ROOT. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - The %makeinstall macro shouldn't be used. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - A package's name must only use the following ASCII characters ... (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines. An exception will require manual review. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - The sources of a package must be accessible (downloadable) from URI in Source: tag (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - The gtk-update-icon-cache command should be run if required. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - The update-desktop-database command should be run if required. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - Whenever possible, Fedora packages should avoid conflicting with each other. An exception will require manual review. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
2) The second set of checks could be automatic inter-package checks. Again, in case of ambiguities, a check could require an additional manual review. - Conflicting package names with packages in the main repository or existing packages in the Playground repository (even if they differ by case alone) are not allowed. (partially implemented in https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...) - Conflicting files between different packages, either from the main repository or the Playground repository, are not allowed.
Even if we initially implement the Playground repository with a subset of the checks, I'd be fine with it.
Tadej
On 03/27/2014 12:58 AM, Tadej Janež wrote:
On Wed, 2014-03-26 at 17:21 -0400, Marcela Mašláňová wrote:
Do you have more concrete proposal? What should we exactly check?
I would go for things that are easy to check automatically, but will nevertheless ensure better packaging quality.
- The first set of checks could be automatic single-package checks
already implemented in FedoraReview. In case of ambiguities, a check could require an additional manual review.
- The spec file name must match the base package %{name} in the format
%{name}.spec. An exception will require manual review. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- A package must own all directories that it creates. If it does not
create a directory that it uses, then it should require a package which does create that directory. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n..., https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- Packages must not own files or directories already owned by other
packages. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- A package must not list a file more than once in the spec file's %
files listings. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- Permissions on files must be set properly. Executables should be set
with executable permissions, for example. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- There should be no config files under /usr
(https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- All filenames in rpm packages must be valid UTF-8.
(https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- The SPEC file shouldn't contain "illegal" tags (i.e. Packager, Vendor,
PreReq, Copyright) (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- A package must use either %{buildroot} or $RPM_BUILD_ROOT.
(https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- The %makeinstall macro shouldn't be used.
(https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- A package's name must only use the following ASCII characters ...
(https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- All build dependencies must be listed in BuildRequires, except for any
that are listed in the exceptions section of the Packaging Guidelines. An exception will require manual review. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- The sources of a package must be accessible (downloadable) from URI in
Source: tag (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- The gtk-update-icon-cache command should be run if required.
(https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- The update-desktop-database command should be run if required.
(https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- Whenever possible, Fedora packages should avoid conflicting with each
other. An exception will require manual review. (https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- The second set of checks could be automatic inter-package checks.
Again, in case of ambiguities, a check could require an additional manual review.
- Conflicting package names with packages in the main repository or
existing packages in the Playground repository (even if they differ by case alone) are not allowed. (partially implemented in https://git.fedorahosted.org/cgit/FedoraReview.git/tree/plugins/generic.py#n...)
- Conflicting files between different packages, either from the main
repository or the Playground repository, are not allowed.
Even if we initially implement the Playground repository with a subset of the checks, I'd be fine with it.
Tadej
env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
1/ fedora-review wasn't written for automatic checks. It was meant to be helping reviewers review, output shouldn't be blindly followed.
From your examples there are many, which fedora-review do incorrectly on groups of packages.
2/ Maybe we should vote about the conflicts and write it down as a rule. I have a feeling we are discussing it everytime.
I believe too much guidelines make Playground hardly accessible to general maintainers. Why not to start with less guidelines and add them if there are problems?
Marcela
On Mon, 2014-03-31 at 16:07 +0200, Marcela Mašláňová wrote:
1/ fedora-review wasn't written for automatic checks. It was meant to be helping reviewers review, output shouldn't be blindly followed.
From your examples there are many, which fedora-review do incorrectly on groups of packages.
Yes, I understand that FedoraReview isn't perfect (yet) :).
I just tried to show that we have something we could start with and I deliberately chose those checks that can be done automatically if the package doesn't involve some special cases.
2/ Maybe we should vote about the conflicts and write it down as a rule. I have a feeling we are discussing it everytime.
Sure.
I believe too much guidelines make Playground hardly accessible to general maintainers. Why not to start with less guidelines and add them if there are problems?
I believe packagers will make mistakes (most of the time not deliberately), so we should make sure we automatically catch as many as we can.
Yes, we can start with a small amount of checks in our guidelines/policy and gradually add them later. What I would like to do now is that we decide that we want to create a framework for automatic package checking that could be extended later. And in my opinion, we should use this framework on initial review and during package's lifetime as a sort of CI.
Tadej
On 03/26/2014 05:17 PM, Tadej Janež wrote:
On Wed, 2014-03-26 at 15:11 -0400, Marcela Mašláňová wrote:
Will there be any review of COPRs/packages that will become part of the Playground repository?
Proposal: Let's add a button 'Raise legal flag' or used this button from Copr page.
I disagree. Surely we want to review the packages that will become part of the Playground repository? Otherwise, how are we going to reach the goal of creating a middle ground between current main repo and COPRs?
We should define a small policy/guidelines for the Playground repository that all the packages will have to adhere to and then develop (semi)automated way to check and enforce it. This will be a much faster and light-weight review than the current manual review process, but it will still allows us to provide packages of higher quality that those from some "random" COPRs.
Tadej
env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
Also as we once have Playground without rules, we can create Playground-curated and apply all rules there.
Marcela
On Wed, 2014-03-26 at 17:34 -0400, Marcela Mašláňová wrote:
Also as we once have Playground without rules, we can create Playground-curated and apply all rules there.
Yes, this is also possible.
By setting up the "Playground without rules" repo, we would learn how to set up such a repo. Later, we would setup the "Playground-curated" repo in the same way and incorporate the automatic policy/guidelines checking I talked about in the previous email.
Tadej
env-and-stacks@lists.fedoraproject.org