Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-02 Thread Sam James
Ionen Wolkens  writes:

> On Wed, May 01, 2024 at 03:32:21PM +0200, Michał Górny wrote:
>> The idea is to increase awareness of the AI policy, as well as other
>> rules, and to inform users before they submit a PR.
>
> Bit mixed feelings about this given checkboxes feel like unnecessary
> churn for routine contributors and is semi-redundant with the
> Signed-off-by.
>
> I think it's great for first-time/occasional contributors though.
>
> Having a AI-specific checkbox does feel kind of overkill when it won't
> concern the majority of contributors, albeit given how how hard the whole
> thing is pushed lately and that we have no real way to verify beside the
> user being made aware of it and certifying it...
>
> On a side-note, I have nothing against having .github in the tree. Just
> saying given I know not everyone is happy with that.

Indeed, the only line for me is if we were solely relying on it, e.g. if
we replaced all self-hosted CI with github actions CI or similar. I
don't see supplementary files for services we make use of, but don't
depend on, as a problem, as long as they're not some minor experiment.



Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-02 Thread Sam James
Michał Górny  writes:

> Signed-off-by: Michał Górny 
> ---
>  .github/pull_request_template.md | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 .github/pull_request_template.md
>
> The idea is to increase awareness of the AI policy, as well as other
> rules, and to inform users before they submit a PR.
>
> Screenshots @ https://github.com/gentoo/gentoo/pull/36503
>
>
> diff --git a/.github/pull_request_template.md 
> b/.github/pull_request_template.md
> new file mode 100644
> index ..9e6fe061db11
> --- /dev/null
> +++ b/.github/pull_request_template.md
> @@ -0,0 +1,12 @@
> +
> +
> +---
> +
> +Please check all the boxes that apply:
> +
> +- [ ] I can submit this contribution in agreement with the [Copyright 
> Policy](https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin).
> +- [ ] This contribution has not been created with the assistance of
> Natural Language Processing artificial intelligence tools, in
> accordance with [AI
> policy](https://wiki.gentoo.org/wiki/Project:Council/AI_policy).
> +- [ ] I have certified the above via adding a `Signed-off-by` line to 
> *every* commit in the pull request.
> +- [ ] I have run `pkgcheck scan --commits --net` to check for issues with my 
> commits.
> +
> +Please note that all boxes must be checked for the pull request to be merged.

I'm OK with the proposal as-is, but would be interested in hearing
suggestions to alleviate ulm's concern of developers feeling they must
tick every single box as well. But that might not be doable.

xgqt's comments wrt testing are interesting but maybe better with us
linking to a checklist instead, rather than something users have to
declare in the github PR. Not sure.

Anyway, thanks for this, I've wanted this for a while anyway as it's
more elegant than the Larry bot method. Glad you came around ;)

thanks,
sam



Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Maciej Barć

I agree, but such documentation doesn't belong in an ebuild repository,
but should be in a dedicated location like the Devmanual or the wiki.


From our workflow and policy standpoint - yes; but to conform how it is 
mostly done in git forges like github/gitlab/codeberg etc this is also 
documented in LICENSE or COPYRIGHT file.
(Offotopic: though I use a dedicated dir called "Copyright" to put all 
legal info there for my own priovate repos.)


W dniu 1.05.2024 o 17:52, Ulrich Mueller pisze:

On Wed, 01 May 2024, Maciej Barć wrote:



Also no license link. Afaik all contribs are under GPL-2.



That's not entirely correct. The files in the licenses/ directory
aren't, and patches in packages' files/ dirs generally follow the
license of their upstream project.



See, so it would help to have a doc that talks about the
irregularities.


I agree, but such documentation doesn't belong in an ebuild repository,
but should be in a dedicated location like the Devmanual or the wiki.

Ulrich


--
Have a great day!

~ Maciej XGQT Barć

https://wiki.gentoo.org/wiki/User:Xgqt
9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Ulrich Mueller
> On Wed, 01 May 2024, Maciej Barć wrote:

>>> Also no license link. Afaik all contribs are under GPL-2.

>> That's not entirely correct. The files in the licenses/ directory
>> aren't, and patches in packages' files/ dirs generally follow the
>> license of their upstream project.

> See, so it would help to have a doc that talks about the
> irregularities.

I agree, but such documentation doesn't belong in an ebuild repository,
but should be in a dedicated location like the Devmanual or the wiki.

Ulrich



Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Maciej Barć

