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.
- 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.
- 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.
- 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.
- 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.
- 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.
Hope this begins to answer your question. -- justin
