Line in the sand.

[Paul Hammant <pa...@yahoo.com>]

I feel I have to say this.  This whole affair has got me so depressed today.

1) I object to people dictating changes to projects I work on, that they do not.
2) People are welcome to contribute, but they should (IMHO) tread slowly at first, and earn the
respect of the preestablished committers for that group.
3) Avalon is a collection of separate-interest projects.  It is an anomaly that it happens to have
a single "yes you are a committer" invite.

I believe these things. I am not going to change my mind.  I apply 1 & 2 everywhere I go. I see it
currently informally applied here (but under threat).  It is the OSS coding equiv of "do unto
others as you would have done unto you" (This 'the golden rule' is Pre-Christian and cross
religion for the record).

-ph

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Line in the sand.

[Leo Simons <le...@apache.org>]

On Mon, 2002-11-11 at 14:17, Paul Hammant wrote:
> I feel I have to say this.  This whole affair has got me so depressed today.

:(

> 1) I object to people dictating changes to projects I work on, that they do not.

and rightly so. This is the fundamental concept of the meritocracy thing
we all hold high.

There are some borderline issues that are largely legalese or
apache-wide things (like when the board tells you to do the license
headers one way or another, or the infrastructure people dicate you
switch to public key encryption for CVS access....usually not a problem
with stuff like that and not what you mean, just adding some nuances).

> 2) People are welcome to contribute, but they should (IMHO) tread slowly at first, and earn the
> respect of the preestablished committers for that group.

and IMHO, and I think in everyone's HO, though I'd add that it's not
neccesarily 'slow' we want them to go (they can do lots of stuff as long
as they're considerate, there is consensus, etc etc), again a nuancy
thing.

> 3) Avalon is a collection of separate-interest projects.  It is an anomaly that it happens to have
> a single "yes you are a committer" invite.

yep. This is something that has gradually grown though, and is hence not
(currently) quite as clear (and hence different people draw different
lines) as the other two.

For example, I'm for all practical purposes an emeritus committer only
to phoenix. But the average avalon user does not know (looking at how
frequently I get support requests via private e-mail...my name is in the
sources and on the site), whereas any avalon user can probably figure
out I am a committer to avalon and not to tomcat.

> I believe these things. I am not going to change my mind.  I apply 1 & 2 everywhere I go. I see it
> currently informally applied here (but under threat).  It is the OSS coding equiv of "do unto
> others as you would have done unto you" (This 'the golden rule' is Pre-Christian and cross
> religion for the record).

and it's good principle!

I'm going to digress now and write a long e-mail detailing why I think
the current proposal of setting up an Avalon PMC does not threaten
avalon or the underlying community principles.

This is not really directed at Paul or his message, it's just some
things that might be good saying here (as opposed to on other mailing
lists, where all has been said before ;).

Most of the below is stuff I remember from other posts by other people,
an overall image built up from posts by influential and experienced
apache people like Roy, Brian, Greg, Sam (all board members I think),
Stefano (active asf member and soon-to-be cocoon pmc member IIUC), Jason
Hunter (I think a VP for the JCP), Peter Donald (I think ex-jakarta pmc
and current apache commons PMC member), and many others. If stuff seems
out-of-whack, that's probably because I misunderstood them :D

Background
----------
When I joined, I got committership (in the active sense) to the
framework, and phoenix, and everything else, at least as I understood
it. I think I've contributed some to all of the different CVS modules.
This goes for many of the committers up to some level or another. When
avalon started, there was one product.

It is only through various ways of refactoring we've grown into a
community with many truely separate products. This is a healthy and
natural process!

The choice to decouple Avalon Phoenix from Avalon Framework was a sound
technical move just like the choice to do develop a java server
framework outside of JServ but in a new project was also a good
technical move. Etc etc.

These decisions, based on being the best from a technical perspective,
also have 'nontechnical' side-effects. For example, phoenix has gotten
brand recognition on its own, now has a different community from the
rest of avalon (centered around phoenix-dev), even if a large part of
the phoenix community also forms the avalon community (and/or other way
around).

Making these decisions allows us to flourish, develop into many
directions without creating bloatware, etc etc. It's seperation of
concerns :)
Proper refactoring like this has allowed avalon to enjoy a healthy
growth. The same is true for many projects on many 'levels' (for
example, Jakarta, cocoon, apache as a whole, ...).

At some point in time, the organisational/management/legal concerns
(usually because of the general project growth) make the people who
worry about those things decide there is also some organisational/
management/legal refactoring need. This need results from the technology
evolution, not the other way around. That's so cool about apache :)

The people I mention above, that worry about the
organisational/management/legal stuff, are the apache board, the apache
officers, the apache PMCs, the apache members and other individuals who
help out in this respect. After long, long debate and analysis, it has
become clear to them what form the refactoring is to take: we roughly
need to center projects (where a project is defined as in "that which is
managed by a Project Management Committee") around products.

It is clear that this is not an option for all products (like fledling
products with too small a community to survive on its own, products with
not enough people in the community who could form a good PMC, products
that don't warrant the organisational overhead of a PMC, or products
that are small and reusable by nature), hence there are now two new
projects (with the organisational entity of the PMC that comes with it)
specifically to care about and handle those situations: Incubator and
Commons. There's also still the Jakarta and XML projects and PMCs.

Avalon (as in the sum of the people that are part of the community in
one way or another, all the code in the CVSes, the mailing lists, the
website; ie the complete entity currently a Jakarta subproject) clearly
has many products (besides "the avalon server framework specification",
several implementations of that spec, and code to support the
implementations, there's a DBMS, an ORB, various reusable modules built
using the framework, a logging toolkit, ...).

The organisational/management/legal people have made it clear that this
makes their jobs difficult to do. Hence, the request to the avalon
community (and just about every community @ apache, for that matter) is
for us to think about how to refactor ourselves to make that job
possible and easier again.

We all want to make that job possible, as it is good for apache as a
whole, hence the software world as a whole, hence our jobs, too. And
because it's what we believe is right. Thus there is discussion about
forming a top-level project, a PMC, moving code different places, etc.


What the Avalon PMC proposal is not about
-----------------------------------------
many things, even if they are brought up in parallel :)