Maybe the solution here is that developers who merge patches from
contributors should test the PR before merging.


Of source, of course they should! (thats how the bug was discovered in 
the case I recalled). It's all about communicating to the contributor 
the most important things that we expect in the PR --- if not, then 
whats the point of having the PR template?


W dniu 1.05.2024 o 17:15, Eli Schwartz pisze:

On 5/1/24 11:02 AM, Maciej Barć wrote:

Well, not really, there were many cases where pkg was broken on sandbox!
The latest example would be nim (before I updated it myself) where
contributor submitted broken pkg without telling anybody. It was a WIP
PR but nowhere they specified that it did not merge under sandbox. I
want to encourage contributors to outright say when they know/think
something might be wrong with package.


And adding another checkbox is going to stop people from submitting WIP
draft PRs without marking them as drafts?

Maybe the solution here is that developers who merge patches from
contributors should test the PR before merging. At least if you don't
have a preexisting relationship with the contributor such that you have
trust in the contributor to publish high quality ebuilds that pass basic
smoketests.

I mean, you probably want to do that anyway because if someone shows up
with their first ever PR and the change looks okay but has a broken
checksum it is awfully hard to tell without actually running it. I
certainly hope that if PRs are merged without being tested locally by
the developer doing the merge, that it's for proxied packages
contributed by the proxied maintainer, not packages where the Developer
that maintains the package is merging untested patches just because
someone suggested a change.

And if proxied maintainers make a habit of breaking their packages by
submitting WIP drafts maybe they aren't such great proxied maintainers
and there's a larger infrastructural problem going on.




--
Have a great day!

~ Maciej XGQT Barć

https://wiki.gentoo.org/wiki/User:Xgqt
9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Eli Schwartz
On 5/1/24 11:02 AM, Maciej Barć wrote:
> Well, not really, there were many cases where pkg was broken on sandbox!
> The latest example would be nim (before I updated it myself) where
> contributor submitted broken pkg without telling anybody. It was a WIP
> PR but nowhere they specified that it did not merge under sandbox. I
> want to encourage contributors to outright say when they know/think
> something might be wrong with package.

And adding another checkbox is going to stop people from submitting WIP
draft PRs without marking them as drafts?

Maybe the solution here is that developers who merge patches from
contributors should test the PR before merging. At least if you don't
have a preexisting relationship with the contributor such that you have
trust in the contributor to publish high quality ebuilds that pass basic
smoketests.

I mean, you probably want to do that anyway because if someone shows up
with their first ever PR and the change looks okay but has a broken
checksum it is awfully hard to tell without actually running it. I
certainly hope that if PRs are merged without being tested locally by
the developer doing the merge, that it's for proxied packages
contributed by the proxied maintainer, not packages where the Developer
that maintains the package is merging untested patches just because
someone suggested a change.

And if proxied maintainers make a habit of breaking their packages by
submitting WIP drafts maybe they aren't such great proxied maintainers
and there's a larger infrastructural problem going on.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Maciej Barć

Asking people to check 8 checkboxes is a bit much.


yea... I would pick 2. and 4. from that and put them in 1 point.
So it could be:
> [ ] I have tested that the package(s) merge inside both the user AND 
net sandbox without violations on a Gentoo-based system. also, if manual 
intervention (beyond "emerge PKG") is required to complete the 
install/update of the package(s) (and such functinality is or can not be 
done in pkg_configure/pkg_postinst/pkg_postrm) I have explained the 
steps needed to be taken in the PR and/or package ebuild(s).


(Eli,) The "[...] Gentoo Wiki" part was when we have one page for all 
knowledge about maintaining some grouped components, like for example 
new compiler porting or .NET pkg maintenance.


W dniu 1.05.2024 o 16:59, Michał Górny pisze:

On Wed, 2024-05-01 at 16:27 +0200, Maciej Barć wrote:

Maybe we could consider also adding something along the lines (4
additional positions):

1. I have emerged the package(s) on a Gentoo-based system (be it
"native" or virtualized by means of hardware-based virtualization or
system layer virtualization).
2. I have tested that the package(s) merge inside both the user and net
sandbox without violations on a Gentoo-based system.
3. I can assure that the packages would be able to be merged on the
currently default Gentoo profile (with or without modifications to USE
flags).
4. If manual intervention (beyond "emerge PKG") is required ro complete
the install/update of the package(s) I have explained the steps needed
to be taken in the PR and/or package ebuild(s) and/or Gentoo Wiki.



