On Fri, Feb 20, 2009 at 1:08 PM, J Aaron Farr <[email protected]> wrote: > > On Fri 20 Feb 2009 20:01, Robert Burrell Donkin > <[email protected]> wrote: > >>> Honestly, I'm not sure if there's a good solution for something that's >>> bigger than labs, but likely never large enough to escape the >>> incubator. Of course, some TLPs are pretty small, so really as long as >>> there were three committers / members interested in taking something >>> from labs to TLP, incubation should be pretty straight forward. >> >> Incubation relies in a credible exit strategy. Projects which are tiny >> cannot graduate without a suitable TLP to act as a home. >> >> For example, RAT had a useful codebase, enthusiastic mentors and was >> staffed by all old Apache hands. Incubation has just about killed the >> project since the code is mature but there's no suitable TLP for >> graduation into. > > Why not take RAT to a TLP then?
i feel it's unethical to do so (i would be using personal influence to bypass what is a systematic problem which the members really need to start thinking about) but RAT is just an illustration. i'm confident that it'll sort itself out sooner or later (and even if it doesn't the reason behind the move was acheived as soon as apache received the software grants). > If it's big enough to need "releases" then it's big enough for a TLP. it's not about code size but maturity and usage a code base that is widely used by apache projects needs to have releases. so, it's an internal need. > If you can't find three committers willing to help out, then it's not > big enough to need releases. If people complain about no releases, > invite them as committers to an incubator project. You only need three > people and if those three are already apache committers then incubation > should be short and effectively a mere formality while the TLP is setup. apache cannot scale if every tiny-but-worthy codebase which can scrape together 3 committers is allowed to become a TLP. graduating a big project is difficult, and imposes a natural friction. provided you're willing to game the system, it's much easier to graduate a tiny project. creating an excessive number of TLPs just pushes the scaling problem to the board level. for example, every one of the 50ish commons components technically has enough committer support to be a TLP but it would have been a mistake to do so. my experience of the commons convinced me that micro libraries are best developed in a collegiate atmosphere where best practice and oversight can be shared. in practice, committers develop a hazy sphere of interests typically encompassing several micro-libraries. these spheres overlap, creating the community. after a while, maintaining the communal brand starts to become an important motivator. i learnt a lot from mentoring new developers on components i have no direct interest in, and helping a developer become a committer and (sometimes, one day) a member is rewarding. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
