On 26/07/2013 11:35 AM, Baptiste MATHUS wrote:
Le 25 juil. 2013 23:05, "Stephen Connolly" <[email protected]>
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.
Encourage or force! Big difference.
Sometimes groupthink does not reach the best conclusion and an
individual effort may be required to move the state of the art.
OTOH, the majority should not be held up by a person with ideas that the
majority does not want to pursue. Both sides can benefit from a fork.
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.
As a consumer of Apache products, I certainly appreciate the importance
of reducing the number of licenses schemes in a dependency.
This means that I would prefer log4j over a marginally better logging
framework that came with another license even if the terms of the
license are acceptable.
I simply prefer to work with a license that I already have invested time
in understanding and trust rather than a license that I have to research.
Ron
Cheers
-- Baptiste
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
