I'd like to propose a new metadata XML element for packages:

<non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to packages
that you do not maintain without prior consultation of the maintainer. I
would expect people to use their common sense to decide if a change may
require maintainer attention or not. In general, it is always a good
idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion that
the maintainer is opposed to non-maintainer commits. It just means that
the maintainer's stance is not known. I do not believe that we need a <non-maintainer-commits-disallowed/> flag, but if the need arises, we
could always consider adding one. Although, in my experience, people
mostly like to communicate the "non-maintainer commits welcome" policy
with others.

WDYT?

- Flow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

     <non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to
packages
that you do not maintain without prior consultation of the maintainer.
I
would expect people to use their common sense to decide if a change
may
require maintainer attention or not. In general, it is always a good
idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion
that
the maintainer is opposed to non-maintainer commits. It just means
that
the maintainer's stance is not known. I do not believe that we need a <non-maintainer-commits-disallowed/> flag, but if the need arises, we
could always consider adding one. Although, in my experience, people
mostly like to communicate the "non-maintainer commits welcome" policy
with others.

WDYT?

- Flow

Ultimately, all these things really matter when only the defaults
change. Turn-right-on-red in the US is such a thing, because unless
otherwise stated, it's the norm. Knowing our devbase, with roughly 75%
mostly AWOL and barely reading the MLs, I don't think this idea will
bring about the desired change. Instead, we should really just go for
the <non-maintainer-commits-disallowed/> tag, because my feeling is that
the default will be that most maintainers don't mind non-maintainer
commits, except a select few territorial ones.

David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5 Jul 2022, at 00:49, Rich Freeman <rich0@gentoo.org> wrote:

On Mon, Jul 4, 2022 at 7:21 PM Robin H. Johnson <robbat2@gentoo.org> wrote:

It had 3 states however:
a) go ahead and touch it, no additional approvals needed
b) please get a maintainer to approve it
c) do not touch it

++

Though to be fair b is really no different from what just about
anybody can do via a pull request. I don't think most maintainers are
going to be hovering between a vs c. I suspect most are going to be
divided between a vs b. I guess I could see an argument for c if some package is really finicky and tends to get a lot of repetitive
requests for changes that won't work for reasons that might not be
obvious, but I'm not sure if that is really a concern.

Right. Difference between b and c might make more sense if c became "run it by another developer as a sanity-check" (who is not necessarily a maintainer of the package, or obviously there's pretty much no point).

--
Rich

Best,
sam

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCYsN+DV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kKzcAQD4iqVqcjW0WHa5pDUxRVqpjGVEenA3+Ar2AgcsSVLbYAD/XgbYqCRUiGrc fBE8zBmH7ifrrr1Vmglnx38MQolPKQ4=
=ZGRX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 04, 2022 at 05:27:03PM +0200, David Seifert wrote:

On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

     <non-maintainer-commits-welcome/>

...

Ultimately, all these things really matter when only the defaults
change. Turn-right-on-red in the US is such a thing, because unless
otherwise stated, it's the norm. Knowing our devbase, with roughly 75%
mostly AWOL and barely reading the MLs, I don't think this idea will
bring about the desired change. Instead, we should really just go for
the <non-maintainer-commits-disallowed/> tag, because my feeling is that
the default will be that most maintainers don't mind non-maintainer
commits, except a select few territorial ones.

I had a rough draft similar proposal to this before that was never
completed into GLEP.

It had 3 states however:
a) go ahead and touch it, no additional approvals needed
b) please get a maintainer to approve it
c) do not touch it

With b) being the proposed default as status-quo at the time.

That however was years ago, and I'll entirely agree that the devbase
isn't as watchful anymore.

With that said, I stand behind the intent of making the default a), with
a migration period.

Something like this for the migration period:
July 1 to Sep 30: default is still b), to allow developers time to update
their metadata.
Oct 1 onwards: default becomes a)


--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it.

iQKTBAABCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAmLDdf5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsTXFA//RkK2ywiuEJkXE1cy/Fcf8FIwmcVU7Nb93Ij3oHqsURxoqnOaxGk17Yr9 1P7atogb3FLNZ1/VSrEwTAOrlRme0uNdRwNGX3A7nL7abDawxJ38gH+RHrtD3Yzw 4CszwFSZOyjRnlweK7uqsBa5GGxDbjds3gDW63bgEVxbp7DlPL1V3T3d0guEk4v/ 7yP0kDSkWDF4gM/YBYUGhaHzjVB5xWyEnUaoCcRL/S4g06BY9P7uy2tMy3KDnor+ ej1SxH9LCM1D1iTefaCnGFLOkYSjIeIJlSg8YHsj8sDbzXG8wefCMPKrhtPFjDuw 4wm5xXo/lRtGzRlXMMSdZ9fsYivDZbjP+jJSIpACgNxFjT+ZoqMBjwATSz4roVeJ WlHehh8gAVTZ6CQ1O3cI

On Mon, Jul 4, 2022 at 7:21 PM Robin H. Johnson <robbat2@gentoo.org> wrote:

It had 3 states however:
a) go ahead and touch it, no additional approvals needed
b) please get a maintainer to approve it
c) do not touch it

++

Though to be fair b is really no different from what just about
anybody can do via a pull request. I don't think most maintainers are
going to be hovering between a vs c. I suspect most are going to be
divided between a vs b. I guess I could see an argument for c if some
package is really finicky and tends to get a lot of repetitive
requests for changes that won't work for reasons that might not be
obvious, but I'm not sure if that is really a concern.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

<non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to packages
that you do not maintain without prior consultation of the maintainer. I would expect people to use their common sense to decide if a change may require maintainer attention or not. In general, it is always a good
idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion that
the maintainer is opposed to non-maintainer commits. It just means that
the maintainer's stance is not known. I do not believe that we need a <non-maintainer-commits-disallowed/> flag, but if the need arises, we
could always consider adding one. Although, in my experience, people
mostly like to communicate the "non-maintainer commits welcome" policy
with others.

WDYT?

Personally I think something per-maintainer rather than per package
would be simpler, and allow to say more as needed.

Think like devaway instructions, but something more permanent and
not for being away, e.g.
"feel free to touch my packages except this big important one, and
or do or do not do this to them"

- Flow

--
ionen

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmLDprQACgkQskQGsLCs QzQdxQf+JbmMyoP8UqSMraHg//VjqaVB6ficQcl22JIO8eRb2YG2yoHzUsUKbPnQ q7Po8CTaEnZvzjZrfGbCiMvNuSDWnIVk2P8Yi3g1un0SX1o5Zm1ULGDLFU09SoAC YaX6rRCZghPWfvBGlRF2APOhnRnaGouw++j/qYqYDhlE8tIiTIaFRZMt0ZEzZLjE aGN1bbDXTa9Ud8THXqsiStW0ug/Ax2gukeq0Hm+nywGpehiHwl3WeRXDNU0Xg9JK uSUgvzWb6mLtqB5AvucYP8lCquFwuu/rLd/hkx9t3mTTlTYUkSqFrIH44E5WtFk6 +L9cli6+7UDfjjc02Ku1L65O865biA==
=fiTD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 04, 2022 at 10:49:25PM -0400, Ionen Wolkens wrote:

On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

<non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to packages that you do not maintain without prior consultation of the maintainer. I would expect people to use their common sense to decide if a change may require maintainer attention or not. In general, it is always a good
idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion that the maintainer is opposed to non-maintainer commits. It just means that the maintainer's stance is not known. I do not believe that we need a <non-maintainer-commits-disallowed/> flag, but if the need arises, we could always consider adding one. Although, in my experience, people mostly like to communicate the "non-maintainer commits welcome" policy with others.

WDYT?

Personally I think something per-maintainer rather than per package
would be simpler, and allow to say more as needed.

... and that could also extend to projects so can clarify policy in
a single place that's easy to find.

Like base-system@ probably do not want random uninformed commits,
but games@, sound@, and such?

Think like devaway instructions, but something more permanent and
not for being away, e.g.
"feel free to touch my packages except this big important one, and
or do or do not do this to them"

- Flow

--
ionen

