I understand that there are some specific circumstances in this case,
but in general I believe this sort of criteria is why we get
complaints that it's impossible to "innovate" at Apache any more. We
require all the grunt work of innovation to occur outside of Apache.
The issues of an open specification is one thing. But aren't "proven
an actual community" and "work the standard 'apache way'" graduation
requirements, not entry requirements? If we expect something coming
into the incubator to already have a fully functioning, health
Apache-style community, then the only point of the Incubator is for
handling licensing issues.
This is quite interesting...
Over at Wicket we have been operating 'the Apache way' from a very
early stage in the project (about two years). We have mail archives,
commit logs, releases, and history of letting new committers in to
prove all that if people are willing to spend an hour looking for it.
But we feel we have to prove ourselves all over again as the
incubation process expects it's podlings to prove themselves within
the confines of the incubation process.
The incubation process might benefit from having a categorization of
projects that want to enter. Such categorization basically answers:
* How old are these projects, how many committers, how large is the
community of developers and users?
* Has the project been working apache style for a certain time (the
time being a categorization in itself). If it has, there is no
question about prove - it'll be there as that is one of the key
factors of working the apache way (mailing lists, committers etc.)?
This categorization would then be the starting point for answering two
things that I think are currently missing in the whole incubation
process (please do tell me if I am wrong/ missed something):
* To what extend can information about the project's readiness be
gathered based on the (outside) history of the project, and how much
information needs to be gathered additionally during incubation? The
availability of such history could get some load of the backs of the
involved parties and might mean a shorter incubation time.
* What would be the proposed time estimate for the whole incubation?
Factor time currently seems to be non existent in the incubation
process. But 'it takes how long it takes' imo does not cut it. I
believe the incubation process would benefit from formalizing
timelines and milestones so that both parties keep focussed on making
progress. Having a schedule for incubation would also mean that
involved parties could use that schedule for any other plans they
might be making. For example, we (Wicket) would like to have our 2.0
version to be released at Apache, after (if) we're done with
incubation. There is currently no way to even remotely predict when
that might happen. This is inconvenient for our users, but also is a
problem as we are writing a book on that version and our publisher
*does* want to know when that book will be ready for publishing.
Having a code base that is release-ready but that's just waiting for
months for the incubation process to move on for some unknown time is
unacceptable to us. The kind of schedule I am thinking of would be
semi-binding. If we meet the requirements for the milestone in time,
we go on to the next stage, unless there is absolute consensus we
shouldn't based on something other that the milestone requirements. If
we don't meet the requirements in time, incubation may be terminated
for that reason alone.
I couldn't find any previous discussions on these topics, but if I
missed them, my apologies and please reply with an URL. Otherwise, I'd
be very interested to hear what others think of this. Also, I am not
specifically proposing anything concrete for Wicket's incubation at
this time; I wouldn't want to get in the way of our mentors :)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
