Re: GH issues and GH discussions

[Olivier Lamy]

On Tue, 30 May 2023 at 01:44, Hervé Boutemy  wrote:
>
> Le lundi 29 mai 2023, 13:50:58 CEST Karl Heinz Marbaise a écrit :
> > To fulfill the formalism (also have documented the decision here on the
> > ML) we should start simply a VOTE to get an in general decision about
> > moving to GH-issues to leave JIRA behind... (not about the details) that
> > can be done later on...(for example using GH discussions etc.)
> >
> > afterwards we can decide with which project we would like to start and
> > fiddle the details.
>
> I'd do it the exact opposite order:
> - test first Jira to GH  for a few projects
> - clarify Users ML replacement with GH Discussion (IIUC, this is what the GH
> discussion looks like, but I did not yet understand fuly: i have no
> experience, sharing examples would be useful)

We cannot replace Users ML; it should stay and be a mirror of GH discussions.
Various reasons:
- subscription to a third party provider is mandatory for GH
discussions whereas you can post a question to uers@ without
registration. Not convenient I agree because you have to wait for
moderation and consult the ML website but some users may still want
freedom of non registration.
- GH is not available in some countries. We will already prevent them
from creating issues because of moving to GH issues so we should leave
them at least one option to reach to us.


>
> and only once we found the right way to do one or the other, vote for making
> the real move
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: GH issues and GH discussions

[Olivier Lamy]

On Mon, 29 May 2023 at 21:51, Karl Heinz Marbaise  wrote:
>
> Hi,
>
> I would suggest to create an umbrella project like:
>
> apache-maven-project
>
> on github and make it the central starting point for users... to ask
> question (discussions) and optionally reroute them to the appropriate
> github repos...
>

we can;t really get rid of ML user or dev.
Is it what you mean here?

