Re: Code conventions

[Glenn Nielsen]

Stefano Mazzocchi wrote:
> 
> Jon Scott Stevens wrote:
> >
> > on 1/10/02 1:16 AM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:
> >
> > >> LOL!
> > >> Are you taking these guys seriously?
> > >> =;o)
> > >>
> > > No, since Jon didn't participate
> > > to the thread ;)
> >
> > I heard that if you shorten the names of your variables and methods down to
> > single letters, the execution speed increases by a factor relative to the
> > amount of space saved in your .java files...
> >
> > :-)
> 
> execution no, but it does reduce classloading time... of course, that's
> not enough of a reason to do it anyway :)
> 

If there is a performance benefit from the above, it sounds like a
natural for the optimize switch of a java compiler.  I wouldn't
do it in code I write.  I've seen enough obfuscated code maintaining
other's perl scripts. ;-)

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

Re: Code conventions

[Stefano Mazzocchi]

Jon Scott Stevens wrote:
> 
> on 1/10/02 1:16 AM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:
> 
> >> LOL!
> >> Are you taking these guys seriously?
> >> =;o)
> >>
> > No, since Jon didn't participate
> > to the thread ;)
> 
> I heard that if you shorten the names of your variables and methods down to
> single letters, the execution speed increases by a factor relative to the
> amount of space saved in your .java files...
> 
> :-)

execution no, but it does reduce classloading time... of course, that's
not enough of a reason to do it anyway :)

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche


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

Re: Code conventions

[Jon Scott Stevens]

on 1/10/02 1:16 AM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:

>> LOL!
>> Are you taking these guys seriously?
>> =;o)
>> 
> No, since Jon didn't participate
> to the thread ;)

I heard that if you shorten the names of your variables and methods down to
single letters, the execution speed increases by a factor relative to the
amount of space saved in your .java files...

:-)

-jon


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

RE: Code conventions

[GOMEZ Henri]

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

No, since Jon didn't participate 
to the thread ;)

--
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:   
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> >
> >
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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: 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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Andrew C. Oliver]

>>> 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.

-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: Code conventions

[Geir Magnusson Jr.]

On 1/8/02 6:12 PM, "Tim Vernum" <[EMAIL PROTECTED]> 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.
> 
> 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...

:)

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


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

Re: Code conventions

[Geir Magnusson Jr.]

On 1/8/02 8:53 AM, "Endre Stølsvik" <[EMAIL PROTECTED]> wrote:

> On Fri, 4 Jan 2002, Geir Magnusson Jr. wrote:
> 
> | My question is what are the consequences to forcing me to do #2 when #1 is
> | perfectly acceptable throughout the professional world?
> 
> That syntax is so bleedin' ugly that I would suspect you were a novice not
> knowing how to code.. ;)
> 
> PROFESSIONALS don't code using really, really ugly standards...

No, they consult the coding manual from the technology vendor.

 :D


> 
> if (something)
> {
>   Some block;
> }
> 
> That's so ugly I have a hard time parsing it.
> 
> The _only_ way which is worse, is:
> 
> if (something)
>   {
>   Some block;
>   }
> 
> How is is possible to devise such a _fantastically_ ugly way of writing a
> block? I have a hard time trying to _write_ that example there. It is so
> utterly incredible. I have to go through it, parsing all such code char by
> char, hitting the del key until a "{" appears after the if clause..!
> 
> ;)
> 

I'm glad that you put your own health and well-being on the line, assuming
the risks for your compatriots, by actually typing if blocks different from
your usual.  Since you did it in the context of an Apache public discussion,
you may apply for funding from the ASF for counseling and therapy, but
remember the out of network co-pay.


> But then, on a serious note, the un-enclosed "block" like this
> 
> if (something)
>   this;
> else
>   that;
> 
> is a bit dangerous.


I think it can be very dangerous, especially in a multi-programmer
environment. (Seriously...)

> If you start, kind of mindlessy, to play around with
> the code there, you all of a sudden insert a line extra after the that
> part, thinking that it will execute only in the else part. Which, of
> course, it won't, as it executes all the time..
> 
> It's only two little lines extra to include the {}'s, IF you of course
> don't use "the really ugly standard", or worse, "the _fantastically_ ugly
> standard", mentioned above.
> 
> if (something) {
>   this;
> }
> else {
>   that;
> }

Foul!  Heathen!  Gaak!
 
> You could, if the this and that parts were very small, do this
> 
> if (something) { this; }
> else { that; }

Ug!  Please stop!  I beg you.
 
> Or prettify that as
> 
> if (something) { this; }
> else   { that; }


Hey!  You stole my code :)
 
> but now you're really moving along the edge..
> 
> :)
> 
> 
> 
> | "On your resume, I see that you were terminated for cause at Sun?"
> |
> | "Yes, I created too many classes with the opening brace on a separate
> | line..."
> 
> "WHAT?  You DARE coming in here, wasting my time, being an
> opening-brace-on-separate-line-ASSHOLE? You get the f*** outta here!!"
> ---
> "GUARDS! - Could you please shove this thing into the incer...  Erhm, I
> meant; show this ... person ... to the door?"
> 

LOL

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin



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

RE: Code conventions

[Ylan Segal]

> -Original Message-
> From: Tim Vernum [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 08, 2002 5:12 PM
> To: 'Jakarta General List'
> 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.
>
How about having your code with a nice format. Then running it through a
utility that strips all formatting and makes the source file compact, and
then compile that.
This would make the code-format-promoting people happy, and also the
need-for-speed-at-every-cost people.
I remember somewhere looking at a utility like this once... but don't know
where.

Just a thought.

Ylan Segal.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Code conventions

[Tim Vernum]

> 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.

-- 


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: Code conventions

[Endre Stølsvik]

On Fri, 4 Jan 2002, Geir Magnusson Jr. wrote:

| My question is what are the consequences to forcing me to do #2 when #1 is
| perfectly acceptable throughout the professional world?

That syntax is so bleedin' ugly that I would suspect you were a novice not
knowing how to code.. ;)

PROFESSIONALS don't code using really, really ugly standards...

if (something)
{
Some block;
}

That's so ugly I have a hard time parsing it.

The _only_ way which is worse, is:

if (something)
{
Some block;
}

How is is possible to devise such a _fantastically_ ugly way of writing a
block? I have a hard time trying to _write_ that example there. It is so
utterly incredible. I have to go through it, parsing all such code char by
char, hitting the del key until a "{" appears after the if clause..!

;)

But then, on a serious note, the un-enclosed "block" like this

if (something)
this;
else
that;

is a bit dangerous. If you start, kind of mindlessy, to play around with
the code there, you all of a sudden insert a line extra after the that
part, thinking that it will execute only in the else part. Which, of
course, it won't, as it executes all the time..

It's only two little lines extra to include the {}'s, IF you of course
don't use "the really ugly standard", or worse, "the _fantastically_ ugly
standard", mentioned above.

if (something) {
this;
}
else {
that;
}

You could, if the this and that parts were very small, do this

if (something) { this; }
else { that; }

Or prettify that as

if (something) { this; }
else   { that; }

but now you're really moving along the edge..

:)



| "On your resume, I see that you were terminated for cause at Sun?"
|
| "Yes, I created too many classes with the opening brace on a separate
| line..."

  "WHAT?  You DARE coming in here, wasting my time, being an
opening-brace-on-separate-line-ASSHOLE? You get the f*** outta here!!"
 ---
  "GUARDS! - Could you please shove this thing into the incer...  Erhm, I
meant; show this ... person ... to the door?"


-- 
Mvh,
Endre


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

Re: Code conventions

[Gunnar Rønning]

* "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
|
| It could even happen in the USA and it is quite dangerous to think
| otherwise (because then you are not alert).

Well, I would argue that it is happening in the US now with the new 
military courts. 

-- 
Gunnar Rønning - [EMAIL PROTECTED]
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/

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

Re: Jakarta Status [was Code conventions]

[Stefano Mazzocchi]

Jon Scott Stevens wrote:
> 
> on 1/4/02 4:20 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> 
> > They aren't even comparable, are they?
>
> Of course not.

No, I agree, I was just teasing :)
 
> http://jakarta.apache.org/velocity/dvsl/
> 
> When DVSL is integrated into Turbine's presentation layer and people are
> using it, the comparison will definitely be Cocoon2 vs. Turbine.

Uh, cool, let me take a look...

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche




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

Re: Jakarta Status [was Code conventions]

[Geir Magnusson Jr.]

On 1/4/02 7:38 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:

> on 1/4/02 4:20 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> 
>> They aren't even comparable, are they?
> 
> Of course not.
> 
>   http://jakarta.apache.org/velocity/dvsl/
> 
> When DVSL is integrated into Turbine's presentation layer and people are
> using it, the comparison will definitely be Cocoon2 vs. Turbine.
> 
> -jon
> 

Certainly!  But that's a whole other kettle of fish :)

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Now what do we do?"


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

Re: Jakarta Status [was Code conventions]

[Jon Scott Stevens]

on 1/4/02 4:20 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:

> They aren't even comparable, are they?

Of course not.

http://jakarta.apache.org/velocity/dvsl/

When DVSL is integrated into Turbine's presentation layer and people are
using it, the comparison will definitely be Cocoon2 vs. Turbine.

-jon


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

Re: Jakarta Status [was Code conventions]

[Geir Magnusson Jr.]

On 1/4/02 6:58 PM, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:

> "Craig R. McClanahan" wrote:
>> 
>> On Fri, 4 Jan 2002, Ceki Gülcü wrote:
>> 
 
 - Sam Ruby
 
 P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
 and Jakarta?  Then discussions as to where POI should go would be moot.
 Gump doesn't care about these arbitrary distinctions, why should we?
>>> 
>>> +1 on the principle of merging Jakarta and XML.
>> 
>> Agreed that it's definitely worth looking at.
>> 
>>> However, you realize
>>> there are technical considerations such as the look and fell of the
>>> merged web-site.
>> 
>> Sheesh ... just when I was starting to think that *nothing* could top the
>> rancor of arguing about coding conventions ... :-)
> 
> Yeah, Anakia vs. Cocoon2 would be a fun pissing contest to watch :) NOT!

They aren't even comparable, are they?

-- 
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: Jakarta Status [was Code conventions]

[Peter Donald]

On Sat, 5 Jan 2002 03:34, Sam Ruby wrote:
> Ted Husted wrote:
> > What would also help, I think, would be if we published more of our
> > statistics. I know Vincent was working on a download stats page once.
> > I've also seen people post interesting statistics about the posts to the
> > mailing lists. A snapshot of how many commits are being made and number
> > of unique committers making them would also be interesting. And other
> > things, I'm sure.
> >
> > Now, if I only had the faintest idea of how to automate something like
> > this ...
>
> Stefano, I and others are working on this.
>
> http://marc.theaimsgroup.com/?l=xml-apache-general&m=100857962129228&w=2
> http://www.apache.org/~stefano/forrest/1.5/

woohooo

> P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
> and Jakarta?

+1

-- 
Cheers,

Pete

Duct tape is like the force.  It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig

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

Re: Jakarta Status [was Code conventions]

[Stefano Mazzocchi]

Sam Ruby wrote:
> 
> Ted Husted wrote:
> >
> > What would also help, I think, would be if we published more of our
> > statistics. I know Vincent was working on a download stats page once.
> > I've also seen people post interesting statistics about the posts to the
> > mailing lists. A snapshot of how many commits are being made and number
> > of unique committers making them would also be interesting. And other
> > things, I'm sure.
> >
> > Now, if I only had the faintest idea of how to automate something like
> > this ...
> 
> Stefano, I and others are working on this.
> 
> http://marc.theaimsgroup.com/?l=xml-apache-general&m=100857962129228&w=2
> http://www.apache.org/~stefano/forrest/1.5/
> 
> - Sam Ruby
> 
> P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
> and Jakarta?  Then discussions as to where POI should go would be moot.
> Gump doesn't care about these arbitrary distinctions, why should we?

I fully resonate with this: I have *always* hated projects as
containers. I think Tomcat is a project, not Jakarta. I think Xerces is
a project not XML (which conflicts with XML the language).

