Re: More abuse of coding styles...

[Micael Padraig Og mac Grene]

At 07:07 PM 1/9/02 -0800, you wrote:
>Ceki Gülcü <[EMAIL PROTECTED]> writes:
>
> > People who repeatedly forget to type "this" represent a minority and
> > should perhaps look to exercise a different profession.
>
>Agreed.
>
> > The problem with
> >
> > public void setSomething(Object something){
> >   this.something = something;
> > }
> >
> > is
> >
> > public void setSomethingComplicated(Object sometingComplicateed){
> >   this.somethingComplicated = somethingComplicated;
> > }
>
>There's only possibility of problem there when you don't copy and
>paste your variable names.


On the one hand, arrogance is never helpful, if you mean to be helpful.  If 
you want to show off how smart you are, on the other hand, it is a great 
tool.  The difference is whether you want to talk about yourself or the 
subject-matter.

- micael


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

Re: License change for new year ?

[Peter Donald]

On Thu, 10 Jan 2002 13:36, Andrew C. Oliver wrote:
> Just a question.  Maybe I missed this in the discussions.  Every once
> and a while the "short license" versus "big license" discussion goes
> through here.  Meaning the source code for some projects whether
> correctly or incorrectly be convention uses a statement and short
> reference to the license and others post the license in its entirety.
> Did anyone consult those "licensing" folks to check if there was a legal
> reasoning?  While I have no particular passion on this and don't wish to
> see a war here, I do know some projects use one and others use another
> and I'm just curious if there are any legal problems that could result.
>
> (at POI we use the long form convention because it seems to be in line
> with where the discussion leaned on here and I'm a paranoid type person)

Theres no legal reason for either case as long as they both are accurate and 
don't misrepresent the license. Some people froth at the mouth at one style 
or the other to an even greater degree than code standards so basically do 
what you are comfortable with.

-- 
Cheers,

Pete

*-*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof."   *
*  - John Kenneth Galbraith   *
*-*

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

Re: License change for new year ?

[Peter Donald]

On Thu, 10 Jan 2002 12:45, Geir Magnusson Jr. wrote:
> On 1/9/02 8:30 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> > On Thu, 10 Jan 2002 12:24, Geir Magnusson Jr. wrote:
> >> Here's a quick question - what makes that a rule?  Ted putting it into a
> >> file?
> >
> > It is a legal requirement for the license to be valid.
>
> Of course.  What I am asking is  what makes it a Jakarta rule that the
> mentioned procedure is how it's supposed to work.  See what I'm getting at?

not really sure what you mean. The one thing that the PMC is required to do 
is enforce all the legalities of stuff. This is legality thing that has to be 
done. The PMC has to enforce regardless or not it is in the "rules" for 
jakarta 

> Jon said "put that rule in" and I was wondering about the process of when
> we decided that specific thing was a rule.

I don't see it as an addition - merely documenting something that already is 
implictly a rule. I never knew about this sort of thing until about 9 months 
ago when a lawyer tried to explain it all to me (though failed at some parts 
cause I had no idea what he was talking about).

Documenting it is good because then people who know not a lot about legalese 
and friends don't have to think ;)

If it was an actualy change proposed it would have to go through the whole 
propose, bitchslap, whine, vote, propose, whine, bitchslap, vote  until 
it got accepted (and ignored), agreed to or everyone thought the subjects was 
dull and stopped participating ;)

-- 
Cheers,

Pete

---
"Wise men don't need advice. Fools don't take it." 
-Benjamin Franklin 
---


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

Re: License change for new year ?

[Ceki Gülcü]

I am not a lawyer and the following is yet another one of my heretical POVs.

Legally speaking the copyright notice is not even required in each source file as long 
as the whole work can be unequivocally attributed to their rightful owners through 
other means.

Example 1) In my home I don't have my name written on every item and piece of 
furniture. There is a littler sign on the door that says this is my home. It follows 
that everything contained therein is my property. 

Example 2) If you look inside any book, you are likely to find that there is only one 
copyright notice covering the whole book. You are very unlikely to find another 
copyright in no sentence, no paragraph, nor in any section not even in any chapter. 
You will find one copyright section inside the cover page. 

Copyright law applies the same way to software as to books. 

Tearing out a page from a book does not remove the copyright of the author even if 
there is no copyright notice on the torn out page. Think about it for a second.

Why are putting copyright notices in every source code file? Because we can and it is 
admitted by industry practice, not because we have to. 