Asking people to check 8 checkboxes is a bit much.



--
Have a great day!

~ Maciej XGQT Barć

https://wiki.gentoo.org/wiki/User:Xgqt
9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Maciej Barć

 The files in the licenses/ directory
aren't, and patches in packages' files/ dirs generally follow the
license of their upstream project.


See, so it would help to have a doc that talks about the irregularities.

W dniu 1.05.2024 o 17:01, Ulrich Mueller pisze:

On Wed, 01 May 2024, Maciej Barć wrote:



Also no license link. Afaik all contribs are under GPL-2.


That's not entirely correct. The files in the licenses/ directory
aren't, and patches in packages' files/ dirs generally follow the
license of their upstream project.

Ulrich


--
Have a great day!

~ Maciej XGQT Barć

https://wiki.gentoo.org/wiki/User:Xgqt
9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Maciej Barć

It's not obvious to me these are necessary since the entire concept
behind submitting an ebuild update is to, well, install and use it. My
base assumption is that users submitting such an update have done so
because it solved a problem for them.

This covers 1, 2, and 3, unless the user has done some fairly heavily
nonstandard things or submits effectively untested spam which admittedly
might happen -- but the checkboxes don't seem the easiest way to solve this.


Well, not really, there were many cases where pkg was broken on sandbox! 
The latest example would be nim (before I updated it myself) where 
contributor submitted broken pkg without telling anybody. It was a WIP 
PR but nowhere they specified that it did not merge under sandbox. I 
want to encourage contributors to outright say when they know/think 
something might be wrong with package.


W dniu 1.05.2024 o 16:47, Eli Schwartz pisze:

On 5/1/24 10:27 AM, Maciej Barć wrote:

Maybe we could consider also adding something along the lines (4
additional positions):

1. I have emerged the package(s) on a Gentoo-based system (be it
"native" or virtualized by means of hardware-based virtualization or
system layer virtualization).
2. I have tested that the package(s) merge inside both the user and net
sandbox without violations on a Gentoo-based system.
3. I can assure that the packages would be able to be merged on the
currently default Gentoo profile (with or without modifications to USE
flags).
4. If manual intervention (beyond "emerge PKG") is required ro complete
the install/update of the package(s) I have explained the steps needed
to be taken in the PR and/or package ebuild(s) and/or Gentoo Wiki.



It's not obvious to me these are necessary since the entire concept
behind submitting an ebuild update is to, well, install and use it. My
base assumption is that users submitting such an update have done so
because it solved a problem for them.

This covers 1, 2, and 3, unless the user has done some fairly heavily
nonstandard things or submits effectively untested spam which admittedly
might happen -- but the checkboxes don't seem the easiest way to solve this.

4 seems semantically wrong since it's not the job of a PR to describe
what users should do to manually intervene to install a package, but
IMHO this is already covered by 3. The only interesting case I can
actually think of is where updating a package requires some sort of e.g.
database migration to run after updating and before the next use -- this
is the minority of packages and should be handled by a postinst message,
but could also be reviewed on a case by case basis...

It is *not* the job of a packager to ensure that the gentoo wiki
excellently describes how to use the software, as that's a different
skillset. I wouldn't want to discourage users from contributing code
because they aren't skilled documentarians.


The existing pull request template suggestion proposes to add checkboxes
for 3 types of requirements that aren't necessarily obvious to users who
had a problem, fixed it, and want to share the fix -- they are all about
complying with Gentoo policy.

Your 4 suggestions are all about requirements for fixing a problem and
successfully fixing it even as a local ebuild. We don't need to remind
people that the PR has to actually fix the problem.




--
Have a great day!

~ Maciej XGQT Barć

https://wiki.gentoo.org/wiki/User:Xgqt
9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Ulrich Mueller
> On Wed, 01 May 2024, Maciej Barć wrote:

> Also no license link. Afaik all contribs are under GPL-2.

That's not entirely correct. The files in the licenses/ directory
aren't, and patches in packages' files/ dirs generally follow the
license of their upstream project.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Michał Górny
On Wed, 2024-05-01 at 10:28 -0400, Ionen Wolkens wrote:
> On Wed, May 01, 2024 at 03:32:21PM +0200, Michał Górny wrote:
> > The idea is to increase awareness of the AI policy, as well as other
> > rules, and to inform users before they submit a PR.
> 
> Bit mixed feelings about this given checkboxes feel like unnecessary
> churn for routine contributors and is semi-redundant with the
> Signed-off-by.
> 
> I think it's great for first-time/occasional contributors though.

