Re: Open Source, Cold Shoulder (fwd)

2004-10-13 Thread Justin Erenkrantz
--On Tuesday, October 12, 2004 9:34 PM +0200 Santiago Gala 
[EMAIL PROTECTED] wrote:

You can separate both functions, i.e. development or patching and code
review/quality control. The linux kernel is beginning to be a good
example, where you have:
- Linus (vanilla) tree as a reference value (think Fed Reserve)
- Andrew Morton (mm) patches, making it a higher risk (think Dow Jones)
- Full preemption and other special or highly experimental patches
(think Nasdaq or even Hedge Funds)
- Hardware manufacturers trying to get their code in, to get more wide
support for their hardware.
- Other people suggesting improvements around (I've sent three typos
recently) just because they don't want to maintain their needed pieces.
The Linux kernel is a great process example if you aren't trying to actually 
cooperate in the development process or build a *real* brand.  Linus views 
RedHat, Debian, Mandrake, etc. as the ones who are responsible for dealing 
with users.  It's also a very ego-centric model - perhaps some developers like 
that.  I don't care for it at all.  -- justin

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


Re: Open Source, Cold Shoulder (fwd)

2004-10-13 Thread Henning Schmiedehausen
On Tue, 2004-10-12 at 19:21, Niclas Hedhman wrote:
 On Tuesday 12 October 2004 21:02, Ben Hyde wrote:
 
  Projects that: fail to
  welcome new comers; fail to bring in credible new contributors ... well
  they are just stupid.  They will ultimately become dysfunctional and
  implode.
 
 Question; Should Open Source be Open Participation?
 
 I am sure that the upper-tier of ASF would shiver at the thought that hordes 
 of people can gain direct access to the repositories. They/we will dust of 
 the same arguments of why Wiki won't work. But it does. Why? Because *most* 
 people *want* it to work.

But the few that don't will spoil the show. We had our share of Wiki
defacement. With a wiki, that is easily corrected because all pages are
in _one_ place. If you have code defacement (consider a malicious third
party put a backdoor into the httpd stable branch) and anyone checks out
code from the CVS with this backdoor, your project reputation is toast
(/. reports a that a backdoor in widely distributed web server has been
found. Film at eleven).

 
 Can it work on code? _I_ am absolutely certain, but I never expect that the 

Sorry Niclas, but in the last few weeks I've read quite a number of
postings of you on the Avalon and general apache lists, that suggest
that you either live in a dream world where everyone is everyone elses'
friend or that you have no clue what you are talking about  

In the real world, there are probably ~99% of the people that are
interested in working constructively together. But the last remaining
percent is enough to put grafitti all over the walls in any bigger city
(probably in Sweden too), burn holes in the seats on the subway and
litter the streets. In the end, the majority of the 99% must adjust to
the 1% of idiots. 

It is the same thing with the internet. On a wiki, where defacement and
pranks are easily repaired, the majority might be able to tolerate the
annoying people on the net. With a code repository where everyone can
get a cheap copy and redistribute it: No way, Jose.

This is a meritocracy, not a democracy. Prove me that you know what you
are doing, earn trust and you will get more power. 

 hard-earned ranks of the upper-tier in ASF to willingly relinguish the 
 'military style rankings' that makes up ASF and most other OSS projects.
 
 Future will tell, but I am putting my money on Open Participation Software 
 (OPS) where everyone is welcome to join in, not barriers of entry and 
 militarism of promotions. ;o)

It seems to me that you have no idea how a larger organization should be
structured. And the ASF with 800+ committers is such a larger
organization. 

There have been lots of experiments in the dot-com bubble startups with
non-hierarchical structures community concensus and self
management. In the end, those companies survived that have modeled
themselves after the good old executive, middle-management, workers
model what has been proven to work in the last few centuries.

Because the others couldn't even agree who should wash the cups after a
meeting and had to hire a consultant for this. 

IMHO you should reflect on:

Now I am a firm believer in democracy, but I also believe that there
are some fields of human activity in which a count of noses does not
provide the best basis for law and order. (Theodore M. Bernstein: The
Careful Writer)

But please, stop talking about things that you obviously have never
tried out or at least not tried out on a marginally successful project.
That your ideas work for the obscure project with a few developers and a
community where everyone knows everyone else: Sure.

Would it work for Tomcat, httpd or even a mid-size project like
Avalon/Merlin/Excalibur: Surely not. 

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/
 
RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

Fighting for one's political stand is an honorable action, but re-
 fusing to acknowledge that there might be weaknesses in one's
 position - in order to identify them so that they can be remedied -
 is a large enough problem with the Open Source movement that it
 deserves to be on this list of the top five problems.
   --Michelle Levesque, Fundamental Issues with
Open Source Software Development


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



Re: Open Source, Cold Shoulder (fwd)

2004-10-13 Thread Niclas Hedhman
On Wednesday 13 October 2004 16:44, Henning Schmiedehausen wrote:

 In the end, the majority of the 99% must adjust to the 1% of idiots.

Hmmm At a 2 magnitude superiority in manpower, the majority is unable to 
keep them in check, and weed them out? Is that a matter of lack of tools, or 
doesn't the majority care?
You mention grafitti as an example; The punks can do it undetected + it is 
more effort to remove than put up. Would they bother if it is fixed by the 
press of a button, when 'anyone' sees it (i.e. good tools)?

Well, maybe I am living in a dream world and there are more idiots out there 
than I think. Maybe you shouldn't tell me, I might get a trauma from getting 
out of my disillusion.

 But please, stop talking about things that you obviously have never
 tried out or at least not tried out on a marginally successful project.

I am amazed at your logic :o), I truly am. 
But asking me to stop questioning the status quo, what is the purpose of that?


Cheers
Niclas
-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+


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



Re: Mail server doesn't accept zip attachments

2004-10-13 Thread Santiago Gala
Infrastructure would be a better place for the technical, though a
discussion on policies would be better here at community :-)

I CC: infrastructure to get an answer from the mail wizards (please cc:
Carlos, I'm not sure he's in the infra list)

El mi, 13-10-2004 a las 16:21 +0200, Carlos Sanchez escribi:
 Hi,
 
 Not sure if this is the correct mailing list for these kind of issues but 
 maybe someone can help.
 
 When trying to send a message with a zip file attached through 
 cvs.apache.org, using a ssh tunnel, I get
 
 552 we don't accept email with executable content (#5.3.4)
 
 The zip content are text files.
 
 Is this intended or is a bug? 
 
 I've tried to send a message with a zip file to my apache.org account and was 
 also rejected, so I can't send nor receive.
 
 
 Regards
 
 Carlos Sanchez
 A Corua, Spain
 http://www.jroller.com/page/carlossg
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Santiago Gala [EMAIL PROTECTED]
High Sierra Technology, SLU


signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada	digitalmente


DOM v3 in JDK 1.5

2004-10-13 Thread Niclas Hedhman

Hi everyone,

This is a semi-cross community technical issue, regarding the change of the 
org.w3c.dom.Node interface (as part of DOM3).

Is there anyone who has investigated the consequences of these changes, and I 
am referring to the previously terrible situation with the DOM1 to DOM2 
transition a couple of years ago.

Will the trio Crimson, Xerces, Xalan be able to cope with it in a reasonable 
way for the users, especially in light of the likes like Tomcat, Cocoon and 
possibly other XML heavy projects.

I am hoping that the Jar-order hell that reign back then is not going to 
repeat itself.


Cheers
Niclas
-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+


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



Re: Open Source, Cold Shoulder (fwd)

2004-10-13 Thread Brian Behlendorf
On Wed, 13 Oct 2004, Niclas Hedhman wrote:
On Wednesday 13 October 2004 16:44, Henning Schmiedehausen wrote:
In the end, the majority of the 99% must adjust to the 1% of idiots.
Hmmm At a 2 magnitude superiority in manpower, the majority is unable to
keep them in check, and weed them out? Is that a matter of lack of tools, or
doesn't the majority care?
You can weed them out... but they can come back too, under a different 
name.  The Apache wiki defacement was done by spammers and by one person 
who just wanted to see the goatse picture... but all anonymous save for an 
IP address.  Defacement and repair is tolerable when we're talking about 
text content, whether it's our documentation or Wikipedia; but it's not 
tolerable when we're talking about code, despite the peer review that 
commits (usually) get.

But, I am really interested in seeing you run an experiment on this, and 
watch how well it scales.  And if there's things we could do to improve 
our own processes and tools - like modifying Subversion in some way to 
allow for open branching so that submitted patches are a part of the 
system rather than passed around as deltas in the bug database or on the 
mailing lists.

But let's talk more about it here as you start seeing results
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]