RE: Managing project documentation (release vs CVS versions) ?

[Conor MacNeill]

You don't have to use a branch - just check out with the release tag. It is
sticky and will not get updated by cvs update.

Conor

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 17 January 2002 10:45 AM
> To: 'Jakarta General List'
> Subject: RE: Managing project documentation (release vs CVS versions) ?
>
>
> I should have thought about this ... stupid me ... Thanks.
>
> -Vincent
>
> > -Original Message-
> > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> > Sent: 16 January 2002 23:38
> > To: Jakarta General List
> > Subject: Re: Managing project documentation (release vs CVS versions)
> ?
> >
> > The "recomended" solution for this is to use a branch. ie When you
> make a
> > release you also branch at same instant. Then if you need to update
> the
> > current web docs you modify them in the branch, then update the
> website
> > (which is using last branch released). If you need to update the docs
> for
> > the
> > current CVS then you do it in the main trunk/HEAD revision. When
> needed
> > you
> > merge the branch back into the main trunk.
> >
> > However I don't know of any projects that do this except for ant.
> >
> > It may also require a bit more CVS savvy that normal but should be
> > possible
> > to do if that is what cactus/whatever needs.
> >
> > On Thu, 17 Jan 2002 10:34, Vincent Massol wrote:
> > > Hi,
> > >
> > > I have always been pondering how to best manage the following.
> Should
> > > there be 2 web sites per project : one for the latest release
> > > (containing docs + javadoc corresponding to the latest release) and
> one
> > > for nightly builds (containing docs + javadocs corresponding to the
> > > latest code) ?
> > >
> > > When I work on a new feature that I want to document, I cannot
> document
> > > it in the xdocs/ directory because next time I change something for
> the
> > > web site and I want to make that change visible, it will also
> contain
> > > the new feature documentation. However, that feature is only present
> in
> > > CVS (not released yet) and users will have trouble understanding why
> > > this feature does not work with the code they downloaded. Of course,
> I
> > > could have a header that says "WARNING: Feature only available in
> CVS"
> > > but it is awkward. Another solution is to have 2 xdocs directory but
> > > again this is awkward ...
> > >
> > > Any idea ? How are other projects doing this ?
> > >
> > > Thanks
> > > -Vincent
> > >
> > > ___
> > > Vincent Massol
> > > OCTO Technology UK Ltd
> > > www.octo.com
> > > [EMAIL PROTECTED]
> > > Tel: (020) 8996 9540
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > *--*
> > | "Nearly all men can stand adversity, but if you want |
> > | to test a man's character, give him power."  |
> > |   -Abraham Lincoln   |
> > *--*
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
>
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Updating the site

[Daniel Rall]

[question from tomcat-dev]

Andy Armstrong <[EMAIL PROTECTED]> writes:

> I was going to update this page
>
>  http://jakarta.apache.org/site/cvsonwin32.html
>
> to reflect the fact that PuTTY, a free / open source SSH client, now
> supports tunnelling.
>
> Do I just update the page and commit it or is there more to it?

You want to update cvsonwin32.xml from the jakarta-site2 module.  Once
you've done that, you execute the Ant build to use Anakia to generate
the HTML version of the XML document, and upload the newly born
cvsonwin32.html file manually.  Make sure that it's accessible over
the web (unix permissions and all that).

If you have any issues, just send me a diff of the xdoc and I'll take
care of it.

- Daniel  (a loyal PuTTY uses when forced to use win32)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing project documentation (release vs CVS versions) ?

[Martin Cooper]

The Struts site originally had the latest and greatest reflected on the main
page, but this caused a lot of confusion, and innumerable postings to
struts-user. To fix this, we (i.e. Ted :) changed the main page to reflect
the currently released version, but included links to the latest and
greatest at the bottom of the page menu, so that documentation is available
for both versions.

Behind the scenes in CVS-land, we cloned the docs into a 'legacy' directory
when we branched the project, so that we could make changes to both
independently but also make both available on the Struts web site.

