[VOTE RESULT] Merge IMAP code to trunk

[Stefano Bagnara <ap...@bago.org>]

Ok, 3 days passed.

+1
Norman Maurer (binding)
Stefano Bagnara (binding)
Guillermo Grandes
Joachim Draeger
Bernd Fondermann (binding)
Vincenzo Gianferrari Pini (binding)

+/- 0
none

-1
none

I will merge it asap.

Stefano

Norman Maurer wrote:
> Hi all,
> 
> i just want to start this vote for mergin the imap code which is now 
> located in a branch to trunk.. I think we can do this without risk..
> 
> So my VOTE:
> 
> +1
> 
> Norman



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [VOTE RESULT] Merge IMAP code to trunk

[Danny Angus <da...@gmail.com>]

On 10/19/06, Serge Knystautas <sk...@gmail.com> wrote:

> Can we just discuss the underlying issue?  Noel knows this software
> inside and out and made the majority of the commits for a couple of
> years there.  Now he doesn't have time to check emails daily and
> always participate timely in a very active group.  How do we make that
> work?  How do let the community make changes as fast as possible and
> get Noel's opinion constructively added to the mix?

IMHO the community of active developers has the right to make
decisions like this by lazy consensus, Noel, (and you and I) have the
right to be involved in a timely manner, or to step back, or even to
get involved after the fact. The goal should be to allow James to
progress, if  the older generation wants to remain involved we must do
so in good time, and not be a dead weight holding the project back.

The two issues I can see are a) that the PMC must have sufficient
oversight, because decisions made on the dev list cannot be anything
other than decisions delegated to the dev list from the PMC. But in
this case we have enough PMC members voting to ensure that there is
adequate PMC involvement.
And b) decisions made without the involvement of all of us *might* be
less well thought out than if all of our experience is brough to the
discussion.
Just might.
In that case it should really be up to the *active* group to decide
whether they believe that an extension to allow those of us who's time
is much more highly contended to add our 2c. In this case I don't
think the time scale was too short, I might have been happier if my +1
would have been counted, but it would have been +1 and I doubt that
Noel's would have been anything else either.

James is in the funny position right now of having two generations of
community, the older one is much less active but has knowedge of
lessons we've learned in the past, the newer generation is very
active, but may not be aware of stuff we've done or the reasons for
decisions we've made in the past. It is all of our responsibility to
make this division work for the benefit of the project, and it isn't
always easy but I don't see anyone at fault in this.
d.

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: [VOTE RESULT] Merge IMAP code to trunk

["Noel J. Bergman" <no...@devtech.com>]

Serge Knystautas wrote:

> Noel J. Bergman wrote:
> > See the final paragraph of that page.  People get a
> bit "rule happy", and that's never good.

> You did not make your point but argued about the rules,
> so you were being just as "rule happy" as Stefano.

Actually, I wasn't referring to Stefano at all.  It was a generic comment
about something that is rather common, and why not everything is always
spelled out.  Avalon suffered from it constantly, and a would normally be my
exemplar, not Stefano.  Being rule happy isn't an issue I've had with
Stefano.

> Can we just discuss the underlying issue?

I wasn't really raising one.  I had thought about it, but it wasn't really
worth raising.  I was simply trying to point out that there really isn't a
final result for this sort of thing because a change can always be vetoed in
the future.  And that is a solution to the generic problem to which you
refer.

FWIW, I do review every commit notice, at least cursorily, and sometimes in
more detail.  I just don't always comment about it unless I notice something
worth commenting upon.  I might, of course, miss something.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [VOTE RESULT] Merge IMAP code to trunk

[Serge Knystautas <sk...@gmail.com>]

On 10/17/06, Noel J. Bergman <no...@devtech.com> wrote:
> See the final paragraph of that page.  People get a bit "rule happy", and
> that's never good.

Noel, I think this is unfair.  You did not make your point but argued
about the rules, so you were being just as "rule happy" as Stefano.

Can we just discuss the underlying issue?  Noel knows this software
inside and out and made the majority of the commits for a couple of
years there.  Now he doesn't have time to check emails daily and
always participate timely in a very active group.  How do we make that
work?  How do let the community make changes as fast as possible and
get Noel's opinion constructively added to the mix?

-- 
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

[LONG] About voting rules (Was: [VOTE RESULT] Merge IMAP code to trunk)

[Stefano Bagnara <ap...@bago.org>]

Noel J. Bergman wrote:
> Stefano Bagnara wrote:
> 
>> Noel J. Bergman wrote:
>>>> Ok, 3 days passed.
> 
>>> Code changes can be vetoed at any time, resulting only in the inability
> to
>>> cut a release containing them.
> 
>> it seems that we followed the right procedure.
> 
> You followed a procedure.  The point is that code votes are never closed.

This should be added to that page: it is a really important thing. It 
should be much more clear what does it mean "Votes should generally be 
permitted to run for at least 72 hours to provide an opportunity for all 
concerned persons to participate regardless of their geographic 
locations." and that this does not apply to code modifications.

In fact it should be cleared also why a VOTE is needed and when the VOTE 
start to have some meaning in a code change proposal. How much you have 
to wait to decide that you can go ahead and apply the change?
I think that the 72 hours and 3 +1 is a clear rule. Of course PMC 
members should make of their best to be able to reply in that 72 hours 
or at least to say they need some more time or anything similar 
otherwise the procedure has no more a clear workflow and this is BAD.