--
ionen

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmLDp7QACgkQskQGsLCs QzTV1Af+LTuWmOUBJ6q4KQBzvn7d2Vbs/qmZtl1eg2+g1xg8IzkfowLsRsfrKZjv AQgOxB/rtx35If0iRDp2q0GrPr4Fl6IdNKPfgg+4vSTLPCS9V8QKi2Ff8axWU37G JpasON/34QVhv6wwBYj+iD5YIy8LWHPKQBD3CMa0bkwXzMQ30arf8VeToEuD7U7n GkXDiv88poTMtPgOyksqErqzOMHOGdmnfIl8u22MbZjr1J4E/qgVsw0DlJ7DonNJ l+nRpWigQ3UtNb8eFoCSeLdw/0XKdJh9zpgeVauDyU0UVFT/jCzb5C3ZIBym2s+Z tTeMCCl3pyRkCvGspK4UwlbPco4Gjw==
=pu82
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5 Jul 2022, at 03:49, Ionen Wolkens <ionen@gentoo.org> wrote:

On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

<non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to packages
that you do not maintain without prior consultation of the maintainer. I
would expect people to use their common sense to decide if a change may
require maintainer attention or not. In general, it is always a good
idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion that
the maintainer is opposed to non-maintainer commits. It just means that
the maintainer's stance is not known. I do not believe that we need a
<non-maintainer-commits-disallowed/> flag, but if the need arises, we
could always consider adding one. Although, in my experience, people
mostly like to communicate the "non-maintainer commits welcome" policy
with others.

WDYT?

Personally I think something per-maintainer rather than per package
would be simpler, and allow to say more as needed.

Think like devaway instructions, but something more permanent and
not for being away, e.g.
"feel free to touch my packages except this big important one, and
or do or do not do this to them"

On this, some prior art from zx2c4: https://marc.info/?l=gentoo-dev&m=147816820903115&w=2).

Best,
sam

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCYsOwj18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kA+EAP9Yx4MYZ4aPSv2LQ40g6ad60lc34ggQr7BJ+7+c/sB/SAEAm5VKwlQRzROu 0/Z96X5v29Hku7cHaxePE6V9WdDo3g0=
=/wkB
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5 Jul 2022, at 04:24, Ionen Wolkens <ionen@gentoo.org> wrote:

On Mon, Jul 04, 2022 at 10:53:41PM -0400, Ionen Wolkens wrote:

On Mon, Jul 04, 2022 at 10:49:25PM -0400, Ionen Wolkens wrote:

On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

<non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors >>>> in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to packages >>>> that you do not maintain without prior consultation of the maintainer. I >>>> would expect people to use their common sense to decide if a change may >>>> require maintainer attention or not. In general, it is always a good
idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion that >>>> the maintainer is opposed to non-maintainer commits. It just means that >>>> the maintainer's stance is not known. I do not believe that we need a
<non-maintainer-commits-disallowed/> flag, but if the need arises, we
could always consider adding one. Although, in my experience, people
mostly like to communicate the "non-maintainer commits welcome" policy >>>> with others.

WDYT?

Personally I think something per-maintainer rather than per package
would be simpler, and allow to say more as needed.

... and that could also extend to projects so can clarify policy in
a single place that's easy to find.

Like base-system@ probably do not want random uninformed commits,
but games@, sound@, and such?

Also, for projects, presenting it more as exception rules makes sense. Especially for all these semi-random understaffed projects, there's
really a handful that would have some "do nots".

Think like devaway instructions, but something more permanent and
not for being away, e.g.
"feel free to touch my packages except this big important one, and
or do or do not do this to them"

-'or do' :eyes:

To add more as an example, personally I don't mind non-maintainer commits
but don't particularly want people to start full on bumping my packages
when I /do/ intend to handle them in a timely fashion and probably had
plans for them, perhaps even already a local WIP ebuild and such. So
I'd likely have something along these lines. A simple tag feels like a
bit too "free for all".

You've nailed something I was wondering about but couldn't
really articulate.

The only time I really care/don't want someone to do it:
- a package genuinely is snowflakey (which is the exception), like it's somehow fragile
- the situation is as you described

Almost makes one wonder about per-package notes again, although
it wouldn't fix the issue wrt projects.

Best,
sam

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCYsOvwF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kC2uAQD+j1wBYrw/WQ6atWW9QB+Ujx45yoRdHzT/WwQFqwNEyAD8DRFJFi2FRrBD zEpLYTUtbPkypBmpQFwVPI3baZB+hws=
=24Ub
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 04, 2022 at 10:53:41PM -0400, Ionen Wolkens wrote:

