maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baptiste MATHUS ...@batmat.net>
Subject Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
Date Fri, 26 Jul 2013 15:35:30 GMT
Le 25 juil. 2013 23:05, "Stephen Connolly" <stephen.alan.connolly@gmail.com>
a écrit :
>
> Perhaps we could reframe the question a little then (as people seem to be
> testing hung up on the committed wording)...
>
> Should the PMC encourage people experimenting on new improvements to Maven
> to do that work at the ASF?

Sure. I don't see how one could disagree with the statement.

> And if so, should they then practice what they
> preach, and ensure that any experiments with Maven take place on the ASF
> SCM servers (at least once such experiments become semi-serious or
progress
> enough not to cause egg-on-face syndrome)?

Re-reading it with *PMC member* in mind, it also makes sense.
The difficulty is actually defining what is semi-serious, but anyway not
sure I'd see the goal for a *pmc member* to commit his WIP outside the asf.
Sure there's github's facilities to help contribution but there's already
an automatic asf->github mirroring, right?

>
> Shoud the PMC promote other Apache projects, or moving non-Apache projects
> to Apache? (Right now, to work on an issue in core and effect the change
> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
> fine with half of these at Eclipse and the ther half here... Or maybe
> not... But that is a lot of projects where you need to establish merit and
> perhaps maintain merit just to be able to commit directly (which sometimes
> is the only way to effect the type of cross system changes that some of
our
> more obscure bugs may require... GIT makes this less of a requirement, as
> patches on SVN are a PITA, though) )

Not sure how this one could get handled in practice. I suppose this is
better to try and keep them at Apache, but using a myriad of different libs
is a reality in a majority if not all java projects.
To handle code issues, I think this might suffice to check the license
allows a local versions be used (as Jenkins does) to be sure Maven does not
get stuck because of one of those deps.
I think apache projects should be preferred when there's a real equivalence
between two choices. But again defining/agreeing on this can be hard. On
the log4j2/logback side for example, even if I personally use logback on a
daily-basis I'd understand log4j2 be chosen as a default provider because
it's a apache project and the equivalence seems to be more and more a
reality.

Cheers

-- Baptiste

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message