I also agree that a PMC member should have always enough power to raise 
a problem and say that something applied 2 years ago shouldn't be there 
and should be removed. But this has nothing to do with "the rule".

If you think that James project needs more than 72 hours we can increase 
it, but imho it is important to have a fixed amount of time otherwise 
people won't ever know if they are following the correct workflow or not.

>> http://www.apache.org/foundation/voting.html does not say anything
>> about your sentence.
> 
>> you should add the rule to that page so anyone will know how VOTEs work.
> 
> See the final paragraph of that page.  People get a bit "rule happy", and
> that's never good.

I agree. But if you say there is a rule, that rule should be written 
there, otherwise we can't consider we agree on that rule.

>>> Votes should generally be permitted to run for at least 72 hours to
>>> provide an opportunity for all concerned persons to participate
>>> regardless of their geographic locations.
> 
> Well, I was going to observe that 72 hours is a bit short when voting during
> a conference, over a holiday, etc., but had decided against conflating two
> points.

This is why I think that voting +/- 0 is always better than non-voting: 
because you let know people you are there.
I would accept to wait until ALL the votes have been casted if we only 
had a more reactive/active team ;-)

I don't know when conferences or holidays take place, so maybe it would 
be better if PMC members announce their unavailability when it happens 
so that votes will be made much longer.

If you instead think that we should use 120 hours instead of 72 for 
james, or 3 full days excluding saturday and sunday or any other similar 
rule feel free to propose it.

I just want to have a clear workflow, because I don't like to have 
doubts about doing something wrong simply because the rule is not clear 
or we have different opinions on what is right and what is wrong ;-)

> And you do need closure for some sorts of votes, e.g., a Committer, a
> Release, etc.  For code, you can operate on lazy consensus until a veto.
> 
> 	--- Noel


Ok, but this is not what I understand from "Votes on Code Modification":
I know my english is not good, but I'm almost sure this is not clear and 
people can't understand this from that page.

My understanding of the voting about code modification is that you can 
use 2 styles:

1) Lazy Consensus: this is an alternative to voting, and you simply 
start a message (without the VOTE prefix) to let people know you're 
making some sort of modification: "The patch below fixes bug #8271847; 
if no-one objects within three days, I'll assume lazy consensus and 
commit it." After the 3 days you commit it. Anyone can raise his own 
voice to block this or to revert this later.

2) Real Vote: three +1 votes are required for a code-modification 
proposal to pass and no -1 votes. There is no other rules.

I think that major changes should always follow the real vote workflow, 
while lazy consensus should be used for minor things.

If this is not what the ASF intended with the rules, I believe it should 
be made more clear because I think I'm not the only one interpreting 
that words this way.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: [VOTE RESULT] Merge IMAP code to trunk

["Noel J. Bergman" <no...@devtech.com>]

Stefano Bagnara wrote:

> Noel J. Bergman wrote:
>>> Ok, 3 days passed.

>> Code changes can be vetoed at any time, resulting only in the inability
to
>> cut a release containing them.

> it seems that we followed the right procedure.

You followed a procedure.  The point is that code votes are never closed.

> http://www.apache.org/foundation/voting.html does not say anything
> about your sentence.

> you should add the rule to that page so anyone will know how VOTEs work.

See the final paragraph of that page.  People get a bit "rule happy", and
that's never good.

> > Votes should generally be permitted to run for at least 72 hours to
> > provide an opportunity for all concerned persons to participate
> > regardless of their geographic locations.

Well, I was going to observe that 72 hours is a bit short when voting during
a conference, over a holiday, etc., but had decided against conflating two
points.

And you do need closure for some sorts of votes, e.g., a Committer, a
Release, etc.  For code, you can operate on lazy consensus until a veto.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [VOTE RESULT] Merge IMAP code to trunk

[Stefano Bagnara <ap...@bago.org>]

Noel J. Bergman wrote:
>> Ok, 3 days passed.
> 
> Code changes can be vetoed at any time, resulting only in the inability to
> cut a release containing them.
> 
> 	--- Noel


Sorry but I don't understand your sentence.

I just read again the http://www.apache.org/foundation/voting.html and 
it seems that we followed the right procedure. That page does not say 
anything about your sentence. I don't have anything with that "rule" but 
you should add the rule to that page so anyone will know how VOTEs work.

 > Votes should generally be permitted to run for at least 72 hours to
 > provide an opportunity for all concerned persons to participate
 > regardless of their geographic locations.

DONE

 > Votes on Code Modification
 > Unless a vote has been declared as using lazy consensus, three +1
 > votes are required for a code-modification proposal to pass.

DONE

 > Votes on Package Releases
 > Votes on whether a package is ready to be released follow a format
 > similar to majority approval  -- except that the decision is
 > officially determined solely by whether at least three +1 votes were
 > registered. Releases may not be vetoed.

This one say something different (against) your sentence: in fact once 
this vote has passed I understand that we could start a vote for a 
release and vetoes would not be applicable.

Did I understand wrong? is the voting explanation page outdated? Can you 
elaborate?

Thank you,
Stefano

PS: again, I don't have problem with "your rule", because I think we 
should not need a strict rule for voting as they are a tool to express 
opinions and opinions can change or anything else, but since your 
sentence is not clear to me wrt "apache rules" I would like to understand.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: [VOTE RESULT] Merge IMAP code to trunk

["Noel J. Bergman" <no...@devtech.com>]

> Ok, 3 days passed.

Code changes can be vetoed at any time, resulting only in the inability to
cut a release containing them.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org