At 22:29 09.01.2002 -0500, Ted Husted wrote:
>At this time, the so-called short form should not be used. Although we
>are told that it is legally defensible. 
>
>http://nagoya.apache.org:8080/jyve-faq/Turbine/screen/DisplayQuestionAnswer/action/SetAll/project_id/2/faq_id/38/topic_id/205/question_id/787
>
>The ASF chair has made a posting to the Committers list regarding a new
>license, which will support a short form, but approval is still
>forthcoming. 
>
>-Ted.
>
>
>"Andrew C. Oliver" wrote:
>> 
>> Pete,
>> 
>> Just a question.  Maybe I missed this in the discussions.  Every once
>> and a while the "short license" versus "big license" discussion goes
>> through here.  Meaning the source code for some projects whether
>> correctly or incorrectly be convention uses a statement and short
>> reference to the license and others post the license in its entirety.
>> Did anyone consult those "licensing" folks to check if there was a legal
>> reasoning?  While I have no particular passion on this and don't wish to
>> see a war here, I do know some projects use one and others use another
>> and I'm just curious if there are any legal problems that could result.
>> 
>> (at POI we use the long form convention because it seems to be in line
>> with where the discussion leaned on here and I'm a paranoid type person)
>> 
>> Thanks,
>> 
>> Andy
>> --
>> www.superlinksoftware.com
>> www.sourceforge.net/projects/poi - port of Excel format to java
>> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
>> - fix java generics!
>> 
>> The avalanche has already started. It is too late for the pebbles to
>> vote.
>> -Ambassador Kosh
>> 
>> --
>> 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: 

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



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

RE: More abuse of coding styles...

[Tim Vernum]

> > public void setSomethingComplicated(Object sometingComplicateed){ 
> >   this.somethingComplicated = somethingComplicated;
> > }
> 
> There's only possibility of problem there when you don't copy and
> paste your variable names.

I find (subjectively) that if you are a reasonable typer, then copy
and paste is a lot slower than just re-typing the variable name.
Especially in vi(m).


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of 
Macquarie Bank or third parties. If you are not the intended recipient of this email 
you should not read, print, re-transmit, store or act in reliance on this e-mail or 
any attachments, and should destroy all copies of them. Macquarie Bank does not 
guarantee the integrity of any emails or any attached files. The views or opinions 
expressed are the author's own and may not reflect the views or opinions of Macquarie 
Bank. 


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

Re: License change for new year ?

[Ted Husted]

At this time, the so-called short form should not be used. Although we
are told that it is legally defensible. 

http://nagoya.apache.org:8080/jyve-faq/Turbine/screen/DisplayQuestionAnswer/action/SetAll/project_id/2/faq_id/38/topic_id/205/question_id/787

The ASF chair has made a posting to the Committers list regarding a new
license, which will support a short form, but approval is still
forthcoming. 

-Ted.


"Andrew C. Oliver" wrote:
> 
> Pete,
> 
> Just a question.  Maybe I missed this in the discussions.  Every once
> and a while the "short license" versus "big license" discussion goes
> through here.  Meaning the source code for some projects whether
> correctly or incorrectly be convention uses a statement and short
> reference to the license and others post the license in its entirety.
> Did anyone consult those "licensing" folks to check if there was a legal
> reasoning?  While I have no particular passion on this and don't wish to
> see a war here, I do know some projects use one and others use another
> and I'm just curious if there are any legal problems that could result.
> 
> (at POI we use the long form convention because it seems to be in line
> with where the discussion leaned on here and I'm a paranoid type person)
> 
> Thanks,
> 
> Andy
> --
> www.superlinksoftware.com
> www.sourceforge.net/projects/poi - port of Excel format to java
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
> - fix java generics!
> 
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> --
> 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: More abuse of coding styles...

[Daniel Rall]

Ceki Gülcü <[EMAIL PROTECTED]> writes:

> People who repeatedly forget to type "this" represent a minority and
> should perhaps look to exercise a different profession.

Agreed.

> The problem with
>
> public void setSomething(Object something){ 
>   this.something = something; 
> }
>
> is 
>
> public void setSomethingComplicated(Object sometingComplicateed){ 
>   this.somethingComplicated = somethingComplicated;
> }

There's only possibility of problem there when you don't copy and
paste your variable names.

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

RE: Mission ...

[Paulo Gaspar]

"Production quality" sounds MUCH better to me!

Have fun,
Paulo Gaspar

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 10, 2002 3:31 AM
> To: general at jakarta
> Subject: Re: Mission ...
> 
> 
> Personally, 
> 
> While I don't have strong feeling about this, and a Mission statement is
> what it is...
> 
> I don't know that commercial-quality is a positive thing these days. 
> Alternatively, I'd say high-quality.  Its a stupid distinction I know
> but I've used some duds that were supposedly "commercial-quality"
> (especially from *cough*microsoft*cough* the big vendors).  I feel
> Jakarta should champion OS software as being equal to or better than
> "commercial-quality" even when OS software is commecial (if that makes
> any sense).  Like I said pedantic but it just stuck out at me.
> 
> -Andy
> -- 
> www.superlinksoftware.com
> www.sourceforge.net/projects/poi - port of Excel format to java
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
>   - fix java generics!
> 
> 
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

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

Re: More abuse of coding styles...

[Daniel Rall]

Stephane Bailliez <[EMAIL PROTECTED]> writes:

> I'm the lucky user of Intellij IDEA which has a code layout feature that
> allows to reformat the whole code in a snap w/ specific code style,
> reorganize imports and remove useless one. I'm using this extensively and
> this is damn cool.

Shockingly enough (!), XEmacs does this too.  ;-)

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

Re: More abuse of coding styles...

[Daniel Rall]

"Craig R. McClanahan" <[EMAIL PROTECTED]> writes:

> On Fri, 4 Jan 2002, Erik Hatcher wrote:
>
>> Date: Fri, 4 Jan 2002 19:27:52 -0500
>> From: Erik Hatcher <[EMAIL PROTECTED]>
>> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
>> To: Jakarta General List <[EMAIL PROTECTED]>
>> Subject: Re: More abuse of coding styles...
>>
>> Rule #1 from The Elements of Java Style is:
>>
>> Adhere to the style of the original
>>
>
> IIRC, we actually had this rule explicitly in the JServ code conventions
> ... looks like it didn't make the transition into the Jakarta docs though.

I am willing to make the xdocs change.  Anyone opposed?

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

Re: License change for new year ?

[Andrew C. Oliver]

Pete,

Just a question.  Maybe I missed this in the discussions.  Every once
and a while the "short license" versus "big license" discussion goes
through here.  Meaning the source code for some projects whether
correctly or incorrectly be convention uses a statement and short
reference to the license and others post the license in its entirety. 
Did anyone consult those "licensing" folks to check if there was a legal
reasoning?  While I have no particular passion on this and don't wish to
see a war here, I do know some projects use one and others use another
and I'm just curious if there are any legal problems that could result.

(at POI we use the long form convention because it seems to be in line
with where the discussion leaned on here and I'm a paranoid type person)

Thanks,

Andy
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

Re: Mission ...

[Andrew C. Oliver]

Personally, 

While I don't have strong feeling about this, and a Mission statement is
what it is...

I don't know that commercial-quality is a positive thing these days. 
Alternatively, I'd say high-quality.  Its a stupid distinction I know
but I've used some duds that were supposedly "commercial-quality"
(especially from *cough*microsoft*cough* the big vendors).  I feel
Jakarta should champion OS software as being equal to or better than
"commercial-quality" even when OS software is commecial (if that makes
any sense).  Like I said pedantic but it just stuck out at me.

-Andy
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

Re: License change for new year ?

[Geir Magnusson Jr.]

On 1/9/02 8:38 PM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> 
> Geir,
> 
> I think the rule is so obvious once stated that no one is likely to disagree
> with it. In a perfect world, we would vote on such a rule in order to adopt it
> formally. However, we don't live in a perfect world with unlimited resources
> and the Jakarta tradition of lazy approval seems to apply. Regards, Ceki

This ties back to the thread earlier this week regarding the community not
conforming to the rules we have.

In this case, while indeed a sensible and required thing, it was a two
message exchange on general@ that formed it into a rule.

Then, it was going to be added to a page that many will probably not see.

So what we've done is set things up for people to violate the 'rule' simply
out of ignorance.


Again, don't get me wrong - I agree 100% with the rule :)


> 
> At 20:24 09.01.2002 -0500, Geir Magnusson Jr. wrote:
>> On 1/9/02 12:53 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
>> 
>>> on 1/9/02 6:49 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>>> 
 Ted Husted wrote:
> 
> I think on a continuing basis, Committers should update the copyright
> notice to include the current year whenever they update a source file.
> This will happen most often in the early part of a year, but should
> happen year-round. So, as Peter said, if you revise a source file from
> 1999, you should change the copyright notice in the license to read
> 1999, 2002. If the file was from 2001, we would change it to 2001-2002.
 
 I have never bothered to learn the details (there are some topics I avoid
 lest I become perceived as an expert on the subject ;-)), but when working
 on software for my employer (who has a tendency of being careful about such
 things), we tend to follow the roughly the rules specified above.
>>> 
>>> Hey Ted, can you update source.xml (or whatever appropriate jakarta-site2
>>> file) in order to get that little rule 'documented'?
>>> 
>> 
>> Here's a quick question - what makes that a rule?  Ted putting it into a
>> file?
>> 
>> I don't disagree with the  suggestion - I mean, we need to do it - I am just
>> asking what makes it a rule now
>> 
>> 
>> On the issue itself, isn't this something that should be uniformly done
>> across all Apache projects?
>> 
>> I would think that since it's part of the License, we want uniformity.
>> 
>> -- 
>> Geir Magnusson Jr.   [EMAIL PROTECTED]
>> System and Software Consulting
>> You're going to end up getting pissed at your software
>> anyway, so you might as well not pay for it. Try Open Source.
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:   
>> For additional commands, e-mail: 
> 
> --
> Ceki Gülcü - http://qos.ch
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

-- 
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: License change for new year ?

[Geir Magnusson Jr.]

On 1/9/02 8:30 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> On Thu, 10 Jan 2002 12:24, Geir Magnusson Jr. wrote:
>> Here's a quick question - what makes that a rule?  Ted putting it into a
>> file?
> 
> It is a legal requirement for the license to be valid.

Of course.  What I am asking is  what makes it a Jakarta rule that the
mentioned procedure is how it's supposed to work.  See what I'm getting at?

(I of course agree we have to do it)

> 
>> I don't disagree with the  suggestion - I mean, we need to do it - I am
>> just asking what makes it a rule now
> 
> Anything that we decide to make a rule (hopefully little), anything that is
> part of Apaches "culture"/regulations/bylaws etc, anything required to
> protect Apache or committers or codebase (usually these are the legal uglies)
> 
> am I missing anything ?

Seems so.

Jon said "put that rule in" and I was wondering about the process of when we
decided that specific thing was a rule.
 
>> On the issue itself, isn't this something that should be uniformly done
>> across all Apache projects?
>> 
>> I would think that since it's part of the License, we want uniformity.
> 
> It would probably be a good idea. You could post this to [EMAIL PROTECTED]
> to proceed if you want. Theres also a lawyer on that list which will be able
> to make sure we are doing the right thing.

Good idea - I will do that.

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



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

Re: Mission ...

[Geir Magnusson Jr.]

On 1/9/02 8:33 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Ted Husted wrote:
>> Danny Angus wrote:
>>> If Jakarta != java and/or Jakarta != server, (which appeared on this
> list a
>>> few days ago, but I cant find the original mail)
>>> then the mission statement is at odds with the project, which must at
> best
>>> create bad karma and at worst it broadcasts a misleading message about
> the
>>> project to the whole world (or the English speaking bit at least).
>>> 
>>> "Mission
>>> Provide commercial-quality server solutions based on the Java Platform
> that
>>> are developed in an open and cooperative fashion"
>> 
>> A lot things appear on this list =:0)
>> 
>> At this point, the general consensus seems to be that we need things
>> like Ant to create the server solutions.
> 
> Admittedly, that argument appears weak at the present time.
> 
> Here's some history.  Originally (before my time), the founders of Jakarta
> created this project with Ant, Tomcat, and Watchdog.  They came up with
> that mission statement.  In hindsight, this was not the best description.
> Then the community grew rapidly.  Many of the new subprojects were from the
> now defunct java.apache.org.
> 
>> We could propose that the word server be strucken from the Jakarta
>> Mission, but the practical value of opening that kettle of fish is
>> debatable.
> 
> At the present time, we have a number of people who are committers to one
> or more of the new-to-Jakarta (even if the subprojects themselves are older
> than Ant, Tomcat, and Watchdog) who feel that Jakarta is getting a bit big.
> That feeling is understandable.  Some proposals have been floated from time
> to time which inevitably seem to split out subprojects from Jakarta that
> the sponsors to those proposals don't actively participate in, and yet
> somehow manage to leave those subprojects that the sponsor does actively
> participate in.  Fancy that.

Since this is aimed partly my way, I'll answer.

As I have been talking about related issues on three threads, and I can't
remember what I said where, I'll try to summarize and be clear here.

0) I do not advocate pushing any project out of Jakarta, or even suggesting
with the intent of inciting support (and would work hard to keep any jakarta
project from leaving.)  If anything I have said seems to contraindicate
this, I first apologize for not being clear, and assure you that the first
sentence above represents how I feel.

1) I do advocate discussing the issue of looking at how the scope has grown
rather than hoping all will be well.

2) I have certainly suggested, as a discussion point, that one could regroup
things along "utility class" - for example, I have suggested, in probably
more than one place, that ant, oro, regexp, BCEL are all in the same class
of "Tools used everywhere", and therefore I think make an intelligent
grouping.  I don't think that this concept, grouping, is wacky - Ted
recently organized our home page along such lines.

3) I think, as a example, that as Ant is such a universally well-known, very
strong project, it could anchor with Oro and Regexp a new project with
almost certain chance of success.   However, to repeat, in no way do I
advocate even suggesting pushing anyone out.


In my case, I actively participate in velocity, one of if not the smallest
project here.

I do not feel that Velocity has the same broad appeal and user base as Ant,
for example, and further, it is a niche product, so it really wouldn't make
sense to try and start a new Apache project around the problem domain it
addresses.  For the majority of users at the moment, Velocity is squarely in
the domain of dynamic web content generation (although it is general
purpose).  If it ever were the case that velocity could help anchor a new
project, I would support that action if the assistance was needed.

 
> My way of resolving this is to offer to help out any proposal to split out
> any subproject which is backed by a majority of committers in that
> subproject or subprojects.  In other words, if someone wishes to create
> another community, they have my blessing, but they have the burden of
> establishing the new identity.
>

