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
signature.asc
Description: This is a digitally signed message part
-- Mailing list: https://launchpad.net/~unity-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~unity-dev More help : https://help.launchpad.net/ListHelp