>
> In general I agree to the tendency to use GH issues etc. instead of JIRA
> based on the hurdles which exists (for a lot of reasons)...
>
> I second Hervé's suggestion to write down the needed/practical steps ...
> and start going...what about things currently in JIRA and needed to be
> migrated moved etc. ..We have a large history in JIRA...
>
>
> To fulfill the formalism (also have documented the decision here on the
> ML) we should start simply a VOTE to get an in general decision about
> moving to GH-issues to leave JIRA behind... (not about the details) that
> can be done later on...(for example using GH discussions etc.)
>
> afterwards we can decide with which project we would like to start and
> fiddle the details.
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 27.05.23 09:22, Hervé Boutemy wrote:
> > on testing GH issues migration from Jira: yes
> >
> > cache-extension [1] looks like an interesting example, given it has a small
> > history with its Jira content
> > we also have mvnd which uses GH issues from the start: testing and making
> > clear practices on release and release notes could also be worked there [2]
> >
> > we'll need to write down what practical steps such a migration requires
> > => probably a good fit for our Wiki, where we already organized equivalent
> > updates in the past [3]
> >
> > on using GH discussions, I suppose this should be an independent next
> > discussion
> >
> >
> > [1] https://github.com/apache/maven-build-cache-extension
> >
> > [2] https://github.com/apache/maven-mvnd
> >
> > [3] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
> >
> > Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> >> Hi,
> >> This has been already discussed in the past.
> >> But due to recent changes in ASF Jira infrastructure (limitation of
> >> Jira users, validation of account creation).
> >> Maybe we could reconsider moving from Jira to GH issues and why not
> >> simplify the workflow as well.
> >> I imagine not having to create an issue if a PR exists first (sounds
> >> like duplicate work).
> >> By the way, release notes will be automatically created from PRs.
> >> (could be manually modified if a change doesn't have a PR).
> >>
> >> Regarding migration, we can start project by project.
> >> Few options:
> >> - extreme simplicity, do not migrate any data (just mark the Jira
> >> project as read only with a banner/link to corresponding gh issues).
> >> If someone really needs an issue to get fixed he will clone it to GH
> >> - middle complexity, migrate only open issues (components moved as a label)
> >> - extreme complexity, migrate all issues of a project (components
> >> moved as a label and version created)
> >>
> >> We can start by small projects such as cache-extension and one plugin
> >> (compiler?)
> >>
> >> Regarding GH discussions, maybe we can open discussions for
> >> https://github.com/apache/maven which sounds like a natural place for
> >> users to go. (discussions could be mirrored to a ML)
> >> I do not have a strong opinion here, but I feel like opening
> >> discussions for every single repo will be complicated to follow up.
> >>
> >> WDYT?
> >>
> >> cheers
> >> Olivier
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: GH issues and GH discussions

[Olivier Lamy]

On Tue, 30 May 2023 at 00:04, Gary Gregory  wrote:
>
> GH has the notion of "projects". Can't we use that?
>

this is something very different. It's used to be a sort of project
version in where to add issues/PRs you want to be done to finalize the
project/version. (as an example look how it is used here
https://github.com/eclipse/jetty.project/projects?query=is%3Aopen )

> Gary
>
> On Mon, May 29, 2023, 09:50 Christoph Läubrich  wrote:
>
> > I must confess "another central project" do not feels right:
> >
> > 1) there already is a "central" one everyone can easily find if
> > searching for "maven github": https://github.com/apache/maven/
> > 2) for "subprojects" its usually better to discuss things close where
> > the code is
> >
> > Please note that some feature in GH do not work well across repositories
> > (e.g. embedding code snippets in issues), also I don't see any advantage
> > in scattering things around.
> >
> > Having a "central place "where contributors need to watch out and move
> > things around or need to find out what the topic is about will make
> > things more confusing, usually users are quite familiar with finding the
> > right place.
> >
> > If one wants to group things more, it would be better to have an
> > apache-maven organization on gihub and move all maven related there (the
> > one can also have organization readme, pinned repositories and so on),
> > this works quite well (e.g. Eclipse Foundation uses that approach).
> >
> > Am 29.05.23 um 13:50 schrieb Karl Heinz Marbaise:
> > > Hi,
> > >
> > > I would suggest to create an umbrella project like:
> > >
> > > apache-maven-project
> > >
> > > on github and make it the central starting point for users... to ask
> > > question (discussions) and optionally reroute them to the appropriate
> > > github repos...
> > >
> > >
> > > In general I agree to the tendency to use GH issues etc. instead of JIRA
> > > based on the hurdles which exists (for a lot of reasons)...
> > >
> > > I second Hervé's suggestion to write down the needed/practical steps ...
> > > and start going...what about things currently in JIRA and needed to be
> > > migrated moved etc. ..We have a large history in JIRA...
> > >
> > >
> > > To fulfill the formalism (also have documented the decision here on the
> > > ML) we should start simply a VOTE to get an in general decision about
> > > moving to GH-issues to leave JIRA behind... (not about the details) that
> > > can be done later on...(for example using GH discussions etc.)
> > >
> > > afterwards we can decide with which project we would like to start and
> > > fiddle the details.
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > On 27.05.23 09:22, Hervé Boutemy wrote:
> > >> on testing GH issues migration from Jira: yes
> > >>
> > >> cache-extension [1] looks like an interesting example, given it has a
> > >> small
> > >> history with its Jira content
> > >> we also have mvnd which uses GH issues from the start: testing and
> > making
> > >> clear practices on release and release notes could also be worked
> > >> there [2]
> > >>
> > >> we'll need to write down what practical steps such a migration requires
> > >> => probably a good fit for our Wiki, where we already organized
> > >> equivalent
> > >> updates in the past [3]
> > >>
> > >> on using GH discussions, I suppose this should be an independent next
> > >> discussion
> > >>
> > >>
> > >> [1] https://github.com/apache/maven-build-cache-extension
> > >>
> > >> [2] https://github.com/apache/maven-mvnd
> > >>
> > >> [3]
> > >> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
> > >>
> > >> Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> > >>> Hi,
> > >>> This has been already discussed in the past.
> > >>> But due to recent changes in ASF Jira infrastructure (limitation of
> > >>> Jira users, validation of account creation).
> > >>> Maybe we could reconsider moving from Jira to GH issues and why not
> > >>> simplify the workflow as well.
> > >>> I imagine not having to create an issue if a PR exists first (sounds
> > >>> like duplicate work).
> > >>> By the way, release notes will be automatically created from PRs.
> > >>> (could be manually modified if a change doesn't have a PR).
> > >>>
> > >>> Regarding migration, we can start project by project.
> > >>> Few options:
> > >>> - extreme simplicity, do not migrate any data (just mark the Jira
> > >>> project as read only with a banner/link to corresponding gh issues).
> > >>> If someone really needs an issue to get fixed he will clone it to GH
> > >>> - middle complexity, migrate only open issues (components moved as a
> > >>> label)
> > >>> - extreme complexity, migrate all issues of a project (components
> > >>> moved as a label and version created)
> > >>>
> > >>> We can start by small projects such as cache-extension and one plugin
> > >>> (compiler?)
> > >>>
> > >>> Regarding GH discussions, maybe we can open discussions for
> > >>> 

[CANCELED][VOTE] Release Maven Surefire version 3.1.1

[Michael Osipov]

I am canceling this vote:

* While going through JIRA issues I have noticed that I missed to update 
the test report schema file which makes the code inconsistent to it

* Give elharo@ some time work on dep updates
* Review a few low hanging report fruits

Will try to respin by end of week

M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Surefire version 3.1.1

[Michael Osipov]

Am 2023-05-29 um 18:27 schrieb Elliotte Rusty Harold:

1. There are 42 open PRs including some dependabot ones. Can any of
these be resolved quickly?


I have a branch as PR 'update-dendencies', but one needs to verify every 
dep independently because some break the build. Time consuming, as for 
the others: require effort and discussion.



2. At least a few assorted dependencies are not up to date. The
dependencies that are declared seem out of sync with what is and isn't
used. I'll send some PRs.


Separate PRs.


3, On my JDK 8 Mac 11.7.5 system `mvn -Prun-its verify` fails like so:


Although I don't have access to such an expensive dongle, it could be:
* https://github.com/apache/maven-surefire/pull/543
* https://issues.apache.org/jira/browse/SUREFIRE-2148
* and maybe something else...

Surefire is a bit special, therefore many of us are afraid to touch it :-D

M


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Surefire version 3.1.1

[Elliotte Rusty Harold]

1. There are 42 open PRs including some dependabot ones. Can any of
these be resolved quickly?

2. At least a few assorted dependencies are not up to date. The
dependencies that are declared seem out of sync with what is and isn't
used. I'll send some PRs.

3, On my JDK 8 Mac 11.7.5 system `mvn -Prun-its verify` fails like so:

[INFO] SureFire JUnit Runner .. SUCCESS [  2.020 s]
[INFO] SureFire JUnit4 Runner . SUCCESS [  1.934 s]
[INFO] Maven Surefire Common .. FAILURE [  3.248 s]
[INFO] SureFire JUnitCore Runner .. SKIPPED
[INFO] SureFire JUnit Platform Runner . SKIPPED
[INFO] SureFire TestNG Utils .. SKIPPED
[INFO] SureFire TestNG Runner . SKIPPED
[INFO] ShadeFire JUnit3 Provider .. SKIPPED
[INFO] Surefire Report Parser . SKIPPED
[INFO] Maven Surefire Plugin .. SKIPPED
[INFO] Maven Failsafe Plugin .. SKIPPED
[INFO] Maven Surefire Report Plugin ... SKIPPED
[INFO] Maven Surefire Integration Tests ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  58.608 s
[INFO] Finished at: 2023-05-29T12:19:17-04:00
[INFO] 
[ERROR] Failed to execute goal
org.jacoco:jacoco-maven-plugin:0.8.8:instrument
(jacoco-instrumentation) on project maven-surefire-common: Unable to
instrument file.: Error while instrumenting
/Users/elharo/maven-surefire/maven-surefire-common/target/classes/org/apache/maven/plugin/surefire/SurefireDependencyResolver$RuntimeArtifactFilter.class
with JaCoCo 0.8.8.202204050719/5dcf34a. -> [Help 1]
[ERROR]

This might be another case where a build can't run twice in a row.
Running mvn clean first and then running the tests again shows
different failures:

[ERROR] -
[ERROR]
[INFO] -
[INFO] Build Summary:
[INFO]   Passed: 1, Failed: 4, Errors: 0, Skipped: 0
[INFO] -
[ERROR] The following builds failed:
[ERROR] *  jetty-war-test-failing/pom.xml
[ERROR] *  working-directory/pom.xml
[ERROR] *  jetty-war-test-passing/pom.xml
[ERROR] *  multiple-summaries/pom.xml

On Sun, May 28, 2023 at 9:24 PM Michael Osipov  wrote:
>
> Hi,
>
> we solved 9 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353266
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1949/
> https://repository.apache.org/content/repositories/maven-1949/org/apache/maven/surefire/surefire/3.1.1/surefire-3.1.1-source-release.zip
>
> Source release checksum(s):
> surefire-3.1.1-source-release.zip
> sha512:
> deb15c554f2c86814cc834de016e9c4559ab33233ed02fd1291bf5119e23bfd27b862f6876b6e0914f950f92e1893f62a41027a802d4df11cc30d146a91060d0
>
> Staging site:
> https://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: GH issues and GH discussions

[Hervé Boutemy]

Le lundi 29 mai 2023, 13:50:58 CEST Karl Heinz Marbaise a écrit :
> To fulfill the formalism (also have documented the decision here on the
> ML) we should start simply a VOTE to get an in general decision about
> moving to GH-issues to leave JIRA behind... (not about the details) that
> can be done later on...(for example using GH discussions etc.)
> 
> afterwards we can decide with which project we would like to start and
> fiddle the details.

I'd do it the exact opposite order:
- test first Jira to GH  for a few projects
- clarify Users ML replacement with GH Discussion (IIUC, this is what the GH 
discussion looks like, but I did not yet understand fuly: i have no 
experience, sharing examples would be useful)

and only once we found the right way to do one or the other, vote for making 
the real move



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: GH issues and GH discussions

[Karl Heinz Marbaise]

Hi,

On 29.05.23 15:50, Christoph Läubrich wrote:

I must confess "another central project" do not feels right:

1) there already is a "central" one everyone can easily find if
searching for "maven github": https://github.com/apache/maven/