--
Martin Cooper


- Original Message -
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 16, 2002 3:34 PM
Subject: Managing project documentation (release vs CVS versions) ?


> Hi,
>
> I have always been pondering how to best manage the following. Should
> there be 2 web sites per project : one for the latest release
> (containing docs + javadoc corresponding to the latest release) and one
> for nightly builds (containing docs + javadocs corresponding to the
> latest code) ?
>
> When I work on a new feature that I want to document, I cannot document
> it in the xdocs/ directory because next time I change something for the
> web site and I want to make that change visible, it will also contain
> the new feature documentation. However, that feature is only present in
> CVS (not released yet) and users will have trouble understanding why
> this feature does not work with the code they downloaded. Of course, I
> could have a header that says "WARNING: Feature only available in CVS"
> but it is awkward. Another solution is to have 2 xdocs directory but
> again this is awkward ...
>
> Any idea ? How are other projects doing this ?
>
> Thanks
> -Vincent
>
> ___
> Vincent Massol
> OCTO Technology UK Ltd
> www.octo.com
> [EMAIL PROTECTED]
> Tel: (020) 8996 9540
>
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing project documentation (release vs CVS versions) ?

[Vincent Massol]

I should have thought about this ... stupid me ... Thanks.

-Vincent

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: 16 January 2002 23:38
> To: Jakarta General List
> Subject: Re: Managing project documentation (release vs CVS versions)
?
> 
> The "recomended" solution for this is to use a branch. ie When you
make a
> release you also branch at same instant. Then if you need to update
the
> current web docs you modify them in the branch, then update the
website
> (which is using last branch released). If you need to update the docs
for
> the
> current CVS then you do it in the main trunk/HEAD revision. When
needed
> you
> merge the branch back into the main trunk.
> 
> However I don't know of any projects that do this except for ant.
> 
> It may also require a bit more CVS savvy that normal but should be
> possible
> to do if that is what cactus/whatever needs.
> 
> On Thu, 17 Jan 2002 10:34, Vincent Massol wrote:
> > Hi,
> >
> > I have always been pondering how to best manage the following.
Should
> > there be 2 web sites per project : one for the latest release
> > (containing docs + javadoc corresponding to the latest release) and
one
> > for nightly builds (containing docs + javadocs corresponding to the
> > latest code) ?
> >
> > When I work on a new feature that I want to document, I cannot
document
> > it in the xdocs/ directory because next time I change something for
the
> > web site and I want to make that change visible, it will also
contain
> > the new feature documentation. However, that feature is only present
in
> > CVS (not released yet) and users will have trouble understanding why
> > this feature does not work with the code they downloaded. Of course,
I
> > could have a header that says "WARNING: Feature only available in
CVS"
> > but it is awkward. Another solution is to have 2 xdocs directory but
> > again this is awkward ...
> >
> > Any idea ? How are other projects doing this ?
> >
> > Thanks
> > -Vincent
> >
> > ___
> > Vincent Massol
> > OCTO Technology UK Ltd
> > www.octo.com
> > [EMAIL PROTECTED]
> > Tel: (020) 8996 9540
> 
> --
> Cheers,
> 
> Pete
> 
> *--*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power."  |
> |   -Abraham Lincoln   |
> *--*
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing project documentation (release vs CVS versions) ?

[Peter Donald]

The "recomended" solution for this is to use a branch. ie When you make a 
release you also branch at same instant. Then if you need to update the 
current web docs you modify them in the branch, then update the website 
(which is using last branch released). If you need to update the docs for the 
current CVS then you do it in the main trunk/HEAD revision. When needed you 
merge the branch back into the main trunk.

However I don't know of any projects that do this except for ant. 

It may also require a bit more CVS savvy that normal but should be possible 
to do if that is what cactus/whatever needs.