Yeah, that's why I tried to keep it relatively short.  We don't want
people clicking too much every single time.

> 
> Having a AI-specific checkbox does feel kind of overkill when it won't
> concern the majority of contributors, albeit given how how hard the whole
> thing is pushed lately and that we have no real way to verify beside the
> user being made aware of it and certifying it...

It's mostly a way of advertising the change.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Michał Górny
On Wed, 2024-05-01 at 16:27 +0200, Maciej Barć wrote:
> Maybe we could consider also adding something along the lines (4 
> additional positions):
> 
> 1. I have emerged the package(s) on a Gentoo-based system (be it 
> "native" or virtualized by means of hardware-based virtualization or 
> system layer virtualization).
> 2. I have tested that the package(s) merge inside both the user and net 
> sandbox without violations on a Gentoo-based system.
> 3. I can assure that the packages would be able to be merged on the 
> currently default Gentoo profile (with or without modifications to USE 
> flags).
> 4. If manual intervention (beyond "emerge PKG") is required ro complete 
> the install/update of the package(s) I have explained the steps needed 
> to be taken in the PR and/or package ebuild(s) and/or Gentoo Wiki.
> 

Asking people to check 8 checkboxes is a bit much.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Eli Schwartz
On 5/1/24 10:38 AM, Maciej Barć wrote:
> Ionen, I think that regular contributors could skip this altogether. For
> example the person I'm mentoring I am sure would follow all requirements
> listed by mgorny and me (see my reply).


Regular contributors might not even be submitting via PRs at all. :P


>> On a side-note, I have nothing against having .github in the tree. Just
>> saying given I know not everyone is happy with that.
> 
> I think we should push more into "conforming" to standard of online
> software forges. Reminder that we STILL do not have any form of a README
> file. Not even one that would say "Hey look at https://gentoo.org/;.
> Also no license link. Afaik all contribs are under GPL-2.


Every file has a copyright header:

# Distributed under the terms of the GNU General Public License v2


It's not clear to me what more you want than this, or who it would help.

A README could be useful to github I guess, but on the other hand the
main purpose of a README is to tell people who don't know what a
repository is for, what that repository is for. Would it basically
duplicate the contents of https://wiki.gentoo.org/wiki/Ebuild_repository
or is there something else you want to see in a README?

I don't think "Hey look at https://gentoo.org; is remotely useful as a
README, compared to what is already there:

[MIRROR] Official Gentoo ebuild repository
https://gitweb.gentoo.org/repo/gentoo.git

which is already quite explanatory in ways that a noncommittal link to
the gentoo homepage is NOT.

-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Eli Schwartz
On 5/1/24 10:27 AM, Maciej Barć wrote:
> Maybe we could consider also adding something along the lines (4
> additional positions):
> 
> 1. I have emerged the package(s) on a Gentoo-based system (be it
> "native" or virtualized by means of hardware-based virtualization or
> system layer virtualization).
> 2. I have tested that the package(s) merge inside both the user and net
> sandbox without violations on a Gentoo-based system.
> 3. I can assure that the packages would be able to be merged on the
> currently default Gentoo profile (with or without modifications to USE
> flags).
> 4. If manual intervention (beyond "emerge PKG") is required ro complete
> the install/update of the package(s) I have explained the steps needed
> to be taken in the PR and/or package ebuild(s) and/or Gentoo Wiki.


It's not obvious to me these are necessary since the entire concept
behind submitting an ebuild update is to, well, install and use it. My
base assumption is that users submitting such an update have done so
because it solved a problem for them.

This covers 1, 2, and 3, unless the user has done some fairly heavily
nonstandard things or submits effectively untested spam which admittedly
might happen -- but the checkboxes don't seem the easiest way to solve this.

4 seems semantically wrong since it's not the job of a PR to describe
what users should do to manually intervene to install a package, but
IMHO this is already covered by 3. The only interesting case I can
actually think of is where updating a package requires some sort of e.g.
database migration to run after updating and before the next use -- this
is the minority of packages and should be handled by a postinst message,
but could also be reviewed on a case by case basis...

It is *not* the job of a packager to ensure that the gentoo wiki
excellently describes how to use the software, as that's a different
skillset. I wouldn't want to discourage users from contributing code
because they aren't skilled documentarians.


The existing pull request template suggestion proposes to add checkboxes
for 3 types of requirements that aren't necessarily obvious to users who
had a problem, fixed it, and want to share the fix -- they are all about
complying with Gentoo policy.

