---
> 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
--
same thing. The improvements I see that
help developers test code are in supplementary libraries like assert4j
or Guava Testlib, not the core frameworks. So if a project wants to
keep using JUnit 3, it should. Burning developer time upgrading is
irrational.
--
Elliot
refactoring so it could be replaced by new issue about
> upgrade.
>
Fair enough, but if the dependencabit PRs are not good, then please
close them so they don't hang around muddying up things.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
Elliot
ble than to make sure we warn about everything
that might be a minor problem with some very low probability.
--
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
com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
> Javaccino founder (Java/.NET service - contact via linkedin)
eral way, please do submit a PR but let's not
let the perfect be the enemy of the good. Right now projects have
false positives about this specific json dependency. Removing those
false positives is an improvement, and it doesn't get in the way of
further work in the future, so l
TEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
t;
> > -
> > 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..
954b98810c7d646b065e
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
Elliotte R
On Sun, Sep 14, 2025 at 1:10 PM Rüdiger wrote:
>
> On 14. Sep 2025, at 12:32, Elliotte Rusty Harold wrote:
> > In general ITs, including our own, are too flaky, too heavyweight, and
> > too configuration dependent to execute them by default when the user
> > is trying t
integration tests during install.
In general ITs, including our own, are too flaky, too heavyweight, and
too configuration dependent to execute them by default when the user
is trying to do something else like package or install.
--
Elliotte Rusty Harold
e
st web framework
based projects) aren't using SpringBoot at all.
Maven should support SpringBoot, but neither require nor assume it.
Maven is for all kinds of Java projects, not just for web projects and
certainly not just for SpringBoot.
--
Elliotte Rust
er gone
anywhere near it, myself included. At Google, SpringBoot only came up
when talking about how third parties might want to deploy their own
apps on GCP. At Meta it never came up at all. Sometimes we can get
tunnel vision and assume our stack is the world, when really it's just
one small to me
xisting goal and introduce #3 in a new
javadoc:generate goal. Thoughts? Preferences?
--
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
etween what's
installed in the bash $PATH and what's specified in a project's
pom.xml. They are not at all the same thing. You can't upgrade the
version of Maven you get when you run `mvn package` by editing one
line in a pom.xml.
-
> 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
itional 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
> [ ] +0
> > [ ] -1
> >
> > cheers
> > Olivier
> >
> > -
> > 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
int in enabling
> those.
Not necessarily. On more than one occasion I've accidentally pushed to
master out of simple confusion about which branch I was on locally,
and then had to roll back. This would prevent such faux pas. Don't let
the perfect be the enemy of the good.
--
Elliotte Rus
maven-dependency-plugin
> (OpenSSF score card for m-dependency-plugin)
> [2]
> https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets
> [3]
> https://github.blog/news-insights/product-news/github-repository-rules-are-now-generally-
= 4.0.0
> so that it can be consumed by Maven 3 and other tools, gradle, ivy, etc...
> This POM is rewritten from the build POM which can have a different model
> version,
> namespace, or language (i.e. not XML).
> So if your concern is about what is deployed as POM, then you don't h
e developers of one build tool making
decisions for everyone. What we can do now is avoid making the problem
even worse by introducing additional namespace URIs beyond what we
already have.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
for a 4.x release?
>3. *Long-term vision*: Would a properly planned Maven 5.0 namespace
>overhaul better serve our goals?
>
> I'm interested in hearing the community's thoughts on this timing vs.
> technical merit trade-off.
>
> Best regards,
> Guillaume Nod
e Java stack but I
guess that's no longer true.
--
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 are already some guidelines on this which I'm unaware of, so
> I'm looking forward to your input.
>
> Regards,
>
> Giovanni van der Schelde
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
T
-dependency-plugin, or would it be better suited for another plugin or
> Maven core itself?
>
> Thanks,
> Calum
--
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
should be like that I can use?
Just follow the Oracle Javadoc guidelines:
https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubs
antly. It is the purposeful design behind HTTP 1.1 in 1996,
and was fully documented and codified in Fielding's thesis in 2000.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apac
ease see
> https://issues.apache.org/jira/browse/MGPG-111
>
> On Sun, Jun 29, 2025, 14:09 Elliotte Rusty Harold
> wrote:
>
> > dependencies look like they could use improvement:
> >
> > [WARNING] Used undeclared dependencies found:
> > [WARNING]
> > com.k
lopment/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
&g
> 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
> >
> >
>
> -
> To
b.com/apache/maven-parent/milestone/25
>
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional
OK, looks like that was in the 4.0 branch and this is for the 3,x
branch. In the 3.x branch there's one unused test dependency that can
be removed, nothing serious I can see.
On Wed, May 28, 2025 at 12:44 PM Elliotte Rusty Harold
wrote:
>
> I see test failures with Maven 3.9.9
s.
> >
> > [ ] +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
n release process works.
However, critical bug fixes should generate a new RC. Overall I would
prefer much more rigorous versioning. Right now we're pushing RCs with
known unstable APIs, which I would normally consider appropriate for
pre-alpha builds.
--
Ell
I
can think of, and I'd be happy to ditch that. We don't run with
outdated dependencies or unsupported JDKs. When we have outdated
dependencies, it's because no one has pressed the Squash and Merge
button on a dependabot PR. It has nothing to do with Java versions.
--
Ellio
g a Java shop, but they too were
using Java 11 at least through late 2024. They and others will
eventually get to Java 25, but that's years in the future.
--
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
need API stability though.
--
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
ads rather than focusing
on long term support and reliability. Should anyone ever care enough
about this to start paying for support and development, that might
change.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubsc
ing to do what
they find fun rather than delivering user value.
--
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
ar it!
>
> Cheers,
>
> Guillaume
--
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
uot; There are many other vendors.
--
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
est regards
>
> Vincent
>
>
>
> PS:
>
> In reality, you don’t notice these tools until problems arise.
>
> It’s like karma—silent and harmless until you break something. Then it comes
> back to show its cost.
>
> Just want to limit this. Currently, there’s no
der some conditions) fix test compile issue: added dependency
> test path for modules
> * Wrong encoding when reading the output of forked JVM on Windows
>
> Martin
>
--
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
s://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.23
> >
> > >
> >
> > > I will work on it, I hope the release can be done in the next two -
> > three weeks.
> >
> > > Any help as usual is apprec
DK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> --------
9fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> ---------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
Elliotte Rusty Ha
s appreciated.
>
>
> --
> Sławomir Jaranowski
>
> -
> 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
--
aying
> that they may be removed in a future version. We would still have the
> other benefits and be prepared for this evolution.
>
> Any though?
>
> Martin
>
> [1]https://github.com/apache/maven/blob/master/api/maven-api-model/src/main/mdo/
les
> [image: tree2.png]
>
> -
> 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
, we absolutely can do that. We use a new modelVersion 4.1.0 for
Maven 4.0. (Confusingly modelVersion 4.0.0 is for Maven 3 but c'est la
vie.) We can make Maven reject any poms that use modelVersion 4.1.0
and do not have the proper namespace. This will not reject any
existing poms which use earlier
I think it's time to create a branch to release Maven 4.0.0 GA in the
> coming weeks and switch master to 4.1.0-SNAPSHOT.
> Thoughts ?
>
> --
> ----
> Guillaume Nodet
--
Elliotte Rusty Harold
elh...@ibiblio.org
t it doesn't need to be in Maven.
--
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
4.1 or 4.2 or whatever that has a
> element.
>
> On Mon, 17 Mar 2025 at 01:53, Elliotte Rusty Harold
> wrote:
>
> > Yes, it's too late. I share your frustration with hierarchies, and
> > more than in just the context of build systems. There are a lot of
> > areas
tool to a genuine
> masterpiece. M4 without tiles would be a huge step backwards even if it
> improves numerous other things.
>
> I have read through the following page, and most of it sounds good:
> https://maven.apache.org/whatsnewinmaven4.html
>
> What's the path forward?
&
scope and `optional`
> qualifier. These are source of interminable discussions on which one
> should be used.
>
> [2]
> https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation
>
>
> --------
--
> 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
t; Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
> -
>
> Matthias
>
>
> -
> To unsubscribe, e-mail
ance. That depends on how well these tools
operate.
--
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
all-changing companies. At my work we got some tools, that still
> > > only support Java EE 6 and Java 8 while we don't get newer versions
> > > provided by ops...
> > >
> > >
> > >
> > > -
--
> 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
ations can't be relied
on. The code will be in worse shape than it was when the effort
started.
On Tue, Feb 11, 2025 at 4:36 AM Xeno Amess wrote:
>
> as title.
> during recently learning about maven and maven-resolver, sometimes I really
> think it better to have nullable/notnull
e only auto-closing issues that were waiting for
feedback when no feedback had arrived by the deadline. We shouldn't
autoclose issues that are waiting for someone to get around to fixing
them or waiting for review.
--
Elliotte Rusty Harold
elh...@ibiblio.org
po and artifacts but not building projects with
Maven.
--
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
gt; somebody wrongly said, , and spend a whole day finding what be
> wrong.
Namespaces could resolve that.
> or is there some way to allow some...prefix?or allow-all-namespace like
> or something?
>
Yes, there is.
--
Elliotte Rusty H
verything I need to build this project?" instead of "Do I
understand every element in this pom?"
A slightly less radical approach would be to ignore elements not in
Maven's own namespace.
--
Elliotte Rusty Harold
elh...@ibiblio.org
--
d by a couple of people from the audience
> > who raised concern about comments in the build POM being removed in the
> > published consumer POM. They thought that could be problematic for larger
> > corporations who want, for example, copyright comments.
> >
> > Any thou
To be clear, we're not banning anyone. We're simply being cautious
about active permissions given the risk of compromised old accounts.
With 72 committers some of whom haven't been heard from in over ten
years, it's likely some of these accounts are effectively defunct.
It
; - 3.x version
>
> will be the best today, so I will prepare updates in documentation
>
>
> On Fri, 7 Feb 2025 at 13:30, Elliotte Rusty Harold wrote:
> >
> > On Fri, Feb 7, 2025 at 8:50 AM Slawomir Jaranowski
> > wrote:
> >
> > > I would like to main
No, not important. Development branches that aren't released aren't
especially risky. We need to be careful about what we ship, not random
sets of changes that have to be reviewed and merged into master before
they ship.
--
Elliotte Rusty Harold
x27;ve made more invasive changes
in the past to increase security, most notably requiring https for
downloading artifacts, so I'm confident we can do this too.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubsc
or the broader community quickly moving to Maven 4. :-(
--
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
mmitters + 1 PMC or b) 2 PMC have to approve.
>
>
> Let's have a constructive discussion here on the ML.
>
> @Hervè I'm open to update site when we have agreed on any result :)
>
> Greeting
> Matthias
>
> [1] https://github.com/apache/maven-site/pull/569
>
>
x version
>
> If there are no objections I will try to do it in this way.
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For addi
If you look at https://github.com/apache/maven-jlink-plugin/issues
you'll notice that all the issues from the Jira have been copied into
github multiple times.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscri
in-testing-archives/LATEST
>
> Please review and vote !
>
> Cheers,
> Guillaume Nodet
>
>
> --
>
> Guillaume Nodet
--
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
tps://www.io7m.com
> >
> > ---------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
>
> Guillaume Nodet
--
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
Cservenák wrote:
>
> Howdy,
>
> So let me get this straight: you are now suffering from
> "unknown branches and/or junkyard of branches in canonical repo"?
> While you still refuse to use forks?
>
> T
>
> On Fri, Jan 24, 2025 at 12:58 PM Elliotte Rusty H
Can I delete the maven-3.x-next branch in the github repo? It appears
to be a relic of circa 3.5.0 and is not the actual current 3.x branch,
which I'm still looking for.
--
Elliotte Rusty Harold
elh...@ibiblio.org
---
ub.com/apache/maven-xinclude-extension/blob/main/src/main/java/org/apache/maven/xinclude/LocalXmlResolver.java
>
> Le jeu. 23 janv. 2025 à 12:55, Elliotte Rusty Harold a
> écrit :
>
> > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt wrote:
> > >
> >
> > &g
an. Do you
really want to include an entire pom.xml? Probably not, and XPath
fragment identifiers aren't well understood or supported.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@m
--
> 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
> with registration number SC005336. Is e buidheann carthannais a th’ ann an
> Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
>
--
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
repository.
>
> I presume the lack of that (plus ‘Discussions’ and ‘Wiki’ tabs) is a
> configuration thing.
>
> Can someone please fix that for me?
>
> Thanks in advance.
>
> Later,
>
> Andy
>
> From: Elliotte Rusty Harold
> Date: Tuesday, 7 January
land,
> with registration number SC005336. Is e buidheann carthannais a th’ ann an
> Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
>
--
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
anup in canonical reposes as well...
>
> TL;DR: fork and create PRs from forks please.
>
> Thanks,
> T
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
ps://arstechnica.com/tech-policy/2024/05/slack-defends-default-opt-in-for-ai-training-on-chats-amid-user-outrage/
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.or
probably not. Seriously these are
such trivial matters, I don't understand why anyone would care. The
only real problem I've seen is a noisy mailing list, and that's
because the mailing list is badly configured, not because folks use
branche
ges" this project. We are all pawns
> on the table.
>
> Thanks
> T
>
> On Mon, Jan 6, 2025 at 4:53 PM Tamás Cservenák wrote:
> >
> > Howdy,
> >
> > And I guess fixing the mailing list will also take care of all your
> > branches in canonical repo, i
e mailing list.
--
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
On Mon, Jan 6, 2025 at 7:38 AM Guillaume Nodet wrote:
>
> Le dim. 5 janv. 2025 à 15:49, Elliotte Rusty Harold
> a écrit :
> >
> > I do think the mailing list is severely misconfigured if it's paying
> > any attention to dev branches. There's no reason it s
o be worked on. Disabling new issue
creation is a good idea.
--
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
he other repos? This is
important.
--
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
bugs,
even things that make code actively worse.
--
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
s "ML is misconfigured"
> - then I asked you who will clean up these vaguely named branches you
> create in canonical repo
> - you came back with "branches as cheap" and "eventually project will
> move off git" and "branches are how git works&qu
es for developers to
follow instead of fixing broken tooling — like apparently whatever is
sending commit messages to the mailing list — is not the way to go.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-
happening in canonical
> ASF reposes, so IMHO this is not a "red herring".
> Just use a fork, that's all.
>
> Thanks
> T
>
> On Sat, Jan 4, 2025 at 3:26 PM Elliotte Rusty Harold
> wrote:
> >
> > This shouldn't be a problem if we disable e
> 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
1 - 100 of 627 matches
Mail list logo
