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: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