In the future, I would simply love to see

 www.apache.org/tomcat

go along with 

 www.apache.org/httpd

and a good software map to tell the story, indicate the overlap, outline
those distinctions and so on.

It would also remove the need for PMCs and give the ASF board a reason
to exist.

The reason question is: could we stand the heat of a [EMAIL PROTECTED]
mail list?

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche




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

Re: Jakarta Status [was Code conventions]

[Stefano Mazzocchi]

"Craig R. McClanahan" wrote:
> 
> On Fri, 4 Jan 2002, Ceki Gülcü wrote:
> 
> > >
> > >- Sam Ruby
> > >
> > >P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
> > >and Jakarta?  Then discussions as to where POI should go would be moot.
> > >Gump doesn't care about these arbitrary distinctions, why should we?
> >
> > +1 on the principle of merging Jakarta and XML.
> 
> Agreed that it's definitely worth looking at.
> 
> > However, you realize
> > there are technical considerations such as the look and fell of the
> > merged web-site.
> 
> Sheesh ... just when I was starting to think that *nothing* could top the
> rancor of arguing about coding conventions ... :-)

Yeah, Anakia vs. Cocoon2 would be a fun pissing contest to watch :) NOT!

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche




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

Re: Jakarta Status [was Code conventions]

[Geir Magnusson Jr.]

On 1/4/02 12:39 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Here's a concrete example to illustrate the issue: I've always been under
> the assumption that at some point a few people in Jakarta land would take a
> sustained interest in contributing code to Gump, at which point, I would
> propose it to be a formal subproject.  At the present time, it looks like
> there is a greater possibility of interest of contributing by people in XML
> land.  This lead to a bit of soul searching, and I came to conclusion that
> if that were to come to pass, I would follow the community.  After all,
> what does it really matter whether the code is jakarta-gump or
> xml-whatever?


Funny.  I've been waiting for it to become a top level project (or at least
an Alexandrai project :)


-- 
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: Code conventions

[Stefano Mazzocchi]

Peter Donald wrote:

> So I +1 on suggesting standards for external parts of project, -1 for forcing
> it

uh, I jumped in the middle of a "where to place the curly brace code
format pissing contest", how cool.

For those of you who weren't around, we had the first resolution of this
(what later became condensed into the current PMC directives) around
1997 on the jserv-dev mail list. (Jon, remember that?)

Sure, it would be cool to have a clear code convention (or a language
like Python that more or less doesn't even compile if you don't follow
the right conventions) or a benevolent dictator (that used the
convention you like!). Unfortunately, we don't have any of those, so the
resolution was: most of the java source code out there (well, it was
1997, you know!) used the Sun coding conventions so we started from
there, but we decided to be tollerant on *cultural* differences.

And *cultural* differences include: editor used, favorite OS, favorite
mail client, favorite browser, favorite native language, favorite ice
cream flavor... :)

Sure, there should be *compromises* and there are some that are very
useful and understandable (the use of english as the language, no HTML
in email, nice quoting, polite messages, support for old browsers, no
ice cream attached to email) and some that are more subject to personal
judgement (local variable names, curly brace location, tab vs. space,
how many spaces for a tab).

When no objective result can be reached, discussions become religious
wars.

I'd follow Sam suggestions: let's be tollerant.

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche




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

Re: Code conventions

[Gunnar Rønning]

* Ceki Gülcü <[EMAIL PROTECTED]> wrote:
|
| >enough that another referendum could be held for the issue.
| 
| Laugh all you want. Referenda are great. Ask any Swiss citizen. 

Well, people are to stupid to know the issues ;-) 

Ask any Norwegian with a pro European Union membership stand ;-)

-- 
Gunnar Rønning - [EMAIL PROTECTED]
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/

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

Re: Jakarta Status [was Code conventions]

[Ceki Gülcü]

At 12:39 04.01.2002 -0500, you wrote:
>Ceki Gülcü wrote:
>>
>> +1 on the principle of merging Jakarta and XML. However, you realize
>> there are technical considerations such as the look and fell of the
>> merged web-site. More importantly, what would be the scope of the merged
>> XML+Jakarta?
>
>The more important question is what is the community model.  As the XML
>bylaws are clones of the Jakarta ones, I would venture to say that they are
>fairly compatible.
>
>> How should we call the combined project? ApacheGrabBag? SourceForgeII?
>
>Jakarta.
>
>[Note: answer above is merely to show that the proposal is not a serious
>one]
>
>One thing I would like people to think about.  I see viceral reaction at
>times to putting things in commons.  Or in Avalon/Turbine/Struts, etc.  And
>often there is lengthy debates about whether something belongs in Jakarta
>or not.  Yet, curiously, there seems to be little consideration as to
>whether something belongs in Apache or not.
>
>How many people here know what the Apache board does?

Yah, they have cocktails, go to the beach and barbecue.

>Here's a concrete example to illustrate the issue: I've always been under
>the assumption that at some point a few people in Jakarta land would take a
>sustained interest in contributing code to Gump, at which point, I would
>propose it to be a formal subproject.  

What? Contribute to Gump to make it more powerful and nagging? I rather 
iron my old shirts before scratching that itch.  Is it possible that Gump
is complete such that no one has anything valuable left to contribute?

>At the present time, it looks like
>there is a greater possibility of interest of contributing by people in XML
>land.  This lead to a bit of soul searching, and I came to conclusion that
>if that were to come to pass, I would follow the community.  After all,
>what does it really matter whether the code is jakarta-gump or
>xml-whatever?

Go for it. 


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



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

RE: Jakarta Status [was Code conventions]

[Gerhard Froehlich]

Hi



>Here's a concrete example to illustrate the issue: I've always been under
>the assumption that at some point a few people in Jakarta land would take a
>sustained interest in contributing code to Gump, at which point, I would
>propose it to be a formal subproject.  At the present time, it looks like
>there is a greater possibility of interest of contributing by people in XML
>land.  This lead to a bit of soul searching, and I came to conclusion that
>if that were to come to pass, I would follow the community.  After all,
>what does it really matter whether the code is jakarta-gump or
>xml-whatever?

Yep it matters because that's mixing of concerns. As an Avalon Committer I 
only say three words: Separation of Concerns :-)!

Beside there is lot of "inoffical" co-operation. Look at Cocoon and Avalon.
Devs in this project are working close together in technical issues though
the project aim is completly different.

I think you should leave the current diversification. Otherwise I see the 
danger that the xml-apache group is forced completely towards Java. But
that's not the aim of XML!

And when we soften Jakarta so that C++ (personally nothing against C)
servers could be possible as subprojects or whatever then we even 
could put everything under www.apache.org and in one mailing list ;)!

I know it's hard for us, but try to think as a guy from a entprise 
sales group ;-).

Just thoughts!

  Gerhard


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

Re: Jakarta Status [was Code conventions]

[Ted Husted]

Sam Ruby wrote:
> The more important question is what is the community model.  As the XML
> bylaws are clones of the Jakarta ones, I would venture to say that they are
> fairly compatible.

What about TCL then? 

I wouldn't actually care if there is one umbrella project or six. But it
seemed like the ASF was trying to organize things along platform lines. 

Should we think about merging with PHP too?

Should there actually be umbrella Apache Projects at all?

Maybe having proved ourselves, perhaps each product should now stand on
its own, as the HTTP Server does. And there would be one PMC for them
all.

Again, don't care. Just asking. 




> How many people here know what the Apache board does?

I used to read the minutes, but they've gotten hard to find. 

Perhaps they should be posted to the Committer list. 



> Here's a concrete example to illustrate the issue: I've always been under
> the assumption that at some point a few people in Jakarta land would take a
> sustained interest in contributing code to Gump, at which point, I would
> propose it to be a formal subproject.  At the present time, it looks like
> there is a greater possibility of interest of contributing by people in XML
> land.  This lead to a bit of soul searching, and I came to conclusion that
> if that were to come to pass, I would follow the community.  After all,
> what does it really matter whether the code is jakarta-gump or
> xml-whatever?

Perhaps if it were over here, then there would be more cross-pollination
between projects. 

Likewise with having things like POI in XML land, that Jartian products
might use. 


-- 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: Jakarta Status [was Code conventions]

[Scott Sanders]

> From: Sam Ruby [mailto:[EMAIL PROTECTED]] 
> One thing I would like people to think about.  I see viceral 
> reaction at times to putting things in commons.  Or in 
> Avalon/Turbine/Struts, etc.  And often there is lengthy 
> debates about whether something belongs in Jakarta or not.  
> Yet, curiously, there seems to be little consideration as to 
> whether something belongs in Apache or not.

Agreed.

> 
> How many people here know what the Apache board does?

:)

> 
> Here's a concrete example to illustrate the issue: I've 
> always been under the assumption that at some point a few 
> people in Jakarta land would take a sustained interest in 
> contributing code to Gump, at which point, I would propose it 
> to be a formal subproject.  At the present time, it looks 
> like there is a greater possibility of interest of 
> contributing by people in XML land.  This lead to a bit of 
> soul searching, and I came to conclusion that if that were to 
> come to pass, I would follow the community.  After all, what 
> does it really matter whether the code is jakarta-gump or 
> xml-whatever?

You should *always* follow the community.  The community gives life to
the codebase.

Scott

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

Re: Jakarta Status [was Code conventions]

[Craig R. McClanahan]

On Fri, 4 Jan 2002, Ceki Gülcü wrote:

> >
> >- Sam Ruby
> >
> >P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
> >and Jakarta?  Then discussions as to where POI should go would be moot.
> >Gump doesn't care about these arbitrary distinctions, why should we?
>
> +1 on the principle of merging Jakarta and XML.

Agreed that it's definitely worth looking at.

> However, you realize
> there are technical considerations such as the look and fell of the
> merged web-site.

Sheesh ... just when I was starting to think that *nothing* could top the
rancor of arguing about coding conventions ... :-)

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

Craig


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

Re: Jakarta Status [was Code conventions]

[Sam Ruby]

Ceki Gülcü wrote:
>
> +1 on the principle of merging Jakarta and XML. However, you realize
> there are technical considerations such as the look and fell of the
> merged web-site. More importantly, what would be the scope of the merged
> XML+Jakarta?

The more important question is what is the community model.  As the XML
bylaws are clones of the Jakarta ones, I would venture to say that they are
fairly compatible.

> How should we call the combined project? ApacheGrabBag? SourceForgeII?

Jakarta.

[Note: answer above is merely to show that the proposal is not a serious
one]

One thing I would like people to think about.  I see viceral reaction at
times to putting things in commons.  Or in Avalon/Turbine/Struts, etc.  And
often there is lengthy debates about whether something belongs in Jakarta
or not.  Yet, curiously, there seems to be little consideration as to
whether something belongs in Apache or not.

How many people here know what the Apache board does?

Here's a concrete example to illustrate the issue: I've always been under
the assumption that at some point a few people in Jakarta land would take a
sustained interest in contributing code to Gump, at which point, I would
propose it to be a formal subproject.  At the present time, it looks like
there is a greater possibility of interest of contributing by people in XML
land.  This lead to a bit of soul searching, and I came to conclusion that
if that were to come to pass, I would follow the community.  After all,
what does it really matter whether the code is jakarta-gump or
xml-whatever?

- Sam Ruby


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

Re: Jakarta Status [was Code conventions]

[Sam Ruby]

Ted Husted wrote:
>
> I'm not sure if I'm ready for the equation
>
> Jakarta != Java

http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/
http://cvs.apache.org/viewcvs/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/optional/dotnet/

> Thinking about it more carefully, ...

That was the real point of this exercise.  ;-)

- Sam Ruby


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

RE: Jakarta Status [was Code conventions]

[Gerhard Froehlich]

Hi,