All this is not a technical matter at all, even if it may end up having
some technical implications (and hence it is important all technical
people participate to the maximum extend possible so we can see that
stuff coming).

No-one of the organisational people is saying (just for example) that
the excalibur CLI package should change to sun standards for
command-line options. They're just saying that it might be best from the
organisation perspective if that CLI package is moved under control of
(for example) the Apache Commons PMC instead of the Jakarta PMC.

The idea is not to make us (as technical people) move (for example) CLI
and impose an organisational structure, the idea is to make us aware of
the current issues (and benefits of a move) and then ask us to figure
out how to make things go smoother.
IOW, the idea is to have us technical people think up the organisational
refactoring too (with all the help and suggestions we need). Only when
'those management people' feel they have no other choice (given their
legal responsibility for example) are they going make the refactoring
proposals themselves.

The idea is also not that the organisational refactoring proposed
currently (ie setting up a PMC) will solve any kind of
non-organisational problem. It won't help us in building an
uber-container, nor will it help us avoid or solve personal conflict. It
certainly isn't going to affect the command-line option format in the
CLI package.

All the talk about what one could dub "community engineering" or
changing our voting guidelines and/or rules is just because people get
exited when they are suddenly entrusted with a formal obligation to
think about those things and are offered the power to vote on them. It
is highly unlikely there will be any big deviations from our current
process.

After all, if we feel like a change in any of all that, we can already
do so with not too much effort (for example, to restrict CVS write
access to jakarta-avalon-logkit to the people that have committed to
that module  in the past should we want to, all we will likely need to
do is vote on that, forward results to the PMC and then contact someone
with root access). This is because the organisational/management/legal
people like the Jakarta PMC and the board are almost always very
supportive of the needs of the community; that's what they do. That's
what any new Avalon PMC will be about, too.

The proposal is also not about a top-level domain. We will probably get
avalon.apache.org if we want after this proposal, but we probably could
as well if we don't form a PMC. Any such move is merely about making the
organisational structure apache has as transparant as possible to the
rest of the world.

The idea is not to increase the amount of bureaucracy, rules, policies,
or anything like that. When an Avalon PMC will indeed be formed, that
PMC will indeed have the option to change rules and policies, but it is
highly likely that this will happen.
If it does happen, that will probably only be to limited extend (we
might want to exchange the guidelines of the jakarta project with those
that come out of the incubator project, where some very smart people are
working on refining existing guidelines).

What the Avalon PMC proposal does entail
----------------------------------------
What establishing a PMC will enable is improving the organisational/
management/legal framework the ASF provides to the avalon community,
which has lots of benefits :)

It will shorten communication channels (the 'organisational layer' of
the jakarta PMC is removed), thus likely increasing cross-project
communication which has numerous benefits and is good for the health of
the greater apache community.

It will make it easier for the board to figure out what is happening all
around apache.

It will make it easier for us to get support on (and resolve) the
various legal issues.

It will relieve the Jakarta PMC of responsibility for avalon, allowing
them to better support the other Jakarta subprojects.

It will likely increase the status and importance of avalon in the eyes
of end users.

etc etc.

The most often raised concerns are that making this move (many other
Jakarta projects are likely to do so, too) will somehow make the other
jakarta subprojects seem less important, that this move might hurt the
Jakarta project, and that this move might hurt the jakarta community as
a whole.
There might be some truth in that. I personally believe that what will
happen is that the subcommunity that jakarta is within the greater
apache community will slowly evolve into something else, perhaps with a
little less identity of its own and a little more apache-generic
identity. Regardless of what happens to Jakarta, I think the net effect
for apache as a whole is definately positive.

best regards,

- Leo Simons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Line in the sand.

[Nicola Ken Barozzi <ni...@apache.org>]

Paul Hammant wrote:
> I feel I have to say this.  This whole affair has got me so depressed today.

:,-(

> 1) I object to people dictating changes to projects I work on, that they do not.
> 2) People are welcome to contribute, but they should (IMHO) tread slowly at first, and earn the
> respect of the preestablished committers for that group.
> 3) Avalon is a collection of separate-interest projects.  It is an anomaly that it happens to have
> a single "yes you are a committer" invite.

I agree with you, and I want to stress point 3.

If Avalon were a single project, 1 and 2 would be automatic, since a 
committer has done them to earn his status.

Since it's not the case, and IMHO it's an anomaly not documented 
anywhere AFAIK, we should decide what is best for us to do.

Making a PMC, starting the new Avalon codebase from scratch, moving 
stuff to Apache Commons, and possibly spinning off projects where is 
makes sense are all things that try to address it.

If Phoenix had been a separate project, if we kept the new comtainers as 
proposals instead of kicking them "live" as indipendent stuff, if if if, 
probably many of these problems we are facing now wouldn't have even 
started.

> I believe these things. I am not going to change my mind.  I apply 1 & 2 everywhere I go. I see it
> currently informally applied here (but under threat).  It is the OSS coding equiv of "do unto
> others as you would have done unto you" (This 'the golden rule' is Pre-Christian and cross
> religion for the record).

If the boat is sinking IMHO, and I have never worked on the failing 
part, and the one that caters for it is IMHO making it worse, I would 
definately go and try to make it work.

But Avalon has stopped being a single boat since a long time...

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>