On Mon, Jul 04, 2022 at 10:49:25PM -0400, Ionen Wolkens wrote:

On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

<non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors in general) that they are happy with others to make changes to the ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to packages that you do not maintain without prior consultation of the maintainer. I would expect people to use their common sense to decide if a change may require maintainer attention or not. In general, it is always a good idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion that the maintainer is opposed to non-maintainer commits. It just means that the maintainer's stance is not known. I do not believe that we need a <non-maintainer-commits-disallowed/> flag, but if the need arises, we could always consider adding one. Although, in my experience, people mostly like to communicate the "non-maintainer commits welcome" policy with others.

WDYT?

Personally I think something per-maintainer rather than per package
would be simpler, and allow to say more as needed.

... and that could also extend to projects so can clarify policy in
a single place that's easy to find.

Like base-system@ probably do not want random uninformed commits,
but games@, sound@, and such?

Also, for projects, presenting it more as exception rules makes sense. Especially for all these semi-random understaffed projects, there's
really a handful that would have some "do nots".

Think like devaway instructions, but something more permanent and
not for being away, e.g.
"feel free to touch my packages except this big important one, and
or do or do not do this to them"

-'or do' :eyes:

To add more as an example, personally I don't mind non-maintainer commits
but don't particularly want people to start full on bumping my packages
when I /do/ intend to handle them in a timely fashion and probably had
plans for them, perhaps even already a local WIP ebuild and such. So
I'd likely have something along these lines. A simple tag feels like a
bit too "free for all".

On a related note, perhaps QA team could even be allowed to give
instructions themselves when a maintainer is generally unresponsive
and is giving no instructions to go with that.

- Flow

--
ionen

--
ionen

--
ionen

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmLDruwACgkQskQGsLCs QzQkewgAhDdJu7gLnQfDvawhPS9plcinJ5XXQl/L5dDWjliGgtQEiNYYmNyNTZMP 29BBPwE+A849VA1/Y+zkGhSAAtbJvGzRxEDuRYs9IpFnazovH3Af5zlkrkl1IkaG wY2NweB/9Ziv8oSnjryaKXZbNQPRdHCPUzpl1pge1HCKoiZVhls0PJJcIhVK8CdW oYeVUXkwv9BPPKquaaXQ72faTCW2kIsnlsGsKklv0BePtGOi/VuRkfSKy02yAsCF K3hvNaNCS+8db5y3gFUUoXtIkXjT1uBOtMYgGlbqDEH4GztfxKPZGto5ZqL3omZS DzG9UxI8LDiYB7RbwqHbjQhFWNMswg==
=J68S
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 4 Jul 2022 22:49:25 -0400
Ionen Wolkens <ionen@gentoo.org> wrote:

On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

<non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to packages that you do not maintain without prior consultation of the maintainer. I would expect people to use their common sense to decide if a change may require maintainer attention or not. In general, it is always a good
idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion that the maintainer is opposed to non-maintainer commits. It just means that
the maintainer's stance is not known. I do not believe that we need a <non-maintainer-commits-disallowed/> flag, but if the need arises, we
could always consider adding one. Although, in my experience, people
mostly like to communicate the "non-maintainer commits welcome" policy
with others.

WDYT?

Personally I think something per-maintainer rather than per package
would be simpler, and allow to say more as needed.

Think like devaway instructions, but something more permanent and
not for being away, e.g.
"feel free to touch my packages except this big important one, and
or do or do not do this to them"

I think it would be more efficient if we use a flag on a per-maintainer
basis. But it adds extra overhead, if the maintainer doesn't want some
special packages to be touched, or if special cases, like bumps need to
be avoided.

We could add a central file, something like the metadata/AUTHORS file
with this information. Possibly in a structured format like xml or json
to make it machine readable as well and the information can be
extracted and shown e.g. on the wiki or p.g.o site.

Something like the devaway
instructions could lock out proxy maintainers, which don't have access
to the Gentoo infrastructure.

