incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: Checkpoint on Harmony (Re: [discussion] Harmony podling to ask for vote for graduation)
Date Fri, 20 Oct 2006 05:00:52 GMT

William A. Rowe, Jr. wrote:
> Sam Ruby wrote:
>> William A. Rowe, Jr. wrote:
>>> IMHO - the only reason to have a project (TLP or subproject, no matter) is
>>> to release code.  Anything prior to a release might be a sandbox, it might
>>> be a podling, it might be a lose alliance of the willing.  Whatever...
>> [snip]
>>> That said ... I don't believe anyone is saying Harmony must release it's
>>> entire codebase to graduate.  Any working and usable component or part of
>>> the harness could be released as 0.1 alpha version, the processes followed,
>>> the issues raised and resolved.  With a codebase as large as Harmony, I sure
>>> don't expect the whole ball of wax to be ready, or at the same level of
>>> stability, all at once.
>> Be aware that in the context of J2SE, a "release" must fulfill some
>> compatibility requirements.  Included in this is a requirement not to
>> subset.
> Understood.  This can not be a J2SE release.  The question I raised is if
> there can be part of the 'firmament' beneath the VM released.  Yes, I grok
> that none of this shall be released as a J2SE VM - because the only J2SE VM
> is a complete VM.
>> Of course, one could simply manufacture a synthetic release for the
>> purposes of satisfying a perceived incubation requirement, but honestly,
>> that seems more like one of the "ticky-marks driven processes" I tend to
>> see within my day job than anything I would expect to see at the ASF.
> I certainly hope that the concept of 'releasing the code' isn't just a tick
> mark - I'd imagined (contrary to other proposals flying around) that it's the
> end goal of nearly any collaborative effort at the ASF, no?

No, because then every project would simply disband after milestone 1 :)

>> [snip]
>>> So as much as I admire the enthusiasm of the entire community and know that
>>> the vote will disappoint some folks, I'll repeat my root question; how does
>>> incubation status interfere with progress of the Harmony project prior to
>>> its first release?
>> If you forgive me, let me propose a thought experiment.  Why don't we
>> simply dissolve the board, and throw everything back into incubation?
>> What would it hurt?  Projects obviously have been holding releases
>> during incubation, many have had multiple releases.
> I'm failing to see where you are going here, and made your post initially
> really hard to follow.  Ignoring the above...
>> No, that's not a serious proposal.  What I am growing increasingly
>> concerned with is that we (collectively) have started to lose sight on
>> what the mission of the incubator is.  Yes, not having a release is an
>> indicator, but there certainly are other indicators.  No, I'm not
>> advocating that we "rush" projects out of the incubator.
> Absolutely, it's gotta be the question.  If whatever decisions are made
> at the incubator don't reflect its mission, well, those decisions are
> pretty pointless, eh?
>> What I am looking for is a happy medium.  In particular, I would like to
>> see is for the rate of disposition (either in a positive or negative
>> manner) of projects in the incubator approximate the rate of creation.
>> More succinctly: I want to see projects that are ready to graduate start
>> graduating, not because it benefits them, but because befits the incubator.
> +1 to keeping some equilibrium, and I hope all the mentors are watching the
> ball.  The recent request by the board to highlight three of the biggest
> obstacles might help define this.
> -1 to simply pushing things out because our plate is full.  I'm not going to
> object if folks start throttling on the front end; "please hang on to your
> proposal, it seems like a worthy effort but the pipeline is too full" ---
> which hopefully leads to a show of hands from a few new ASF members to take
> on and mentor a few more projects.  I'm suggesting new blood/more blood, not
> bleeding the current volunteers to death.

But no one is suggesting that we need to get Harmony out simply to make 
room for something else.

After contemplating for several months now, we thought the time was 
right.  I think requiring a release is losing sight of the basic 
premises of incubator, which are creating a healthy apache community 
with a clean codebase.

A release is one of many things that a community will grapple with in 
it's lifetime, and yes, it's a good reference point to *observe* a 
project in it's natural state when evaluating health.  But as I noted 
earlier, there are many things that are good reference points to observe 
(deal with a troll, resolve a technical difference, choose among two 
solutions, deal with an outside project, etc...).

I think that the mentors and experienced participants teach.  When the 
mentors (and the podling) agree that graduation is in order, it's up to 
the rest of us to evaluate the data that's there.  Clearly the mentors 
used some data to make their decision...

This is why I pushed back on this - not because a release of some small 
thing in Harmony isn't possible, but because I think there is ample 
information to look at and I think we're missing the forest for the 
trees. I'm somewhat sorry that I didn't notice this sooner and speak up.

>> Returning the subject back to Harmony, with regard to a release, what
>> matters more to me is whether or not those who are directly involved
>> with Harmony (which most decidedly does *not* include me) are interested
>> in producing a release at this time.  If not, and if their reasons make
>> sense, then I would be inclined to respect their wishes.
> Which brings me back to your question, what's the point?  If the point is to
> have a self-sustaining community, I'd argue that a codebase without a release
> at all is in serious risk of ultimately stalling.

I don't see how you can make that statement.  Harmony doesn't have a 
release.  We have plans and a time line for a release, and have had it 
for months.

We have not stalled w/o that release, but instead continue to rally and 
grow.  I know it keeps me up at night :)

>  A codebase with users and
> a community that relies on it has a built in healing factor, in which the
> users themselves can step up to the plate, even if the -entire- development
> community waved goodbye.  Or not, but that's then in the users' hands :)

Sure, and we need to get a minimum amount of working code to start 
attracting users.  We're getting drips and drabs of users now, but we're 
still rather unstable, and we're competing with state of the art 
implementations of the same thing that are FREE. We're not [yet] 
something new and different that people can't get elsewhere, and hence 
you can get a user community going of people that are willing to put up 
with the warts if it solves their problem.

We knew this problem going into this, and are more than happy to grit 
our teeth and keep going, because once we *do* get the code stabilized, 
I think you'll start seeing users and consumers of the parts.

> And as far as their wishes go, nobody's addressing the question,
>>> how does incubation status interfere with progress of the Harmony project
>>> prior to its first release?
> Can someone shed some light on this, please?

Because being out of the incubator gives others confidence that there is 
a solid community (-ish) and that the greater Apache community is 
serious about the project and approves it.  It's really all about 
external perception.  (I was happy just coding away down there for the 
last 18 months, but it's time...)

For some projects, this means that people are more willing to use the 
software as it feels more "real".  In our case, where we're always 
looking for contributors and participants, and many of these potential 
contributors are conservative commercial organizations, they may be 
holding back simply because they want to wait until we are "real".  I 
personally don't have this problem, but I've heard it enough times to 
know that the perception is out there.

I hope that helps.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message