That does not help here because that project is Maven itself (maven
core)... which will produce much more confusion from my POV.



2) for "subprojects" its usually better to discuss things close where
the code is


In general yes ... but unfortunately many people do not see the need
focus for that...(https://maven.apache.org/plugins/) shows every project
with link to appropriate GH projects etc...




Please note that some feature in GH do not work well across repositories
(e.g. embedding code snippets in issues), also I don't see any advantage
in scattering things around.


Yes that is a real problem with GH issues etc.



Having a "central place "where contributors need to watch out and move
things around or need to find out what the topic is about will make
things more confusing, usually users are quite familiar with finding the
right place.


I have different experiences...




If one wants to group things more, it would be better to have an
apache-maven organization on gihub and move all maven related there (the
one can also have organization readme, pinned repositories and so on),
this works quite well (e.g. Eclipse Foundation uses that approach).


Yes that might be a better solution going via a Apache Maven Project
Organisation ... +1 for that...

But in the end it will not solve the problem to redirect the people to
the "correct" project


Kind regards
Karl Heinz Marbase



Am 29.05.23 um 13:50 schrieb Karl Heinz Marbaise:

Hi,

I would suggest to create an umbrella project like:

apache-maven-project

on github and make it the central starting point for users... to ask
question (discussions) and optionally reroute them to the appropriate
github repos...


In general I agree to the tendency to use GH issues etc. instead of JIRA
based on the hurdles which exists (for a lot of reasons)...

I second Hervé's suggestion to write down the needed/practical steps ...
and start going...what about things currently in JIRA and needed to be
migrated moved etc. ..We have a large history in JIRA...


To fulfill the formalism (also have documented the decision here on the
ML) we should start simply a VOTE to get an in general decision about
moving to GH-issues to leave JIRA behind... (not about the details) that
can be done later on...(for example using GH discussions etc.)

afterwards we can decide with which project we would like to start and
fiddle the details.


Kind regards
Karl Heinz Marbaise

On 27.05.23 09:22, Hervé Boutemy wrote:

on testing GH issues migration from Jira: yes

cache-extension [1] looks like an interesting example, given it has a
small
history with its Jira content
we also have mvnd which uses GH issues from the start: testing and
making
clear practices on release and release notes could also be worked
there [2]

we'll need to write down what practical steps such a migration requires
=> probably a good fit for our Wiki, where we already organized
equivalent
updates in the past [3]

on using GH discussions, I suppose this should be an independent next
discussion


[1] https://github.com/apache/maven-build-cache-extension

[2] https://github.com/apache/maven-mvnd

[3]
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure

Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :

Hi,
This has been already discussed in the past.
But due to recent changes in ASF Jira infrastructure (limitation of
Jira users, validation of account creation).
Maybe we could reconsider moving from Jira to GH issues and why not
simplify the workflow as well.
I imagine not having to create an issue if a PR exists first (sounds
like duplicate work).
By the way, release notes will be automatically created from PRs.
(could be manually modified if a change doesn't have a PR).

Regarding migration, we can start project by project.
Few options:
- extreme simplicity, do not migrate any data (just mark the Jira
project as read only with a banner/link to corresponding gh issues).
If someone really needs an issue to get fixed he will clone it to GH
- middle complexity, migrate only open issues (components moved as a
label)
- extreme complexity, migrate all issues of a project (components
moved as a label and version created)

We can start by small projects such as cache-extension and one plugin
(compiler?)

Regarding GH discussions, maybe we can open discussions for
https://github.com/apache/maven which sounds like a natural place for
users to go. (discussions could be mirrored to a ML)
I do not have a strong opinion here, but I feel like opening
discussions for every single repo will be complicated to follow up.

WDYT?

cheers
Olivier



-
To unsubscribe, e-mail: 

[RESULT] [VOTE] Release Maven Project Info Reports Plugin version 3.4.4

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Gabriel Belingueres, Sylwester Lachiewicz, Michael Osipov, Hervé 
Boutemy, tison


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: GH issues and GH discussions

[Gary Gregory]

GH has the notion of "projects". Can't we use that?

Gary

On Mon, May 29, 2023, 09:50 Christoph Läubrich  wrote:

> I must confess "another central project" do not feels right:
>
> 1) there already is a "central" one everyone can easily find if
> searching for "maven github": https://github.com/apache/maven/
> 2) for "subprojects" its usually better to discuss things close where
> the code is
>
> Please note that some feature in GH do not work well across repositories
> (e.g. embedding code snippets in issues), also I don't see any advantage
> in scattering things around.
>
> Having a "central place "where contributors need to watch out and move
> things around or need to find out what the topic is about will make
> things more confusing, usually users are quite familiar with finding the
> right place.
>
> If one wants to group things more, it would be better to have an
> apache-maven organization on gihub and move all maven related there (the
> one can also have organization readme, pinned repositories and so on),
> this works quite well (e.g. Eclipse Foundation uses that approach).
>
> Am 29.05.23 um 13:50 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > I would suggest to create an umbrella project like:
> >
> > apache-maven-project
> >
> > on github and make it the central starting point for users... to ask
> > question (discussions) and optionally reroute them to the appropriate
> > github repos...
> >
> >
> > In general I agree to the tendency to use GH issues etc. instead of JIRA
> > based on the hurdles which exists (for a lot of reasons)...
> >
> > I second Hervé's suggestion to write down the needed/practical steps ...
> > and start going...what about things currently in JIRA and needed to be
> > migrated moved etc. ..We have a large history in JIRA...
> >
> >
> > To fulfill the formalism (also have documented the decision here on the
> > ML) we should start simply a VOTE to get an in general decision about
> > moving to GH-issues to leave JIRA behind... (not about the details) that
> > can be done later on...(for example using GH discussions etc.)
> >
> > afterwards we can decide with which project we would like to start and
> > fiddle the details.
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > On 27.05.23 09:22, Hervé Boutemy wrote:
> >> on testing GH issues migration from Jira: yes
> >>
> >> cache-extension [1] looks like an interesting example, given it has a
> >> small
> >> history with its Jira content
> >> we also have mvnd which uses GH issues from the start: testing and
> making
> >> clear practices on release and release notes could also be worked
> >> there [2]
> >>
> >> we'll need to write down what practical steps such a migration requires
> >> => probably a good fit for our Wiki, where we already organized
> >> equivalent
> >> updates in the past [3]
> >>
> >> on using GH discussions, I suppose this should be an independent next
> >> discussion
> >>
> >>
> >> [1] https://github.com/apache/maven-build-cache-extension
> >>
> >> [2] https://github.com/apache/maven-mvnd
> >>
> >> [3]
> >> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
> >>
> >> Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> >>> Hi,
> >>> This has been already discussed in the past.
> >>> But due to recent changes in ASF Jira infrastructure (limitation of
> >>> Jira users, validation of account creation).
> >>> Maybe we could reconsider moving from Jira to GH issues and why not
> >>> simplify the workflow as well.
> >>> I imagine not having to create an issue if a PR exists first (sounds
> >>> like duplicate work).
> >>> By the way, release notes will be automatically created from PRs.
> >>> (could be manually modified if a change doesn't have a PR).
> >>>
> >>> Regarding migration, we can start project by project.
> >>> Few options:
> >>> - extreme simplicity, do not migrate any data (just mark the Jira
> >>> project as read only with a banner/link to corresponding gh issues).
> >>> If someone really needs an issue to get fixed he will clone it to GH
> >>> - middle complexity, migrate only open issues (components moved as a
> >>> label)
> >>> - extreme complexity, migrate all issues of a project (components
> >>> moved as a label and version created)
> >>>
> >>> We can start by small projects such as cache-extension and one plugin
> >>> (compiler?)
> >>>
> >>> Regarding GH discussions, maybe we can open discussions for
> >>> https://github.com/apache/maven which sounds like a natural place for
> >>> users to go. (discussions could be mirrored to a ML)
> >>> I do not have a strong opinion here, but I feel like opening
> >>> discussions for every single repo will be complicated to follow up.
> >>>
> >>> WDYT?
> >>>
> >>> cheers
> >>> Olivier
> >>>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> 

Re: GH issues and GH discussions

[Christoph Läubrich]

I must confess "another central project" do not feels right:

1) there already is a "central" one everyone can easily find if 
searching for "maven github": https://github.com/apache/maven/
2) for "subprojects" its usually better to discuss things close where 
the code is