>At 11:34 04.01.2002 -0500, you wrote:
>>Ted Husted wrote:
>>>
>>> What would also help, I think, would be if we published more of our
>>> statistics. I know Vincent was working on a download stats page once.
>>> I've also seen people post interesting statistics about the posts to the
>>> mailing lists. A snapshot of how many commits are being made and number
>>> of unique committers making them would also be interesting. And other
>>> things, I'm sure.
>>>
>>> Now, if I only had the faintest idea of how to automate something like
>>> this ...
>>
>>Stefano, I and others are working on this.
>>
>>http://marc.theaimsgroup.com/?l=xml-apache-general&m=100857962129228&w=2
>>http://www.apache.org/~stefano/forrest/1.5/
>>
>>- Sam Ruby
>>
>>P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
>>and Jakarta?  Then discussions as to where POI should go would be moot.
>>Gump doesn't care about these arbitrary distinctions, why should we?
>
>+1 on the principle of merging Jakarta and XML. However, you realize
>there are technical considerations such as the look and fell of the
>merged web-site. More importantly, what would be the scope of the merged 
>XML+Jakarta?
>
>How should we call the combined project? ApacheGrabBag? SourceForgeII?
>
>How about all the C++ projects in XML land? 
>
>When do you think ApacheGrabBag/SourceForgeII and the httpd projects 
>could be merged?
>
>Seriously, I think the idea is worth our consideration. Regards, Ceki

No, I wouldn't merge. Leave the URLs as are, take the Forrest design and 
change the color ;-)!

  Gerhard





 

In the beginning there was nothing... then even *that* exploded!



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

RE: Jakarta Status [was Code conventions]

[Paulo Gaspar]

I am 100% for that.

Even because:
 - How server specific is Ant?
 - And BCEL?
 - And Log4J?
 - And ORO?
 - And Regexp?
 - And Xerces?
 - And commons collections, DBCP, Beanutils...

And I could push it a bit more.

Of course that they are useful to build server stuff... as they could be
useful to build client stuff, which is exactly what happens with POI!


I think the QUALITY distinction is much more important than the server
issue and that should probably be formalized.

For me the important arguments being presented are those going on between
Stefano and Jon - if there is enough commitment and support for it.
(IMO Stefano record looks great. It only makes it better that he knows 
how and to whom to delegate responsibilities.)


Have fun,
Paulo Gaspar

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 04, 2002 6:14 PM
> 
> 
> Sam Ruby wrote:
> > P.S.  Food for thought: wouldn't it be nice if we could somehow 
> merge xml
> > and Jakarta?  Then discussions as to where POI should go would be moot.
> > Gump doesn't care about these arbitrary distinctions, why should we?
> 
> The thing with XML is that core products like Xerces are cross-platform.
> I'm not sure if I'm ready for the equation 
> 
> Jakarta != Java
> 
> Thinking about it more carefully, I would venture to say that POI (along
> with Battick, FOP, and Xang) may belong under Jakarta. 
> 
> But I'm not sure that we want to say that Jakarta != Java or XML==Java.
> 
> I do think it might be helpful to drop the "server" stipulation from the
> Jakarta charter. I realized that we are all born of the HTTPD Apache
> server, but I think the ASF is growing past that. Jakarta should be
> about the development of open source products on the Java platform. And
> the ASF should be about promoting meritocratic development, regardless
> of what it has any ties to the Apache HTTPD.
> 
> This coincides nicely with the other ASF projects, which are also based
> around given languages, like PHP. 
> 
> -- 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: 
> 

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

RE: Code conventions

[Gerhard Froehlich]

Hi,

>Gerhard,
>
>Is it fair and accurate to say that he came to power
>within the bounds and rules of a democratic system?

Yes and it should remind us, that the democratic system
is very imperfect! Even in the USA. A powerful President
with deep influence can slowly become more and more powerful
until the Parliament is meaningless.
And when the country simultaneously is in a deep recession
then "gnade uns gott".

IMO:
  politics == process howto get more power and control!

And a democratic system don't saves us for persons, which
want to use this power evil. It just makes the process
more bureaucratic. And that's the trick.

But you can't compare the democratic system of 1932 with our
systems in 2002!

But take look on Austria and Jörg Haider. If you are a German native
Speaker you should read the current discussion on about bilingual
street shields .

But don't let this dicussion become political!
IMHO politics sucks ;)

  Gerhard


-
I don't suffer from insanity. I enjoy every minute of it.
-

>At 17:58 04.01.2002 +0100, you wrote:
>>Hi,
>>
>>
>>
>>>Any democratic system is imperfect and hence flawed. Hitler was elected
>>>democratically although he soon moved to dismantle the system that
>>>brought him to power. D'oh, that damn Godwin's Law!
>>
>>Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler
>>because the other so called democratic parties like Volkspartei and
>>Socialist where so quarreled that they were unable to form a strong
>>coalition to kick this asshole out and preserve my country from this
>>dark 15 years.
>>Therefore the current Reichspräsident Hindenburg called Hitler for the
>>new Reichskanzler, because the existing Parlament was to weak. After
>>his dead '35 Hitler began with the so called Gleichschaltung.
>>
>>Hitler slowly destroyed the democratic system, but he was *never* elected
>>democratic!!
>>
>>
>>
>>  Gerhard
>>
>>
>>
>>
>>--
>>Black holes were created when God divided by zero.
>>--
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>For additional commands, e-mail: 
>
>--
>Ceki Gülcü - http://qos.ch
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>



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

RE: Code conventions

[Paulo Gaspar]

I am sure Gerhard can give a better answer, but IMHO he abused a lot
the system.

The truth is that it can happen anywhere if people are not very alert
and ready to fight for their rights.

It could even happen in the USA and it is quite dangerous to think
otherwise (because then you are not alert).


Have fun,
Paulo


> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 04, 2002 6:14 PM
>
> Gerhard,
>
> Is it fair and accurate to say that he came to power
> within the bounds and rules of a democratic system?
>
> At 17:58 04.01.2002 +0100, you wrote:
> >Hi,
> >
> >
> >
> >>Any democratic system is imperfect and hence flawed. Hitler was elected
> >>democratically although he soon moved to dismantle the system that
> >>brought him to power. D'oh, that damn Godwin's Law!
> >
> >Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler
> >because the other so called democratic parties like Volkspartei and
> >Socialist where so quarreled that they were unable to form a strong
> >coalition to kick this asshole out and preserve my country from this
> >dark 15 years.
> >Therefore the current Reichspräsident Hindenburg called Hitler for the
> >new Reichskanzler, because the existing Parlament was to weak. After
> >his dead '35 Hitler began with the so called Gleichschaltung.
> >
> >Hitler slowly destroyed the democratic system, but he was *never* elected
> >democratic!!
> >
> >
> >
> >  Gerhard


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

RE: Code conventions

[Paulo Gaspar]

In the process Hitler and his gang played a surprisingly high number of
dirty tricks. Surprising at least for a non German, since we only get
an overview of the WW2 history.

Since I work in Germany I have the benefit of the many documentaries
about the Nazi era played on TV (history is not forgotten here). I am
often quite surprised about how twisted and sophisticated some of those
tricks and strategies were.

BTW, a lot of those strategies involve scaring and distracting the
people with some fictional or real enemy.


Have fun,
Paulo

> -Original Message-
> From: Gerhard Froehlich [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 04, 2002 5:59 PM
>
> Hi,
>
> 
>
> >Any democratic system is imperfect and hence flawed. Hitler was elected
> >democratically although he soon moved to dismantle the system that
> >brought him to power. D'oh, that damn Godwin's Law!
>
> Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler
> because the other so called democratic parties like Volkspartei and
> Socialist where so quarreled that they were unable to form a strong
> coalition to kick this asshole out and preserve my country from this
> dark 15 years.
> Therefore the current Reichspräsident Hindenburg called Hitler for the
> new Reichskanzler, because the existing Parlament was to weak. After
> his dead '35 Hitler began with the so called Gleichschaltung.
>
> Hitler slowly destroyed the democratic system, but he was *never* elected
> democratic!!
>
> 
>
>   Gerhard


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

Re: Jakarta Status [was Code conventions]

[Ted Husted]

Sam Ruby wrote:
> P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
> and Jakarta?  Then discussions as to where POI should go would be moot.
> Gump doesn't care about these arbitrary distinctions, why should we?

The thing with XML is that core products like Xerces are cross-platform.
I'm not sure if I'm ready for the equation 

Jakarta != Java

Thinking about it more carefully, I would venture to say that POI (along
with Battick, FOP, and Xang) may belong under Jakarta. 

But I'm not sure that we want to say that Jakarta != Java or XML==Java.

I do think it might be helpful to drop the "server" stipulation from the
Jakarta charter. I realized that we are all born of the HTTPD Apache
server, but I think the ASF is growing past that. Jakarta should be
about the development of open source products on the Java platform. And
the ASF should be about promoting meritocratic development, regardless
of what it has any ties to the Apache HTTPD.

This coincides nicely with the other ASF projects, which are also based
around given languages, like PHP. 

-- 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: Code conventions

[Ceki Gülcü]

Gerhard,

Is it fair and accurate to say that he came to power 
within the bounds and rules of a democratic system? 

At 17:58 04.01.2002 +0100, you wrote:
>Hi,
>
>
>
>>Any democratic system is imperfect and hence flawed. Hitler was elected
>>democratically although he soon moved to dismantle the system that
>>brought him to power. D'oh, that damn Godwin's Law!
>
>Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler
>because the other so called democratic parties like Volkspartei and
>Socialist where so quarreled that they were unable to form a strong
>coalition to kick this asshole out and preserve my country from this
>dark 15 years.
>Therefore the current Reichspräsident Hindenburg called Hitler for the
>new Reichskanzler, because the existing Parlament was to weak. After
>his dead '35 Hitler began with the so called Gleichschaltung.
>
>Hitler slowly destroyed the democratic system, but he was *never* elected
>democratic!!
>
>
>
>  Gerhard
>
>
>
>
>--
>Black holes were created when God divided by zero.
>--
>
>
>
>
>--
>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: Code conventions

[Gerhard Froehlich]

Hi,



>Any democratic system is imperfect and hence flawed. Hitler was elected
>democratically although he soon moved to dismantle the system that
>brought him to power. D'oh, that damn Godwin's Law!

Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler
because the other so called democratic parties like Volkspartei and
Socialist where so quarreled that they were unable to form a strong
coalition to kick this asshole out and preserve my country from this
dark 15 years.
Therefore the current Reichspräsident Hindenburg called Hitler for the
new Reichskanzler, because the existing Parlament was to weak. After
his dead '35 Hitler began with the so called Gleichschaltung.

Hitler slowly destroyed the democratic system, but he was *never* elected
democratic!!



  Gerhard




--
Black holes were created when God divided by zero.
--




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

Re: Jakarta Status [was Code conventions]

[Ceki Gülcü]

At 11:34 04.01.2002 -0500, you wrote:
>Ted Husted wrote:
>>
>> What would also help, I think, would be if we published more of our
>> statistics. I know Vincent was working on a download stats page once.
>> I've also seen people post interesting statistics about the posts to the
>> mailing lists. A snapshot of how many commits are being made and number
>> of unique committers making them would also be interesting. And other
>> things, I'm sure.
>>
>> Now, if I only had the faintest idea of how to automate something like
>> this ...
>
>Stefano, I and others are working on this.
>
>http://marc.theaimsgroup.com/?l=xml-apache-general&m=100857962129228&w=2
>http://www.apache.org/~stefano/forrest/1.5/
>
>- Sam Ruby
>
>P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
>and Jakarta?  Then discussions as to where POI should go would be moot.
>Gump doesn't care about these arbitrary distinctions, why should we?

+1 on the principle of merging Jakarta and XML. However, you realize
there are technical considerations such as the look and fell of the
merged web-site. More importantly, what would be the scope of the merged 
XML+Jakarta?

How should we call the combined project? ApacheGrabBag? SourceForgeII?

How about all the C++ projects in XML land? 

When do you think ApacheGrabBag/SourceForgeII and the httpd projects 
could be merged?

Seriously, I think the idea is worth our consideration. Regards, Ceki


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



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

RE: Code conventions

[Ceki Gülcü]

At 16:01 04.01.2002 +, you wrote:
>Ceci wrote:
>
>> The inability of the PMC to take initiative stems from the Apache
>> voting process
>
>
>
>> The current system   is inappropriate for managing large projects
>like
>> Jakarta.
>
>
>
>I agree with this, I've only been a commiter since the end of last summer,
>and have been surprised that while the web site says..
>"This committee is the official managing body of the Jakarta Project and is
>responsible for setting overall project direction."
>It does not appear very pro-active in this role.
>
>I've been subscribed to this list out of curiosity about what the PMC do, to
>keep a finger on the pulse as it were, and apart from the discussions about
>new projects and the current rash of opinion on code standards there seems
>to be little traffic discussing "overall project direction"
>
>Perhaps thats because the direction is not changing, are the goals of the
>project still the same, are the subprojects all still moving steadily
>forward?
>They seem to be, and this would be a good reason for not interfering, after
>all there are no deadlines except those imposed by individual projects and
>few imperatives of the kind which, in the commercial world, need to be
>enforced by PM's.
>
>> we either:
>>
>> 1) Elect a PMC with real power, power to intervene and take painful
>> decisions, until the next elections.
>
>In a democracy (and I *know* apache isn't that) we elect from amongst
>ourselves representatives whom we charge with making decisions on our
>behalf, for that to make any sense we have to give them the authority to
>make those decisons and bind ourselves to them, anything else is just
>posturing.
>
>>
>> 2) Instate a system based on referendum, where the public can directly
>> intervene in making laws. By "public", I mean developers with commit
>> rights.
>
>Always contentious, referenda are un-democratic in that they imply that the
>fundamental assertion of democracy (that we elect people to represent us) is
>flawed.