Your 4 suggestions are all about requirements for fixing a problem and
successfully fixing it even as a local ebuild. We don't need to remind
people that the PR has to actually fix the problem.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Maciej Barć
Ionen, I think that regular contributors could skip this altogether. For 
example the person I'm mentoring I am sure would follow all requirements 
listed by mgorny and me (see my reply).



On a side-note, I have nothing against having .github in the tree. Just
saying given I know not everyone is happy with that.


I think we should push more into "conforming" to standard of online 
software forges. Reminder that we STILL do not have any form of a README 
file. Not even one that would say "Hey look at https://gentoo.org/;. 
Also no license link. Afaik all contribs are under GPL-2.


W dniu 1.05.2024 o 16:28, Ionen Wolkens pisze:

On Wed, May 01, 2024 at 03:32:21PM +0200, Michał Górny wrote:

The idea is to increase awareness of the AI policy, as well as other
rules, and to inform users before they submit a PR.


Bit mixed feelings about this given checkboxes feel like unnecessary
churn for routine contributors and is semi-redundant with the
Signed-off-by.

I think it's great for first-time/occasional contributors though.

Having a AI-specific checkbox does feel kind of overkill when it won't
concern the majority of contributors, albeit given how how hard the whole
thing is pushed lately and that we have no real way to verify beside the
user being made aware of it and certifying it...

On a side-note, I have nothing against having .github in the tree. Just
saying given I know not everyone is happy with that.


--
Have a great day!

~ Maciej XGQT Barć

https://wiki.gentoo.org/wiki/User:Xgqt
9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Ionen Wolkens
On Wed, May 01, 2024 at 03:32:21PM +0200, Michał Górny wrote:
> The idea is to increase awareness of the AI policy, as well as other
> rules, and to inform users before they submit a PR.

Bit mixed feelings about this given checkboxes feel like unnecessary
churn for routine contributors and is semi-redundant with the
Signed-off-by.

I think it's great for first-time/occasional contributors though.

Having a AI-specific checkbox does feel kind of overkill when it won't
concern the majority of contributors, albeit given how how hard the whole
thing is pushed lately and that we have no real way to verify beside the
user being made aware of it and certifying it...

On a side-note, I have nothing against having .github in the tree. Just
saying given I know not everyone is happy with that.
-- 
ionen


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] .github: Add pull request template

2024-05-01 Thread Maciej Barć
Maybe we could consider also adding something along the lines (4 
additional positions):


1. I have emerged the package(s) on a Gentoo-based system (be it 
"native" or virtualized by means of hardware-based virtualization or 
system layer virtualization).
2. I have tested that the package(s) merge inside both the user and net 
sandbox without violations on a Gentoo-based system.
3. I can assure that the packages would be able to be merged on the 
currently default Gentoo profile (with or without modifications to USE 
flags).
4. If manual intervention (beyond "emerge PKG") is required ro complete 
the install/update of the package(s) I have explained the steps needed 
to be taken in the PR and/or package ebuild(s) and/or Gentoo Wiki.


W dniu 1.05.2024 o 15:32, Michał Górny pisze:

Signed-off-by: Michał Górny 
---
  .github/pull_request_template.md | 12 
  1 file changed, 12 insertions(+)
  create mode 100644 .github/pull_request_template.md

The idea is to increase awareness of the AI policy, as well as other
rules, and to inform users before they submit a PR.

Screenshots @ https://github.com/gentoo/gentoo/pull/36503


diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
new file mode 100644
index ..9e6fe061db11
--- /dev/null
+++ b/.github/pull_request_template.md
@@ -0,0 +1,12 @@
+
+
+---
+
+Please check all the boxes that apply:
+
+- [ ] I can submit this contribution in agreement with the [Copyright 
Policy](https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin).
+- [ ] This contribution has not been created with the assistance of Natural 
Language Processing artificial intelligence tools, in accordance with [AI 
policy](https://wiki.gentoo.org/wiki/Project:Council/AI_policy).
+- [ ] I have certified the above via adding a `Signed-off-by` line to *every* 
commit in the pull request.
+- [ ] I have run `pkgcheck scan --commits --net` to check for issues with my 
commits.
+
+Please note that all boxes must be checked for the pull request to be merged.


--
Have a great day!

~ Maciej XGQT Barć

https://wiki.gentoo.org/wiki/User:Xgqt
9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature