unity-dev team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Mon, 2013-01-07 at 18:12 +0000, Mark Shuttleworth wrote:
> On 01/07/2013 02:09 PM, Ted Gould wrote:
> 
> > 
> > The problem is that we're not talking about released versions, which
> > certainly should manage their API/ABI with proper SO numbers etc,
> > we're talking about development trunk.  We've removed the ability to
> > have a playground before committing to an API that developers are
> > committing to.  We can't expect merging to trunk to be a long term
> > commitment to API or ABI stability.  Doing a release is saying "this
> > is baked" and we'll commit to it, proposing a merge is not.
> 
> 
> Hacking APIs ad-hoc is a recipe for changes release-to-release that
> feel uncoordinated, unplanned, badly designed and frustrating. If we
> are not conscious and deliberate about small changes, how can we
> possibly be conscious, deliberate and designed at a macro
> release-to-release level?


I think that we're talking about different things here.  I'm not saying
"throw it at the wall and see what sticks."  What I am saying is that a
group of people working together needs a place to share ideas without
committing to every point forever.

Let's use the example of a group of 10 developers working on a library
for a development cycle to add a certain set of features.  Through out
those days of development ideas will need to be proposed, rebuffed,
rethought and perhaps reorganized.  If every time one of the developers
wants to share with the group she is required to be committing to an
API, we introduce friction to the sharing of ideas.  Sometimes things
are good enough to unblock someone else on the team, even though
additional work needs to be done.  We've all made commits that includes
a few TODO comments in it.

We could, quite easily, say that the development of this team happens on
a separate integration branch and then when the team has completed their
development cycle it gets committed to trunk as a single revision.  But
then, what have we gained?  We've specified our goals as getting
feedback as quickly as possible from all contributors, and the
integration branch effectively removes the development team from getting
that feedback until they've completed the entire task.

If we do want the feedback as quickly as possible, we have to assume
that there will be some incomplete ideas included and deal with the
repercussions of those incomplete ideas being published.  Perhaps we
need to have different policies on how we release libraries and other
projects.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part