[Sugar-devel] R&D vs Product Support

Bernie Innocenti bernie at codewiz.org
Sat Jun 19 11:17:20 EDT 2010


El Fri, 18-06-2010 a las 12:25 -0400, Martin Langhoff escribió: 
>     ... how about an experimental branch? Or a bunch of them?

This is what I like about Gitorious: it nicely gives anyone the ability
to quickly create a branch and publish it. No authorizations needed.

What we're missing now is a well maintained integration tree to test and
showcase multiple experimental projects. Michael Stone's sugar tree
resembles this, but I'd like to see this work showcased alongside the
stable trees.


> Clearly, some people want to take on approaches that others (for
> example myself) consider risky, and that are only worthwhile if
> someone can show that they have a clear, tangible return.
>
> I like how Junio manages git -- in simplified summary:
> 
>  - Many branches, one per experimental project.
> 
>  - They get merged to "pu" ("proposed updates") -- pu is torn down and
> "remade"/"remerged" frequently (git-rerere remembers the conflict
> resolutions to ease the pain here).
>
>  - Experimental projects that show clear benefits, don't break toys or
> APIs graduate to 'master', where they get merged and become part of
> the "final" project history. Both the experimental branches and "pu"
> are a drafting space.
> 
>  - 'master' is from where new releases are made.
>
> Doing this for every new thing is too costly and cumbersome. But is
> really good for experimental code.

Your example helps debunking the notion that a stable trunk slows down
development, as git evolved really fast over the past two years.

Stability is also great: I always use a version of git built from the
master branch and I never had a problem with it.


> > Despite being used in production for ~2 years, Sugar still has many
> > traits of a half-finished prototype
> 
> Completely agreed. I want to find a way out of that particular conundrum.
> 
> And at the same time, not stop anyone from doing potentially
> revolutionary work. Truth is: most revolutionary changes don't pan out
> (or cost 100x than initially expected). We want to find that out,
> before they reach master.

I'm also with you.

Next step would be finding someone who would like to manage this new
integration tree to aggregate experimental work. Any volunteers?

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/





More information about the Sugar-devel mailing list