That¹s fine, but I think that we are all interested in the success of such a
venture, should a project desire to do that, and I wonder if besides
standing back and holding the door open, we could do something to tilt the
playing field in that project's favor.
 

> I really wish that either somebody would take me up on my offer, or stop
> floating proposals that don't meet the criteria specified above.  Until
> then, this debate keeps resurfacing every time a new subproject is
> considered or someone brings up the divergence between the mission
> statement and the actual community it proports to describe.
> 

The latter issue can be addressed directly, can't it?


-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
You're going to end up getting pissed at your software

Re: License change for new year ?

[Ceki Gülcü]

Geir,

I think the rule is so obvious once stated that no one is likely to disagree with it. 
In a perfect world, we would vote on such a rule in order to adopt it formally. 
However, we don't live in a perfect world with unlimited resources and the Jakarta 
tradition of lazy approval seems to apply. Regards, Ceki
 
At 20:24 09.01.2002 -0500, Geir Magnusson Jr. wrote:
>On 1/9/02 12:53 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
>
>> on 1/9/02 6:49 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>> 
>>> Ted Husted wrote:
 
 I think on a continuing basis, Committers should update the copyright
 notice to include the current year whenever they update a source file.
 This will happen most often in the early part of a year, but should
 happen year-round. So, as Peter said, if you revise a source file from
 1999, you should change the copyright notice in the license to read
 1999, 2002. If the file was from 2001, we would change it to 2001-2002.
>>> 
>>> I have never bothered to learn the details (there are some topics I avoid
>>> lest I become perceived as an expert on the subject ;-)), but when working
>>> on software for my employer (who has a tendency of being careful about such
>>> things), we tend to follow the roughly the rules specified above.
>> 
>> Hey Ted, can you update source.xml (or whatever appropriate jakarta-site2
>> file) in order to get that little rule 'documented'?
>> 
>
>Here's a quick question - what makes that a rule?  Ted putting it into a
>file?
>
>I don't disagree with the  suggestion - I mean, we need to do it - I am just
>asking what makes it a rule now
>
>
>On the issue itself, isn't this something that should be uniformly done
>across all Apache projects?
>
>I would think that since it's part of the License, we want uniformity.
>
>-- 
>Geir Magnusson Jr.   [EMAIL PROTECTED]
>System and Software Consulting
>You're going to end up getting pissed at your software
>anyway, so you might as well not pay for it. Try Open Source.
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

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



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

Re: License change for new year ?

[Ted Husted]

"Geir Magnusson Jr." wrote:
> Here's a quick question - what makes that a rule?  Ted putting it into a
> file?
> 
> I don't disagree with the  suggestion - I mean, we need to do it - I am just
> asking what makes it a rule now
> 
> On the issue itself, isn't this something that should be uniformly done
> across all Apache projects?
> 
> I would think that since it's part of the License, we want uniformity.


Following up on an allusion Sam made the other day, I'm thinking that
the Jakarta guidelines are a product like any other here, and the PMC
act as its Committers. 

A change to the guidelines is a product change like any other, and
subject to lazy consensus. 

Of course, since we are all good Apache Scientists, we would discuss any
significant change before making it, to prevent a round of commits and
vetos. 

The mailbox for general Apache and licensing questions is
[EMAIL PROTECTED] if someone wants to follow up. 

There is also a brief license faq here:


http://nagoya.apache.org:8080/jyve-faq/Turbine/screen/DisplayTopics/action/SetAll/project_id/2/faq_id/38


Brian once agreed that there should be more licensing information
available, but didn't seem interested in pursuing it himself.

Perhaps we could suggest that someone with the appropriate karma use our
new addition as a model for updating this page:

http://apache.org/foundation/preFAQ.html#licence


-- 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: License change for new year ?

[Peter Donald]

On Thu, 10 Jan 2002 12:24, Geir Magnusson Jr. wrote:
> Here's a quick question - what makes that a rule?  Ted putting it into a
> file?

It is a legal requirement for the license to be valid.

> I don't disagree with the  suggestion - I mean, we need to do it - I am
> just asking what makes it a rule now

Anything that we decide to make a rule (hopefully little), anything that is 
part of Apaches "culture"/regulations/bylaws etc, anything required to 
protect Apache or committers or codebase (usually these are the legal uglies)

am I missing anything ?

> On the issue itself, isn't this something that should be uniformly done
> across all Apache projects?
>
> I would think that since it's part of the License, we want uniformity.

It would probably be a good idea. You could post this to [EMAIL PROTECTED] 
to proceed if you want. Theres also a lawyer on that list which will be able 
to make sure we are doing the right thing.

-- 
Cheers,

Pete

**
| You can't wake a person who is pretending  |
|   to be asleep. -Navajo Proverb.   |
**

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

Re: License change for new year ?

[Geir Magnusson Jr.]

On 1/9/02 12:53 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:

> on 1/9/02 6:49 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> 
>> Ted Husted wrote:
>>> 
>>> I think on a continuing basis, Committers should update the copyright
>>> notice to include the current year whenever they update a source file.
>>> This will happen most often in the early part of a year, but should
>>> happen year-round. So, as Peter said, if you revise a source file from
>>> 1999, you should change the copyright notice in the license to read
>>> 1999, 2002. If the file was from 2001, we would change it to 2001-2002.
>> 
>> I have never bothered to learn the details (there are some topics I avoid
>> lest I become perceived as an expert on the subject ;-)), but when working
>> on software for my employer (who has a tendency of being careful about such
>> things), we tend to follow the roughly the rules specified above.
> 
> Hey Ted, can you update source.xml (or whatever appropriate jakarta-site2
> file) in order to get that little rule 'documented'?
> 

