You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Arron Bates <st...@keyboardmonkey.com> on 2004/03/18 04:16:54 UTC
[ANNOUNCE] Struts goes TLP with unanimous vote...
Guys,
Just got the summary email from the Apache board meeting, and the Struts
proposal went through with flying colours.
Congrats guys, really. So much never-ending quality work.
I guess that with everyone else out driking Irish alcohol I was the first to
see the email, and I got to be the whistle-blower. :)
Cheers,
Arron.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [ANNOUNCE] Struts goes TLP with unanimous vote...
Posted by Steve Raeburn <sr...@apache.org>.
Yay, Struts!
Congratulations to everyone and special thanks to Martin for preparing
the proposal. Thanks also to Craig for agreeing to be the scapego..
err.. VP of the new project.
Steve
> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org]
> Sent: March 17, 2004 7:21 PM
> To: Struts Developers List
> Subject: Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
>
>
> On Wed, 17 Mar 2004, Arron Bates wrote:
>
> > Guys,
> >
> > Just got the summary email from the Apache board meeting,
> and the Struts
> > proposal went through with flying colours.
> >
> > Congrats guys, really. So much never-ending quality work.
> >
> >
> > I guess that with everyone else out driking Irish alcohol I
> was the first to
> > see the email, and I got to be the whistle-blower. :)
>
> Nah, you just type a little faster than I do. ;-)
>
> I'll be putting together a list, shortly, of what needs to
> happen next for
> us to fully "graduate". Stay tuned...
>
> --
> Martin Cooper
>
>
> >
> >
> > Cheers,
> >
> > Arron.
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Bylaws (was Re: [ANNOUNCE] Struts goes TLP with unanimous vote...)
Posted by Ted Husted <hu...@apache.org>.
On Sat, 20 Mar 2004 14:27:34 -0800 (PST), Martin Cooper wrote:
> This looks pretty good, Ted. Just a couple of things:
>
> * If we're going to introduce the idea of Struts sub-projects right
> up front, then I would prefer to consider these as purely
> organisational, at least initially. That is, I'm open to breaking
> up the code base / docs / etc. into multiple sub-projects, but I
> would prefer that all people related matters span the Struts
> project. Specifically, I wouldn't want to allow for "sub-project X
> committers" as distinct from Struts committers. (Basically, I want
> to be quite clear that this is not an umbrella project in any shape
> or form. ;)
Yes, "All PMC members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote."
So, this is not Jakarta, nor the Commons, but more like the fabled "Agora". :) There should only be one list of committers, with equal access to all Struts repositories. And I would say that there should be a single DEV list, for the same reasons.
As you say, the subprojects would be "organisation" units of release. Nothing more. No subcommittees, no subcommitters.
We could also think about the term "product" rather than "subproject". Subproject just seemed to flow better.
> * In the Roles page, I'd prefer that the CLA submission be called
> out in the text, and not just left to the sample letter, as it is
> now. There has been confusion on this in Jakarta, so let's make it
> as clear as possible for Struts. ;-)
Sure.
> * Should the release process (i.e. the Tomcat-like process we
> recently adopted) be part of the bylaws, or is that not necessary?
> That came to mind as I was reading the "Release Testing" section,
> since they're somewhat related.
We already have that in our release guidelines, which would remain. We'd probably have to resolve some overlap, as you point out.
> By the way, Stefan Bodewig put together a very nice wiki page to
> serve as a resource as the Gump team puts their own bylaws together:
>
> http://wiki.apache.org/gump/Drafts/ProjectBylaws
>
>
> It might be worth perusing for additional ideas. (I'm planning on
> doing some perusing of it myself when I have some time.)
>
> --
> Martin Cooper
>
>
> On Thu, 18 Mar 2004, Ted Husted wrote:
>
>
>> On Wed, 17 Mar 2004 19:20:54 -0800 (PST), Martin Cooper wrote:
>>
>>> I'll be putting together a list, shortly, of what needs to
>>> happen next for us to fully "graduate". Stay tuned...
>>>
>>
>> One thing the resolution mentions is that we are to draw up a set
>> of bylaws.
>>
>>
>> Heretofore, we've been operating under the Jakarta Guidelines, to
>> good effect, IMHO.
>>
>>
>> I recently created a proposed patch the guidelines to reflect
>> that the PMC members are the decisions makers, and that
>> Committers are essentially Contributors with write privileges.
>>
>>
>> http://www.apache.org/~husted/jakarta-site2/site2-patch.txt
>>
>>
>> copies of the affected pages as HTML:
>>
>>
>> http://www.apache.org/~husted/jakarta-site2/guidelines.html
>> http://www.apache.org/~husted/jakarta-site2/roles.html
>> http://www.apache.org/~husted/jakarta-site2/communication.html
>> http://www.apache.org/~husted/jakarta-site2/decisions.html
>> http://www.apache.org/~husted/jakarta-site2/management.html
>>
>> Of course, the Bylaws or "management" page would have to be
>> revised to reflect our project.
>>
>>
>> I would propose an extension to the Subproject section that says
>> something like:
>>
>>
>> ----
>>
>>
>> Subprojects are the project's unit of release. Each subproject
>> should represent an implementation of the Struts core or a
>> related component. Each subproject should focus on creating,
>> maintaining, and releasing a single software product or
>> "deliverable".
>>
>>
>> All PMC members have voting rights in all subprojects. Members
>> not familiar with a subproject codebase may abstain from any
>> given vote.
>>
>>
>> ----
>>
>>
>> The intent being that as we "rationalize" Struts, we can move
>> things like the taglibs and some of the contrib packages into
>> their own subprojects, with their own release cycles.
>>
>>
>> When a subproject is created, we could decide whether a
>> subproject needs its own mailing list or not. I have no opinion
>> as to USER lists, but would lean toward keeping a single DEV
>> list, for the sake of cross-pollination. In any event, mailing
>> list allocation is not part of the proposed, initial bylaws.
>>
>>
>> If this sounds all right, I'll merge this with our existing
>> documentation. Of course, we can always change any of this later.
>> But at least we will have fulfilled that portion of the
>> resolution.
>>
>>
>> -Ted.
>>
>>
>> ------------------------------------------------------------------
>> --- To unsubscribe, e-mail: struts-dev-
>> unsubscribe@jakarta.apache.org For additional commands, e-mail:
>> struts-dev-help@jakarta.apache.org
>>
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Bylaws (was Re: [ANNOUNCE] Struts goes TLP with unanimous vote...)
Posted by Martin Cooper <ma...@apache.org>.
This looks pretty good, Ted. Just a couple of things:
* If we're going to introduce the idea of Struts sub-projects right up
front, then I would prefer to consider these as purely organisational, at
least initially. That is, I'm open to breaking up the code base / docs /
etc. into multiple sub-projects, but I would prefer that all people
related matters span the Struts project. Specifically, I wouldn't want to
allow for "sub-project X committers" as distinct from Struts committers.
(Basically, I want to be quite clear that this is not an umbrella project
in any shape or form. ;)
* In the Roles page, I'd prefer that the CLA submission be called out in
the text, and not just left to the sample letter, as it is now. There has
been confusion on this in Jakarta, so let's make it as clear as possible
for Struts. ;-)
* Should the release process (i.e. the Tomcat-like process we recently
adopted) be part of the bylaws, or is that not necessary? That came to
mind as I was reading the "Release Testing" section, since they're
somewhat related.
By the way, Stefan Bodewig put together a very nice wiki page to serve as
a resource as the Gump team puts their own bylaws together:
http://wiki.apache.org/gump/Drafts/ProjectBylaws
It might be worth perusing for additional ideas. (I'm planning on doing
some perusing of it myself when I have some time.)
--
Martin Cooper
On Thu, 18 Mar 2004, Ted Husted wrote:
> On Wed, 17 Mar 2004 19:20:54 -0800 (PST), Martin Cooper wrote:
> > I'll be putting together a list, shortly, of what needs to happen
> > next for us to fully "graduate". Stay tuned...
>
> One thing the resolution mentions is that we are to draw up a set of bylaws.
>
> Heretofore, we've been operating under the Jakarta Guidelines, to good effect, IMHO.
>
> I recently created a proposed patch the guidelines to reflect that the PMC members are the decisions makers, and that Committers are essentially Contributors with write privileges.
>
> http://www.apache.org/~husted/jakarta-site2/site2-patch.txt
>
> copies of the affected pages as HTML:
>
> http://www.apache.org/~husted/jakarta-site2/guidelines.html
> http://www.apache.org/~husted/jakarta-site2/roles.html
> http://www.apache.org/~husted/jakarta-site2/communication.html
> http://www.apache.org/~husted/jakarta-site2/decisions.html
> http://www.apache.org/~husted/jakarta-site2/management.html
>
> Of course, the Bylaws or "management" page would have to be revised to reflect our project.
>
> I would propose an extension to the Subproject section that says something like:
>
> ----
>
> Subprojects are the project's unit of release. Each subproject should represent an implementation of the Struts core or a related component. Each subproject should focus on creating, maintaining, and releasing a single software product or "deliverable".
>
> All PMC members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote.
>
> ----
>
> The intent being that as we "rationalize" Struts, we can move things like the taglibs and some of the contrib packages into their own subprojects, with their own release cycles.
>
> When a subproject is created, we could decide whether a subproject needs its own mailing list or not. I have no opinion as to USER lists, but would lean toward keeping a single DEV list, for the sake of cross-pollination. In any event, mailing list allocation is not part of the proposed, initial bylaws.
>
> If this sounds all right, I'll merge this with our existing documentation. Of course, we can always change any of this later. But at least we will have fulfilled that portion of the resolution.
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
Posted by Ted Husted <hu...@apache.org>.
On Thu, 18 Mar 2004 08:01:35 -0600, Joe Germuska wrote:
> Actually, now that I read the generated HTML, I can see how this
> isn't actually a conflict -- the roles.xml blurb isn't actually
> saying that committers get to cast binding votes... I'm not coming
> up with better verbiage, but one clarification would be to add some
> text later in the document under the PMC section specifically
> mentioning voting.
>
> Not a huge deal really, but clarity is a good thing.
Agreed. The point is that only the PMC Members have binding votes, and we should be sure the posted text relects that.
I think in our case, like HTTPD, any active Committers will end up as PMC Members anyway.
But, given our experience, I think the now-conventional two-step process will help reduce the number of inactive PMC Members. It's not been uncommon for a new Struts Committer to fall away after a few months.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:11 AM -0500 3/18/04, Ted Husted wrote:
>On Wed, 17 Mar 2004 19:20:54 -0800 (PST), Martin Cooper wrote:
>> I'll be putting together a list, shortly, of what needs to happen
>> next for us to fully "graduate". Stay tuned...
>
>One thing the resolution mentions is that we are to draw up a set of bylaws.
>
>Heretofore, we've been operating under the Jakarta Guidelines, to
>good effect, IMHO.
>
>I recently created a proposed patch the guidelines to reflect that
>the PMC members are the decisions makers, and that Committers are
>essentially Contributors with write privileges.
>
> http://www.apache.org/~husted/jakarta-site2/site2-patch.txt
Maybe I'm reading the diffs wrong, but I think that it says
+ However, the only binding votes are those cast by a PMC Member.
(in decisions.xml, patch line 51)
and also
+ Those who have been longterm or valuable contributors to the project
+ can earn the right to commit directly to the source repository and to
+ cast binding votes during the decision-making process.
(roles.xml, patch lines 279-281)
Actually, now that I read the generated HTML, I can see how this
isn't actually a conflict -- the roles.xml blurb isn't actually
saying that committers get to cast binding votes... I'm not coming
up with better verbiage, but one clarification would be to add some
text later in the document under the PMC section specifically
mentioning voting.
Not a huge deal really, but clarity is a good thing.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
Posted by Ted Husted <hu...@apache.org>.
On Wed, 17 Mar 2004 19:20:54 -0800 (PST), Martin Cooper wrote:
> I'll be putting together a list, shortly, of what needs to happen
> next for us to fully "graduate". Stay tuned...
One thing the resolution mentions is that we are to draw up a set of bylaws.
Heretofore, we've been operating under the Jakarta Guidelines, to good effect, IMHO.
I recently created a proposed patch the guidelines to reflect that the PMC members are the decisions makers, and that Committers are essentially Contributors with write privileges.
http://www.apache.org/~husted/jakarta-site2/site2-patch.txt
copies of the affected pages as HTML:
http://www.apache.org/~husted/jakarta-site2/guidelines.html
http://www.apache.org/~husted/jakarta-site2/roles.html
http://www.apache.org/~husted/jakarta-site2/communication.html
http://www.apache.org/~husted/jakarta-site2/decisions.html
http://www.apache.org/~husted/jakarta-site2/management.html
Of course, the Bylaws or "management" page would have to be revised to reflect our project.
I would propose an extension to the Subproject section that says something like:
----
Subprojects are the project's unit of release. Each subproject should represent an implementation of the Struts core or a related component. Each subproject should focus on creating, maintaining, and releasing a single software product or "deliverable".
All PMC members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote.
----
The intent being that as we "rationalize" Struts, we can move things like the taglibs and some of the contrib packages into their own subprojects, with their own release cycles.
When a subproject is created, we could decide whether a subproject needs its own mailing list or not. I have no opinion as to USER lists, but would lean toward keeping a single DEV list, for the sake of cross-pollination. In any event, mailing list allocation is not part of the proposed, initial bylaws.
If this sounds all right, I'll merge this with our existing documentation. Of course, we can always change any of this later. But at least we will have fulfilled that portion of the resolution.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 17 Mar 2004, Arron Bates wrote:
> Guys,
>
> Just got the summary email from the Apache board meeting, and the Struts
> proposal went through with flying colours.
>
> Congrats guys, really. So much never-ending quality work.
>
>
> I guess that with everyone else out driking Irish alcohol I was the first to
> see the email, and I got to be the whistle-blower. :)
Nah, you just type a little faster than I do. ;-)
I'll be putting together a list, shortly, of what needs to happen next for
us to fully "graduate". Stay tuned...
--
Martin Cooper
>
>
> Cheers,
>
> Arron.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org