struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
Subject Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Date Wed, 16 Jan 2008 18:52:50 GMT
Ted Husted wrote:
> A release is not an action that requires consensus approval. It's a
> majority action. Look farther down under "Release Plan" and "Release
> Grade".

Ah your right!  Ok, in that case:

"An action requiring majority approval must receive at least 3 binding 
+1 votes and more +1 votes than -1 votes"

That would apply then, correct?  In which case, I don't think the case 
is any different: if a binding vote is the same as a non-binding vote, 
as Niall and others have said, then non-binding voters can still hault a 
majority action, and hence the release, based on what that statement 
says.  Are we OK with that?  If not, then it's tantamount to saying 
binding votes are not the same as non-binding votes.  Getting consensus 
on that statement, one way or another, is important because the bylaws 
either directly contradict it, or they just need to be massaged a little 
to come in line with the reality.

>> And I think that's a perfectly reasonable way to approach it, but that's
>> not what the bylaws says, nor is it what Nial and Nathan say is in
>> "their books" (I'm not picking on you two by the way, but I don't think
>> you're the only ones that feel that way, hence it's likely a reflection
>> on a larger group feeling).
> 
> Well, first, AFAIK, it's never actually happened. But, if we did have
> a flurry of earnest -1s from regular contributors, I'd probably change
> my own vote, and I expect most other PMC members would do the same.

And I suspect you're right about that.  Make no mistake, I don't believe 
there has ever been an irresponsible vote outcome, certainly none I can 
recall ever seeing.  I'm just saying it would be better to have it all 
codified cleanly, matching the reality, and I'm not at all sure that's 
the case today.

> Which is why we've been having these discussions, to clarify our
> expections. Martin, Niall, Nathan, and I don't chat out-of-band.
> Everything we've had to say to each other, we've said here.

Absolutely, and that's a healthy community at work.  But simply 
clarifying expectations without putting it in writing almost inevitably 
leads to the same kind of discussions down the road, especially in a 
community with members coming and going frequently.

> I asked about a voter's implied intention to make a good-faith effort,
> which is effectively an opinion.

I don't think I'd agree with that... I can have an opinion on what grade 
a release should have for instance, can even vote on it, without any 
intention of supporting it.  I can do this because I cast a non-binding 
vote.  But again, it everyone feels binding==non-binding, I'll certainly 
vote (or simply not vote as the case may be) accordingly.  I still 
believe the bar is higher for binding voters though.

> In the case of a release vote, it occurs to me that the "obligation"
> in question is reviewing the release and forming an opinion as to
> whether it meets our standards our correctness. Where "our" is the
> expectations of the ASF as well as the expectations of the Apache
> Struts Group. The meaning then becomes that we are not simply tossing
> out an armchair opinion, but we are stating an informed opinion based
> on direct experience.

That's interesting... so you see no implied statement in the case of a 
release vote about intention/willingness to support?

> As for our intentions as to support, the general opinion seems to be
> that support is a separate topic from release grade.

Ah, I think that answers my previous question :)  But it begs another: 
how does the question of support get dealt with then?  I'm pushing here 
because I believe it's important that it's clear, not just to Apache 
members, but to anyone that may be thinking of using Struts and 
therefore has some interest in who will or will not (may or may not) 
support a release.

Think of it this way: if someone can't tell by looking at the guiding 
principals of the project, i.e., the bylaws, that those releasing the 
bits believe their votes carries some implied intent to support, and if 
that intention isn't otherwise somehow stated (a separate vote 
perhaps?), then how can that person ever have any confidence whatsoever 
that the bits they are looking at using will have any level of support? 
  And yes, I realize this is open-source where there is never a 
guarantee about such a thing, but we're not talking about making 
guarantees, we're simply talking about good-faith intentions, either 
directly stated or implied, and in the case of implied, that implication 
being codified.

> Since the project is a living working group, and not a political body,
> some ambiguity seems fine, even necessary. Within the ASF boundaries,
> each set of committers should be able to able to put their own spin on
> things, so that the project works for us, not the other way around.

I don't disagree that flexibility is good, to a degerr, and I'm not 
looking to write up a binding contract here either :)  But the fact that 
this discussion began in the first place from an apparent disagreement 
between you and Martin about the meaning of something that there 
probably shouldn't have been any question about in the first place I 
take as a sign that there is some level of disconnect going on, and 
getting the bylaws right if for no other reason than everyone can point 
to it and say "that's the right answer", is the way to deal with it.

> -Ted.

Frank

-- 
Frank W. Zammetti
Author of "Practical Ajax Projects With Java Technology"
  (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
  (2007, Apress, ISBN 1-59059-816-4)
and "Practical DWR 2 Projects"
  (2008, Apress, ISBN 1-59059-941-1)
Java Web Parts - http://javawebparts.sourceforge.net
  Supplying the wheel, so you don't have to reinvent it!

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


Mime
View raw message