- Flow

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRR1RCQUVCQ2dCOUZpRUV4SWczK0Vtazcw bnFBUTJ5YmI0SzFVbzdNY1lGQW1KT3ZEQmZGSUFBQUFBQUxnQW8KYVhOemRXVnlMV1p3Y2tCdWIz UmhkR2x2Ym5NdWIzQmxibkJuY0M1bWFXWjBhR2h2Y25ObGJXRnVMbTVsZEVNMApPRGd6TjBZNE5E bEJORVZHTkRsRlFUQXhNRVJDTWpaRVFrVXdRVVExTkVFelFqTXhRellBQ2drUWJiNEsxVW83Ck1j YnlqZ2dBNDB1bjVNclA4RHl5Vm1KWFJVVFNyeE5IYkNGY2svN3ZDUkh1SGZ5bmMyYkNGWWszSnF2 ZkZjdTMKRDVtczdzSCszWkJ4R2dVdENHN0x3V09RWjg5cFNrUUZYUEN1KzRQYjBMbFZnejZ4K2xG eUdOWGRUMWc0UnlYdQoxVHpxUWxvazVnT21seEorYUsrQzZDbXpON2UrME1mZThsR0hWTGZjdWt6 amxDZ2xvY2hhdklYdWlHN0tOaVRCCjRyVVNlVkxKNk9hTGtlcVlRNEVZcmhVOGdraUE4bnNINFRx WFd4bUI2Y0ZoZnkwZTF3T0dsa0szMVE5am1tWnAKUjRxcFJGMlF3SDdDQUtsSVc5VFQ4Zlowa3cw NlVWb0dvc204bHhNQTJ3UTJXeWNUblBwN2tiUmFUdmRFTkVxYgpVZ2dDRjdoaDJnN1k2TFNoMzNm Mmw2VE5seEgwdEE9PQo9RzRLRwotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04/07/2022 17.27, David Seifert wrote:

Ultimately, all these things really matter when only the defaults
change. Turn-right-on-red in the US is such a thing, because unless
otherwise stated, it's the norm. Knowing our devbase, with roughly 75%
mostly AWOL and barely reading the MLs, I don't think this idea will
bring about the desired change.

This sounds like you assume that the majority of Gentoo devs are OK with
other people making changes to their packages. This very well could be
true, but without an indication you never know if the maintainer feels
this way.

Instead, we should really just go for
the <non-maintainer-commits-disallowed/> tag, because my feeling is that
the default will be that most maintainers don't mind non-maintainer
commits, except a select few territorial ones.

It appears that we have at least two options here:

A) Establish that the default is non-maintainer-commits-welcome, and
introduce a <non-maintainer-commits-disallowed/> metadata element.

B) Declare the default to be unspecified and introduce two metadata
elements: <non-maintainer-commits-welcome/> and <non-maintainer-commits-disallowed/>.

I think you are proposing A) here, but please correct me if I am wrong.

Personally I would tend to B). But I have no strong opinion on this, as
long as some kind of signalling is established.

How do others feel about this?

- Flow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

     <non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

I don't think adding such an element is a good idea. In my opinion,
this will strengthen the assumption that "unless otherwise noted, you
don't dare touch anything" (even though that's not your goal). "Common
sense" should really be good enough for almost everything.

I mean, I do realize that 10 years ago, in the golden years of Gentoo,
it was considered normal for developers to be like "my package, my
fortress, don't you dare add systemd unit or I will retire" but today I
think we're aiming for a more welcoming developer base, and I think
we're actually going in that direction. What I'm afraid is that some
people will use this as an excuse to push back once again.

Can you really think of a case when common sense really, really wouldn't
work? I mean, sure, we all make mistakes but we should be able to learn
from them and do better next time. This also implies package
maintainers learning that they're not the only people who will ever
touch the package in question and starting to document the pitfalls.

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 6, 2022 at 8:42 AM Florian Schmaus <flow@gentoo.org> wrote:

It appears that we have at least two options here:

A) Establish that the default is non-maintainer-commits-welcome, and introduce a <non-maintainer-commits-disallowed/> metadata element.

B) Declare the default to be unspecified and introduce two metadata
elements: <non-maintainer-commits-welcome/> and <non-maintainer-commits-disallowed/>.

I think you are proposing A) here, but please correct me if I am wrong.

Personally I would tend to B). But I have no strong opinion on this, as
long as some kind of signalling is established.

