On 02/08/2013 12:29 PM, Paul Benedict wrote:
I've stated from the beginning of this thread that it's impossible to
prevent someone from developing outside of Apache. I stand by that still.
That can't be prevented and any attempt will fail since it's not practical.
If my words today aren't clear, I'll try again. My stance isn't about
halting developing elsewhere, but to halt what I (and maybe some others)
perceive as a way of getting around the Apache community.
I won't use your "ultra whizzbang high performance logging" :-) example
because it doesn't fit what my concern; but imagine an existing component
(I won't name any) that is critical and Maven's existence and Maven can't
function without it. It's very easy for any PMC member to go to another OSS
community, develop it, and then kind of leave the other PMCs with no real
"choice" but to use it because the code realizes the future of Maven. Those
other PMCs are really backed into a corner; they have no real recourse to
preventing this, lest Maven development is simply halted altogether. The
other OSS community has other committers, other mailing lists, other
deliberations, etc. Community work and input becomes marginalized here.
Does this make sense to you? That kind of community-splitting effort needs
to stop and that's what I am trying to address.
The Maven group can always port the code back into the Maven project if
the other project is OSS.
If it has gone to a proprietary project (lots of open source stuff goes
that way too), then the Apache maven team will have to invent its own
future to be better or the same as the alternative future.
Not sure how this could happen in real life.
It sounds like the "future of Maven" resided in the head of one person
who felt that the Apache Maven project did not have room for its own
future so he moved on to a team that wanted to make the "future" happen now.
That would appear to be a good thing for Maven users.
The users adopt to this new project and enjoy the future.
The Apache project members who see the "future" as a good thing move to
the new group and the people who did not want to support the "future"
keep supporting the old way.
This would not be the first project that died rather than innovate.
You can't write a policy that protects against this and still stays open
source.
You have no way to stop this from happening nor should you try.
Ron
Cheers,
Paul
On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
We cannot stop somebody from developing something outside of Apache.
So I could go off and write a High Performance Logging API... now I could
be doing that because I want to foist that Logging API on Maven... or I
could be doing it as an experiment that, if successful, I may offer for
Maven to consume... or I could be doing it because I need it for my Day
Job...
We cannot know the reasons why somebody is doing something outside of
Maven... we can ask, but we cannot *know* if the answer we are given is
truthful.
So anyway, I now have this ultra whizzbang high performance logging API and
I am aware of some deficit in the logging performance of Maven, so I spin
up a private fork (it could be a hidden private fork, or it could be a
public one... doesn't matter) and integrate the logging API and low and
behold I see a whopping X% improvement... so I want to bring that back to
Maven...
Is there anything wrong with the above?
If the library I created is under a Category A license and open source and
I go with CTR and nobody vetos my commit... we have consensus... why do we
need to go all Iron Fist and require a vote?
We already have established tools: review of commits, vetos on commits,
mandatory votes for Category B dependencies...
Do we really need *more* processes and procedures to follow?
On 2 August 2013 16:51, Paul Benedict <pbened...@apache.org> wrote:
I don't understand the iron hand analogy. I was expressing the use of a
vote to allow or disallow critical development outside of Apache. The
vote
would lead to a consensus, no?
On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
On 2 August 2013 16:32, Paul Benedict <pbened...@apache.org> wrote:
Furthermore, I'd like to see explicit procedural rules on Maven Core
and
forking. For example, if there's a critical component needing
development
for Core, and a PMC expresses that such development will be done
outside
of
Apache and then used as a dependency, shouldn't there be a vote on
that?
Votes should be a tool to confirm consensus... not an iron hand.
If the consensus of the developers is to use the dependency which is
external to the project, then that is fine. If there is no consensus
then
the dependency will not be introduced.
We already have a policy that adding Category B dependencies to Core
requires approval of the PMC, I don't see that there is much value in
adding even more to this document... but if you can suggest a patch and
people agree with it...
-Stephen
--
Cheers,
Paul
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