Here's a quick question - what makes that a rule?  Ted putting it into a
file?

I don't disagree with the  suggestion - I mean, we need to do it - I am just
asking what makes it a rule now


On the issue itself, isn't this something that should be uniformly done
across all Apache projects?

I would think that since it's part of the License, we want uniformity.

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



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

Re: Mission ...

[Geir Magnusson Jr.]

On 1/9/02 7:42 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> Danny Angus wrote:
>> If Jakarta != java and/or Jakarta != server, (which appeared on this list a
>> few days ago, but I cant find the original mail)
>> then the mission statement is at odds with the project, which must at best
>> create bad karma and at worst it broadcasts a misleading message about the
>> project to the whole world (or the English speaking bit at least).
>> 
>> "Mission
>> Provide commercial-quality server solutions based on the Java Platform that
>> are developed in an open and cooperative fashion"
> 
> 
> A lot things appear on this list =:0)
> 
> At this point, the general consensus seems to be that we need things
> like Ant to create the server solutions.
> 
> We could propose that the word server be strucken from the Jakarta
> Mission, but the practical value of opening that kettle of fish is
> debatable. 
> 

I'm confused - didn't you already propose that we do that?  I remember
peter's +1, which got us started on our little scope thread...

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert


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

Re: Mission ...

[Ted Husted]

SHORT TERM PLAN 

There's a proposed update to the mission page at 

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

It uses the language from our latest charter, 

http://jakarta.apache.org/site/pmc/01-03-19-meeting-summary.html at 2.1

and also adds information about the Apache Software Foundation and some
"more information" links to fill out the page. 

-Ted.

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

RE: [OT] Code conventions

[Paulo Gaspar]

What about at leat a clue ("[OT]") that this is completely out
of topic?
=;o)

(Yeah! I should have done this before myself.)

Have fun,
Paulo

> -Original Message-
> From: Armin Zeltner [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 09, 2002 11:31 PM
> To: Jakarta General List
> Subject: Re: Code conventions
> 
> 
> Hi folks,
> 
> what  about micro-printed on-screen code, watched through glasses?
> faster? or  slower?
> 
> 
> JAVA is a myst
> 
> 
> Kurt Schrader wrote:
> 
> >
> > On Wednesday, January 9, 2002, at 03:34 PM, Andrew C. Oliver wrote:
> >
> >> What about if you set the font size really small? LOL
> >>
> >> -Andy
> >
> >
> > Perhaps Microsoft just has their font size set really big.  :)
> >
> > -Kurt
> >
> >
> > -- 
> > 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: Code conventions

[Armin Zeltner]

Hi folks,

what  about micro-printed on-screen code, watched through glasses?
faster? or  slower?


JAVA is a myst


Kurt Schrader wrote:

>
> On Wednesday, January 9, 2002, at 03:34 PM, Andrew C. Oliver wrote:
>
>> What about if you set the font size really small? LOL
>>
>> -Andy
>
>
> Perhaps Microsoft just has their font size set really big.  :)
>
> -Kurt
>
>
> -- 
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>



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

Re: Code conventions

[Kurt Schrader]

On Wednesday, January 9, 2002, at 03:34 PM, Andrew C. Oliver wrote:

> What about if you set the font size really small? LOL
>
> -Andy

Perhaps Microsoft just has their font size set really big.  :)

-Kurt


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

Re: Code conventions

[Andrew C. Oliver]

Tim Vernum wrote:

> > > It's only two little lines extra to include the {}'s,
> >
> > Yeah, but those two lines will make my code run slower.
> >
> > Don't you know?
> >
> > The less space your source code takes, the less space
> > your class file will take.
> > And smaller classes run faster.
> >

> Well, I could be wrong, but if i remember it well, the same compiler
produces the same 
> object code no matter the number of spaces, newlines, and tabs are
between tokens, 
> statements, and so. They are not important for object code, just for >
> readability. 
> Compiler could take a bit (quite bit) more to compile a file, but once
> the class is 
> generated, the result object file should be the same.

> (Forgive me if i am wrong)

What about if you set the font size really small? LOL

-Andy

-- 
eat POI its good http://poi.sourceforge.net - all those Hawaiians can't
be wrong.

The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

Re: Code conventions

[Andrew C. Oliver]

>>
>> >:)
>>
>> Someone told me if you use a really small font like courier 6pt then
>> you don't even need an optimizing compiler.
>>

>Thanks to this conversation, I finally did think of a good reason to
use
>braces on a separate line (which I detest, but that's just me) -- if

+1

>your
>manager judges you on how many lines of code you write, you get two
free
>lines for every "if"  statement.

What is absolutely scary is I've worked at places where I would not have
been the least bit surprised.  I'd find that easier to conform to than a
standardized IDE (which I've been in numerous places that did).

>:-)

>> -Andy
>>

>Craig


-- 
eat POI its good http://poi.sourceforge.net - all those Hawaiians can't
be wrong.

The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

RE: Code conventions

[Paulo Gaspar]

LOL!
Are you taking these guys seriously?
=;o)

Have fun,
Paulo

> -Original Message-
> From: Carlos Alonso Vega [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 09, 2002 8:31 PM
> To: Jakarta General List; [EMAIL PROTECTED]
> Subject: Re: Code conventions
> 
> 
> 
> Tim Vernum wrote:
> 
> > > It's only two little lines extra to include the {}'s,
> >
> > Yeah, but those two lines will make my code run slower.
> >
> > Don't you know?
> >
> > The less space your source code takes, the less space
> > your class file will take.
> > And smaller classes run faster.
> >
> 
> Well, I could be wrong, but if i remember it well, the same 
> compiler produces the same object code no matter the number of 
> spaces, newlines, and tabs are between tokens, statements, and 
> so. They are not important for object code, just for readability. 
> Compiler could take a bit (quite bit) more to compile a file, but 
> once the class is generated, the result object file should be the same.
> 
> (Forgive me if i am wrong)
> 


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

Re: Code conventions

[Carlos Alonso Vega]

Tim Vernum wrote:

> > It's only two little lines extra to include the {}'s,
>
> Yeah, but those two lines will make my code run slower.
>
> Don't you know?
>
> The less space your source code takes, the less space
> your class file will take.
> And smaller classes run faster.
>

Well, I could be wrong, but if i remember it well, the same compiler produces the same 
object code no matter the number of spaces, newlines, and tabs are between tokens, 
statements, and so. They are not important for object code, just for readability. 
Compiler could take a bit (quite bit) more to compile a file, but once the class is 
generated, the result object file should be the same.

(Forgive me if i am wrong)



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

Re: [PATCH] jakarta-site2/xdocs/site/mail.xml

[Ceki Gulcu]

Done. I hope the actual patch contains less typos than
my previous mail describing the patch. :-)