Any democratic system is imperfect and hence flawed. Hitler was elected
democratically although he soon moved to dismantle the system that
brought him to power. D'oh, that damn Godwin's Law!

The PMC consists of a body of over 10 individuals who each have veto power and 
different interests.

>IMHO (as this whole spiel is) referenda would therefore render the PMC
>irrelevant.

Not necessarily. It depends how the roles and competencies of the
PMC and that of the body of committers are defined.

>However consensus decisions are *much* harder to achieve in larger groups,
>it would be un-realistic to expect every commiter to spend time giving every
>vote serious consideration, and so I favour a PMC where the elected members
>have made a commitment to considering the issues.

Not only is reaching consensus in larger groups harder, it is 
plain impossible. Thus, we should at least study other ways for taking 
decisions, for example by majority vote.

Hmm, I wonder who will -1 that first.

>> 3) Keeps things as they are and hope for the best.
>
>Unless the goals of the project have changed, or unless a significant change
>is needed to either the goals or the nature of the project the existing
>system should continue to work, perhaps Ceci's comments stem from a feeling
>that change is needed of the kind only changes in PM can accomodate.
>
>If so what's wrong? and why won't the current system be able to deliver the
>changes needed?

Yes, the current system could be adapted. 

Many people are probably wondering whether this discussion is not too political.
We are here to code not to chatter, right? 


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



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

Re: Jakarta Status [was Code conventions]

[Sam Ruby]

Ted Husted wrote:
>
> What would also help, I think, would be if we published more of our
> statistics. I know Vincent was working on a download stats page once.
> I've also seen people post interesting statistics about the posts to the
> mailing lists. A snapshot of how many commits are being made and number
> of unique committers making them would also be interesting. And other
> things, I'm sure.
>
> Now, if I only had the faintest idea of how to automate something like
> this ...

Stefano, I and others are working on this.

http://marc.theaimsgroup.com/?l=xml-apache-general&m=100857962129228&w=2
http://www.apache.org/~stefano/forrest/1.5/

- Sam Ruby

P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
and Jakarta?  Then discussions as to where POI should go would be moot.
Gump doesn't care about these arbitrary distinctions, why should we?


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

Re: Jakarta Status [was Code conventions]

[Ted Husted]

Danny Angus wrote:
> Perhaps thats because the direction is not changing, are the goals of the
> project still the same, are the subprojects all still moving steadily
> forward?
>
> They seem to be, and this would be a good reason for not interfering, after
> all there are no deadlines except those imposed by individual projects and
> few imperatives of the kind which, in the commercial world, need to be
> enforced by PM's.

I agree. Personally, I don't see that anything is broken. Things don't
happen as quickly as any of us would like, but they are happening.
Struts now supports Velocity along with JavaServer Pages. Turbine is
exposing more of its components, and Torque may graduate to a subproject
in its own right. Avalon is up to speed, and just made a significant
release. We've added BCEL, Lucene, and others to our midst this year.
Doug Cutting was going to step back from Lucene, but it looks like we've
drawn him back into the game ;-). The Commons has made several releases,
and is actively whiteboarding severl exciting new products, like the
Workflow and DynaBeans. 

I think the newsletter will help bring more of this out. There mis ore
good news than people imagine. We just don't blow our own horn much.

What would also help, I think, would be if we published more of our
statistics. I know Vincent was working on a download stats page once.
I've also seen people post interesting statistics about the posts to the
mailing lists. A snapshot of how many commits are being made and number
of unique committers making them would also be interesting. And other
things, I'm sure.

Now, if I only had the faintest idea of how to automate something like
this ...


-- 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: Code conventions

[Ceki Gülcü]

At 10:32 04.01.2002 -0500, you wrote:
>For reasons that are unknown to me, none of the e-mail that I have sent
>over the last few days has made it out to the mailing lists.  For all I
>know, at some point in the distant future, it will all be unleashed and
>make little sense out of context.  :-(
>
>Anyway, it looks like e-mail that I send now gets through so let me take
>advantage of it while I can...
>
>Ceki Gülcü wrote:
>>
>>> If some particular codebase under the Jakarta umbrella consistently
>>> chose to take actions which were inconsistent with the Apache mission,
>>> then I'm confident that the PMC would swiftly act to disolve this code
>>> base.  I am not aware of this being done before, so it would be
>>> uncharted territory, but I'm sure we would find a way.  And that way
>>> would not require 100% consensus.
>>>
>>> In my mind, the willful insertion of newlines in direct contradiction
>>> to the "Code Conventions for the Java Programming Language" does not
>>> rise to this level.
>>
>> This analysis sums up the current state of affairs. As long as you are
>> in and do not commit murder, you are free to do whatever you like,
>> regardless of the consequences of your actions. Murder is defined as
>> not adopting or infringing on the Apache Software License.
>
>All I am saying is that adopting a different set of coding conventions
>should not be a "federal" crime.  

I totally agree.

>Jakarta effectively is a federation of states, each with the power to 
>adopt their own conventions.  I do have
>great sympathy for Jon's point that those subprojects that have not taken
>the time or effort to document their standards do a great disservice to
>themselves and us all.

Ditto.

>> Real problems I see is
>>
>> 1) lack of focus,
>> 2) duplication between projects,
>> 3) lack of common procedures for doing things.
>
>Let me start with #2.
>
>Did you realize that the Tomcat project can service HTTP requests?  Gasp!
>Lets get them to rip this code out as Apache has a little known HTTPD
>project which owns this mission.
>
>Not.

I see where you are heading.

>This instance of duplication of effort is well known and essentially
>sanctioned by the board.  Allowing people to fork and pursue their own
>vision is part of the essence what makes open source different then the
>centrally planned economies that one often finds in big corporate software
>development projects.

Well put. 

>Re: focus.  What do ant and httpd have in common?  The purpose of Apache is
>not to build a single product or family of products.  The purpose is to
>propagate an open methodology centered around community base development.
>Quality or integration or unity of purpose are often useful by-products,
>but not the central goal.

Couldn't agree more.

>Re: lack of common procedures.  I will grant you that this is an area that
>we can always improve on.  You have made a number of references to a
>"benevolent dictator" implying that the existence of such would be an
>improvement over the current state of affairs.  If that is the case, then I
>am not that person.  I prefer to educate or cajole or nag over dictating.
>Gump is a prime example.  (Note: in the case of a "federal crime" mentioned
>above, I would not hesitate to initiate action to remove a committer or
>even an entire code base).

Gump is a prime example indeed. Masterfully done.

>As an example related back to this subject line, I would not be in favor of
>a tool which rejects commits that don't conform to a particular style.  I
>also would not be in favor of a tool which post-processes commits to
>retrofit a particular style.  I would be in favor of a tool which reviews
>commits and informs you of issues that it determines.  At the moment, Jon
>serves this purpose.  ;-)
>
>> I will not instigate revolution! I will not instigate revolution!
>
>Be forewarned that the Apache tradition is to allow people with enough
>"fire in their belly" to tackle a particular problem that is important to
>them the freedom to do so.  If the problems you see are something that you
>feel need tackling and the only effective way in which this can be
>accomplished is for you to become the Jakarta PMC chair, then I could
>certainly arrange for an election to take place.  I can't guarantee the
>results of the election or the success of your quest, but I can do my part
>to enable you to pursue your goals.
>
>Think about this for a while, and let me know if this is a path you wish to
>pursue.

I have thought about for about 30 seconds and the answer is no, non, 
nein, nyet. Thanks, but 

Re: Code conventions

[Ted Husted]

Sam Ruby wrote:
> I would be in favor of a tool which reviews
> commits and informs you of issues that it determines.  At the moment, Jon
> serves this purpose.  ;-)

+1 -- Any Jikes developers out there? It would be cool if the compiler
issued the Jon-style warnings!


-- 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: Code conventions

[Danny Angus]

Ceci wrote:

> The inability of the PMC to take initiative stems from the Apache
> voting process



> The current system   is inappropriate for managing large projects
like
> Jakarta.



I agree with this, I've only been a commiter since the end of last summer,
and have been surprised that while the web site says..
"This committee is the official managing body of the Jakarta Project and is
responsible for setting overall project direction."
It does not appear very pro-active in this role.

I've been subscribed to this list out of curiosity about what the PMC do, to
keep a finger on the pulse as it were, and apart from the discussions about
new projects and the current rash of opinion on code standards there seems
to be little traffic discussing "overall project direction"

Perhaps thats because the direction is not changing, are the goals of the
project still the same, are the subprojects all still moving steadily
forward?
They seem to be, and this would be a good reason for not interfering, after
all there are no deadlines except those imposed by individual projects and
few imperatives of the kind which, in the commercial world, need to be
enforced by PM's.

> we either:
>
> 1) Elect a PMC with real power, power to intervene and take painful
> decisions, until the next elections.

In a democracy (and I *know* apache isn't that) we elect from amongst
ourselves representatives whom we charge with making decisions on our
behalf, for that to make any sense we have to give them the authority to
make those decisons and bind ourselves to them, anything else is just
posturing.

>
> 2) Instate a system based on referendum, where the public can directly
> intervene in making laws. By "public", I mean developers with commit
> rights.

Always contentious, referenda are un-democratic in that they imply that the
fundamental assertion of democracy (that we elect people to represent us) is
flawed.

IMHO (as this whole spiel is) referenda would therefore render the PMC
irrelevant.
However consensus decisions are *much* harder to achieve in larger groups,
it would be un-realistic to expect every commiter to spend time giving every
vote serious consideration, and so I favour a PMC where the elected members
have made a commitment to considering the issues.

>
> 3) Keeps things as they are and hope for the best.

Unless the goals of the project have changed, or unless a significant change
is needed to either the goals or the nature of the project the existing
system should continue to work, perhaps Ceci's comments stem from a feeling
that change is needed of the kind only changes in PM can accomodate.

If so what's wrong? and why won't the current system be able to deliver the
changes needed?


d.




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

Re: Code conventions

[Sam Ruby]

For reasons that are unknown to me, none of the e-mail that I have sent
over the last few days has made it out to the mailing lists.  For all I
know, at some point in the distant future, it will all be unleashed and
make little sense out of context.  :-(

Anyway, it looks like e-mail that I send now gets through so let me take
advantage of it while I can...

Ceki Gülcü wrote:
>
>> If some particular codebase under the Jakarta umbrella consistently
>> chose to take actions which were inconsistent with the Apache mission,
>> then I'm confident that the PMC would swiftly act to disolve this code
>> base.  I am not aware of this being done before, so it would be
>> uncharted territory, but I'm sure we would find a way.  And that way
>> would not require 100% consensus.
>>
>> In my mind, the willful insertion of newlines in direct contradiction
>> to the "Code Conventions for the Java Programming Language" does not
>> rise to this level.
>
> This analysis sums up the current state of affairs. As long as you are
> in and do not commit murder, you are free to do whatever you like,
> regardless of the consequences of your actions. Murder is defined as
> not adopting or infringing on the Apache Software License.

All I am saying is that adopting a different set of coding conventions
should not be a "federal" crime.  Jakarta effectively is a federation of
states, each with the power to adopt their own conventions.  I do have
great sympathy for Jon's point that those subprojects that have not taken
the time or effort to document their standards do a great disservice to
themselves and us all.

> Real problems I see is
>
> 1) lack of focus,
> 2) duplication between projects,
> 3) lack of common procedures for doing things.

