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
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 infor
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
documente
> 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
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 expec
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
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 (beyo
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ć w
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 s
> 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
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 checkboxe
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
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.
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 virtualizati
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
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
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
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.
Scre
18 matches
Mail list logo
