[Sugar-devel] R&D vs Product Support
Martin Langhoff
martin.langhoff at gmail.com
Fri Jun 18 12:25:08 EDT 2010
On Thu, Jun 17, 2010 at 6:56 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> At the same time, I'm seeing a number of very skilled Sugar hackers who
> would be more inclined to work on complex innovative projects and would
> therefore prefer a less structured approach.
>
> Long term, both approaches are essential to the evolution of a project.
...
I agree. But before we go into big debate-land...
... how about an experimental branch? Or a bunch of them?
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.
> 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.
cheers,
m
--
martin.langhoff at gmail.com
martin at laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
More information about the Sugar-devel
mailing list