On Tue, Nov 2, 2010 at 3:19 PM, Jason van Zyl wrote:
>
> On Nov 2, 2010, at 6:41 PM, Brian Fox wrote:
>
>> I don't see why it would be any different than if you took that same
>> code from an svn patch in Jira.
>
> Have you actually used Git with someone else, or processed a pull request?
>
Dude
On Tue, Nov 2, 2010 at 2:19 PM, Jason van Zyl wrote:
>
> At Apache? There is no IP review process. What are you talking about?
Contributor License Agreements are available from Apache -- I think
used mostly when a committer joins and external projects migrate in
the incubator.
Quote from the lic
On Nov 2, 2010, at 6:41 PM, Brian Fox wrote:
> I don't see why it would be any different than if you took that same
> code from an svn patch in Jira.
Have you actually used Git with someone else, or processed a pull request?
> The point is that there's a threshold
> to a code contribution that
I don't see why it would be any different than if you took that same
code from an svn patch in Jira. The point is that there's a threshold
to a code contribution that requires an ip review process. The
mechanism if it's a patch file or a pull request shouldn't matter if
we trust the committers to d
On Tue, Nov 2, 2010 at 12:30 PM, Jason van Zyl wrote:
>
>> Is there a way we can utilise pull requests from github.org/apache and still
>> get them back to the svn repository so we can try this in a meaningful way?
I thought any code stored in SVN but developed outside of Apache
requires going t
On Nov 2, 2010, at 5:00 PM, Brett Porter wrote:
>
> On 02/11/2010, at 6:06 AM, Jason van Zyl wrote:
>
>>
>>
>>> Those parts are about 10% at the start and end. The rest is in the middle,
>>> and perhaps the pressure to fix more things while you are there.
>>>
>>
>> No, I think it's mostly
On 02/11/2010, at 6:06 AM, Jason van Zyl wrote:
>
>
>> Those parts are about 10% at the start and end. The rest is in the middle,
>> and perhaps the pressure to fix more things while you are there.
>>
>
> No, I think it's mostly not seeing the patches and no one actively
> cultivating the p
On Nov 2, 2010, at 9:23 AM, Brett Porter wrote:
>
> On 01/11/2010, at 10:26 PM, Brian Fox wrote:
>
>>> The barrier to collaboration is high here.
>>
>> That's all I'm saying. The tools make that partially true but it's not
>> stopping other projects so it's clearly not the only issue. Maybe no
On 2 November 2010 08:23, Brett Porter wrote:
>
> On 01/11/2010, at 10:26 PM, Brian Fox wrote:
>
>>> The barrier to collaboration is high here.
>>
>> That's all I'm saying. The tools make that partially true but it's not
>> stopping other projects so it's clearly not the only issue. Maybe no
>> on
On 2 November 2010 08:26, Brett Porter wrote:
>
> On 01/11/2010, at 6:42 PM, Stephen Connolly wrote:
>
>> On 1 November 2010 21:37, Dennis Lundberg wrote:
>>> On 2010-11-01 22:10, Stephen Connolly wrote:
Then -1 the commits.
We have a commit first, ask forgiveness second policy in
On 01/11/2010, at 6:42 PM, Stephen Connolly wrote:
> On 1 November 2010 21:37, Dennis Lundberg wrote:
>> On 2010-11-01 22:10, Stephen Connolly wrote:
>>> Then -1 the commits.
>>>
>>> We have a commit first, ask forgiveness second policy in maven last time I
>>> checked
>>
>> So do you think th
On 01/11/2010, at 10:26 PM, Brian Fox wrote:
>> The barrier to collaboration is high here.
>
> That's all I'm saying. The tools make that partially true but it's not
> stopping other projects so it's clearly not the only issue. Maybe no
> one really cares about these plugins, and for the ones ra
>The barrier to collaboration is high here.
That's all I'm saying. The tools make that partially true but it's not
stopping other projects so it's clearly not the only issue. Maybe no
one really cares about these plugins, and for the ones raised so far,
that's probably the case.
-
On Nov 2, 2010, at 2:31 AM, Brian Fox wrote:
> 2010/11/1 Arnaud Héritier :
>> I agree.
>> Perhaps for some of them we could discuss to move them to mojo.codehaus.org
>> to let the community take the lead on them if we find some volunteers (I'm
>> thinking about the eclipse plugin for example).
2010/11/1 Arnaud Héritier :
> I agree.
> Perhaps for some of them we could discuss to move them to mojo.codehaus.org
> to let the community take the lead on them if we find some volunteers (I'm
> thinking about the eclipse plugin for example).
It probably needs to be said that if people want to
2010/11/1 Dennis Lundberg :
> I've now reverted the changes in svn.
Thank Dennis to have catch up the legendary Jason's speed.
Vincent
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: d
On 2010-11-01 23:50, Stephen Connolly wrote:
> On 1 November 2010 22:32, Dennis Lundberg wrote:
>> That is something we need to add to the process. But until the process
>> has been finalized I think we should revert the svn moves.
>>
>
> +1
>
> In the absense of a process, since retirement is e
On Nov 1, 2010, at 11:32 PM, Dennis Lundberg wrote:
> On 2010-11-01 23:19, Vincent Siveton wrote:
>> 2010/11/1 Jason van Zyl :
>>>
>>> On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
>>>
Hi,
I agree in the fact to move unmaintened plugins but god, why are you
so quick o
On Nov 1, 2010, at 11:19 PM, Vincent Siveton wrote:
> 2010/11/1 Jason van Zyl :
>>
>> On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
>>
>>> Hi,
>>>
>>> I agree in the fact to move unmaintened plugins but god, why are you
>>> so quick one more time!
>>> You asked Dennis to create a wiki pa
On 1 November 2010 22:32, Dennis Lundberg wrote:
> That is something we need to add to the process. But until the process
> has been finalized I think we should revert the svn moves.
>
+1
In the absense of a process, since retirement is essentially an SVN
operation, then our commit first forgive
On 1 November 2010 21:37, Dennis Lundberg wrote:
> On 2010-11-01 22:10, Stephen Connolly wrote:
>> Then -1 the commits.
>>
>> We have a commit first, ask forgiveness second policy in maven last time I
>> checked
>
> So do you think that it's OK for someone to pull the rug from under your
> feet, w
On 2010-11-01 23:19, Vincent Siveton wrote:
> 2010/11/1 Jason van Zyl :
>>
>> On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
>>
>>> Hi,
>>>
>>> I agree in the fact to move unmaintened plugins but god, why are you
>>> so quick one more time!
>>> You asked Dennis to create a wiki page but you al
2010/11/1 Jason van Zyl :
>
> On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
>
>> Hi,
>>
>> I agree in the fact to move unmaintened plugins but god, why are you
>> so quick one more time!
>> You asked Dennis to create a wiki page but you already retired the
>> plugins.
>
> Yes, because I would
in after! We are a community Jason!
>
And I'll happily abide by stuff we document.
> Cheers,
>
> Vincent
>
> -- Forwarded message --
> From: Jason van Zyl
> Date: 2010/11/1
> Subject: Re: Culling dead/inactive plugins
> To: Maven Developers Lis
,
Vincent
-- Forwarded message --
From: Jason van Zyl
Date: 2010/11/1
Subject: Re: Culling dead/inactive plugins
To: Maven Developers List
I started moving any of the ones discussed here:
http://svn.apache.org/repos/asf/maven/retired/
If anyone disagrees we can move them back
On Nov 1, 2010, at 10:37 PM, Dennis Lundberg wrote:
> On 2010-11-01 22:10, Stephen Connolly wrote:
>> Then -1 the commits.
>>
>> We have a commit first, ask forgiveness second policy in maven last time I
>> checked
>
> So do you think that it's OK for someone to pull the rug from under your
> fe
On 2010-11-01 22:10, Stephen Connolly wrote:
> Then -1 the commits.
>
> We have a commit first, ask forgiveness second policy in maven last time I
> checked
So do you think that it's OK for someone to pull the rug from under your
feet, while you are working on something?
(as in my work on the St
On 2010-11-01 22:14, Jason van Zyl wrote:
>
> On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote:
>
>> Hi Jason
>>
>> Doing some house cleaning among our plugins is a good thing, and I'm in
>> favor of retiring those that we feel that we cannot support.
>>
>> However it is not OK for you to go ch
On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote:
> Hi Jason
>
> Doing some house cleaning among our plugins is a good thing, and I'm in
> favor of retiring those that we feel that we cannot support.
>
> However it is not OK for you to go changing things in Subversion less
> than an hour afte
On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote:
> Hi Jason
>
> Doing some house cleaning among our plugins is a good thing, and I'm in
> favor of retiring those that we feel that we cannot support.
>
> However it is not OK for you to go changing things in Subversion less
> than an hour afte
Then -1 the commits.
We have a commit first, ask forgiveness second policy in maven last time I
checked
- Stephen
On 1 Nov 2010 21:05, "Dennis Lundberg" wrote:
Hi Jason
Doing some house cleaning among our plugins is a good thing, and I'm in
favor of retiring those that we feel that we cannot
Hi Jason
Doing some house cleaning among our plugins is a good thing, and I'm in
favor of retiring those that we feel that we cannot support.
However it is not OK for you to go changing things in Subversion less
than an hour after your proposal (which wasn't even labeled as one).
That is not the
I started moving any of the ones discussed here:
http://svn.apache.org/repos/asf/maven/retired/
If anyone disagrees we can move them back but I think the ones suggest so far
are good candidates.
On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote:
> Following up from a discussion on the user list.
On Nov 1, 2010, at 1:41 PM, Arnaud Héritier wrote:
> I agree.
> Perhaps for some of them we could discuss to move them to mojo.codehaus.org
> to let the community take the lead on them if we find some volunteers (I'm
> thinking about the eclipse plugin for example).
>
+1 to moving out the mave
I agree.
Perhaps for some of them we could discuss to move them to mojo.codehaus.org to
let the community take the lead on them if we find some volunteers (I'm
thinking about the eclipse plugin for example).
Arnaud
On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote:
> Following up from a discussi
Following up from a discussion on the user list. I think it's time to be
realistic about providing a healthy level of support for plugins here. I think
it makes more sense to reduce the foot print of plugins we say we support and
do those well as opposed to housing many plugin that just don't ge
36 matches
Mail list logo