How do others feel about this?

What about <non-maintainer-commits-welcome-but-talk-to-me-first/>? I
guess that is what we're calling "disallowed" but that seems to have a connotation that devs don't want contributions, when they just want to
be aware of what is going into their packages before it happens.

Deferring maintenance to bumps is the one use case that came up in the
thread that seems likely to be pretty common.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06-07-2022 15:50:30 +0200, Michał Górny wrote:

On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

     <non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

I don't think adding such an element is a good idea. In my opinion,
this will strengthen the assumption that "unless otherwise noted, you
don't dare touch anything" (even though that's not your goal). "Common sense" should really be good enough for almost everything.

Right, "common sense". The problem with that one, is that "common" is
not as "common" as you think it is. Ask a bunch of people, and you'll
find that what they consider "common" isn't the same.

So, if you do this, then please define clearly what you think is OK.
For example for me:

- feel free to add patches necessary for operation
- feel free to fix constructs (like an if or case that should apply for
something else/different/mode)
- feel free to fix typos
- please do not needlessly change style: if you do not "maintain" the
ebuild, respect the style of the maintainer, so only add the changes
you need, keep it minimal, respect the original even though you don't
like it (and don't use QA as an excuse to change style)
- when you make a change, make sure you check for bugs in the following
days, so you can cleanup yourself should there be fallout

I mean, I do realize that 10 years ago, in the golden years of Gentoo,
it was considered normal for developers to be like "my package, my
fortress, don't you dare add systemd unit or I will retire" but today I
think we're aiming for a more welcoming developer base, and I think
we're actually going in that direction. What I'm afraid is that some
people will use this as an excuse to push back once again.

Not sure I have the same memories of how it used to be 10 years ago. I actually think it is pretty much the same as it is now, as it was then. Different and fewer people, but still different
preferences/opinions/common sense.

Can you really think of a case when common sense really, really wouldn't work? I mean, sure, we all make mistakes but we should be able to learn
from them and do better next time. This also implies package
maintainers learning that they're not the only people who will ever
touch the package in question and starting to document the pitfalls.

Honestly, I've never been a fan of "maintainership". It basically is
some sort of "sign" that says "beware for the dog, stay away". However,
it's true that sometimes people really delve into a package, and thereby
know very much how it works, and what you should/should not do.
Something like LLVM is a good example, maybe. Anyway, in such
situation, I think extreme care should be taken by non-maintainers.
Dunno how to best indicate that, and/or if that's feasible -- like you
said, it quickly ends up being an excuse for declaring a package to be off-limits.

Fabian

--
Fabian Groffen
Gentoo on a different level

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEELUvHd/Gtp7LaU1vuzpXahU5EQpMFAmLFpGEACgkQzpXahU5E QpOUOQgAnPy1qUArTIGEINCg0rvQSxDhUwOsn2UOvMNZ37f4ODJJgSHNUzwlbyzJ 8+3O5fb6PHQf2vGaRrR3fdgsj9Ii4myjbH+WCoUoW6HjNRIhp5jU155N5D1yjszr Z9vxT+NH3d5dO+rjVZhwd7xLRUPmvJoUl/GJ9l/nhRKvETJDfExQHt1DfHnDoXa5 q+8hAJ0XENBkQMnbj637tWQfnuviOnAAQYrBrk1Rb/YdOHI9gBTaJsMNC0egVT7u V7wPp+dshcqvex6cakDMyvFYUmvBF1zCIP6EZZI9vkAqu9eMlWCqv3sb7dmJvicz N7Buna11ko5MF9wHRWDpL5ZLt5qYAw==
=gWBg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/4/22 16:19, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

    <non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

Of course, this is not a free ticket to always make changes to packages
that you do not maintain without prior consultation of the maintainer. I would expect people to use their common sense to decide if a change may require maintainer attention or not. In general, it is always a good
idea to communicate changes in every case.

The absence of the flag does not automatically allow the conclusion that
the maintainer is opposed to non-maintainer commits. It just means that
the maintainer's stance is not known. I do not believe that we need a <non-maintainer-commits-disallowed/> flag, but if the need arises, we
could always consider adding one. Although, in my experience, people
mostly like to communicate the "non-maintainer commits welcome" policy
with others.

I worry that this might send wrong signal. My understanding is that just
like any OSS also Gentoo struggles with attracting new contributors and
telling anybody "hey, your contribution is not welcome" does not help.

I think that rejecting a contribution (regardless of the flag) should be
based on technical merit, rather than individual maintainers personal preferences. I do understand some packages are like your babies, you
watch them grow, fine tune everything. But in the end, if somebody finds
a bug in the ebuild/eclass/... and is even willing to provide a fix, we
should have a discussion about the proposed fix rather than refer to a
flag (or lack of thereof) when closing the MR (unmerged).

Michal

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------5XmAtcXZJ71hqIupaHBEpKns
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7/6/22 18:04, Fabian Groffen wrote:

- please do not needlessly change style: if you do not "maintain" the
ebuild, respect the style of the maintainer, so only add the changes
you need, keep it minimal, respect the original even though you don't
like it (and don't use QA as an excuse to change style)

QA actually states to honor the maintainer's style as much as possible, https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html "Respect developers' coding preferences. Unnecessarily changing the
syntax of an ebuild can cause complications for others. Syntax changes
should only be done if there is a real benefit, such as faster
compilation, improved information for the end user, or compliance with
Gentoo policies. "

Of course there are some "strict" rules, but very much is left to the maintainer. https://projects.gentoo.org/qa/policy-guide/ebuild-format.html#pg0101

- when you make a change, make sure you check for bugs in the following
days, so you can cleanup yourself should there be fallout

ago does a good job CCing the commit author too in his bug reports, if
the person is not the maintainer. This only applies to tinderbox bugs
though. Obviously you should manually CC the author if you see the bug
coming from their commit.

-- juippis


--------------5XmAtcXZJ71hqIupaHBEpKns--

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEltRJ9L6XRmDQCngHc4OUK43AaWIFAmLGkMJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 RDQ0OUY0QkU5NzQ2NjBEMDBBNzgwNzczODM5NDJCOERDMDY5NjIACgkQc4OUK43A aWINggf/X5x5c2Hd+SZnHvSDCh7JBk+pNNznFbqI2HOaAesmPQQFRaArTkLEo7hE mq/TH2nQLKbJJyNhPWL2rizHkUi+3xvsssMqC3Bs+LM8jzPqpL0+N/XIC5FrTzgF qeuDLE88ijum7ZmCUqXj3+UyLz32yYOvmT8LREVZPr0DQnEacNbytiKbL/xhej6j YJnN62G7zVY7iJYaXADMkuYyCIgM1gvaeJ+QnR9MwZoFAwzhghAVUMnngirzkicg f+yFFTerCJ6zbhT7vw5niQeIT4dMfeNDI4xM9oqN9WnKafPNasqob3TSnJM2/b5j WzRlduFs2y19RWIbPzI3+NjM6MYhSw==
=SFVo
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi All,

On 2022/07/06 15:50, Michał Górny wrote:

On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:

I'd like to propose a new metadata XML element for packages:

     <non-maintainer-commits-welcome/>

Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.

I don't think adding such an element is a good idea. In my opinion,
this will strengthen the assumption that "unless otherwise noted, you
don't dare touch anything" (even though that's not your goal). "Common sense" should really be good enough for almost everything.

I agree, but also note that what I consider to be "common sense" isn't
always "your common sense".

I also agree that having some way to indicate the preference on the
specific package may be a good thing.  With various possible levels of sensitivity.

For example, net-misc/asterisk and net-libs/pjproject is very sensitive
for me.  net-misc/dahdi{,-tools} and x11-wm/evilwm less so.  In all
cases I'd still prefer to be kept in the loop at a minimum.

As such, it looks like there is multiple options, and there are
suggestions for various tags, this is a sensible way to indicate
preference.  Eg, also, what kind of fixes don't require communication,
eg, I've seen drive-by's on the above packages to fix dependencies based
on slots because depended on packages changed their structure, or
because LUA became slotted, or adding := etc ...  This makes sense to
allow these, but if you're going to mess with my ./configure on asterisk
or pjproject without consulting with me I'm going to be upset.  A simple
code fix to fix some compile error (specific to say llvm), probably
fine, but I'd still appreciate communication as I'd like to submit that upstream kind of thing as well.

If this does go live, then there should be a single tag where the value indicates the level of "sensitivity", or multiple tags of which only one
is allowed.  Since some of these options may be orthogonal to each
other, a single tag with multiple attributes may be more appropriate, I
don't know, nor do I personally care that much, so far I've been
respected, and the drive-by's that has been made were all either part of
global fixes, or in the one or two cases where it was specific, was put
into the tree as ~ so were all just fine.  In one particular case it was
also masked specifically because the change depended on another change
to happen simultaneously/close together (lua slotting) - the experience
of which was most refreshing.  Obviously nothing is set in stone w.r.t. specifics, but if the initial course is at least somewhat in the right direction it's easier to course-correct.

I thus have no strong opinion one way or the other, but just wanted to
state the above.


Kind Regards,
Jaco

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07.07.22 09:45, Michal Prívozník wrote:

I think that rejecting a contribution (regardless of the flag) should be based on technical merit, rather than individual maintainers personal preferences. I do understand some packages are like your babies, you
watch them grow, fine tune everything. But in the end, if somebody finds
a bug in the ebuild/eclass/... and is even willing to provide a fix, we should have a discussion about the proposed fix rather than refer to a
flag (or lack of thereof) when closing the MR (unmerged).

It was never the intention to create a scenario where maintainers reject
a contribution based on such a flag. Gentoo, being free and open source software, if fully aligned with the spirit of FOSS, which *everyone* can
use, study, share and *improve*.

With the replies in mind, I gave this some more thought. I think the
best default is "everyone can propose changes to the maintainer, on
which the maintainer has to act within a reasonable amount of time".

However, there are maybe cases where trivial fixes for low-maintenance
packages are for some reason not merged into ::gentoo and the maintainer
is unresponsive. If those packages where flagged with <non-maintainer-commits-welcome/>, then I would be less reluctant to
commit them to ::gentoo. After committing, I would always inform the maintainer.

On the other hand, there is the situation where seemingly innocent
changes could cause some fallout, because this is the kind of package
where you assume you know what is going on from reading the ebuild and
playing with it, but you actually don't. Such packages could carry a
flag indicating that all changes require review by the maintainer. It
appears that <non-maintainer-commits-disallowed/> gives the wrong
impression, so maybe <changes-require-maintainer-ack/>?

- Flow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 06, 2022 at 02:42:34PM +0200, Florian Schmaus wrote:

On 04/07/2022 17.27, David Seifert wrote:

Ultimately, all these things really matter when only the defaults
change. Turn-right-on-red in the US is such a thing, because unless otherwise stated, it's the norm. Knowing our devbase, with roughly 75% mostly AWOL and barely reading the MLs, I don't think this idea will
bring about the desired change.

This sounds like you assume that the majority of Gentoo devs are OK with other people making changes to their packages. This very well could be
true, but without an indication you never know if the maintainer feels
this way.

I was on vacation when this thread started, so that's why I'm responding
now.

The default assumption according to the dev manual is that maintainers
are not ok with others touching their packages without permission except
for very trivial changes. IMO this is the safer default.

https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html

Instead, we should really just go for
the <non-maintainer-commits-disallowed/> tag, because my feeling is that the default will be that most maintainers don't mind non-maintainer commits, except a select few territorial ones.

It appears that we have at least two options here:

A) Establish that the default is non-maintainer-commits-welcome, and introduce a <non-maintainer-commits-disallowed/> metadata element.

This would go against the default from the dev manual, so if we go with
it, which I do not recommend, we should fix the dev manual.

B) Declare the default to be unspecified and introduce two metadata elements: <non-maintainer-commits-welcome/> and <non-maintainer-commits-disallowed/>.

I think you are proposing A) here, but please correct me if I am wrong.

Personally I would tend to B). But I have no strong opinion on this, as
long as some kind of signalling is established.

How do others feel about this?

I would suggest the default be consistent with the dev manual and we add
a <non-maintainer-commits-welcome/> element.

William

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCYtH+6AAKCRBuVBb0MMRl ONITAJsEGLQjrbilmziGdvbWX7e34PPPnACeNPD7Kwef5z0sMIDIOsmfm76AKH8=
=6tpD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)