On Thu, 17 Jan 2002 10:34, Vincent Massol wrote:
> Hi,
>
> I have always been pondering how to best manage the following. Should
> there be 2 web sites per project : one for the latest release
> (containing docs + javadoc corresponding to the latest release) and one
> for nightly builds (containing docs + javadocs corresponding to the
> latest code) ?
>
> When I work on a new feature that I want to document, I cannot document
> it in the xdocs/ directory because next time I change something for the
> web site and I want to make that change visible, it will also contain
> the new feature documentation. However, that feature is only present in
> CVS (not released yet) and users will have trouble understanding why
> this feature does not work with the code they downloaded. Of course, I
> could have a header that says "WARNING: Feature only available in CVS"
> but it is awkward. Another solution is to have 2 xdocs directory but
> again this is awkward ...
>
> Any idea ? How are other projects doing this ?
>
> Thanks
> -Vincent
>
> ___
> Vincent Massol
> OCTO Technology UK Ltd
> www.octo.com
> [EMAIL PROTECTED]
> Tel: (020) 8996 9540

-- 
Cheers,

Pete

*--*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."  |
|   -Abraham Lincoln   |
*--*

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing project documentation (release vs CVS versions) ?

[Geir Magnusson Jr.]

On 1/16/02 6:34 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I have always been pondering how to best manage the following. Should
> there be 2 web sites per project : one for the latest release
> (containing docs + javadoc corresponding to the latest release) and one
> for nightly builds (containing docs + javadocs corresponding to the
> latest code) ?
> 
> When I work on a new feature that I want to document, I cannot document
> it in the xdocs/ directory because next time I change something for the
> web site and I want to make that change visible, it will also contain
> the new feature documentation. However, that feature is only present in
> CVS (not released yet) and users will have trouble understanding why
> this feature does not work with the code they downloaded. Of course, I
> could have a header that says "WARNING: Feature only available in CVS"
> but it is awkward. Another solution is to have 2 xdocs directory but
> again this is awkward ...
> 
> Any idea ? How are other projects doing this ?


In velocity-land, we document to the latest-greatest.  I guess it would be
good to note that on the site :)

Then, when a release is made, the docs reflect the state of the project at
the time the branch is made for the release.

Keeps things simple, and we really haven't had a problem yet.  However, this
is a good point, and I'll look into noting that somewhere.

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Updating the site

[Andy Armstrong]

Peter Donald wrote:
> 
> Read.
> 
> http://jakarta.apache.org/site/jakarta-site2.html
> 
> or recently proposed
> 
> http://jakarta.apache.org/site/jakarta-site2b.html

Just have. Sorry. Should have RTFM. So I need a karma upgrade so I can
commit the mods. Who takes care of that?

-- 
Andy Armstrong, Tagish

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Managing project documentation (release vs CVS versions) ?

[Vincent Massol]

Hi,

I have always been pondering how to best manage the following. Should
there be 2 web sites per project : one for the latest release
(containing docs + javadoc corresponding to the latest release) and one
for nightly builds (containing docs + javadocs corresponding to the
latest code) ?

When I work on a new feature that I want to document, I cannot document
it in the xdocs/ directory because next time I change something for the
web site and I want to make that change visible, it will also contain
the new feature documentation. However, that feature is only present in
CVS (not released yet) and users will have trouble understanding why
this feature does not work with the code they downloaded. Of course, I
could have a header that says "WARNING: Feature only available in CVS"
but it is awkward. Another solution is to have 2 xdocs directory but
again this is awkward ...

Any idea ? How are other projects doing this ?

Thanks
-Vincent

___
Vincent Massol
OCTO Technology UK Ltd
www.octo.com
[EMAIL PROTECTED]
Tel: (020) 8996 9540 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Updating the site

[Peter Donald]

Read.

http://jakarta.apache.org/site/jakarta-site2.html

or recently proposed

http://jakarta.apache.org/site/jakarta-site2b.html

