J Aaron Farr 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?
If it's big enough to need "releases" then it's big enough for a TLP.
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.
Maybe there are 3 committers to make a release, but after the release
the project is more or less mature because the codebase is very small.
Does this really justify to go TLP, just to make a release, make a
full-blown website, etc.? I don't think so.
We have a very focused model how a ASF project should look like. And
this model is pretty successful and there is no need to change it, for
obvious reasons: We have 30+ projects in the incubator which want to get
big enough to go classical TLP. This takes tons of efforts. We have 60+
TLPs to manage which want to stay 'healthy', having a thriving
community, releases, docs etc. There seems to be no obvious reason to
think beyond, because all that which is the ASF today keeps us really,
really busy.
But our foundation is not per se restricted to this project model. Our
goal is "the creation and maintenance of 'open source' software
distributed to the public at no charge". Does this exclude small
projects? No.
Small projects with one or two contributors are a problem. Some live in
symbiosis with some TLP, some are in labs, some struggle in incubation.
What - I'm only brainstorming here - could we do make small projects
Apache-cool? What can we do with them that we can't do in classical TLPs?
+ Have a responsible person for every small project (just like the PI in
labs).
+ Make that person stick very close to the project, if he/she disappears
someone else takes over on short notice or the project is attic'ed.
+ Keep high profile: Since the community is probably small, small
projects need to be very active about communicating/reporting (this is a
problem here in labs, most lablings keep a very low profile).
+ Define a project size (lines of code, size of release artefact) when
the small project is no longer a small project and has to go TLP (or may
be split into two small projects).
+ Build ad-hoc release committees, where others join which do not work
on the project normally, but due-dilligence it for the release.
+ To make that work: A small project must release every 500th line of
changed code or 50th commit or three (or six) month, whatever comes
first. So outsiders of the codebase can judge what happened, with
reasonable effort.
+ Mature small project are put in 'mature mode', but no open issues may
exist in the issue tracker.
+ Every project is reviewed every two month by a PMC-like committee,
regarding size, release, community outreach and PI engagement.
Small projects can be more agile, and they have to be - otherwise they
are closed/matured. They should have a more structured lifecycle (and
this is also what lab tried to establish in a way).
Of course, this is all very much only a set of rough ideas, thanks for
listening anyway :-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