Let me start with #2.

Did you realize that the Tomcat project can service HTTP requests?  Gasp!
Lets get them to rip this code out as Apache has a little known HTTPD
project which owns this mission.

Not.

This instance of duplication of effort is well known and essentially
sanctioned by the board.  Allowing people to fork and pursue their own
vision is part of the essence what makes open source different then the
centrally planned economies that one often finds in big corporate software
development projects.

Re: focus.  What do ant and httpd have in common?  The purpose of Apache is
not to build a single product or family of products.  The purpose is to
propagate an open methodology centered around community base development.
Quality or integration or unity of purpose are often useful by-products,
but not the central goal.

Re: lack of common procedures.  I will grant you that this is an area that
we can always improve on.  You have made a number of references to a
"benevolent dictator" implying that the existence of such would be an
improvement over the current state of affairs.  If that is the case, then I
am not that person.  I prefer to educate or cajole or nag over dictating.
Gump is a prime example.  (Note: in the case of a "federal crime" mentioned
above, I would not hesitate to initiate action to remove a committer or
even an entire code base).

As an example related back to this subject line, I would not be in favor of
a tool which rejects commits that don't conform to a particular style.  I
also would not be in favor of a tool which post-processes commits to
retrofit a particular style.  I would be in favor of a tool which reviews
commits and informs you of issues that it determines.  At the moment, Jon
serves this purpose.  ;-)

> I will not instigate revolution! I will not instigate revolution!

Be forewarned that the Apache tradition is to allow people with enough
"fire in their belly" to tackle a particular problem that is important to
them the freedom to do so.  If the problems you see are something that you
feel need tackling and the only effective way in which this can be
accomplished is for you to become the Jakarta PMC chair, then I could
certainly arrange for an election to take place.  I can't guarantee the
results of the election or the success of your quest, but I can do my part
to enable you to pursue your goals.

Think about this for a while, and let me know if this is a path you wish to
pursue.

- Sam Ruby


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Code conventions

[Danny Angus]

> Aside : does Sun use deviation from coding standards as an actionable HR
> issue?  ;)
>
> "On your resume, I see that you were terminated for cause at Sun?"
>
> "Yes, I created too many classes with the opening brace on a separate
> line..."

I don't know about sun, but we would certainly warn employees about repeated
infringements, and that *is* the start of a process which can end in
dismissal for persistently deviating from code standards.

I expect the same process here could lead to a commiter being
disenfranchised (what is the correct verb?) if their deviation was
sufficiently persistent, what you have to hope is that we have enough
intelligence to respond to the first warning.

d.


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

Re: Code conventions

[Ceki Gülcü]

At 00:57 05.01.2002 +1100, you wrote:
>On Fri, 4 Jan 2002 23:23, Ceki Gülcü wrote:
>> The threat is to Jakarta's *nature* and it comes from our indecisiveness.
>>
>> Real problems I see is
>>
>> 1) lack of focus,
>
>Dont see this as a problem. Each project is usually focused on its dowmain 
>and the overall project has a sort of scope. Personally I would have no 
>problem widening scope of jakarta to include virtually any java project, 
>serverside, clientside, frameworks, products, etc but not everyone thinks 
>this is a great idea ;)

No, some people would not like to see Jakarta widen its scope and 
they would -1 any steps in that direction.  However, it is certainly 
possible that a majority of Jakarta committers would be amenable to 
the idea.  

In the system I am suggesting, you would propose the idea, have four 
other committers support it, and then launch a vote on the subject. If it
were adopted then the scope of Jakarta would be widened and nobody would
be able to do anything about it, not me, not Ted, not even Jon.

Widening the scope of Jakarta is not necessarily a bad idea. Your ideas are 
not all bad. (Don't get me wrong, there are not always good either.)

>> 2) duplication between projects,
>
>diversity aids evolution though preferably it would be intra rather than 
>inter project duplicity. However the PMC has historically not seen that as 
>desirable due to advertising. 

duplicity - noun, plural duplicities

1. a. Deliberate deceptiveness in behavior or speech. b. An instance
of deliberate deceptiveness; double-dealing.

2. The quality or state of being twofold or double.

I have read and reread your comment. It just does not make any sense. 

>> 3) lack of common procedures for doing things.
>
>This is the one possible issue I see. However I only see it as a problem for 
>the "external" interface between projects. Mainly this involves things like 
>release naming cconventions, targets in ant files, location of intermediate 
>and destination files in a build. 
>
>It really is irrelevent to outsiders what indent style is used, whether 
>anakia or stylebook is used yadda yadda.
>
>So I +1 on suggesting standards for external parts of project, -1 for forcing 
>it

Indeed, that seems to be the consensus.


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



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

Re: Code conventions

[Ceki Gülcü]

At 00:55 05.01.2002 +1100, you wrote:
>On Fri, 4 Jan 2002 22:04, Ceki Gülcü wrote:
>> 1) Elect a PMC with real power, power to intervene and take painful
>> decisions, until the next elections.
>
>-1 power would be abused and misused. If power is what you want you are not 
>going to get it by donning a skippy badge but earning it through respect. 

Power can and is abused. Knives can and do cut through flesh. Knives can 
also be used to cut bread. I have no problem delegating legislative power 
to the members of parliament as long as its members were elected for a 
limited length term in fair and square elections.

>> 2) Instate a system based on referendum, where the public can directly
>> intervene in making laws. By "public", I mean developers with commit
>> rights.
>
>yay - popularity contests! That would be sooo much fun.

Who is talking about popularity contest? What popularity contest?

>> To avoid keeping voting on the same issue time and again, a wait
>> period of 12 months is necessary between two referenda on the same
>> or nearly the same issue.
>
>And maybe we should elect a committee to determine whether issues are too 
>similar and they can break apart into sub-committees to determine the 
>viability of holding a referendum to determine if two issues are dissimilar 
>enough that another referendum could be held for the issue.

Laugh all you want. Referenda are great. Ask any Swiss citizen. 

>> 3) Keeps things as they are and hope for the best.

>things as they are are for the best. People do things because they see that 
>it is the "right" thing to do for them - which usually means it is 
>technically the right thing. Sometimes it takes time (it took me 1.5 years to 
>convince one apache person of something) but most things work out better in 
>the end. 
>
>At times it is infuriating when someone else is doing something stupid but 
>forcing them to change is not the answer - for one you may be wrong, if not 
>you are probably going to cause resentment - not something healthy for the 
>community.

I really don't like paying taxes but I do. I would be great to live in 
the Bahamas, drink cocktails and fornicate day in day out.


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



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

Re: Code conventions

[Ceki Gülcü]

At 08:01 04.01.2002 -0500, Geir Magnusson Jr. wrote:
>> The debate about code conventions is just an excuse to ask the
>> following question, and it is a question:
>> 
>> Do we want to instate rules for the good of the larger community?
>> 
>
>I think yes, but the prepositional phrase "for the good of the larger
>community" is going to be the trouble spot...  Historically always has :)
>
>> We keep saying that Jakarta is not SourceForge. How can this be if
>> each project can act totally independently?
>
>Because they really can't act *totally* independently, additional projects
>can't be formed (and abandoned) ad hoc by 'outsiders', there is indeed peer
>pressure (as well mechanical things like Gump) that enforce some
>consistency, and lots of cross pollenation.  I mean, Jon is everywhere ;)
>
>>From my personal experience, I do think of it as one big community but
>different 'departments'.  I talk to people from many of the subprojects when
>I need something or have a question, and I certainly feel welcome and like
>it's one big group.

That's a good description.

>Another thought I have on this is that we are sort of like sourdough bread
>made with a starter :)  We add new projects, but it's (usually) initiated,
>championed and/or participated in by someone steeped in the Apache/Jakarta
>'gestalt', so the traditions and practices continue.

The reasons for which projects get accepted or rejected is an important 
subject in itself.

>> Remember the scene where Lisa, from the Simpons, is thrown out of
>> music class even of she plays her sax beautifully. We all emphasize
>> with Lisa's view. However, what would you do if you were in the
>> teacher's shoes?
>
>(I thought you were going to the scene : "Lisa, get away from that Jazz
>man!" )

Oh, yes, then she (Maggie) turns to the to the Jazz man and says: 

"Nothing personal, I just fear the unfamiliar."

How true, how succinct.

>Well, that's the difference between the teacher having to do something about
>it, and Principal Skinner listening in over the intercom and getting Lisa to
>leave  Within the community, the community is the teacher, and can
>legislate itself (modulo Principal Skinner, of course...)

Amusingly enough that episode starts with Bart writing on the chalkboard:

I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!
I will not instigate revolution! I will not instigate revolution!

Regards, Bart.


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Ted Husted]

Peter Donald wrote:
> Thats nice for some codebases but not appropriate for all. For instance the
> Ant codebase has got to have at least 10-15 different styles (probably way
> way way more) because 70% of code is not written by the committers but by
> members of community who have their own particular tastes. It is is largely
> up to the committers to decide whether to restyle the files and that really
> has not greatly impacted the quality of ant. However other codebases have
> much more rigourous conventions that are followed precisely. Its up to the
> developers what they want to do.

Agreed. 

I'm simply saying that, moving forward, the Ant PMC member should
encourage the subproject to stick to the default convention, or declare
one of their own. If we had been more careful about this sooner, then
perhaps the Ant codebase would not be host to so many diverse styles.

I agree that any change has to be made by a Committer to the subproject,
but reserve our right to nag. If the Committers want to ignore us they
can, but that doesn't mean we should go quietly into the night. 

I personally believe these things don't happen because people are
bloody-minded, they happen because people are unaware, and we haven't
been watching each other's back.

In the meantime, I do suggest we go with rule #1 - Adhere to the style
of the original.

-- 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: Code conventions

[Peter Donald]

On Fri, 4 Jan 2002 23:23, Ceki Gülcü wrote:
> The threat is to Jakarta's *nature* and it comes from our indecisiveness.
>
> Real problems I see is
>
> 1) lack of focus,

Dont see this as a problem. Each project is usually focused on its dowmain 
and the overall project has a sort of scope. Personally I would have no 
problem widening scope of jakarta to include virtually any java project, 
serverside, clientside, frameworks, products, etc but not everyone thinks 
this is a great idea ;)

> 2) duplication between projects,

diversity aids evolution though preferably it would be intra rather than 
inter project duplicity. However the PMC has historically not seen that as 
desirable due to advertising. 

> 3) lack of common procedures for doing things.

This is the one possible issue I see. However I only see it as a problem for 
the "external" interface between projects. Mainly this involves things like 
release naming cconventions, targets in ant files, location of intermediate 
and destination files in a build. 

It really is irrelevent to outsiders what indent style is used, whether 
anakia or stylebook is used yadda yadda.

So I +1 on suggesting standards for external parts of project, -1 for forcing 
it


-- 
Cheers,

Pete

--
I just hate 'yes' men, don't you Smithers?
--

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

Re: Code conventions

[Peter Donald]

On Fri, 4 Jan 2002 22:04, Ceki Gülcü wrote:
> 1) Elect a PMC with real power, power to intervene and take painful
> decisions, until the next elections.

-1 power would be abused and misused. If power is what you want you are not 
going to get it by donning a skippy badge but earning it through respect. 

> 2) Instate a system based on referendum, where the public can directly
> intervene in making laws. By "public", I mean developers with commit
> rights.

yay - popularity contests! That would be sooo much fun.

> To avoid keeping voting on the same issue time and again, a wait
> period of 12 months is necessary between two referenda on the same
> or nearly the same issue.