--- Jon Scott Stevens <[EMAIL PROTECTED]> wrote:
> on 1/9/02 4:27 AM, "Ceki Gulcu" <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Hello all,
> > 
> > Here is a patch jakarta-site2/xdocs/site/mail.xml,
> the source for the
> > http://jakarta.apache.org/site/mail.html page.
> > 
> > The patch contains a few corrections, a sligt
> re-organisation and some
> > stylistic changes. I think it provides for easier
> reading.
> > 
> > I have not yet applied the patch awating approval.
> Regards, Ceki
> 
> +1. I'm always up for experimentation on this page.
> 
> -jon
> 
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


=
-
Ceki - http://qos.ch

__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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

Re: License change for new year ?

[Ted Husted]

Yes, it's on my list.

Jon Scott Stevens wrote:
> 
> on 1/9/02 6:49 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> 
> > Ted Husted wrote:
> >>
> >> I think on a continuing basis, Committers should update the copyright
> >> notice to include the current year whenever they update a source file.
> >> This will happen most often in the early part of a year, but should
> >> happen year-round. So, as Peter said, if you revise a source file from
> >> 1999, you should change the copyright notice in the license to read
> >> 1999, 2002. If the file was from 2001, we would change it to 2001-2002.
> >
> > I have never bothered to learn the details (there are some topics I avoid
> > lest I become perceived as an expert on the subject ;-)), but when working
> > on software for my employer (who has a tendency of being careful about such
> > things), we tend to follow the roughly the rules specified above.
> 
> Hey Ted, can you update source.xml (or whatever appropriate jakarta-site2
> file) in order to get that little rule 'documented'?
> 
> Thx.
> 
> -jon
> 
> --
> 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: License change for new year ?

[Jon Scott Stevens]

on 1/9/02 6:49 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Ted Husted wrote:
>> 
>> I think on a continuing basis, Committers should update the copyright
>> notice to include the current year whenever they update a source file.
>> This will happen most often in the early part of a year, but should
>> happen year-round. So, as Peter said, if you revise a source file from
>> 1999, you should change the copyright notice in the license to read
>> 1999, 2002. If the file was from 2001, we would change it to 2001-2002.
> 
> I have never bothered to learn the details (there are some topics I avoid
> lest I become perceived as an expert on the subject ;-)), but when working
> on software for my employer (who has a tendency of being careful about such
> things), we tend to follow the roughly the rules specified above.

Hey Ted, can you update source.xml (or whatever appropriate jakarta-site2
file) in order to get that little rule 'documented'?

Thx.

-jon


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

Re: [PATCH] jakarta-site2/xdocs/site/mail.xml

[Jon Scott Stevens]

on 1/9/02 4:27 AM, "Ceki Gulcu" <[EMAIL PROTECTED]> wrote:

> 
> Hello all,
> 
> Here is a patch jakarta-site2/xdocs/site/mail.xml, the source for the
> http://jakarta.apache.org/site/mail.html page.
> 
> The patch contains a few corrections, a sligt re-organisation and some
> stylistic changes. I think it provides for easier reading.
> 
> I have not yet applied the patch awating approval. Regards, Ceki

+1. I'm always up for experimentation on this page.

-jon


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

Re: Code conventions

[Craig R. McClanahan]

On 9 Jan 2002, Andrew C. Oliver wrote:

> Date: 09 Jan 2002 00:07:00 -0500
> From: Andrew C. Oliver <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: general at jakarta <[EMAIL PROTECTED]>
> Subject: Re: Code conventions
>
> >>> It's only two little lines extra to include the {}'s,
> >> > Yeah, but those two lines will make my code run slower.
> >> > Don't you know?
> >> > The less space your source code takes, the less space
> >> your class file will take.
> >> And smaller classes run faster.
> >> > It must be true - 90% of people I've worked with seem
> >> to live by that principle.
> >
> >Add to that the fact that if it was hard to write, it should be hard to
> >read...
>
> >:)
>
> Someone told me if you use a really small font like courier 6pt then
> you don't even need an optimizing compiler.
>

Thanks to this conversation, I finally did think of a good reason to use
braces on a separate line (which I detest, but that's just me) -- if your
manager judges you on how many lines of code you write, you get two free
lines for every "if"  statement.

:-)

> -Andy
>

Craig


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

Re: License change for new year ?

[Sam Ruby]

Ted Husted wrote:
>
> I think on a continuing basis, Committers should update the copyright
> notice to include the current year whenever they update a source file.
> This will happen most often in the early part of a year, but should
> happen year-round. So, as Peter said, if you revise a source file from
> 1999, you should change the copyright notice in the license to read
> 1999, 2002. If the file was from 2001, we would change it to 2001-2002.

I have never bothered to learn the details (there are some topics I avoid
lest I become perceived as an expert on the subject ;-)), but when working
on software for my employer (who has a tendency of being careful about such
things), we tend to follow the roughly the rules specified above.

> But I'm not sure that we need to any automatic updates of source files
> that have not changed.

Again, my experience is consistent with this observation.

- Sam Ruby


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

Re: License change for new year ?

[Ted Husted]

I think on a continuing basis, Committers should update the copyright
notice to include the current year whenever they update a source file.
This will happen most often in the early part of a year, but should
happen year-round. So, as Peter said, if you revise a source file from
1999, you should change the copyright notice in the license to read
1999, 2002. If the file was from 2001, we would change it to 2001-2002. 

But I'm not sure that we need to any automatic updates of source files
that have not changed.

-Ted.

