On Monday, November 10, 2003, at 01:18 PM, Justin Erenkrantz wrote:
--On Monday, November 10, 2003 6:04 AM -0500 "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
Is there a good post describing the benefit of these changes? I don't
understand the upside of moving oro and regex from one umbrella to another
umbrella, nor trying to get j-c projects to move to a-c. I see j-c as a
vibrant and prolific community, and wonder about the effects of breaking it
apart.
I either missed the point somewhere (likely) or don't get it (also likely).
Okay, we've gone over these before, but I'll try to restate what I believe the benefits to be for the newcomers. Others are welcome to chime in and comment.
- I don't quite believe it'll be the same sort of umbrella as J-C or Jakarta itself. We're trying to advocate that groupings should receive their own topic-centric mailing list. We're trying to advocate a higher degree of interaction with the PMC, etc. From all reports, J-C is starting to collapse under its own weight. Something has to give.
- It's isn't quite a lateral move as you'd make it out to be. I believe it, at best, would be cutting out one level of bureaucracy (namely the Jakarta PMC) and restoring power to committers working on code. This has the advantage of allowing the actual developers working on the projects to have a voice in the PMC (and, legally, this is as they are required). I've heard concerns from J-C folks that they don't really have any direction from the Jakarta PMC on what to do, nor do they have any say. Yet, in A-C, there would be *at least* one Commons PMC member per project who is active - the Commons PMC needs to ensure that as part of its oversight responsibility.
I think that this slightly misrepresents the problem, as it's not clear what 'power' needs to be restored. I agree that there could and should be more representation on the PMC for legal reasons, but that can be achieved with a bigger PMC.
- A chance to re-organize projects that aren't 'quite big enough' for TLP status that are meant for reusability under one shared PMC. I believe that a lot of 'small' projects will share common needs and requirements: a PMC that understands that can be extremely beneficial with the right processes and tools in place.
This is far fetched - the Jakarta Commons has been *amazingly* successful in being a place for not-big-enough projects (we call them components) to be able to incubate and form. This aspect is what I fear will be lost - the huge collaborative effect that commons fosters. I don't always agree with the side effects (I mean, does every damn bean need to log via commons-logging????), but the success can't be argued with.
- It's harder to build communities around reusable libraries that don't have any direct user interfaces: it takes a lot of time and effort and doesn't usually start with the community size that mandates TLP status. And, I'll point out that this isn't quite the same as the incubator - which is only meant as a legal checklist.
I'm not sure what you mean here. What do you define to be 'direct user interface'? In commons, there is a huge community, which was created and fostered to scratch the itch of another community, Jakarta. And within commons, mini-communities were formed around each component. There's an interesting fractal-like structure to it, and one that joins unrelated Jakarta subprojects in interesting ways. I think commons glued lots of jakarta sub-projects together. While I think that a-c could be a good idea, I fear the difference may be that the communities you are trying to bring together don't have enough in common. People have been learning this the hard way (for example, Yugoslavia...).
- A learning place where these reusability projects (or groupings of projects) that do become 'big enough' to become TLPs. As these collections of functional groupings are defined and projects start to develop communities that can manage themselves, I believe the Commons PMC should advocate that they should be promoted en masse as a new TLP. This respects the current feelings (among some) that the ASF should reorganize around very specific TLPs rather than broad PMCs.
I see both sides of that argument, and feel that whatever problems one has or had with jakarta, you can't argue with the amazing success in terms of software and communities. I do think that Jakarta grew too large, or too diverse, actually, for it's own good - the cohesion seemed to diminish a bit.
- Yet, we will have to find the balance on what should be spun off and what shouldn't be. IMHO, the ideal code in Commons is one that is 'done' and doesn't need much work or oversight. Hence, creating a TLP doesn't make sense for certain classes of libraries as when they're done, they're 'done.' You've created the 'perfect' math library. > Yay.
Hm
- From my C-centric perspective, a place where I can develop reusable code and libraries as there are no PMCs willing to accept reusable C libraries anywhere in the ASF such as serf. (APR did for a little while, but that was under extreme protest.) So, I'm merely here to scratch my own itch as I'd expect most people should be, too.
Why not bring them to Jakarta commons ? That probably wouldn't stretch the boundaries of the charter any further than it has been already ;)
Hope this begins to answer your question. -- justin
Thanks for the info.
geir
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