Please note that some feature in GH do not work well across repositories 
(e.g. embedding code snippets in issues), also I don't see any advantage 
in scattering things around.


Having a "central place "where contributors need to watch out and move 
things around or need to find out what the topic is about will make 
things more confusing, usually users are quite familiar with finding the 
right place.


If one wants to group things more, it would be better to have an 
apache-maven organization on gihub and move all maven related there (the 
one can also have organization readme, pinned repositories and so on), 
this works quite well (e.g. Eclipse Foundation uses that approach).


Am 29.05.23 um 13:50 schrieb Karl Heinz Marbaise:

Hi,

I would suggest to create an umbrella project like:

apache-maven-project

on github and make it the central starting point for users... to ask
question (discussions) and optionally reroute them to the appropriate
github repos...


In general I agree to the tendency to use GH issues etc. instead of JIRA
based on the hurdles which exists (for a lot of reasons)...

I second Hervé's suggestion to write down the needed/practical steps ...
and start going...what about things currently in JIRA and needed to be
migrated moved etc. ..We have a large history in JIRA...


To fulfill the formalism (also have documented the decision here on the
ML) we should start simply a VOTE to get an in general decision about
moving to GH-issues to leave JIRA behind... (not about the details) that
can be done later on...(for example using GH discussions etc.)