Berin Loritsch wrote:
> 
> Peter Donald wrote:
> 
> > On Wed, 9 Jan 2002 10:55, Vincent Massol wrote:
> >
> >>1/ Now that we are in 2002, do we need to change the text in all our
> >>license files to be : "Copyright (c) 1999-2002 The Apache Software
> >>Foundation" instead of "Copyright (c) 1999-2001 The Apache Software
> >>Foundation" ?
> >>
> >
> > should change it to include 2002. However the start date is determined by
> > when the project actually started/was donated to Apache - so many of the
> > newer ones will be 2001-2002
> >
> >
> >>2/ Some license files only have "Copyright (c) 1999 The Apache Software
> >>Foundation" and some others have a year range as in "Copyright (c)
> >>1999-2001 The Apache Software Foundation". Should one be preferred over
> >>the other ? Are they both valid ?
> >>
> >
> > It should be the longest duration at which it has been continuously developed
> > and owned by Apache. So most projects will be one of
> >
> > 1999-2002
> > 2000-2002
> > 2001-2002
> >
> > However some projects were mothballed and if we ever restarted work on them
> > we would have to do something like
> >
> > 1999-2000,2002 (for stylebook for instance)
> 
> Basically once the code is "published" in some form, (I.e. public CVS, official
> 
> release, etc.) you have to have a stamp on it.  Print publications have full
> dates for each release of the publication--though we shouldn't need to do that
> for our code.
> 
> --
> 
> "They that 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: 

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

Re: License change for new year ?

[Berin Loritsch]

Peter Donald wrote:

> On Wed, 9 Jan 2002 10:55, Vincent Massol wrote:
> 
>>1/ Now that we are in 2002, do we need to change the text in all our
>>license files to be : "Copyright (c) 1999-2002 The Apache Software
>>Foundation" instead of "Copyright (c) 1999-2001 The Apache Software
>>Foundation" ?
>>
> 
> should change it to include 2002. However the start date is determined by 
> when the project actually started/was donated to Apache - so many of the 
> newer ones will be 2001-2002
> 
> 
>>2/ Some license files only have "Copyright (c) 1999 The Apache Software
>>Foundation" and some others have a year range as in "Copyright (c)
>>1999-2001 The Apache Software Foundation". Should one be preferred over
>>the other ? Are they both valid ?
>>
> 
> It should be the longest duration at which it has been continuously developed 
> and owned by Apache. So most projects will be one of
> 
> 1999-2002
> 2000-2002
> 2001-2002
> 
> However some projects were mothballed and if we ever restarted work on them 
> we would have to do something like
> 
> 1999-2000,2002 (for stylebook for instance)


Basically once the code is "published" in some form, (I.e. public CVS, official

release, etc.) you have to have a stamp on it.  Print publications have full
dates for each release of the publication--though we shouldn't need to do that
for our code.




-- 

"They that 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: Mission ...

[Sam Ruby]

Ted Husted wrote:
>Danny Angus wrote:
>> If Jakarta != java and/or Jakarta != server, (which appeared on this
list a
>> few days ago, but I cant find the original mail)
>> then the mission statement is at odds with the project, which must at
best
>> create bad karma and at worst it broadcasts a misleading message about
the
>> project to the whole world (or the English speaking bit at least).
>>
>> "Mission
>> Provide commercial-quality server solutions based on the Java Platform
that
>> are developed in an open and cooperative fashion"
>
> A lot things appear on this list =:0)
>
> At this point, the general consensus seems to be that we need things
> like Ant to create the server solutions.

Admittedly, that argument appears weak at the present time.

Here's some history.  Originally (before my time), the founders of Jakarta
created this project with Ant, Tomcat, and Watchdog.  They came up with
that mission statement.  In hindsight, this was not the best description.
Then the community grew rapidly.  Many of the new subprojects were from the
now defunct java.apache.org.

> We could propose that the word server be strucken from the Jakarta
> Mission, but the practical value of opening that kettle of fish is
> debatable.

At the present time, we have a number of people who are committers to one
or more of the new-to-Jakarta (even if the subprojects themselves are older
than Ant, Tomcat, and Watchdog) who feel that Jakarta is getting a bit big.
That feeling is understandable.  Some proposals have been floated from time
to time which inevitably seem to split out subprojects from Jakarta that
the sponsors to those proposals don't actively participate in, and yet
somehow manage to leave those subprojects that the sponsor does actively
participate in.  Fancy that.

My way of resolving this is to offer to help out any proposal to split out
any subproject which is backed by a majority of committers in that
subproject or subprojects.  In other words, if someone wishes to create
another community, they have my blessing, but they have the burden of
establishing the new identity.

I really wish that either somebody would take me up on my offer, or stop
floating proposals that don't meet the criteria specified above.  Until
then, this debate keeps resurfacing every time a new subproject is
considered or someone brings up the divergence between the mission
statement and the actual community it proports to describe.

- Sam Ruby


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

Re: Mission ...

[Ted Husted]

Danny Angus wrote:
> If Jakarta != java and/or Jakarta != server, (which appeared on this list a
> few days ago, but I cant find the original mail)
> then the mission statement is at odds with the project, which must at best
> create bad karma and at worst it broadcasts a misleading message about the
> project to the whole world (or the English speaking bit at least).
> 
> "Mission
> Provide commercial-quality server solutions based on the Java Platform that
> are developed in an open and cooperative fashion"


A lot things appear on this list =:0)

At this point, the general consensus seems to be that we need things
like Ant to create the server solutions. 

We could propose that the word server be strucken from the Jakarta
Mission, but the practical value of opening that kettle of fish is
debatable. 

-Ted.

I don't necessarily agree with everything I say.
--- Marshall McLuhan (1911 - 1980)


> 
> d.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

[PATCH] jakarta-site2/xdocs/site/mail.xml

[Ceki Gulcu]

 
Hello all,

Here is a patch jakarta-site2/xdocs/site/mail.xml, the source for the
http://jakarta.apache.org/site/mail.html page.

The patch contains a few corrections, a sligt re-organisation and some
stylistic changes. I think it provides for easier reading.

I have not yet applied the patch awating approval. Regards, Ceki

Index: xdocs/site/mail.xml
===
RCS file: /home/cvs/jakarta-site2/xdocs/site/mail.xml,v
retrieving revision 1.20
diff -u -r1.20 mail.xml
--- xdocs/site/mail.xml 8 Dec 2001 00:11:17 -   1.20
+++ xdocs/site/mail.xml 9 Jan 2002 11:58:37 -
@@ -10,54 +10,50 @@
 
 
 
