You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2008/01/15 19:35:39 UTC
Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
On Jan 15, 2008 1:09 PM, Dale Newfield <Da...@newfield.org> wrote:
> Frank W. Zammetti wrote:
> > my feeling is that until a project deprecates a release, then
> > no, there would be no expiration. Anyone who +1'd a release is implying
> > they are willing to support it until it's officially deprecated.
>
> Do we ever deprecate any releases except non-current patch-level ones?
> (I.E.: is W.X.Y automatically deprecated when W.X.Z (where Z>Y) is
> released? Is A.B.C ever deprecated if there exists no A.B.D where D>C?)
Not in so many words. Though, once we move on to the next minor series
(x.1 to x.2), it seems unlikely that we would go back and add new
features to x.1. But if a committer wanted to do it for some reason,
and the release plan and quality vote passed, then it would happen.
The Apache Way favors individual initiative tempered by peer review.
We do deprecate features regularly ... and we even try to remove them
after deprecation :)
The strange part is that while the release plan is lazy majority, and
the quality vote is active majority (3 +1s for quorum and +1s>-1s),
each individual code change is subject to a lazy consensus vote, where
a PMC member has a unilateral veto.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Philip Luppens <ph...@gmail.com>.
On Jan 16, 2008 5:10 PM, Ted Husted <hu...@apache.org> wrote:
> On Jan 16, 2008 12:23 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > That's a fair question, but I have an answer for it. Put simply, I feel
> > that anyone officially made a member of a project team has accepted a
> > greater level of responsibility than someone in the larger user community.
>
> A careful reading of "How it Works" implies that the Apache Way is
> designed so that individual committers do not have to accept a greater
> level of responsibility. The notion is that we can invite enough
> committers to the table that there will always be other volunteers
> available.
>
> @Struts, we seem to have trouble keeping enough active committers in
> play to make up for the committers who are heads-down on our day jobs.
> We also have trouble electing "grassroot contributors" who are not
> star coders. The trouble with electing only star coders is that people
> tend to focus on their own contributions, rather than applying patches
> submitted by others. I can testify that some of the very best features
> in Struts 1 were contributions made by people who where not
> committers.
>
> As PMC member, I would really like to know who intends to be available
> to support a release, or at least who expects to be heads-down for
> awhile. It's not uncommon for a release to pass with a minimum number
> of binding votes. If some of the voters are about to go heads-down on
> another project for six months, I'd like to know that before casting
> my own GA vote. As a group, we really suck at letting each other know
> that we won't be around for a while.
Well, although I'm following the mailing lists and doing the
occasional quickfix in the wiki, I'm pretty much drowning in work. I'm
combining a fulltime consultancy job and a startup, and neither one
has anything serious to do with Struts 2. I would very much like to
'dive into it' again (just like all other WW devs, but everyone,
except Nils (portlets) and Toby (back to support WW), is too busy atm
- at least they were at JavaPolis). So more than advocating Struts 2
in my current enviroment and trying to keep up with some plugins will
not be possible for at least a couple of months (May, June .. ?).
After that, I plan on finally getting those performance tests into
place and releasing some more plugins I have on my harddisk.
Cheers,
Phil
>
>
> On Jan 16, 2008 1:45 AM, Al Sutton <al...@alsutton.com> wrote:
> > We could always switch to holding off releases until we have 0 bugs of major
> > and above level :) (if we did that then we should do the M$ thing and switch
> > the default JIRA level to be the lowest possible and let the user upgrade it
> > rather than everything going in as Major by default).
>
> In practice, we do. There have been many times we counted down to
> rolling a build based on how many outstanding issues we had left.
>
> To an extent, that's what's happening with Struts 2.1.1. When we get
> to zero patches, I would be happy to roll another build. (Though, if
> another committer got antzy, someone else could post another release
> plan and roll one sooner.)
>
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Software Architect - Hydrodesk
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Matt Raible <mr...@gmail.com>.
On Jan 16, 2008, at 8:10 AM, Ted Husted wrote:
> On Jan 16, 2008 12:23 AM, Frank W. Zammetti <fz...@omnytex.com>
> wrote:
>> That's a fair question, but I have an answer for it. Put simply,
>> I feel
>> that anyone officially made a member of a project team has accepted a
>> greater level of responsibility than someone in the larger user
>> community.
>
> A careful reading of "How it Works" implies that the Apache Way is
> designed so that individual committers do not have to accept a greater
> level of responsibility. The notion is that we can invite enough
> committers to the table that there will always be other volunteers
> available.
>
> @Struts, we seem to have trouble keeping enough active committers in
> play to make up for the committers who are heads-down on our day jobs.
> We also have trouble electing "grassroot contributors" who are not
> star coders. The trouble with electing only star coders is that people
> tend to focus on their own contributions, rather than applying patches
> submitted by others. I can testify that some of the very best features
> in Struts 1 were contributions made by people who where not
> committers.
>
> As PMC member, I would really like to know who intends to be available
> to support a release, or at least who expects to be heads-down for
> awhile. It's not uncommon for a release to pass with a minimum number
> of binding votes. If some of the voters are about to go heads-down on
> another project for six months, I'd like to know that before casting
> my own GA vote. As a group, we really suck at letting each other know
> that we won't be around for a while.
Since I'm not currently using Struts 2 in my day job, it's unlikely
that I'll contribute much in the form of working on the project.
However, I will continue to test new releases and support users that
use it as part of AppFuse. If my job changes to one where I'm using
Struts 2, you'll likely see an increase in my activity because I'm
paid to work on it. After 5 years of spending 20+ hours a week on
unpaid open source work, I've been taking a break for the last few
months and I'm really enjoying myself. ;-)
Matt
>
>
> On Jan 16, 2008 1:45 AM, Al Sutton <al...@alsutton.com> wrote:
>> We could always switch to holding off releases until we have 0
>> bugs of major
>> and above level :) (if we did that then we should do the M$ thing
>> and switch
>> the default JIRA level to be the lowest possible and let the user
>> upgrade it
>> rather than everything going in as Major by default).
>
> In practice, we do. There have been many times we counted down to
> rolling a build based on how many outstanding issues we had left.
>
> To an extent, that's what's happening with Struts 2.1.1. When we get
> to zero patches, I would be happy to roll another build. (Though, if
> another committer got antzy, someone else could post another release
> plan and roll one sooner.)
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Ted Husted <hu...@apache.org>.
On Jan 16, 2008 2:14 PM, Antonio Petrelli <an...@gmail.com> wrote:
> Sorry for being rude.
No offense taken.
Like all ASF projects, Apache Struts is modeled after the original
Apache HTTPD Group. In this sense, it is like a group in an operating
system. Everyone in the group has the same privileges (or "karma")
and, we can do all the same things, interchangeably.
The Apache HTTPD Group came about because the NCSA web server was not
being maintained. People needed a scalable and secure web server to
use at work, but no one at NCSA was available to apply the needed
patches.
Much of the Apache Way is designed to keep individuals from becoming
bottlenecks, and to keep companies from controlling the future of a
product. Most people become involved in ASF projects because we use
the product at work, and it is in our professional best interest that
the product be the best that it can be.
A key idea is that an ASF development group is relatively large, so
that if two or three or four of us are busy, there are other
volunteers who can pick up the slack. Unfortunately, in the case of
Struts, we have so few active committers, that if a couple of us
become busy, progress grinds to a halt.
It's OK to busy. It's good to be busy. But, when we become too busy to
do the work, we should at least try to nominate other volunteers who
may be eager to do the work we cannot do.
Spread the joy; share the wealth.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Ted Husted <hu...@apache.org>.
On Jan 16, 2008 4:42 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> What I don't understand is why there's any hesitation to get the bylaws inline with reality,
There's no hesitation. Before acting, some of us just like to give
others a chance to express their own opinions.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Paul Benedict <pb...@apache.org>.
Ted,
I think you're mixing a vote on quality with a vote on support. A +1 should
mean only of those things. If you really want to find out who intends to
support the release, hold another vote on that. For me, when I give a +1,
it's to determine software quality -- not my involvement. My vote is not
about me, but the product.
Paul
On Jan 16, 2008 1:34 PM, Dave Newton <ne...@yahoo.com> wrote:
> One thing we could do is to use a section of the wiki (is the export for
> distribution controlled by... top-level page, or...?) is to provide some
> info
> about expected availability *when such information is available*.
>
> For example, I know that for the next month that I'll be able to work a
> tiny
> bit on work-related issues and a few minor things that have popped up here
> and there as well as continue participating on struts-user.
>
> If we had a clearing house for that kind of low-granularity info it might
> be
> handy for providing a high-level overview of potential participation
> metrics.
>
> I don't think anybody here supposes there is an absolute obligation except
> for having a vote be meaningful and not just "OH HAI +1 KTHXBYE"
> lolstruts.
>
> I can only speak for myself, but voting for me do means I'll do my best to
> resolve issues as they come up and continue to do what little I can on the
> user list. (Albeit a bit testily at times. I'm really quite crabby,
> especially when overloaded like I am at the moment :)
>
> d.
>
> --- Antonio Petrelli <an...@gmail.com> wrote:
>
> > 2008/1/16, Ted Husted <hu...@apache.org>:
> > > As a group, we really suck at letting each other know
> > > that we won't be around for a while.
> >
> > Ted,
> > we are not a group, we are a community. In a group there is a chief,
> > there is a plan, and so on. Most of us (me included) participate in
> > the spare time. For example, I cannot say if I will be busy or not: I
> > work on Struts and Tiles in the evening for one hour or two, by
> > dropping a line of code here and there.
> > Ted, you must not expect from us anything: we are doing our best to
> > help Struts, but no one pays for it. Essentially, at present time,
> > Struts 1 and 2 are "hobby" projects, with valuable code and
> > developers, but nothing more.
> > If you want a "group", recruit it and pay to develop Struts.
> >
> > Sorry for being rude.
> > Antonio
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Dave Newton <ne...@yahoo.com>.
One thing we could do is to use a section of the wiki (is the export for
distribution controlled by... top-level page, or...?) is to provide some info
about expected availability *when such information is available*.
For example, I know that for the next month that I'll be able to work a tiny
bit on work-related issues and a few minor things that have popped up here
and there as well as continue participating on struts-user.
If we had a clearing house for that kind of low-granularity info it might be
handy for providing a high-level overview of potential participation metrics.
I don't think anybody here supposes there is an absolute obligation except
for having a vote be meaningful and not just "OH HAI +1 KTHXBYE" lolstruts.
I can only speak for myself, but voting for me do means I'll do my best to
resolve issues as they come up and continue to do what little I can on the
user list. (Albeit a bit testily at times. I'm really quite crabby,
especially when overloaded like I am at the moment :)
d.
--- Antonio Petrelli <an...@gmail.com> wrote:
> 2008/1/16, Ted Husted <hu...@apache.org>:
> > As a group, we really suck at letting each other know
> > that we won't be around for a while.
>
> Ted,
> we are not a group, we are a community. In a group there is a chief,
> there is a plan, and so on. Most of us (me included) participate in
> the spare time. For example, I cannot say if I will be busy or not: I
> work on Struts and Tiles in the evening for one hour or two, by
> dropping a line of code here and there.
> Ted, you must not expect from us anything: we are doing our best to
> help Struts, but no one pays for it. Essentially, at present time,
> Struts 1 and 2 are "hobby" projects, with valuable code and
> developers, but nothing more.
> If you want a "group", recruit it and pay to develop Struts.
>
> Sorry for being rude.
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/16, Ted Husted <hu...@apache.org>:
> As a group, we really suck at letting each other know
> that we won't be around for a while.
Ted,
we are not a group, we are a community. In a group there is a chief,
there is a plan, and so on. Most of us (me included) participate in
the spare time. For example, I cannot say if I will be busy or not: I
work on Struts and Tiles in the evening for one hour or two, by
dropping a line of code here and there.
Ted, you must not expect from us anything: we are doing our best to
help Struts, but no one pays for it. Essentially, at present time,
Struts 1 and 2 are "hobby" projects, with valuable code and
developers, but nothing more.
If you want a "group", recruit it and pay to develop Struts.
Sorry for being rude.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by James Mitchell <jm...@apache.org>.
Ted, I am guilty as charged of going "heads down" for a while.
However, I am back for at least the next year. Though I won't be able
to participate in user and dev discussions due to time. I'm on the
lists, but not reading everything unless it stands out. If you want
my input, please holla at me.
On Jan 16, 2008 11:10 AM, Ted Husted <hu...@apache.org> wrote:
> On Jan 16, 2008 12:23 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > That's a fair question, but I have an answer for it. Put simply, I feel
> > that anyone officially made a member of a project team has accepted a
> > greater level of responsibility than someone in the larger user community.
>
> A careful reading of "How it Works" implies that the Apache Way is
> designed so that individual committers do not have to accept a greater
> level of responsibility. The notion is that we can invite enough
> committers to the table that there will always be other volunteers
> available.
>
> @Struts, we seem to have trouble keeping enough active committers in
> play to make up for the committers who are heads-down on our day jobs.
> We also have trouble electing "grassroot contributors" who are not
> star coders. The trouble with electing only star coders is that people
> tend to focus on their own contributions, rather than applying patches
> submitted by others. I can testify that some of the very best features
> in Struts 1 were contributions made by people who where not
> committers.
>
> As PMC member, I would really like to know who intends to be available
> to support a release, or at least who expects to be heads-down for
> awhile. It's not uncommon for a release to pass with a minimum number
> of binding votes. If some of the voters are about to go heads-down on
> another project for six months, I'd like to know that before casting
> my own GA vote. As a group, we really suck at letting each other know
> that we won't be around for a while.
>
>
> On Jan 16, 2008 1:45 AM, Al Sutton <al...@alsutton.com> wrote:
> > We could always switch to holding off releases until we have 0 bugs of major
> > and above level :) (if we did that then we should do the M$ thing and switch
> > the default JIRA level to be the lowest possible and let the user upgrade it
> > rather than everything going in as Major by default).
>
> In practice, we do. There have been many times we counted down to
> rolling a build based on how many outstanding issues we had left.
>
> To an extent, that's what's happening with Struts 2.1.1. When we get
> to zero patches, I would be happy to roll another build. (Though, if
> another committer got antzy, someone else could post another release
> plan and roll one sooner.)
>
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
James Mitchell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Ted Husted <hu...@apache.org>.
On Jan 16, 2008 12:23 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> That's a fair question, but I have an answer for it. Put simply, I feel
> that anyone officially made a member of a project team has accepted a
> greater level of responsibility than someone in the larger user community.
A careful reading of "How it Works" implies that the Apache Way is
designed so that individual committers do not have to accept a greater
level of responsibility. The notion is that we can invite enough
committers to the table that there will always be other volunteers
available.
@Struts, we seem to have trouble keeping enough active committers in
play to make up for the committers who are heads-down on our day jobs.
We also have trouble electing "grassroot contributors" who are not
star coders. The trouble with electing only star coders is that people
tend to focus on their own contributions, rather than applying patches
submitted by others. I can testify that some of the very best features
in Struts 1 were contributions made by people who where not
committers.
As PMC member, I would really like to know who intends to be available
to support a release, or at least who expects to be heads-down for
awhile. It's not uncommon for a release to pass with a minimum number
of binding votes. If some of the voters are about to go heads-down on
another project for six months, I'd like to know that before casting
my own GA vote. As a group, we really suck at letting each other know
that we won't be around for a while.
On Jan 16, 2008 1:45 AM, Al Sutton <al...@alsutton.com> wrote:
> We could always switch to holding off releases until we have 0 bugs of major
> and above level :) (if we did that then we should do the M$ thing and switch
> the default JIRA level to be the lowest possible and let the user upgrade it
> rather than everything going in as Major by default).
In practice, we do. There have been many times we counted down to
rolling a build based on how many outstanding issues we had left.
To an extent, that's what's happening with Struts 2.1.1. When we get
to zero patches, I would be happy to roll another build. (Though, if
another committer got antzy, someone else could post another release
plan and roll one sooner.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK
1.4 distribution)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Ted Husted <hu...@apache.org>.
On Jan 16, 2008 11:42 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> That may be so in practice Ted, but the bylaws say differently:
>
> "An action requiring consensus approval must receive at least 3 binding
> +1 votes and no binding vetos."
A release is not an action that requires consensus approval. It's a
majority action. Look farther down under "Release Plan" and "Release
Grade".
> 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 that too is reasonable, except that now you've got Martin seemingly
> disagreeing with you (how this all started as I recall) and both Niall
> and Nathan apparently with understanding that don't seem to jive with
> the bylaws, hence it seems obvious to me that something needs to be
> done, and the easiest answer is probably to rewrite the bylaws to match
> the consensus view, whatever that turns out to be.
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.
> > Since everyone here is a volunteer, there's no way to enforce an
> > obligation, and the ASF guidelines remind us of this. A vote is an
> > opinion, not a commitment.
>
> Didn't you effectively say the opposite just yesterday? :
I asked about a voter's implied intention to make a good-faith effort,
which is effectively an opinion.
> Maybe it's a semantic thing, but if a +1 vote means "...he or she
> intends to help support the release", isn't that an obligation? Or is
> "obligation" simply the wrong term? Perhaps willingness, as I suggested
> yesterday?
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.
My recollection is that we inherited the "act of voting" language form
a Jakarta document, which was in turn based on an ancient Apache HTTPD
document. The key point now is that our page doesn't jive
word-for-word with the ASF guidelines. (Though, I would contend that
the spirit remains the same.)
* http://apache.org/foundation/voting.html
Now that the ASF guidelines includes an "implications" section (it
didn't always), my suggestion would be that we strike that language
from our own. We can probably simplify or eliminate other sections as
well, by incorporating the latest ASF pages by reference.
As for our intentions as to support, the general opinion seems to be
that support is a separate topic from release grade.
> We're saying the same thing here. I personally feel that a +1 *should*
> imply something, but if everyone disagrees with me, that's fine, but it
> seems obvious there isn't consensus on that right now, and the bylaws
> say something that not everyone else seems to be saying in any case, so
> what's the final arbiter of which way is accurate? The bylaws should
> spell it all out clearly and unambiguously, regardless of what it is
> that they actually spell out, just to avoid such situations.
>
> I understand the bylaws aren't meant to be legalize, but I believe I've
> pointed out some contradictions and interpretations that should be dealt
> with so there's never any debate over what a vote does or does not mean,
> what obligations someone does or does not have. I don't so much care
> what the answers actually are, only that they are clear and
> unassailable, and I'd expect everyone would want that level of clarity
> from any project they're involve din.
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.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK
1.4 distribution)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dave Newton wrote:
> --- "Frank W. Zammetti" <fz...@omnytex.com> wrote:
>> Ted Husted wrote:
>>> Since everyone here is a volunteer, there's no way to enforce an
>>> obligation, and the ASF guidelines remind us of this. A vote is an
>>> opinion, not a commitment.
>> Didn't you effectively say the opposite just yesterday? :
>>
>> "It's true that we're volunteers, and any of us can walk away whenever
>> we like, but it's also true that when we vote +1 on a GA, each voter
>> is saying that he or she intends to help support the release. If the
>> release includes a J4 distribution, it means that we are each saying
>> that we will make a good-faith effort to support that distribution
>> too."
>
> It doesn't sound like the opposite. "Intention" is not "obligation", and a
> "good-faith effort" is just that--an expressed intent made in good faith to
> support the distro.
>
> IMO "obligation" means that regardless of other circumstances that support
> *must* be provided.
That's my point though: obligation probably isn't the right word under
any circumstances. The best you can hope for, ask for or expect, is a
good-faith statement of intent. If everyone here is saying that a +1
implies such a good-faith intention to support, then there's no problem,
everything is right with the world There seems to be some question
about that implied meaning though, which is where this discussion began
as I recall.
> d.
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
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Dave Newton <ne...@yahoo.com>.
--- "Frank W. Zammetti" <fz...@omnytex.com> wrote:
> Ted Husted wrote:
> > Since everyone here is a volunteer, there's no way to enforce an
> > obligation, and the ASF guidelines remind us of this. A vote is an
> > opinion, not a commitment.
>
> Didn't you effectively say the opposite just yesterday? :
>
> "It's true that we're volunteers, and any of us can walk away whenever
> we like, but it's also true that when we vote +1 on a GA, each voter
> is saying that he or she intends to help support the release. If the
> release includes a J4 distribution, it means that we are each saying
> that we will make a good-faith effort to support that distribution
> too."
It doesn't sound like the opposite. "Intention" is not "obligation", and a
"good-faith effort" is just that--an expressed intent made in good faith to
support the distro.
IMO "obligation" means that regardless of other circumstances that support
*must* be provided.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK
1.4 distribution)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Ted Husted wrote:
> On Jan 16, 2008 10:47 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> (1) If as you say Niall "votes are votes", then that SHOULD mean that
>> non-binding voters can veto a release, but the bylaws say differently:
>> "3 binding +1 votes" and "no binding vetos" is the benchmark to whether
>> a action passes or not. It doesn't say "3 +1 votes from anyone", nor
>> does it say "no vetos from anyone", it specifically spells out binding
>> votes. Non-binding votes are not officially considered in other words.
>
> Nobody can veto a release. It's a majority vote action not a consensus
> vote action.
That may be so in practice Ted, but the bylaws say differently:
"An action requiring consensus approval must receive at least 3 binding
+1 votes and no binding vetos."
Does that not say, effectively, that a single binding -1 causes an
action (which I assume a release is) to not have consensus approval?
Seems to me that's exactly what it says.
> We don't "count" non-binding votes, but most of us would take them
> into consideration. If I'm on the fence, and a number of contributors
> cast +1 non-binding votes, then I'm more likely to cast my binding
> vote for GA. The inverse is also true.
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).
> We publish the project guidelines (or "by laws") to cover the common
> cases, so that we don't have to have these types of discussions every
> time we create a release. We're not trying to be legalistic, we're
> just trying to get the work done.
And that too is reasonable, except that now you've got Martin seemingly
disagreeing with you (how this all started as I recall) and both Niall
and Nathan apparently with understanding that don't seem to jive with
the bylaws, hence it seems obvious to me that something needs to be
done, and the easiest answer is probably to rewrite the bylaws to match
the consensus view, whatever that turns out to be.
> Since everyone here is a volunteer, there's no way to enforce an
> obligation, and the ASF guidelines remind us of this. A vote is an
> opinion, not a commitment.
Didn't you effectively say the opposite just yesterday? :
"It's true that we're volunteers, and any of us can walk away whenever
we like, but it's also true that when we vote +1 on a GA, each voter
is saying that he or she intends to help support the release. If the
release includes a J4 distribution, it means that we are each saying
that we will make a good-faith effort to support that distribution
too."
Maybe it's a semantic thing, but if a +1 vote means "...he or she
intends to help support the release", isn't that an obligation? Or is
"obligation" simply the wrong term? Perhaps willingness, as I suggested
yesterday?
> The key thing to me is what are the expectations of the commiters when
> we vote +1 on a GA release. Right now, the general feeling is that a
> +1 GA vote doesn't indicate that the committer will have the bandwidth
> available to support the release. Meaning, if I want to ask about
> that, we need to ask in a different context.
We're saying the same thing here. I personally feel that a +1 *should*
imply something, but if everyone disagrees with me, that's fine, but it
seems obvious there isn't consensus on that right now, and the bylaws
say something that not everyone else seems to be saying in any case, so
what's the final arbiter of which way is accurate? The bylaws should
spell it all out clearly and unambiguously, regardless of what it is
that they actually spell out, just to avoid such situations.
I understand the bylaws aren't meant to be legalize, but I believe I've
pointed out some contradictions and interpretations that should be dealt
with so there's never any debate over what a vote does or does not mean,
what obligations someone does or does not have. I don't so much care
what the answers actually are, only that they are clear and
unassailable, and I'd expect everyone would want that level of clarity
from any project they're involve din.
> -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
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
Posted by Ted Husted <hu...@apache.org>.
On Jan 16, 2008 10:47 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> (1) If as you say Niall "votes are votes", then that SHOULD mean that
> non-binding voters can veto a release, but the bylaws say differently:
> "3 binding +1 votes" and "no binding vetos" is the benchmark to whether
> a action passes or not. It doesn't say "3 +1 votes from anyone", nor
> does it say "no vetos from anyone", it specifically spells out binding
> votes. Non-binding votes are not officially considered in other words.
Nobody can veto a release. It's a majority vote action not a consensus
vote action.
A release quality vote would only fail if there is not a quorum of
three +1 binding votes, or if there are more binding -1s than binding
+1s.
We don't "count" non-binding votes, but most of us would take them
into consideration. If I'm on the fence, and a number of contributors
cast +1 non-binding votes, then I'm more likely to cast my binding
vote for GA. The inverse is also true.
We publish the project guidelines (or "by laws") to cover the common
cases, so that we don't have to have these types of discussions every
time we create a release. We're not trying to be legalistic, we're
just trying to get the work done.
Since everyone here is a volunteer, there's no way to enforce an
obligation, and the ASF guidelines remind us of this. A vote is an
opinion, not a commitment.
The key thing to me is what are the expectations of the commiters when
we vote +1 on a GA release. Right now, the general feeling is that a
+1 GA vote doesn't indicate that the committer will have the bandwidth
available to support the release. Meaning, if I want to ask about
that, we need to ask in a different context.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org