And maybe we should elect a committee to determine whether issues are too 
similar and they can break apart into sub-committees to determine the 
viability of holding a referendum to determine if two issues are dissimilar 
enough that another referendum could be held for the issue.

> 3) Keeps things as they are and hope for the best.

things as they are are for the best. People do things because they see that 
it is the "right" thing to do for them - which usually means it is 
technically the right thing. Sometimes it takes time (it took me 1.5 years to 
convince one apache person of something) but most things work out better in 
the end. 

At times it is infuriating when someone else is doing something stupid but 
forcing them to change is not the answer - for one you may be wrong, if not 
you are probably going to cause resentment - not something healthy for the 
community.

-- 
Cheers,

Pete

-
First, we shape our tools, thereafter, they shape us.
-

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

Re: Code conventions

[Peter Donald]

On Fri, 4 Jan 2002 23:07, Ted Husted wrote:
> "Geir Magnusson Jr." wrote:
> > For those of us (like me) that dont get it, can we do a quick review why
> > deviation from the One True But Sometimes Really Ugly Coding Standard as
> > defined by Sun Microsystems is such a threat to the ongoing health of
> > Jakarta?  And if the above isn't really the problem, but just an example,
> > can we talk a bit about what the problems are?
>
> I believe it is reasonable to expect that a given codebase will follow a
> common convention. This is especially important in a ASF product, since
> we expect that the product will maintained over a long period of time by
> many different individuals.
>
> I fully support the idea that each codebase is entitled to its own
> conventions. I also fully support the idea that having defined
> conventions, we should follow them.
>
> I think the status quo is just fine, but we do have to remember to watch
> each other's backs, and remind people to use the conventions expected
> within each codebase.

Thats nice for some codebases but not appropriate for all. For instance the 
Ant codebase has got to have at least 10-15 different styles (probably way 
way way more) because 70% of code is not written by the committers but by 
members of community who have their own particular tastes. It is is largely 
up to the committers to decide whether to restyle the files and that really 
has not greatly impacted the quality of ant. However other codebases have 
much more rigourous conventions that are followed precisely. Its up to the 
developers what they want to do.

-- 
Cheers,

Pete

---
"It is easy to dodge our responsibilities, but we 
cannot dodge the consequences of dodging our 
responsibilities." -Josiah Stamp 
---

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

Re: Code conventions

[Geir Magnusson Jr.]

On 1/4/02 7:56 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> At 06:57 04.01.2002 -0500, you wrote:
>> On 1/4/02 6:43 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:
>> 
>>> 
>>> 
>>> On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
>>> 
>>>> If some particular codebase under the Jakarta umbrella consistently
>>>> chose to take actions which were inconsistent with the Apache mission,
>>>> then I'm confident that the PMC would swiftly act to disolve this code
>>>> base.  I am not aware of this being done before, so it would be
>>>> uncharted territory, but I'm sure we would find a way.  And that way
>>>> would not require 100% consensus.
>>>> 
>>>> In my mind, the willful insertion of newlines in direct contradiction
>>>> to the "Code Conventions for the Java Programming Language" does not
>>>> rise to this level.
>>> 
>>> This analysis sums up the current state of affairs. As long as you are
>>> in and do not commit murder, you are free to do whatever you like,
>>> regardless of the consequences of your actions. Murder is defined as
>>> not adopting or infringing on the Apache Software License.
>>> 
>>> Is this how we want Jakarta to be? If not, what can be done?
>>> 
>> 
>> I don't see what the negative consequences for community are when I do
>> something like
>> 
>> if ( condition )
>> { 
>>statement;
>> }
>> 
>> versus
>> 
>> if ( condition ) {
>>statement;
>> }
>> 
>> or
>> 
>>  if ( condition )
>>  statement;
>> 
>> Other than I made my code is more readable :)
>>  
>> My question is what are the consequences to forcing me to do #2 when #1 is
>> perfectly acceptable throughout the professional world?  We are going to
>> look like a bunch of PHB's if we do this.  Someone's is then going to write
>> the utility JU (Jakarta Uglifier).
>> 
>> I realize that some of this is simply a matter of taste, and people don't
>> think that #1 above is more readable than #2. I'm just trying to figure out
>> why this personal style decision in what is in many ways an artistic
>> endevour constitutes a risk to the community.  Note that I don't advocate a
>> coding free for all - I also understand that with multiple developers, some
>> 'workmanlike' ('workpersonlike'?) standards are important.
> 
> 
> All excellent points. I don't have any good answers, just more
> questions.
> 
> Yes, by imposing strict code conventions there is a real danger of
> acting like a PHB.  Yes, code conventions infringe on artistic freedom
> and might even curtail creativity.
> 
> The debate about code conventions is just an excuse to ask the
> following question, and it is a question:
> 
> Do we want to instate rules for the good of the larger community?
> 

I think yes, but the prepositional phrase "for the good of the larger
community" is going to be the trouble spot...  Historically always has :)

> We keep saying that Jakarta is not SourceForge. How can this be if
> each project can act totally independently?

Because they really can't act *totally* independently, additional projects
can't be formed (and abandoned) ad hoc by 'outsiders', there is indeed peer
pressure (as well mechanical things like Gump) that enforce some
consistency, and lots of cross pollenation.  I mean, Jon is everywhere ;)

>From my personal experience, I do think of it as one big community but
different 'departments'.  I talk to people from many of the subprojects when
I need something or have a question, and I certainly feel welcome and like
it's one big group.

Another thought I have on this is that we are sort of like sourdough bread
made with a starter :)  We add new projects, but it's (usually) initiated,
championed and/or participated in by someone steeped in the Apache/Jakarta
'gestalt', so the traditions and practices continue.

 
>> Aside : does Sun use deviation from coding standards as an actionable HR
>> issue?  ;)
>> 
>> "On your resume, I see that you were terminated for cause at Sun?"
>> 
>> "Yes, I created too many classes with the opening brace on a separate
>> line..."
> 
> Remember the scene where Lisa, from the Simpons, is thrown out of
> music class even of she plays her sax beautifully. We all emphasize
> with Lisa's view. However, what would you do if you were in the
> teacher's shoes?

Re: Code conventions

[Ted Husted]

Ceki Gülcü wrote:
> We keep saying that Jakarta is not SourceForge. How can this be if
> each project can act totally independently?

I think the ASF page says it best:

"The Apache projects are characterized by a collaborative, consensus
based development process, an open and pragmatic software license, and a
desire to create high quality software that leads the way in its field.
We consider ourselves not simply a group of projects sharing a server,
but rather a community of developers and users."

In the US, we have a national community, state communities, and then
county, city, town and village communites. 

For most matters, each sub-community can create many rules of their own.
In one state you can turn right on red, in another you can't. This
doesn't mean that both states are not part of the same national
community. 

The Jakarta subprojects are the same way. Right now, we have give the
subprojects permission to declare their own conventions, or use the
project defaults. I think that's fine, we just have to remind the
subprojects to use their own conventions. 

But if a subproject said, "We're going to scuttle the Apache Software
License, let one Committer make all the decisions, and disband everyone
else's veto power", they would quickly find their access to the CVS cut
off. 

It's a matter of scope and tolerances. I think selecting a coding
convention is within the scope of the subprojects, so long as they
select one and stick to it. 

-- 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: Code conventions

[Ceki Gülcü]

At 06:57 04.01.2002 -0500, you wrote:
>On 1/4/02 6:43 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:
>
>> 
>> 
>> On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
>> 
>>> If some particular codebase under the Jakarta umbrella consistently
>>> chose to take actions which were inconsistent with the Apache mission,
>>> then I'm confident that the PMC would swiftly act to disolve this code
>>> base.  I am not aware of this being done before, so it would be
>>> uncharted territory, but I'm sure we would find a way.  And that way
>>> would not require 100% consensus.
>>> 
>>> In my mind, the willful insertion of newlines in direct contradiction
>>> to the "Code Conventions for the Java Programming Language" does not
>>> rise to this level.
>> 
>> This analysis sums up the current state of affairs. As long as you are
>> in and do not commit murder, you are free to do whatever you like,
>> regardless of the consequences of your actions. Murder is defined as
>> not adopting or infringing on the Apache Software License.
>> 
>> Is this how we want Jakarta to be? If not, what can be done?
>> 
>
>I don't see what the negative consequences for community are when I do
>something like
>
> if ( condition )
> { 
>statement;
> }
>
>versus
>
> if ( condition ) {
>statement;
> }
>
>or
>
>  if ( condition )
>  statement;
>
>Other than I made my code is more readable :)
>  
>My question is what are the consequences to forcing me to do #2 when #1 is
>perfectly acceptable throughout the professional world?  We are going to
>look like a bunch of PHB's if we do this.  Someone's is then going to write
>the utility JU (Jakarta Uglifier).
>
>I realize that some of this is simply a matter of taste, and people don't
>think that #1 above is more readable than #2. I'm just trying to figure out
>why this personal style decision in what is in many ways an artistic
>endevour constitutes a risk to the community.  Note that I don't advocate a
>coding free for all - I also understand that with multiple developers, some
>'workmanlike' ('workpersonlike'?) standards are important.


All excellent points. I don't have any good answers, just more
questions.

Yes, by imposing strict code conventions there is a real danger of
acting like a PHB.  Yes, code conventions infringe on artistic freedom
and might even curtail creativity.

The debate about code conventions is just an excuse to ask the
following question, and it is a question:

  Do we want to instate rules for the good of the larger community?

We keep saying that Jakarta is not SourceForge. How can this be if
each project can act totally independently? 

>Aside : does Sun use deviation from coding standards as an actionable HR
>issue?  ;)
>
>"On your resume, I see that you were terminated for cause at Sun?"
>
>"Yes, I created too many classes with the opening brace on a separate
>line..."

Remember the scene where Lisa, from the Simpons, is thrown out of
music class even of she plays her sax beautifully. We all emphasize
with Lisa's view. However, what would you do if you were in the
teacher's shoes?

Questions, questions...


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Geir Magnusson Jr.]

On 1/4/02 7:23 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> At 06:46 04.01.2002 -0500, you wrote:
>> On 1/4/02 6:04 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:
>> 
>> 
>>> 
>>> Jakarta does not have a benevolent dictator where the puck stops.
>>> Recognizing this fact, we either:
>>> 
>> 
>> [SNIP]
>> 
>>> 
>>> 3) Keeps things as they are and hope for the best.
>>> 
>> 
>> For those of us (like me) that don¹t get it, can we do a quick review why
>> deviation from the One True But Sometimes Really Ugly Coding Standard as
>> defined by Sun Microsystems is such a threat to the ongoing health of
>> Jakarta?  And if the above isn't really the problem, but just an example,
>> can we talk a bit about what the problems are?
> 
> Deviation from the "One True But Sometimes Really Ugly Coding
> Standard" as defined by Sun Microsystems is *not* a threat to the
> ongoing health of Jakarta.  It is just an example, albeit a symbolic
> one.
> 

Whew ;)

> The threat is to Jakarta's *nature* and it comes from our indecisiveness.
> 
> Real problems I see is
> 
> 1) lack of focus,

I too worry about this.  A lot.  I don't know what to do about it yet.

> 2) duplication between projects,

Too many damn loggers - thank goodness sun is providing us with on via
JSR-47.  I am sure that the Code Conventions will be followed to the letter
too.

(You know I'm kidding - I'm a huge log4j fan, but that one was *just* too
easy...)

Seriously, I don't know if that is a problem, as I think it drives
development.

We have two web frameworks, Turbine and Struts, and they are different in
current implementation, and as far as I understand it, different in
evolutionary roadmap.  I think this is good and healthy.

We have regexp and ORO.  I always use ORO for the Perl stuff.  No other
comments.

We have repetition in commons/commons-sandbox, which I think is great.

Those are the top level ones.  It's clear that there is repetition within
projects (the database connection pools being my canonical example) but that
too seems to be evidence of exploring the solution space rather than pure
wheel re-invention (although there is some of that...)

I think (and only 'I thin') the only thing we can do about this, as you
can't mandate what project communities decide to work on, is to ensure that
the top level projects remain clear in scope, and encourage cross-project
cooperation and sharing, which I think the Commons was intended in part to
do.  

> 3) lack of common procedures for doing things.
> 

