[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