> -Original Message-
> From: Emmanuel Bourg
> Sent: Wednesday, June 08, 2011 16:25
> To: Commons Developers List
> Subject: Re: [VOTE] Revised dormancy policy - take 3
>
> Le 07/06/2011 22:24, Phil Steitz a écrit :
>
> > 2) To revive a component requi
Le 07/06/2011 22:24, Phil Steitz a écrit :
2) To revive a component requires a VOTE. Any ASF committer interested in
bringing the zombie back to life can initiate this action. Revival VOTEs
are majority rule.
I'm -1 on this revival rule. A vote implies that the revival could be
rejected, an
On 6/8/11 8:05 AM, James Carman wrote:
> On Wed, Jun 8, 2011 at 10:06 AM, Phil Steitz wrote:
>> That would then still require a sandbox promotion VOTE and I see no
>> reason to fuss with moving svn and the site to the sandbox just to
>> revive something. The idea in the proposal is you just go ba
On Wed, Jun 8, 2011 at 10:06 AM, Phil Steitz wrote:
>
> That would then still require a sandbox promotion VOTE and I see no
> reason to fuss with moving svn and the site to the sandbox just to
> revive something. The idea in the proposal is you just go back to
> hacking on the revived zombie in c
+1
I kind of know Jelly will come here...
And with this rule, it feels like it might allow me to smoothly restart work on
jelly when time comes, then request a vote for removal of dormancy when I feel
confident.
As answered by Phil to James, I believe that the vote is only considered with
tha
ant. Implementation
details will be worked out once we have consensus that we want to
take this step.
>> -Original Message-
>> From: Phil Steitz [mailto:phil.ste...@gmail.com]
>> Sent: Tuesday, June 07, 2011 16:25
>> To: Commons Developers List
>> Subject: [VOTE]
On 6/8/11 4:16 AM, James Carman wrote:
> I really don't like the idea of having a vote to revive something
I think we all agree on the "low bar for revival" principle. I
removed the traditional "rule of 3" that we have applied in the past
even for sandbox promotions from the proposal, so all tha
I really don't like the idea of having a vote to revive something.
I'd say that if a commons committer has an itch, then let them scratch
it in the sandbox if they want to. Do we really need a special
procedure here? Can't we just say that you have to revive it into the
sandbox and then follow th
Le 07/06/2011 22:24, Phil Steitz a écrit :
Thanks, all, for the great comments on the previous versions [1][2].
I have tried to incorporate them.
Revised Dormancy Policy
0) To move a component to dormant requires a VOTE. A single -1
suffices to postpone the action; but a -1 in a dormancy vote
8, 2011 at 12:02 AM, Jason Pyeron wrote:
> -1, needs better handling of details and an outside revival procedure.
>
>> -Original Message-
>> From: Phil Steitz [mailto:phil.ste...@gmail.com]
>> Sent: Tuesday, June 07, 2011 16:25
>> To: Commons Developers List
&g
-1, needs better handling of details and an outside revival procedure.
> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com]
> Sent: Tuesday, June 07, 2011 16:25
> To: Commons Developers List
> Subject: [VOTE] Revised dormancy policy - take 3
>
>
+1
Oliver
Am 07.06.2011 22:24, schrieb Phil Steitz:
Thanks, all, for the great comments on the previous versions [1][2].
I have tried to incorporate them.
Revised Dormancy Policy
0) To move a component to dormant requires a VOTE. A single -1
suffices to postpone the action; but a -1 in a do
Thanks, all, for the great comments on the previous versions [1][2].
I have tried to incorporate them.
Revised Dormancy Policy
0) To move a component to dormant requires a VOTE. A single -1
suffices to postpone the action; but a -1 in a dormancy vote is
really a +1 to help sustain or advance th
>>> If someone goes and
>>> keeps on working stuff ... well ... then that status is nullified by
>>> merit. (not through a single commit though) I don't see a reason to
>>> forbid svn access
>
> dormancy should be a "lean status" easy to change into sandbox or
> active component. dormancy should be
I like the new dormancy suggestion, plus:
> I am OK with changing "revival" to require only
> one ASF committer.
and:
>> If someone goes and
>> keeps on working stuff ... well ... then that status is nullified by
>> merit. (not through a single commit though) I don't see a reason to
>> forbid sv
On Tue, May 17, 2011 at 7:56 AM, Torsten Curdt wrote:
> IMO "domant" is just an indication of a status. If someone goes and
> keeps on working stuff ... well ... then that status is nullified by
> merit. (not through a single commit though) I don't see a reason to
> forbid svn access ...that's the
On May 17, 2011, at 11:59, Phil Steitz wrote:
> On 5/17/11 2:27 AM, Emmanuel Bourg wrote:
>> What is the goal of this policy? Is it meant to lure users away
>> from the component because it's obsolete or seriously broken? Is
>> it an attempt to get new developers interested in maintaining the
>>
On 5/17/11 2:27 AM, Emmanuel Bourg wrote:
> What is the goal of this policy? Is it meant to lure users away
> from the component because it's obsolete or seriously broken? Is
> it an attempt to get new developers interested in maintaining the
> component? Or a mere indication that no support will b
What is the goal of this policy? Is it meant to lure users away from the
component because it's obsolete or seriously broken? Is it an attempt to
get new developers interested in maintaining the component? Or a mere
indication that no support will be provided for this component?
- If the compo
- "Phil Steitz" a écrit :
> On 5/16/11 4:21 PM, sebb wrote:
> > On 17 May 2011 00:07, Gary Gregory wrote:
> >> On Mon, May 16, 2011 at 5:57 PM, Paul Libbrecht
> wrote:
> >>
> >>> So we should relaunch a vote?
> >>> (or... I should vote a no and relaunch?)
> >>>
> >>> paul
> >>>
> >>>
> >>>
+1 to Gary's idea and Torsten considerations
Have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, May 17, 2011 at 8:56 AM, Torsten Curdt wrote:
> IMO "domant" is just an indication of a status. If someone goes and
> keeps on working stuff ... well ... t
IMO "domant" is just an indication of a status. If someone goes and
keeps on working stuff ... well ... then that status is nullified by
merit. (not through a single commit though) I don't see a reason to
forbid svn access ...that's the wrong signal. We just need to agree
and maintain and communica
+1.
I still expect us to send truly dead items to the Attic.
Hen
On Mon, May 16, 2011 at 10:52 AM, Phil Steitz wrote:
> I would like to take the proposal made in [1], modified per
> discussion on that thread to a VOTE, so we can start implementing
> the policy.
>
> The provisions are as follows
On 5/16/11 4:21 PM, sebb wrote:
> On 17 May 2011 00:07, Gary Gregory wrote:
>> On Mon, May 16, 2011 at 5:57 PM, Paul Libbrecht wrote:
>>
>>> So we should relaunch a vote?
>>> (or... I should vote a no and relaunch?)
>>>
>>> paul
>>>
>>>
>>> Le 16 mai 2011 à 23:44, Phil Steitz a écrit :
>>>
>>
+ 1 with change to d to be "svn is open but no release without a vote".
Ralph
On May 16, 2011, at 10:52 AM, Phil Steitz wrote:
> I would like to take the proposal made in [1], modified per
> discussion on that thread to a VOTE, so we can start implementing
> the policy.
>
> The provisions are a
On 17 May 2011 00:07, Gary Gregory wrote:
> On Mon, May 16, 2011 at 5:57 PM, Paul Libbrecht wrote:
>
>> So we should relaunch a vote?
>> (or... I should vote a no and relaunch?)
>>
>> paul
>>
>>
>> Le 16 mai 2011 à 23:44, Phil Steitz a écrit :
>>
>> >>> d) svn remains open (but no commits witho
On Mon, May 16, 2011 at 5:57 PM, Paul Libbrecht wrote:
> So we should relaunch a vote?
> (or... I should vote a no and relaunch?)
>
> paul
>
>
> Le 16 mai 2011 à 23:44, Phil Steitz a écrit :
>
> >>> d) svn remains open (but no commits without revival vote)
> >> It seems slightly too harsh to me
On 5/16/11 2:57 PM, Paul Libbrecht wrote:
> So we should relaunch a vote?
> (or... I should vote a no and relaunch?)
Lets see how others respond. There may be other changes...
Phil
> paul
>
>
> Le 16 mai 2011 à 23:44, Phil Steitz a écrit :
>
d) svn remains open (but no commits without rev
So we should relaunch a vote?
(or... I should vote a no and relaunch?)
paul
Le 16 mai 2011 à 23:44, Phil Steitz a écrit :
>>> d) svn remains open (but no commits without revival vote)
>> It seems slightly too harsh to me.
>> Since jelly is among the heaviest targeted ones here, I think the wh
On 5/16/11 2:34 PM, Paul Libbrecht wrote:
> Sorry Phil,
>
> I missed that one. I would like to adjust that policy at line:
>>d) svn remains open (but no commits without revival vote)
> It seems slightly too harsh to me.
> Since jelly is among the heaviest targeted ones here, I think the whole
Sorry Phil,
I missed that one. I would like to adjust that policy at line:
>d) svn remains open (but no commits without revival vote)
It seems slightly too harsh to me.
Since jelly is among the heaviest targeted ones here, I think the whole
dormancy aspect would fit but preventing commits so
+1
-Rahul
On Mon, May 16, 2011 at 1:52 PM, Phil Steitz wrote:
> I would like to take the proposal made in [1], modified per
> discussion on that thread to a VOTE, so we can start implementing
> the policy.
>
> The provisions are as follows:
>
> 0) To move a component to dormant requires a VOTE.
+1 for me, sounds a wise procedure
thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, May 16, 2011 at 7:52 PM, Phil Steitz wrote:
> I would like to take the proposal made in [1], modified per
> discussion on that thread to a VOTE, so we can start implementing
I would like to take the proposal made in [1], modified per
discussion on that thread to a VOTE, so we can start implementing
the policy.
The provisions are as follows:
0) To move a component to dormant requires a VOTE. A single -1
suffices to postpone the action; but a -1 in a dormancy vote is
34 matches
Mail list logo