Mixed feelings, as this tends to be personal taste, and leads to operational
totalitarianism which I think stifles innovation.  There is something to be
said for common build procedures, but with ant and a little documentation,
it generally isn't a big deal I've found.

> Are these perceived as problems by others or is it just my
> imagination?
> 
> 
> --
> Ceki Gülcü - http://qos.ch
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Ceki Gülcü]

At 06:46 04.01.2002 -0500, you wrote:
>On 1/4/02 6:04 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:
>
>
>> 
>> Jakarta does not have a benevolent dictator where the puck stops.
>> Recognizing this fact, we either:
>> 
>
>[SNIP]
>
>> 
>> 3) Keeps things as they are and hope for the best.
>> 
>
>For those of us (like me) that don¹t get it, can we do a quick review why
>deviation from the One True But Sometimes Really Ugly Coding Standard as
>defined by Sun Microsystems is such a threat to the ongoing health of
>Jakarta?  And if the above isn't really the problem, but just an example,
>can we talk a bit about what the problems are?

Deviation from the "One True But Sometimes Really Ugly Coding
Standard" as defined by Sun Microsystems is *not* a threat to the
ongoing health of Jakarta.  It is just an example, albeit a symbolic
one.

The threat is to Jakarta's *nature* and it comes from our indecisiveness. 

Real problems I see is 

1) lack of focus,
2) duplication between projects,
3) lack of common procedures for doing things.

Are these perceived as problems by others or is it just my
imagination?


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



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

Re: Code conventions

[Geir Magnusson Jr.]

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

> "Geir Magnusson Jr." wrote:
>> For those of us (like me) that don¹t get it, can we do a quick review why
>> deviation from the One True But Sometimes Really Ugly Coding Standard as
>> defined by Sun Microsystems is such a threat to the ongoing health of
>> Jakarta?  And if the above isn't really the problem, but just an example,
>> can we talk a bit about what the problems are?
> 
> I believe it is reasonable to expect that a given codebase will follow a
> common convention. This is especially important in a ASF product, since
> we expect that the product will maintained over a long period of time by
> many different individuals.
> 
> I fully support the idea that each codebase is entitled to its own
> conventions. I also fully support the idea that having defined
> conventions, we should follow them.
> 
> I think the status quo is just fine, but we do have to remember to watch
> each other's backs, and remind people to use the conventions expected
> within each codebase.


Agreed - and that seems to me to be another way of saying that each Jakarta
subproject is a community into itself, with conventions and practices
determined by that community (modulo the basic procedural and licensing
practices of the ASF).

When you remind me about conventions in my codebase, you are in essence
becoming a part of my community. (Which is cool...)


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


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

Re: Code conventions

[Ted Husted]

"Geir Magnusson Jr." wrote:
> For those of us (like me) that don¹t get it, can we do a quick review why
> deviation from the One True But Sometimes Really Ugly Coding Standard as
> defined by Sun Microsystems is such a threat to the ongoing health of
> Jakarta?  And if the above isn't really the problem, but just an example,
> can we talk a bit about what the problems are?

I believe it is reasonable to expect that a given codebase will follow a
common convention. This is especially important in a ASF product, since
we expect that the product will maintained over a long period of time by
many different individuals. 

I fully support the idea that each codebase is entitled to its own
conventions. I also fully support the idea that having defined
conventions, we should follow them. 

I think the status quo is just fine, but we do have to remember to watch
each other's backs, and remind people to use the conventions expected
within each codebase.

-- 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: Code conventions

[Geir Magnusson Jr.]

On 1/4/02 6:43 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> 
> 
> On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
> 
>> If some particular codebase under the Jakarta umbrella consistently
>> chose to take actions which were inconsistent with the Apache mission,
>> then I'm confident that the PMC would swiftly act to disolve this code
>> base.  I am not aware of this being done before, so it would be
>> uncharted territory, but I'm sure we would find a way.  And that way
>> would not require 100% consensus.
>> 
>> In my mind, the willful insertion of newlines in direct contradiction
>> to the "Code Conventions for the Java Programming Language" does not
>> rise to this level.
> 
> This analysis sums up the current state of affairs. As long as you are
> in and do not commit murder, you are free to do whatever you like,
> regardless of the consequences of your actions. Murder is defined as
> not adopting or infringing on the Apache Software License.
> 
> Is this how we want Jakarta to be? If not, what can be done?
> 

I don't see what the negative consequences for community are when I do
something like

 if ( condition )
 { 
statement;
 }

versus

 if ( condition ) {
statement;
 }

or

  if ( condition )
  statement;

Other than I made my code is more readable :)
  
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world?  We are going to
look like a bunch of PHB's if we do this.  Someone's is then going to write
the utility JU (Jakarta Uglifier).

I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community.  Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.

Aside : does Sun use deviation from coding standards as an actionable HR
issue?  ;)

"On your resume, I see that you were terminated for cause at Sun?"

"Yes, I created too many classes with the opening brace on a separate
line..."


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Geir Magnusson Jr.]

On 1/4/02 6:04 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:


> 
> Jakarta does not have a benevolent dictator where the puck stops.
> Recognizing this fact, we either:
> 

[SNIP]

> 
> 3) Keeps things as they are and hope for the best.
> 

For those of us (like me) that don¹t get it, can we do a quick review why
deviation from the One True But Sometimes Really Ugly Coding Standard as
defined by Sun Microsystems is such a threat to the ongoing health of
Jakarta?  And if the above isn't really the problem, but just an example,
can we talk a bit about what the problems are?


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


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

Re: Code conventions

[Ceki Gülcü]

On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote: 

> If some particular codebase under the Jakarta umbrella consistently
> chose to take actions which were inconsistent with the Apache mission,
> then I'm confident that the PMC would swiftly act to disolve this code
> base.  I am not aware of this being done before, so it would be
> uncharted territory, but I'm sure we would find a way.  And that way
> would not require 100% consensus.
> 
> In my mind, the willful insertion of newlines in direct contradiction
> to the "Code Conventions for the Java Programming Language" does not
> rise to this level.

This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.

Is this how we want Jakarta to be? If not, what can be done?


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Ceki Gülcü]

On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
> Let's all take a moment to review:
>
>   http://www.godwinslaw.com/

Amusing but not very pertinent to the discussion.  No one exchanged
accusations of Nazism. Although I recognize that your goal was
probably to diffuse the tension.

As things stand today, the Jakarta project is a loose assembly of
subprojects united by a common license, a common web site and a common PMC. 

Here is what http://jakarta.apache.org/site/roles.html has to say on
the Project Management Committee (PMC):

   This committee is the official managing body of the Jakarta Project
   and is responsible for setting overall project direction.

The PMC currently follows a non-interventionist policy. Its actions in
the past year have been limited to accepting or rejecting new
subprojects which is inadequate for setting the overall project
direction, the stated goal of the PMC.

The inability of the PMC to take initiative stems from the Apache
voting process where every member has a veto power. This limits the
decision power of the PMC to consensual decisions only.

The Jakarta PMC is averse of discussing things in private in fear that
its legitimacy might be challenged.  IMHO, if the legitimacy of the
PMC is challenged, let the challenger wait and suffer until the next
PMC elections. I believe the next elections are scheduled for February
or March 2002.

The current system of veto based voting might be appropriate for
development but is inappropriate for managing large projects like
Jakarta. Either we admit it and act now or watch Jakarta become
SourceForge-elite, an assembly of excellent projects but with no
common purpose.

Jakarta does not have a benevolent dictator where the puck stops.
Recognizing this fact, we either:

1) Elect a PMC with real power, power to intervene and take painful
decisions, until the next elections.

2) Instate a system based on referendum, where the public can directly
intervene in making laws. By "public", I mean developers with commit
rights.

To avoid voting on trivialities, a referendum would require the support of
at least five committers to acquire the "valid" status. After a
possible but short delay, a valid referendum is submitted to popular
vote. The result of the vote determines whether the referendum is
accepted or rejected. An accepted referendum becomes law of the land.

To avoid keeping voting on the same issue time and again, a wait
period of 12 months is necessary between two referenda on the same
or nearly the same issue.

3) Keeps things as they are and hope for the best.

Regards, Ceki


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



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

Re: Code conventions

[Peter Donald]

On Thu, 3 Jan 2002 00:34, Conor MacNeill wrote:
> Ted Husted wrote:
> > Peter, I hope you and yours are well. The Australian "Black Christmas"
> > is all over the morning news here.
>
> The smoke is pretty thick here right now even in the city suburbs.
> Having all your windows shut up when the outside temperature is in the
> mid thirties isn't fun. Of course, we are better off than those who live
> on the edge of the bush.

yer - I have seen the burns and some of the projected burns and it 
would be horrible to live in any of those areas.

> Anyway, Ted, I'm sure Peter isn't too concerned, he is about 800 km
> away, in Melbourne. We do like their helicopter though.

Actually I was in the heart of sydney (darling harbour/belmain/parramatta) 
until just before new year ;) Had to return to melb though as asthma was 
playing up due to the smoke. 

The scary part is some of my companies software is being used to manage the 
resource deployment up there ... crossing fingers that nothing breaks ;)

-- 
Cheers,

Pete


The two secrets to success:
   1- Don't tell anyone everything.



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

Re: Code conventions

[Peter Donald]

On Thu, 3 Jan 2002 00:24, Sam Ruby wrote:
> Let's all take a moment to review:
>
>http://www.godwinslaw.com/
>
> If some particular codebase under the Jakarta umbrella consistently chose
> to take actions which were inconsistent with the Apache mission, then I'm
> confident that the PMC would swiftly act to disolve this code base.  I am
> not aware of this being done before, so it would be uncharted territory,
> but I'm sure we would find a way.  And that way would not require 100%
> consensus.
>
> In my mind, the willful insertion of newlines in direct contradiction to
> the "Code Conventions for the Java Programming Language" does not rise to
> this level.

Got to love that site !

-- 
Cheers,

Pete

---
|  If you turn on the light quickly enough,   |
|you can see what the dark looks like.|
---


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Ted Husted]

Sam Ruby wrote:
> If some particular codebase under the Jakarta umbrella consistently chose
> to take actions which were inconsistent with the Apache mission, then I'm
> confident that the PMC would swiftly act to disolve this code base.  I am
> not aware of this being done before, so it would be uncharted territory,
> but I'm sure we would find a way.  And that way would not require 100%
> consensus.
> 
> In my mind, the willful insertion of newlines in direct contradiction to
> the "Code Conventions for the Java Programming Language" does not rise to
> this level.
> 
> - Sam Ruby


Agreed. Though, at the same time, we should not abdicate our
responsibilities as to the general direction of the codebases. 

As it stands the PMC members have agreed to monitor one or more
products. Perhaps we might suggest that this monitoring should include
keeping an eye on the CVS commits and issuing gentle reminders regarding
the product's coding conventions, following Jon's most excellent
example.

Of course, it remains up to the committers to a product to correct any
deviation (or let it stand), and any other member of the community could
also issue the type of gentle reminder. But the PMC member monitoring
the product may wish to set an example.

Ceki, and Peter in another thread, do have a point, and the code in some
of the commits has been growing lax as to following the conventions.
But, as Jon has shown us, often a word to wise is sufficient.

-- 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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Sam Ruby]

Let's all take a moment to review:

   http://www.godwinslaw.com/

If some particular codebase under the Jakarta umbrella consistently chose
to take actions which were inconsistent with the Apache mission, then I'm
confident that the PMC would swiftly act to disolve this code base.  I am
not aware of this being done before, so it would be uncharted territory,
but I'm sure we would find a way.  And that way would not require 100%
consensus.

In my mind, the willful insertion of newlines in direct contradiction to
the "Code Conventions for the Java Programming Language" does not rise to
this level.

- Sam Ruby


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Conor MacNeill]

Ted Husted wrote:
 >

> Peter, I hope you and yours are well. The Australian "Black Christmas"
> is all over the morning news here. 
> 


The smoke is pretty thick here right now even in the city suburbs. 
Having all your windows shut up when the outside temperature is in the 
mid thirties isn't fun. Of course, we are better off than those who live 
on the edge of the bush.

Anyway, Ted, I'm sure Peter isn't too concerned, he is about 800 km 
away, in Melbourne. We do like their helicopter though.

Conor :-)




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

Re: Code conventions

[Ted Husted]

Guys, 

Let's just clarify that any proposals, even proposals to make proposals,
should go to General. The private PMC business should be reserved for
extremely sensitive matters, usually involving site security. 

If we mis-post something to a private list, we should give the original
poster a clear opportunity to move the thread to the public list, and
continue the discussion there, or let the matter drop.

Peter, I hope you and yours are well. The Australian "Black Christmas"
is all over the morning news here. 

-- 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: Code conventions

[Ceki Gulcu]

At 19:23 02.01.2002 +1100, you wrote:
>On Wed, 2 Jan 2002 08:58, Ceki Gulcu wrote:
>> At 07:39 02.01.2002 +1100, Peter Donald wrote:
>> >Hi,
>> >
>> >This is not something that should have been brought up on the PMC list -
>> > it should be discussed on general.
>>
>> Peter I do not need your permission to bring up a subject on the PMC
>> list.
>
>Its not the purpose of the PMC list. If someone asks how to configure tomcat 
>on the general mailing list they would get a similar redirect.
>
>> It was uncourteous of you to forward my message to the general
>> list without permission.
>
>It was uncourteous of you to misuse the PMC mailing list - you should no 
>better than to do that.

Let us not confuse courtesy and your intolerance, shall we?

>> If you had read my proposal carefully you
>> would have seen that my proposal was to reach agreement on the PMC
>> list first and than consult with the wider jakarta community.
>
>You got it all backwards. Consult with the committers. The PMC is irrelevent 
>for this type of discussion - the developers are the ones to decide and PMC 
>only steps in when there is legal or similar issues arise.
>
>> Again, my proposal required al least two thirds majority of jakarta
>> committers in order for the conventions to be adopted. 
>
>Your right - it should be obvious that the preferences of that one third are 
>not important.

While you are at it, call me dictator, call me tyrant. Your remark reminds me 
of the following paragraph from the Green Book.

  Political struggle that results in the victory of a candidate with
  51 per cent of the votes leads to a dictatorial governing body
  disguised as a false democracy, since 49 per cent of the electorate is
  ruled by an instrument of governing they did not vote for, but had
  imposed upon them. This is dictatorship. 

  -- The Green Book, Muammar Al Qathafi 

For full text and the final solution to the problems of any community,
refer to http://www.geocities.com/Athens/8744/readgb.htm

The Green Book can be summarized as,

  War is peace. Freedom is slavery. Ignorance is strength.

  -- 1984, George Orwell

I am so happy I don't live in Libya.  Regards, Ceki 





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

Re: Code conventions

[Peter Donald]

On Wed, 2 Jan 2002 08:58, Ceki Gulcu wrote:
> At 07:39 02.01.2002 +1100, Peter Donald wrote:
> >Hi,
> >
> >This is not something that should have been brought up on the PMC list -
> > it should be discussed on general.
>
> Peter I do not need your permission to bring up a subject on the PMC
> list.

Its not the purpose of the PMC list. If someone asks how to configure tomcat 
on the general mailing list they would get a similar redirect.

> It was uncourteous of you to forward my message to the general
> list without permission.

It was uncourteous of you to misuse the PMC mailing list - you should no 
better than to do that.

> If you had read my proposal carefully you
> would have seen that my proposal was to reach agreement on the PMC
> list first and than consult with the wider jakarta community.

You got it all backwards. Consult with the committers. The PMC is irrelevent 
for this type of discussion - the developers are the ones to decide and PMC 
only steps in when there is legal or similar issues arise.

> Again, my proposal required al least two thirds majority of jakarta
> committers in order for the conventions to be adopted. 

Your right - it should be obvious that the preferences of that one third are 
not important.

-- 
Cheers,

Pete

---
 I don't suffer from insanity. I enjoy every minute of it.
---

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

Re: Code conventions

[Ceki Gulcu]

Ted,

The reason I brought up the issue on the PMC list rather than on
general was to see if there was consensus on the subject in a smaller
group. There seems to be no such consensus. Consequently, it does not
make sense to submit the proposal to the jakarta community.

This has been a good lesson which I am not about to renew. Have a nice 
day, Ceki

At 17:33 01.01.2002 -0500, you wrote:
>Ceki Gulcu wrote:
>> Peter I do not need your permission to bring up a subject on the PMC
>> list. It was uncourteous of you to forward my message to the general
>> list without permission. If you had read my proposal carefully you
>> would have seen that my proposal was to reach agreement on the PMC
>> list first and than consult with the wider jakarta community.
>
>Peter has a point, in that we're only suppose to use the PMC list for
>security or other sensitive issues, much the way the Committer list is
>used. Anything else should be handled on General. I didn't bring it up
>myself, since I was hoping it would just go away. Discussing coding
>conventions just creates a lot of traffic, and never accomplishes very
>much. 
>
>AFAIK, a formal change to the guidelines like this will require a 3/4
>vote of the PMC, and it would seem unlikely that a proposal like this
>would receive the requisite number of votes. Personally, I'm happy with
>the guideline we already have
>
>http://jakarta.apache.org/site/source.html
>
>
>-- 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/
>
>
>
> Original Message 
>Subject: Code conventions
>Date: Tue, 01 Jan 2002 02:18:18 +0100
>From: Ceki Gülcü <[EMAIL PROTECTED]>
>Reply-To: "Jakarta Project Management Committee List"
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>
>
>Hello all,
>
>As a follow up to the indentation discussion on the members list, I
>would like to propose the following text to popular (=committer) vote.
>
>Please indicate if you agree with the procedure of PMC draft followed
>by popular vote. Although the PMC may have the mandate to impose
>indentation
>rules, I feel it is wiser to consult the wider committer population.
>
>Here is my first draft of the text to be submitted to popular vote.
>
>==
>
>In order to enforce cohesion across Jakarta projects as well as the
>jakarta brand, the jakarta PMC would like to submit the following two
>articles to popular vote.
>
>Article 1)
>
>   All Java Language source code in the repository must be written in
>conformance to the "Code Conventions for the Java Programming
>Language" (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html)
>as
>published by Sun.
>
>Article 2)
>
>   Recognizing that migrating large amounts of code is no trivial
>matter, a transition period of 6 months, starting after the adoption
>of Article 1, is hereby granted to every subproject. After the
>transition period every project is expected to fully adhere to the
>code conventions adopted in Article 1.
>
>The above articles will be adopted if and only if at least two thirds
>of expressed votes are cast in favor. 
>
>Note that article 1 implies K&R style indentation of braces.
>
>
>
>Regards, Ceki
>
>ps. Best wishes for the new year.
>
>--
>
>Ceki Gülcü - http://qos.ch
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Ted Husted]

Ceki Gulcu wrote:
> Peter I do not need your permission to bring up a subject on the PMC
> list. It was uncourteous of you to forward my message to the general
> list without permission. If you had read my proposal carefully you
> would have seen that my proposal was to reach agreement on the PMC
> list first and than consult with the wider jakarta community.

Peter has a point, in that we're only suppose to use the PMC list for
security or other sensitive issues, much the way the Committer list is
used. Anything else should be handled on General. I didn't bring it up
myself, since I was hoping it would just go away. Discussing coding
conventions just creates a lot of traffic, and never accomplishes very
much. 

AFAIK, a formal change to the guidelines like this will require a 3/4
vote of the PMC, and it would seem unlikely that a proposal like this
would receive the requisite number of votes. Personally, I'm happy with
the guideline we already have

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


-- 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/



 Original Message 
Subject: Code conventions
Date: Tue, 01 Jan 2002 02:18:18 +0100
From: Ceki Gülcü <[EMAIL PROTECTED]>
Reply-To: "Jakarta Project Management Committee List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]


Hello all,

As a follow up to the indentation discussion on the members list, I
would like to propose the following text to popular (=committer) vote.

Please indicate if you agree with the procedure of PMC draft followed
by popular vote. Although the PMC may have the mandate to impose
indentation
rules, I feel it is wiser to consult the wider committer population.

Here is my first draft of the text to be submitted to popular vote.

==

In order to enforce cohesion across Jakarta projects as well as the
jakarta brand, the jakarta PMC would like to submit the following two
articles to popular vote.

Article 1)

   All Java Language source code in the repository must be written in
conformance to the "Code Conventions for the Java Programming
Language" (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html)
as
published by Sun.

Article 2)

   Recognizing that migrating large amounts of code is no trivial
matter, a transition period of 6 months, starting after the adoption
of Article 1, is hereby granted to every subproject. After the
transition period every project is expected to fully adhere to the
code conventions adopted in Article 1.

The above articles will be adopted if and only if at least two thirds
of expressed votes are cast in favor. 

Note that article 1 implies K&R style indentation of braces.



Regards, Ceki

ps. Best wishes for the new year.

--

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

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Code conventions

[Ceki Gulcu]

At 07:39 02.01.2002 +1100, Peter Donald wrote:
>Hi,
>
>This is not something that should have been brought up on the PMC list - it 
>should be discussed on general.

Peter I do not need your permission to bring up a subject on the PMC
list. It was uncourteous of you to forward my message to the general
list without permission. If you had read my proposal carefully you
would have seen that my proposal was to reach agreement on the PMC
list first and than consult with the wider jakarta community.

>On Tue, 1 Jan 2002 20:28, Ceki Gülcü wrote:
>> Conventions are a matter of taste and habit.
>
>Some are and some are designed to force programmers to implement things in 
>particular ways and indirectly force good programming habits.
>
>> Each subproject can
>> indeed adopt and publish a convention of its own. However, most
>> projects with the exception of Turbine and Velocity did not publish
>> conventions. (Please correct me if I am wrong.)
>
>Avalon has one ... based on an earlier version of Turbines.
>
>> I am not suggesting that we jettison the code and fire the committers,
>> that would be pointy-haired.
>
>no but you are suggesting that the people who actually do the work no longer 
>get to have a say in how they write code. Thats not pointy-haired at all!
>
>As soon as I see my first jakarta paycheck I will happily change over.

You are saying the individual first collectivity second. How about 
collectivity first and the individual second?

>If it was a legitimate concern then maybe we could do something about 
>it. About the only thing I can think of that we would want to change is 
>when people use conventions like
>
>a_class_name anObject = ...;
>anObject.do_something();
>
>And that is mainly due to the fact that it effects people outside the project 
>aswell. 
>
>However I don't think any of the jakarta projects use those conventions and I 
>am not going to be the one to force anyone to change if they do.

Again, my proposal required al least two thirds majority of jakarta
committers in order for the conventions to be adopted.  You nor I
alone, do we represent a two thirds majority.  However, a two thirds
majority represents the will of the community. If that is contested as
seems to be the case here, then the only remaining possibility is that
there is no community but a loose gathering of unruly individuals.

Regards, Ceki



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

Re: Code conventions

[Peter Donald]

Hi,

This is not something that should have been brought up on the PMC list - it 
should be discussed on general.

On Tue, 1 Jan 2002 20:28, Ceki Gülcü wrote:
> Conventions are a matter of taste and habit.

Some are and some are designed to force programmers to implement things in 
particular ways and indirectly force good programming habits.

> Each subproject can
> indeed adopt and publish a convention of its own. However, most
> projects with the exception of Turbine and Velocity did not publish
> conventions. (Please correct me if I am wrong.)

Avalon has one ... based on an earlier version of Turbines.

> I am not suggesting that we jettison the code and fire the committers,
> that would be pointy-haired.

no but you are suggesting that the people who actually do the work no longer 
get to have a say in how they write code. Thats not pointy-haired at all!

As soon as I see my first jakarta paycheck I will happily change over.

If it was a legitimate concern then maybe we could do something about 
it. About the only thing I can think of that we would want to change is 
when people use conventions like

a_class_name anObject = ...;
anObject.do_something();

And that is mainly due to the fact that it effects people outside the project 
aswell. 

However I don't think any of the jakarta projects use those conventions and I 
am not going to be the one to force anyone to change if they do.

-- 
Cheers,

Pete

--
Kitsch never goes out of style
--

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