afterwards we can decide with which project we would like to start and
fiddle the details.


Kind regards
Karl Heinz Marbaise

On 27.05.23 09:22, Hervé Boutemy wrote:

on testing GH issues migration from Jira: yes

cache-extension [1] looks like an interesting example, given it has a 
small

history with its Jira content
we also have mvnd which uses GH issues from the start: testing and making
clear practices on release and release notes could also be worked 
there [2]


we'll need to write down what practical steps such a migration requires
=> probably a good fit for our Wiki, where we already organized 
equivalent

updates in the past [3]

on using GH discussions, I suppose this should be an independent next
discussion


[1] https://github.com/apache/maven-build-cache-extension

[2] https://github.com/apache/maven-mvnd

[3] 
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure


Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :

Hi,
This has been already discussed in the past.
But due to recent changes in ASF Jira infrastructure (limitation of
Jira users, validation of account creation).
Maybe we could reconsider moving from Jira to GH issues and why not
simplify the workflow as well.
I imagine not having to create an issue if a PR exists first (sounds
like duplicate work).
By the way, release notes will be automatically created from PRs.
(could be manually modified if a change doesn't have a PR).

Regarding migration, we can start project by project.
Few options:
- extreme simplicity, do not migrate any data (just mark the Jira
project as read only with a banner/link to corresponding gh issues).
If someone really needs an issue to get fixed he will clone it to GH
- middle complexity, migrate only open issues (components moved as a 
label)

- extreme complexity, migrate all issues of a project (components
moved as a label and version created)

We can start by small projects such as cache-extension and one plugin
(compiler?)

Regarding GH discussions, maybe we can open discussions for
https://github.com/apache/maven which sounds like a natural place for
users to go. (discussions could be mirrored to a ML)
I do not have a strong opinion here, but I feel like opening
discussions for every single repo will be complicated to follow up.

WDYT?

cheers
Olivier




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Surefire version 3.1.1

[Romain Manni-Bucau]

+1, tested on several projects without issues

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 29 mai 2023 à 13:52, Karl Heinz Marbaise  a
écrit :

> Hi,
>
> +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
> On 28.05.23 23:24, Michael Osipov wrote:
> > Hi,
> >
> > we solved 9 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353266
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1949/
> >
> https://repository.apache.org/content/repositories/maven-1949/org/apache/maven/surefire/surefire/3.1.1/surefire-3.1.1-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.1.1-source-release.zip
> > sha512:
> >
> deb15c554f2c86814cc834de016e9c4559ab33233ed02fd1291bf5119e23bfd27b862f6876b6e0914f950f92e1893f62a41027a802d4df11cc30d146a91060d0
> >
> > Staging site:
> > https://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: GH issues and GH discussions

[Karl Heinz Marbaise]

Hi,
On 29.05.23 14:07, Michael Osipov wrote:

Am 2023-05-29 um 13:50 schrieb Karl Heinz Marbaise:

Hi,

I would suggest to create an umbrella project like:

apache-maven-project

on github and make it the central starting point for users... to ask
question (discussions) and optionally reroute them to the appropriate
github repos...


In general I agree to the tendency to use GH issues etc. instead of JIRA
based on the hurdles which exists (for a lot of reasons)...

I second Hervé's suggestion to write down the needed/practical steps ...
and start going...what about things currently in JIRA and needed to be
migrated moved etc. ..We have a large history in JIRA...


To fulfill the formalism (also have documented the decision here on the
ML) we should start simply a VOTE to get an in general decision about
moving to GH-issues to leave JIRA behind... (not about the details) that
can be done later on...(for example using GH discussions etc.)

afterwards we can decide with which project we would like to start and
fiddle the details.


Before we do that, we need to aggressively go through all tickets and
closes issues which we will never address or are invalid by now.

M


Yep good idea +1 for that.

Kind regards
Karl Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: GH issues and GH discussions

[Michael Osipov]

Am 2023-05-29 um 13:50 schrieb Karl Heinz Marbaise:

Hi,

I would suggest to create an umbrella project like:

apache-maven-project

on github and make it the central starting point for users... to ask
question (discussions) and optionally reroute them to the appropriate
github repos...


In general I agree to the tendency to use GH issues etc. instead of JIRA
based on the hurdles which exists (for a lot of reasons)...

I second Hervé's suggestion to write down the needed/practical steps ...
and start going...what about things currently in JIRA and needed to be
migrated moved etc. ..We have a large history in JIRA...


To fulfill the formalism (also have documented the decision here on the
ML) we should start simply a VOTE to get an in general decision about
moving to GH-issues to leave JIRA behind... (not about the details) that
can be done later on...(for example using GH discussions etc.)

afterwards we can decide with which project we would like to start and
fiddle the details.


Before we do that, we need to aggressively go through all tickets and 
closes issues which we will never address or are invalid by now.


M

Re: [VOTE] Release Maven Surefire version 3.1.1

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise
On 28.05.23 23:24, Michael Osipov wrote:

Hi,

we solved 9 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353266

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-1949/
https://repository.apache.org/content/repositories/maven-1949/org/apache/maven/surefire/surefire/3.1.1/surefire-3.1.1-source-release.zip

Source release checksum(s):
surefire-3.1.1-source-release.zip
sha512:
deb15c554f2c86814cc834de016e9c4559ab33233ed02fd1291bf5119e23bfd27b862f6876b6e0914f950f92e1893f62a41027a802d4df11cc30d146a91060d0

Staging site:
https://maven.apache.org/surefire-archives/surefire-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: GH issues and GH discussions

[Karl Heinz Marbaise]

Hi,

I would suggest to create an umbrella project like:

apache-maven-project

on github and make it the central starting point for users... to ask
question (discussions) and optionally reroute them to the appropriate
github repos...


In general I agree to the tendency to use GH issues etc. instead of JIRA
based on the hurdles which exists (for a lot of reasons)...

I second Hervé's suggestion to write down the needed/practical steps ...
and start going...what about things currently in JIRA and needed to be
migrated moved etc. ..We have a large history in JIRA...


To fulfill the formalism (also have documented the decision here on the
ML) we should start simply a VOTE to get an in general decision about
moving to GH-issues to leave JIRA behind... (not about the details) that
can be done later on...(for example using GH discussions etc.)

afterwards we can decide with which project we would like to start and
fiddle the details.


Kind regards
Karl Heinz Marbaise

On 27.05.23 09:22, Hervé Boutemy wrote:

on testing GH issues migration from Jira: yes

cache-extension [1] looks like an interesting example, given it has a small
history with its Jira content
we also have mvnd which uses GH issues from the start: testing and making
clear practices on release and release notes could also be worked there [2]

we'll need to write down what practical steps such a migration requires
=> probably a good fit for our Wiki, where we already organized equivalent
updates in the past [3]

on using GH discussions, I suppose this should be an independent next
discussion


[1] https://github.com/apache/maven-build-cache-extension

[2] https://github.com/apache/maven-mvnd

[3] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure

Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :

Hi,
This has been already discussed in the past.
But due to recent changes in ASF Jira infrastructure (limitation of
Jira users, validation of account creation).
Maybe we could reconsider moving from Jira to GH issues and why not
simplify the workflow as well.
I imagine not having to create an issue if a PR exists first (sounds
like duplicate work).
By the way, release notes will be automatically created from PRs.
(could be manually modified if a change doesn't have a PR).

Regarding migration, we can start project by project.
Few options:
- extreme simplicity, do not migrate any data (just mark the Jira
project as read only with a banner/link to corresponding gh issues).
If someone really needs an issue to get fixed he will clone it to GH
- middle complexity, migrate only open issues (components moved as a label)
- extreme complexity, migrate all issues of a project (components
moved as a label and version created)

We can start by small projects such as cache-extension and one plugin
(compiler?)

Regarding GH discussions, maybe we can open discussions for
https://github.com/apache/maven which sounds like a natural place for
users to go. (discussions could be mirrored to a ML)
I do not have a strong opinion here, but I feel like opening
discussions for every single repo will be complicated to follow up.

WDYT?

cheers
Olivier




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Surefire version 3.1.1

[Michael Osipov]

Am 2023-05-28 um 23:24 schrieb Michael Osipov:

Hi,

we solved 9 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353266

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-1949/
https://repository.apache.org/content/repositories/maven-1949/org/apache/maven/surefire/surefire/3.1.1/surefire-3.1.1-source-release.zip

Source release checksum(s):
surefire-3.1.1-source-release.zip
sha512: 
deb15c554f2c86814cc834de016e9c4559ab33233ed02fd1291bf5119e23bfd27b862f6876b6e0914f950f92e1893f62a41027a802d4df11cc30d146a91060d0


Staging site:
https://maven.apache.org/surefire-archives/surefire-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [HEADS UP] Upcoming Resolver and Maven releases

[Christoph Läubrich]

Well the problem is that most users won't notice any "votes" or are able 
to take action on it (e.g. because they can't run a custom build maven 
on their CI easily).


I already have recommended that there should be a SNAPSHOT build on the 
download-page with clear indication to the user to help testing these 
snapshots, but for some strange ASF policy it is not allowed to promote 
snapshots on the download page.


e.g. on Tycho we have quite some success with the strategy we have a 
simple instructions here:

https://github.com/eclipse-tycho/tycho/wiki#getting-tycho-snapshots

and a lot of projects using at least an extra nightly-build to get 
warned early if things change/break for them so most of the time we get 
reports of regressions withing a few days and can often verify fixes 
right after the snapshot is deployed as people simply restart their 
builds and can report back if it is fixed.



Am 29.05.23 um 09:36 schrieb Romain Manni-Bucau:

Le lun. 29 mai 2023 à 09:03, Delany  a écrit :


Since most issues (like this one) are discovered after release, what about
introducing a backward compatibility policy of "second-to-last"?
For example, a feature is introduced (with config value BRIEF) in 3.9.2
Then its decided in 3.9.3 to change it to something else (SUMMARY).
This should be allowed since 3.9.3 is within the "cool off period".
If that wasn't done then from 3.9.4 the usual process of deprecation can be
followed to remove it (with attendant bureaucracy).
For the kind of developers who always update to the latest, like myself,
this isn't a problem.
I have chosen to get the latest features with the tradeoff of having to
deal with new issues.
This way the window for change is widened to include real world scenarios
and one settles these sorts of issues sooner.
Delany



Hi, this is what the vote is done for, if we do then you'll probably want
to tackle people upgrading later too (so a range) or to majors too so,
IMHO, it is just moving the issue that people don't test their build with
the snapshots. For the cli we can surely write a command to help but will
not solve the actual build so, still IMHO, we should just encourage people
to test during the vote period and if they don't we can't help much except
trying to fix unexpected regressions ASAP.




On Sun, 28 May 2023 at 22:58, Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:


You spend so much time on ceremony and bureaucracy by filing tickets that
no one is going to pick up or read and then creating pull requests that

at

best will be glanced at and then "LGTM"ed.

This is a trivial, non-controversial change that any committer can just
commit. Worst case scenario, someone else is going to comment on it and
then it can be iterated. That is how Apache has always worked and why CTR
is more efficient with a small team. Every committer is explicitly

trusted

to work on the code base without constant "there needs to be a ticket.
there needs to be a PR. there needs to be a week of discussion whether

that

change is good. there needs to be "approval" or "majority agreement" by
some star chamber that can decide what is good for the project.

Reserve the ceremony and discussion for the large, gnarly, controversial
changes that warrant discussion and where there is value in doing more
upfront planning. But for god's sake, stop doing ceremony for ceremony's
sake.

It is a literal one-liner. - https://github.com/apache/maven/pull/1132

-h


On Fri, May 26, 2023 at 1:24 PM Tamás Cservenák 
wrote:


Howdy,

good call, created https://issues.apache.org/jira/browse/MNG-7797

Thanks
T

On Fri, May 26, 2023 at 10:09 PM Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:


maven 3.9.2:

mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
install
[...]

current 3.9.3-SNAPSHOT:

mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
install
[...]

*[WARNING] Invalid value specified for property

maven.plugin.validation:

'BRIEF'. Supported values are (case insensitive): [NONE, INLINE,

SUMMARY,

VERBOSE]*

You shipped "BRIEF" in 3.9.2, removing it now breaks scripts that

added

this to the command line or the pom.

I suggest mapping "BRIEF" to "SUMMARY".

-h


On Fri, May 26, 2023 at 12:46 AM Tamás Cservenák <

ta...@cservenak.net>

wrote:


Howdy,

Resolver 1.9.11 is shaping:









https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.11


one resolver issue under scrutiny:
https://issues.apache.org/jira/browse/MRESOLVER-362

Maven 3.9.3 as well:









https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.3


As usual, I plan these for next week, so if anyone has anything to

say,

speak up!

Thanks
T













-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [HEADS UP] Upcoming Resolver and Maven releases

[Romain Manni-Bucau]

Le lun. 29 mai 2023 à 09:03, Delany  a écrit :

> Since most issues (like this one) are discovered after release, what about
> introducing a backward compatibility policy of "second-to-last"?
> For example, a feature is introduced (with config value BRIEF) in 3.9.2
> Then its decided in 3.9.3 to change it to something else (SUMMARY).
> This should be allowed since 3.9.3 is within the "cool off period".
> If that wasn't done then from 3.9.4 the usual process of deprecation can be
> followed to remove it (with attendant bureaucracy).
> For the kind of developers who always update to the latest, like myself,
> this isn't a problem.
> I have chosen to get the latest features with the tradeoff of having to
> deal with new issues.
> This way the window for change is widened to include real world scenarios
> and one settles these sorts of issues sooner.
> Delany
>

Hi, this is what the vote is done for, if we do then you'll probably want
to tackle people upgrading later too (so a range) or to majors too so,
IMHO, it is just moving the issue that people don't test their build with
the snapshots. For the cli we can surely write a command to help but will
not solve the actual build so, still IMHO, we should just encourage people
to test during the vote period and if they don't we can't help much except
trying to fix unexpected regressions ASAP.


>
> On Sun, 28 May 2023 at 22:58, Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
> > You spend so much time on ceremony and bureaucracy by filing tickets that
> > no one is going to pick up or read and then creating pull requests that
> at
> > best will be glanced at and then "LGTM"ed.
> >
> > This is a trivial, non-controversial change that any committer can just
> > commit. Worst case scenario, someone else is going to comment on it and
> > then it can be iterated. That is how Apache has always worked and why CTR
> > is more efficient with a small team. Every committer is explicitly
> trusted
> > to work on the code base without constant "there needs to be a ticket.
> > there needs to be a PR. there needs to be a week of discussion whether
> that
> > change is good. there needs to be "approval" or "majority agreement" by
> > some star chamber that can decide what is good for the project.
> >
> > Reserve the ceremony and discussion for the large, gnarly, controversial
> > changes that warrant discussion and where there is value in doing more
> > upfront planning. But for god's sake, stop doing ceremony for ceremony's
> > sake.
> >
> > It is a literal one-liner. - https://github.com/apache/maven/pull/1132
> >
> > -h
> >
> >
> > On Fri, May 26, 2023 at 1:24 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > good call, created https://issues.apache.org/jira/browse/MNG-7797
> > >
> > > Thanks
> > > T
> > >
> > > On Fri, May 26, 2023 at 10:09 PM Henning Schmiedehausen <
> > > henn...@schmiedehausen.org> wrote:
> > >
> > > > maven 3.9.2:
> > > >
> > > > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > > > install
> > > > [...]
> > > >
> > > > current 3.9.3-SNAPSHOT:
> > > >
> > > > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > > > install
> > > > [...]
> > > >
> > > > *[WARNING] Invalid value specified for property
> > maven.plugin.validation:
> > > > 'BRIEF'. Supported values are (case insensitive): [NONE, INLINE,
> > SUMMARY,
> > > > VERBOSE]*
> > > >
> > > > You shipped "BRIEF" in 3.9.2, removing it now breaks scripts that
> added
> > > > this to the command line or the pom.
> > > >
> > > > I suggest mapping "BRIEF" to "SUMMARY".
> > > >
> > > > -h
> > > >
> > > >
> > > > On Fri, May 26, 2023 at 12:46 AM Tamás Cservenák <
> ta...@cservenak.net>
> > > > wrote:
> > > >
> > > > > Howdy,
> > > > >
> > > > > Resolver 1.9.11 is shaping:
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.11
> > > > >
> > > > > one resolver issue under scrutiny:
> > > > > https://issues.apache.org/jira/browse/MRESOLVER-362
> > > > >
> > > > > Maven 3.9.3 as well:
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.3
> > > > >
> > > > > As usual, I plan these for next week, so if anyone has anything to
> > say,
> > > > > speak up!
> > > > >
> > > > > Thanks
> > > > > T
> > > > >
> > > >
> > >
> >
>

Re: [HEADS UP] Upcoming Resolver and Maven releases

[Delany]

Since most issues (like this one) are discovered after release, what about
introducing a backward compatibility policy of "second-to-last"?
For example, a feature is introduced (with config value BRIEF) in 3.9.2
Then its decided in 3.9.3 to change it to something else (SUMMARY).
This should be allowed since 3.9.3 is within the "cool off period".
If that wasn't done then from 3.9.4 the usual process of deprecation can be
followed to remove it (with attendant bureaucracy).
For the kind of developers who always update to the latest, like myself,
this isn't a problem.
I have chosen to get the latest features with the tradeoff of having to
deal with new issues.
This way the window for change is widened to include real world scenarios
and one settles these sorts of issues sooner.
Delany

On Sun, 28 May 2023 at 22:58, Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> You spend so much time on ceremony and bureaucracy by filing tickets that
> no one is going to pick up or read and then creating pull requests that at
> best will be glanced at and then "LGTM"ed.
>
> This is a trivial, non-controversial change that any committer can just
> commit. Worst case scenario, someone else is going to comment on it and
> then it can be iterated. That is how Apache has always worked and why CTR
> is more efficient with a small team. Every committer is explicitly trusted
> to work on the code base without constant "there needs to be a ticket.
> there needs to be a PR. there needs to be a week of discussion whether that
> change is good. there needs to be "approval" or "majority agreement" by
> some star chamber that can decide what is good for the project.
>
> Reserve the ceremony and discussion for the large, gnarly, controversial
> changes that warrant discussion and where there is value in doing more
> upfront planning. But for god's sake, stop doing ceremony for ceremony's
> sake.
>
> It is a literal one-liner. - https://github.com/apache/maven/pull/1132
>
> -h
>
>
> On Fri, May 26, 2023 at 1:24 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > good call, created https://issues.apache.org/jira/browse/MNG-7797
> >
> > Thanks
> > T
> >
> > On Fri, May 26, 2023 at 10:09 PM Henning Schmiedehausen <
> > henn...@schmiedehausen.org> wrote:
> >
> > > maven 3.9.2:
> > >
> > > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > > install
> > > [...]
> > >
> > > current 3.9.3-SNAPSHOT:
> > >
> > > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > > install
> > > [...]
> > >
> > > *[WARNING] Invalid value specified for property
> maven.plugin.validation:
> > > 'BRIEF'. Supported values are (case insensitive): [NONE, INLINE,
> SUMMARY,
> > > VERBOSE]*
> > >
> > > You shipped "BRIEF" in 3.9.2, removing it now breaks scripts that added
> > > this to the command line or the pom.
> > >
> > > I suggest mapping "BRIEF" to "SUMMARY".
> > >
> > > -h
> > >
> > >
> > > On Fri, May 26, 2023 at 12:46 AM Tamás Cservenák 
> > > wrote:
> > >
> > > > Howdy,
> > > >
> > > > Resolver 1.9.11 is shaping:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.11
> > > >
> > > > one resolver issue under scrutiny:
> > > > https://issues.apache.org/jira/browse/MRESOLVER-362
> > > >
> > > > Maven 3.9.3 as well:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.3
> > > >
> > > > As usual, I plan these for next week, so if anyone has anything to
> say,
> > > > speak up!
> > > >
> > > > Thanks
> > > > T
> > > >
> > >
> >
>