-
-A mailing list is an electronic discussion forum that anyone can
-"subscribe" to. When someone sends an email message to the mailing list,
+A mailing list is an electronic discussion forum that anyone can
+subscribe to. When someone sends an email message to the mailing list,
 a copy of that message is broadcast to everyone who is subscribed to
 that mailing list. Mailing lists provide a simple and effective
-communication mechanism. Because it is a forum with potentially
-thousands of subscribers, there is a common set of etiquette guidelines
-that should be observed (keep reading).
+communication mechanism. With potentially thousands of subscribers,
+there is a common set of etiquette guidelines that you should observe.
+Please keep on reading.
 
 
-
-Every volunteer project obtains its strength from the people involved
-in it. These people are joined through the mailing lists that they are
-subscribed to. You are welcome to join any of our mailing lists (or
-all of them if you wish). You can choose to lurk, or actively
-participate; it's up to you.  The level of community responsiveness to
-specific questions you post about is generally directly proportional
-to the amount of effort you spend formulating your question.
-
 
 
-Before you join any mailing lists, you should make sure that you
-read and follow the information below...
-
-
-
-We ask that you do your best to respect the charter of the appropriate 
-mailing list. There are generally two types of lists that you can join. 
+
+ Respect the mailing list type
+
+ There are generally two types of lists.
 
 
 
 
 
-The "User" list is where you should send questions and comments
-about configuration, setup, usage and other "user" types of
-questions.
+The "User" lists where you can send questions and comments about
+configuration, setup, usage and other "user" types of questions.
 
 
-The "Developer" list is where you should should send questions and
+The "Developer" lists where you can send questions and
 comments about the actual software source code and general
 "development" types of questions.
 
 
 
 
+Some questions are appropriate for posting on both the "user" and
+the "developer" lists. In this case, pick one and only one. Do not
+cross post.
+
+Asking a configuration question on the developers list is frowned
+upon because developers' time is as precious as yours. By contacting
+them directly instead of the user base you are abusing resources. In
+fact, it is unlikely that you will get a quicker answer, if at
+all.
+
 
 
-Summary: Join the lists that are appropriate for your discussion.
+ Join the lists that are appropriate for your discussion.
 
 Please make sure that you are joining the list that is appropriate for the 
 topic or product that you would like to discuss. For example, 
@@ -68,27 +64,22 @@
 
 
 
-Summary: Do not abuse resources in order to get help.
-
-Asking your configuration or user type of question on the developers list 
-because you think that you will get help more quickly by going directly to 
-the developers instead of to the user base is not very nice. Chances are 
-that doing this will actually prevent people from answering your question 
-because it is clear that you are trying to abuse resources.
-
+Ask smart questions.   
 
-
-
-Summary: Ask smart questions.
-
-http://www.tuxedo.org/~esr/faqs/smart-questions.html";>Please
-read this essay which details how to write a smart question. 
-This will almost guarantee that you will get a good answer.
+Every volunteer project obtains its strength from the people involved
+in it. You are welcome to join any of our mailing lists.  You can
+choose to lurk, or actively participate; it's up to you.  The level of
+community responsiveness to specific questions is generally directly
+proportional to the amount of effort you spend formulating your
+question. Eric Raymond has even written an essay entitled http://www.tuxedo.org/~esr/faqs/smart-questions.html";>"Asking
+Smart Questions" precisely on this topic.  Although somewhat
+militant, it is definitely worth reading.
 
 
 
 
-Summary: Keep your email short and to the point.
+Keep your email short and to the point.
 
 If your email is more than about a page of text, chances are

Mission ...

[Danny Angus]

If Jakarta != java and/or Jakarta != server, (which appeared on this list a
few days ago, but I cant find the original mail)
then the mission statement is at odds with the project, which must at best
create bad karma and at worst it broadcasts a misleading message about the
project to the whole world (or the English speaking bit at least).

"Mission
Provide commercial-quality server solutions based on the Java Platform that
are developed in an open and cooperative fashion"

d.



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

Re: License change for new year ?

[Conor MacNeill]

Vincent Massol wrote:

> I have 2 questions :
> 
> 1/ Now that we are in 2002, do we need to change the text in all our
> license files to be : "Copyright (c) 1999-2002 The Apache Software
> Foundation" instead of "Copyright (c) 1999-2001 The Apache Software
> Foundation" ?
> 
> 2/ Some license files only have "Copyright (c) 1999 The Apache Software
> Foundation" and some others have a year range as in "Copyright (c)
> 1999-2001 The Apache Software Foundation". Should one be preferred over
> the other ? Are they both valid ?
> 
> Thanks
> -Vincent


Vincent,

I don't know the official Apache or Jakarta policies, if there are any. 
I have tried to follow something I read in the Taligent guide to 
designing programs (A C++ era coding convention/design guide book), 
where it states

"If you significantly modify a file, list the year of the modification. 
The years correspond to publication, not creation, dates. Separate 
consecutive years with a dash, but off years with a comma

// Copyright (c) 1992, 1994-1996 "

Seems a reasonable approach.

Conor





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

Re: License change for new year ?

[Peter Donald]

On Wed, 9 Jan 2002 10:55, Vincent Massol wrote:
> 1/ Now that we are in 2002, do we need to change the text in all our
> license files to be : "Copyright (c) 1999-2002 The Apache Software
> Foundation" instead of "Copyright (c) 1999-2001 The Apache Software
> Foundation" ?

should change it to include 2002. However the start date is determined by 
when the project actually started/was donated to Apache - so many of the 
newer ones will be 2001-2002

> 2/ Some license files only have "Copyright (c) 1999 The Apache Software
> Foundation" and some others have a year range as in "Copyright (c)
> 1999-2001 The Apache Software Foundation". Should one be preferred over
> the other ? Are they both valid ?

It should be the longest duration at which it has been continuously developed 
and owned by Apache. So most projects will be one of

1999-2002
2000-2002
2001-2002

However some projects were mothballed and if we ever restarted work on them 
we would have to do something like

1999-2000,2002 (for stylebook for instance)

-- 
Cheers,

Pete


 "No. Try not. Do. Or do not. There is no try." 
 -- Yoda 



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