On Thu, 17 Jan 2002 10:26, Andy Armstrong wrote:
> I've updated this page
>
>  http://jakarta.apache.org/site/cvsonwin32.html
>
> to reflect the fact that PuTTY, a free / open source SSH client, now
> supports tunnelling and can be used to build tunnels for CVS.
>
> How do I commit the changes?

-- 
Cheers,

Pete

---
If your life passes before your eyes when you die, 
 does that include the part where your life passes before 
your eyes?
---

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Updating the site

[Andy Armstrong]

I've updated this page

 http://jakarta.apache.org/site/cvsonwin32.html

to reflect the fact that PuTTY, a free / open source SSH client, now
supports tunnelling and can be used to build tunnels for CVS.

How do I commit the changes?

-- 
Andy Armstrong, Tagish

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Sam Ruby
" writes:
>The number of PMC seats will be set at seven.  Annually, all seven seats
>will be up for renewal.  The ASF board will be asked to provide a person or
>persons to administer the nominations and a subsequent ballot. The
>administrator(s) will determine the mechanics of the voting procedures.
>Any committer to any Jakarta code base will be eligible to vote.  Once the
>new PMC is in place, the first order of business will be to determine a
>chairperson from amongst their ranks.
>
>Once ratified, this proposal would be effective immediately, and an
>election would be initiated.

+1



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Ceki Gülcü]

+1

At 14:27 16.01.2002 -0500, you wrote:
>The number of PMC seats will be set at seven.  Annually, all seven seats
>will be up for renewal.  The ASF board will be asked to provide a person or
>persons to administer the nominations and a subsequent ballot. The
>administrator(s) will determine the mechanics of the voting procedures.
>Any committer to any Jakarta code base will be eligible to vote.  Once the
>new PMC is in place, the first order of business will be to determine a
>chairperson from amongst their ranks.
>
>Once ratified, this proposal would be effective immediately, and an
>election would be initiated.
>
>- Sam Ruby




--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Geir Magnusson Jr.]

On 1/16/02 5:07 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> On Thu, 17 Jan 2002 06:27, Sam Ruby wrote:
>> The number of PMC seats will be set at seven.  Annually, all seven seats
>> will be up for renewal.  The ASF board will be asked to provide a person or
>> persons to administer the nominations and a subsequent ballot. The
>> administrator(s) will determine the mechanics of the voting procedures.
>> Any committer to any Jakarta code base will be eligible to vote.  Once the
>> new PMC is in place, the first order of business will be to determine a
>> chairperson from amongst their ranks.
>> 
>> Once ratified, this proposal would be effective immediately, and an
>> election would be initiated.
> 
> Sounds good - but this kinda has one other implication. The PMC will no
> longer be able to adequetly cover all sub-projects - it would be quite
> possible that some some projects would be completely without representation.
> 
> If this was put in place it kinda suggests that maybe jakarta should not be
> so big ... ;)

There is another risk - that a large committer base of a project or project
bloc could get control of the PMC.  I see no problem with the current group
of people I interact with, but you never know what the future holds.

However, even with that said

+1


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Ted Husted]

True. Right now, I monitor the Commons, Lucene, and Taglibs, and only
have commit rights to one of these. 

Since the PMC meets here, the subprojects can represent their own
interests. The primary role of the PMC is to ensure that the ASF bylaws
and Jakarta guidelines are observed, and that Apache resources are not
used in inappropriate ways. 

The PMC gets to vote on new subprojects, but the committee members have
no other special privledges or powers.

-Ted.


