Mailing-List: contact lucy-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Tue, 10 Jan 2012 09:57:39 -0800 (PST)
From: Chris Hostetter <hossman_lucy@fucit.org>
To: lucy-dev@incubator.apache.org
cc: peter@peknet.com
In-Reply-To: <20120110052750.GA1637@rectangular.com>
Message-ID: <alpine.DEB.2.00.1201100941390.3248@bester>
References: <4F0BB29B.1040107@peknet.com>
 <20120110052750.GA1637@rectangular.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [lucy-dev] 0.3.0 release prep


: > For the c/ files, since that is just the stub of the tip of the beginning of a
: > start for that code, do we even want it in the release?
: 
: IMO: yes.  Canonical release tarballs should be snapshots from the VCS.
: Things get annoyingly complicated if you deviate from that.
: 
: If we don't want something in an official release, we should develop it on a
: branch.  That will be more straightforward once we switch to Git in a few
: months.
: 
: > Could/should files be removed from a branch if they do not represent
: > 'finished' product? I realize this last is a philosophical as well as
: > practical question.
: 
: I don't think it matters much.  All of the 0.2.x releases have had a ruby/
: dir containing useless in-progress code; nobody complained.

On the philosophical side: Lucy is a young project that still needs to
think hard about focusing on atracting to "contributing-users" first, and
"non-contributing-users" second.

I think it should be considered preferable for the releases to be "warts 
and all" and include all of the half-finished unpolished partly-broken 
language bindings that are in progress, because having that code in a 
release will make it (the unfinished code) more visible and more likely to 
attract new contributors who might think "hmmm... here's a binding that's 
already started i can help out out" but who otherwise night have never 
considered contributing back to Lucy ... perhaps because they had no idea 
how to "get started" with a binding for XYZ (and wouldn't realize someone 
already had if it wasn't in the release).  The only downside to 
unfinished/non-working code in a release, is it may discourage / scare-off 
novice users who might try it and think "hmmm... this stuff doesn't even 
work!" w/o realizing how much *does* work.

In otherwords: i would suggest that for now, avoid the "let's build this 
feature on a branch until it's stable" mentality, and reserve branches for 
"let's experiment with changing this existing API/functionality on a 
branch so we don't risk it leaking out into a release before we're sure it 
doesn't break existing users" type situations.

The caveat to all of this is that as you guys add new bindings, it should 
be drop dead simple for someone browsing the release artifacts to see what 
stuff is expected to "work" and what stuff is still in progress; to help 
mitigate the number of pissed off users who get really excited when 
they see binding XYZ and then waste a day of coding before they discover 
that it's only half implemented and they need to start over from scratch 
(because thye don't know enough C code to help finish it)

You could put this type of info at the top of a README file for every 
binding, (afterall: every binding should really have a README describing 
what it is, how it owrks, etc...) but i would suggest that something like 
the top level STATUS file might also be a good idea to have in each 
individual binding directory.  I might even go so far as to suggest that 
the *name* of the status file should indicate (at a high level) it's 
usability, ie...

STATUS 
  .. for bindings that work and are tested and and there is an intention 
to remain back compatable moving forward. contents contain wishlist of 
features to add.

STATUS_EXPERIMENTAL
  .. for bindings that are complete, but still need vetting and the 
contracts might need changed in the future. contents should spell out 
exactly what the open concerns are as well as wishlist of future features.

STATUS_BROKEN
  .. for bindings that are so rough and in progress users shouldn't even 
try them unless they are planning on helping to write them. contents 
should list what needs to be done in order to finish and become 
"experimental"


...etc.  (the exact names could be anything, but you get the idea)


-Hoss