Re: [gentoo-dev] proposal
On Mon, 4 Jul 2022 22:49:25 -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: > > > > 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 > 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 > -BEGIN PGP SIGNATURE- iQGTBAEBCgB9FiEExIg3+Emk70nqAQ2ybb4K1Uo7McYFAmJOvDBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM0 ODgzN0Y4NDlBNEVGNDlFQTAxMERCMjZEQkUwQUQ1NEEzQjMxQzYACgkQbb4K1Uo7 McbyjggA40un5MrP8DyyVmJXRUTSrxNHbCFck/7vCRHuHfync2bCFYk3JqvfFcu3 D5ms7sH+3ZBxGgUtCG7LwWOQZ89pSkQFXPCu+4Pb0LlVgz6x+lFyGNXdT1g4RyXu 1TzqQlok5gOmlxJ+aK+C6CmzN7e+0Mfe8lGHVLfcukzjlCglochavIXuiG7KNiTB 4rUSeVLJ6OaLkeqYQ4EYrhU8gkiA8nsH4TqXWxmB6cFhfy0e1wOGlkK31Q9jmmZp R4qpRF2QwH7CAKlIW9TT8fZ0kw06UVoGosm8lxMA2wQ2WycTnPp7kbRaTvdENEqb UggCF7hh2g7Y6LSh33f2l6TNlxH0tA== =G4KG -END PGP SIGNATURE-
Re: [gentoo-dev] proposal
> On 5 Jul 2022, at 00:21, Robin H. Johnson wrote: > > 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: >>> >>> > ... >> 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 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. https://marc.info/?l=gentoo-dev=137184067920894=2 and possibly a later version too if anyone is interested like I was. The discussions there are pretty interesting if nothing else. Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] proposal
> On 5 Jul 2022, at 03:49, 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: >> >> >> >> 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 >> 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=147816820903115=2). Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] proposal
> On 5 Jul 2022, at 04:24, Ionen Wolkens 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: 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 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 signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] proposal
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: > > > > > > > > > > > > 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 > > > 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 signature.asc Description: PGP signature
Re: [gentoo-dev] proposal
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: > > > > > > > > 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 > > 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 signature.asc Description: PGP signature
Re: [gentoo-dev] proposal
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: > > > > 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 > 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 signature.asc Description: PGP signature
Re: [gentoo-dev] proposal
> On 5 Jul 2022, at 00:49, Rich Freeman wrote: > > On Mon, Jul 4, 2022 at 7:21 PM Robin H. Johnson 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 signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] proposal
On Mon, Jul 4, 2022 at 7:21 PM Robin H. Johnson 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
Re: [gentoo-dev] proposal
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: > > > > ... > 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 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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] proposal
On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote: > I'd like to propose a new metadata XML element for packages: > > > > 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 > 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 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
[gentoo-dev] proposal
I'd like to propose a new metadata XML element for packages: 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 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
[gentoo-dev] [PATCH] java-pkg-simple.eclass: invoke einstalldocs
On EAPI 6, or newer, invoke einstalldocs in
java-pkg-simple_src_install.
Closes: https://bugs.gentoo.org/789582
Signed-off-by: Florian Schmaus
---
eclass/java-pkg-simple.eclass | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass
index 47499c7870a9..1e101a828c40 100644
--- a/eclass/java-pkg-simple.eclass
+++ b/eclass/java-pkg-simple.eclass
@@ -424,7 +424,7 @@ java-pkg-simple_src_compile() {
# @DESCRIPTION:
# src_install for simple single jar java packages. Simply installs
# ${JAVA_JAR_FILENAME}. It will also install a launcher if
-# ${JAVA_MAIN_CLASS} is set.
+# ${JAVA_MAIN_CLASS} is set. Also invokes einstalldocs.
java-pkg-simple_src_install() {
local sources=sources.lst classes=target/classes apidoc=target/api
@@ -455,6 +455,12 @@ java-pkg-simple_src_install() {
fi
java-pkg_dosrc ${srcdirs}
fi
+
+ if [[ ${EAPI} == 5 ]]; then
+ # einstalldocs is only available on EAPI >= 6.
+ return
+ fi
+ einstalldocs
}
# @FUNCTION: java-pkg-simple_src_test
--
2.35.1