Marc Saegesser wrote:
> 
> Simply because each Jakarta project doesn't have a committer on the PMC does
> not necessarily imply that each project would not have representation on the
> PMC.  Hopefully, through the nomination and voting process, each project
> would find someone that is willing to represent their interests in the PMC.
> Requiring direct representation for each project does not sound like a good
> long term strategy.
> 
> Marc Saegesser
> 
> > -Original Message-
> > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 16, 2002 4:07 PM
> > To: Jakarta General List
> > Subject: Re: [PROPOSAL] Jakarta PMC bylaws change
> >
> >
> > On Thu, 17 Jan 2002 06:27, Sam Ruby wrote:
> > > The number of PMC seats will be set at seven.  Annually,
> > all seven seats
> > > will be up for renewal.  The ASF board will be asked to
> > provide a person or
> > > persons to administer the nominations and a subsequent ballot. The
> > > administrator(s) will determine the mechanics of the voting
> > procedures.
> > > Any committer to any Jakarta code base will be eligible to
> > vote.  Once the
> > > new PMC is in place, the first order of business will be to
> > determine a
> > > chairperson from amongst their ranks.
> > >
> > > Once ratified, this proposal would be effective immediately, and an
> > > election would be initiated.
> >
> > Sounds good - but this kinda has one other implication. The
> > PMC will no
> > longer be able to adequetly cover all sub-projects - it would
> > be quite
> > possible that some some projects would be completely without
> > representation.
> >
> > If this was put in place it kinda suggests that maybe jakarta
> > should not be
> > so big ... ;)
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > 
> >  These aren't the droids you're
> >  looking for. Move along.
> > 
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Sam Ruby]

Peter Donald wrote:
>
> If this was put in place it kinda suggests that maybe jakarta should not be
> so big ... ;)

It is the same basic procedure that is used to elect the Apache board,
which by definition has a bigger scope than jakarta.

But, as I have said many o' times.  Anybody who wants to take a subset of
subprojects and form a new project will have my support.  I only bristle
when people make suggestions that OTHERS should take THEIR subprojects out
of Jakarta.

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] jakarta-site2.xml [Was Re: updating subproject websites]

[robert burrell donkin]

On Wednesday, January 16, 2002, at 10:33 PM, Ted Husted wrote:

> Done.

thanks

- robert


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] jakarta-site2.xml [Was Re: updating subproject websites]

[Ted Husted]

Done. 

http://jakarta.apache.org/site/jakarta-site2b.html


robert burrell donkin wrote:
> 
> On Tuesday, January 15, 2002, at 10:27 PM, Ted Husted wrote:
> 
> > If you would like to send the XML the page to me, Robert, and I will
> > post it as an alternative page, and we can whiteboard it for a day or
> > two, as we did on the New Product Proposal page, before talking it live
> > and direct :)
> 
> sounds like a good plan to me :)
> 
> - robert
>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Ted Husted]

It does mean that each member will have to monitor an average of 3
subprojects, but that's what happens in practice anyway. 

Peter Donald wrote:
> Sounds good - but this kinda has one other implication. The PMC will no
> longer be able to adequetly cover all sub-projects - it would be quite
> possible that some some projects would be completely without representation.
> 
> If this was put in place it kinda suggests that maybe jakarta should not be
> so big ... ;)
> 
> --
> Cheers,
> 
> Pete
> 
> 
>  These aren't the droids you're
>  looking for. Move along.
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PROPOSAL] Jakarta PMC bylaws change

[Marc Saegesser]

Simply because each Jakarta project doesn't have a committer on the PMC does
not necessarily imply that each project would not have representation on the
PMC.  Hopefully, through the nomination and voting process, each project
would find someone that is willing to represent their interests in the PMC.
Requiring direct representation for each project does not sound like a good
long term strategy.


