I was noticing a missing file, titled a logfile, (Who did the inspection when, and was it OK)
Leslie Satenstein
On Wednesday, April 10, 2024 at 10:05:34 a.m. EDT, David Cantrell <dcantrell@xxxxxxxxxx> wrote:
On 4/9/24 17:14, Kevin Fenzi wrote:
> On Tue, Apr 09, 2024 at 01:55:41PM -0400, David Cantrell wrote:
>> Hello all,
>>
>> I am looking for multiple people to help be upstream stewards of the rpminspect-data-fedora project. This is a project that contains config files and rules for running rpminspect on Fedora builds. It is a package containing distribution policy. It needs people to look over it and review and merge contributions from other developers, do occassional releases, and ensure that it is updated as new releases of Fedora are started (and we get new dist tags).
>>
>> The project currently lives here:
>>
>> https://github.com/rpminspect/rpminspect-data-fedora
>>
>> But absolutely can move depending on the desires of the individuals who take over maintenance. I created these rules files in the data package for rpminspect so that different vendors can customize how rpminspect runs and reacts to findings. Maintenance of the rules is independent of the software maintenance.
>>
>> If you are interested, please email me directly and we can get going on the logistics. If you have general questions, feel free to ask here.
>
> I wonder if this isn't something we should have the QE or releng teams
> manage... ie, adding new branch info (releng), adjusting tests (qe)?
>
I think that's a good idea. Syncing the creation of new dist tag files in rpminspect-data-fedora could be aligned with creating them in koji, etc. QE and rel-eng don't specifically have to own doing that work, just making sure it has been taken care of by one of the rpminspect-data-fedora stewards.
Right now package maintainers can control how rpminspect runs with a local rpminspect config file in the dist-git repo. However, some things cannot be overridden with that config file so those changes have to be made in the vendor data package. So having someone review those changes and collectively sign off on them is also a good idea for process control. (An example of something that has to be in the vendor data package and cannot be in the local package's rpminspect config file is an executable that needs to carry setuid or setgid bits.)
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> On Tue, Apr 09, 2024 at 01:55:41PM -0400, David Cantrell wrote:
>> Hello all,
>>
>> I am looking for multiple people to help be upstream stewards of the rpminspect-data-fedora project. This is a project that contains config files and rules for running rpminspect on Fedora builds. It is a package containing distribution policy. It needs people to look over it and review and merge contributions from other developers, do occassional releases, and ensure that it is updated as new releases of Fedora are started (and we get new dist tags).
>>
>> The project currently lives here:
>>
>> https://github.com/rpminspect/rpminspect-data-fedora
>>
>> But absolutely can move depending on the desires of the individuals who take over maintenance. I created these rules files in the data package for rpminspect so that different vendors can customize how rpminspect runs and reacts to findings. Maintenance of the rules is independent of the software maintenance.
>>
>> If you are interested, please email me directly and we can get going on the logistics. If you have general questions, feel free to ask here.
>
> I wonder if this isn't something we should have the QE or releng teams
> manage... ie, adding new branch info (releng), adjusting tests (qe)?
>
I think that's a good idea. Syncing the creation of new dist tag files in rpminspect-data-fedora could be aligned with creating them in koji, etc. QE and rel-eng don't specifically have to own doing that work, just making sure it has been taken care of by one of the rpminspect-data-fedora stewards.
Right now package maintainers can control how rpminspect runs with a local rpminspect config file in the dist-git repo. However, some things cannot be overridden with that config file so those changes have to be made in the vendor data package. So having someone review those changes and collectively sign off on them is also a good idea for process control. (An example of something that has to be in the vendor data package and cannot be in the local package's rpminspect config file is an executable that needs to carry setuid or setgid bits.)
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