Marc Saegesser 

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 16, 2002 4:07 PM
> To: Jakarta General List
> Subject: Re: [PROPOSAL] Jakarta PMC bylaws change
> 
> 
> On Thu, 17 Jan 2002 06:27, Sam Ruby wrote:
> > The number of PMC seats will be set at seven.  Annually, 
> all seven seats
> > will be up for renewal.  The ASF board will be asked to 
> provide a person or
> > persons to administer the nominations and a subsequent ballot. The
> > administrator(s) will determine the mechanics of the voting 
> procedures.
> > Any committer to any Jakarta code base will be eligible to 
> vote.  Once the
> > new PMC is in place, the first order of business will be to 
> determine a
> > chairperson from amongst their ranks.
> >
> > Once ratified, this proposal would be effective immediately, and an
> > election would be initiated.
> 
> Sounds good - but this kinda has one other implication. The 
> PMC will no 
> longer be able to adequetly cover all sub-projects - it would 
> be quite 
> possible that some some projects would be completely without 
> representation.
> 
> If this was put in place it kinda suggests that maybe jakarta 
> should not be 
> so big ... ;)
> 
> -- 
> Cheers,
> 
> Pete
> 
> 
>  These aren't the droids you're 
>  looking for. Move along. 
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Peter Donald]

On Thu, 17 Jan 2002 06:27, Sam Ruby wrote:
> The number of PMC seats will be set at seven.  Annually, all seven seats
> will be up for renewal.  The ASF board will be asked to provide a person or
> persons to administer the nominations and a subsequent ballot. The
> administrator(s) will determine the mechanics of the voting procedures.
> Any committer to any Jakarta code base will be eligible to vote.  Once the
> new PMC is in place, the first order of business will be to determine a
> chairperson from amongst their ranks.
>
> Once ratified, this proposal would be effective immediately, and an
> election would be initiated.

Sounds good - but this kinda has one other implication. The PMC will no 
longer be able to adequetly cover all sub-projects - it would be quite 
possible that some some projects would be completely without representation.

If this was put in place it kinda suggests that maybe jakarta should not be 
so big ... ;)

-- 
Cheers,

Pete


 These aren't the droids you're 
 looking for. Move along. 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Ted Husted]

+1

Sam Ruby wrote:
> 
> The number of PMC seats will be set at seven.  Annually, all seven seats
> will be up for renewal.  The ASF board will be asked to provide a person or
> persons to administer the nominations and a subsequent ballot. The
> administrator(s) will determine the mechanics of the voting procedures.
> Any committer to any Jakarta code base will be eligible to vote.  Once the
> new PMC is in place, the first order of business will be to determine a
> chairperson from amongst their ranks.
> 
> Once ratified, this proposal would be effective immediately, and an
> election would be initiated.
> 
> - Sam Ruby
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Jon Scott Stevens]

on 1/16/02 11:27 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> The number of PMC seats will be set at seven.  Annually, all seven seats
> will be up for renewal.  The ASF board will be asked to provide a person or
> persons to administer the nominations and a subsequent ballot. The
> administrator(s) will determine the mechanics of the voting procedures.
> Any committer to any Jakarta code base will be eligible to vote.  Once the
> new PMC is in place, the first order of business will be to determine a
> chairperson from amongst their ranks.
> 
> Once ratified, this proposal would be effective immediately, and an
> election would be initiated.
> 
> - Sam Ruby

+1

-jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Craig R. McClanahan]

On Wed, 16 Jan 2002, Sam Ruby wrote:

> Date: Wed, 16 Jan 2002 14:27:54 -0500
> From: Sam Ruby <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Jakarta PMC bylaws change
>
> The number of PMC seats will be set at seven.  Annually, all seven seats
> will be up for renewal.  The ASF board will be asked to provide a person or
> persons to administer the nominations and a subsequent ballot. The
> administrator(s) will determine the mechanics of the voting procedures.
> Any committer to any Jakarta code base will be eligible to vote.  Once the
> new PMC is in place, the first order of business will be to determine a
> chairperson from amongst their ranks.
>
> Once ratified, this proposal would be effective immediately, and an
> election would be initiated.
>

+1

> - Sam Ruby
>
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[Jason van Zyl]

On 1/16/02 2:27 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> The number of PMC seats will be set at seven.  Annually, all seven seats
> will be up for renewal.  The ASF board will be asked to provide a person or
> persons to administer the nominations and a subsequent ballot. The
> administrator(s) will determine the mechanics of the voting procedures.
> Any committer to any Jakarta code base will be eligible to vote.  Once the
> new PMC is in place, the first order of business will be to determine a
> chairperson from amongst their ranks.
> 
> Once ratified, this proposal would be effective immediately, and an
> election would be initiated.

+1

> - Sam Ruby
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PROPOSAL] Jakarta PMC bylaws change

[Scott Sanders]

+1

> -Original Message-
> From: Sam Ruby [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, January 16, 2002 11:28 AM
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Jakarta PMC bylaws change
> 
> 
> The number of PMC seats will be set at seven.  Annually, all 
> seven seats will be up for renewal.  The ASF board will be 
> asked to provide a person or persons to administer the 
> nominations and a subsequent ballot. The
> administrator(s) will determine the mechanics of the voting 
> procedures. Any committer to any Jakarta code base will be 
> eligible to vote.  Once the new PMC is in place, the first 
> order of business will be to determine a chairperson from 
> amongst their ranks.
> 
> Once ratified, this proposal would be effective immediately, 
> and an election would be initiated.
> 
> - Sam Ruby
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PROPOSAL] Jakarta PMC bylaws change

[Sam Ruby]

The number of PMC seats will be set at seven.  Annually, all seven seats
will be up for renewal.  The ASF board will be asked to provide a person or
persons to administer the nominations and a subsequent ballot. The
administrator(s) will determine the mechanics of the voting procedures.
Any committer to any Jakarta code base will be eligible to vote.  Once the
new PMC is in place, the first order of business will be to determine a
chairperson from amongst their ranks.

Once ratified, this proposal would be effective immediately, and an
election would be initiated.

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] jakarta-site2.xml [Was Re: updating subproject websites]

[robert burrell donkin]

On Tuesday, January 15, 2002, at 10:27 PM, Ted Husted wrote:

> If you would like to send the XML the page to me, Robert, and I will
> post it as an alternative page, and we can whiteboard it for a day or
> two, as we did on the New Product Proposal page, before talking it live
> and direct :)

sounds like a good plan to me :)

- robert



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: How to switch to another mail-address?

[alexus]

i believe that's the only one way.. 

- Original Message - 
From: "Oleg V Alexeev" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 16, 2002 6:56 AM
Subject: How to switch to another mail-address?


> Hello Jakarta,
> 
>   Now I have some difficalites with my old mail-address and want to
>   switch to the new one. Can I do so by the any standart way except of
>   unsubscribe/subscribe letters sending?
> 
> -- 
> Best regards,
>  Oleg  mailto:[EMAIL PROTECTED]
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Fwd: Watchdog download links are incorrect]

[Ted Husted]

Anyone with Watchdog karma up for this?

-Ted.

 Original Message 
Subject: Watchdog download links are incorrect
Date: 14 Jan 2002 13:13:30 -0500
From: Ryan Lubke <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Hi,

This issue has been brought up several times in the watchdog mailing
list, yet no resolution has been provided.  I haven't been able to find
the location in CVS where the watchdog page is kept, so I haven't been
able to update it myself.

The following URLs:

http://jakarta.apache.org/builds/jakarta-watchdog/nightly
http://jakarta.apache.org/builds/jakarta-watchdog/nightly/src

*should* be:

http://jakarta.apache.org/builds/jakarta-watchdog-4.0/nightly
http://jakarta.apache.org/builds/jakarta-watchdog-4.0/nightly/src

If the recipient is unable to update the appropriate page, could I
be given a pointer on where the watchdog site is located within CVS so I
can fix this issue?

Thanks,

Ryan Lubke

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

How to switch to another mail-address?

[Oleg V Alexeev]

Hello Jakarta,

  Now I have some difficalites with my old mail-address and want to
  switch to the new one. Can I do so by the any standart way except of
  unsubscribe/subscribe letters sending?

-- 
Best regards,
 Oleg  mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   
For additional commands, e-mail: