On Sun, 15 Jul 2012 18:38:37 -0700, Alex Rønne Petersen <[email protected]>
wrote:
On 16-07-2012 03:11, Andrei Alexandrescu wrote:
On 7/15/12 7:44 PM, Adam Wilson wrote:
I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those
five
points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)
Allow me to propose something.
Right now all dmd changes get merged in the head. Suppose we find a
volunteer in the community who is:
1. Highly motivated
2. With a good understanding of D
3. Expert with git
4. Reliable
I wonder if it's possible that that person cherry-picks commits from
HEAD into two separate branches: bugfixes and unstable. It should be
easy to create installers etc. for those.
If we see this works well and gathers steady interest, we can improve it
and make it the practice of the entire team.
Would this be possible?
Andrei
I propose a slight variation:
* master: This is the 'incoming' branch. Unstable, in-dev, etc. It's
easier this way since pull requests will usually target this branch and
build bots will test this.
* stable: This branch contains only bug fixes to existing language
features, and enhancements that do not in any way impact existing
features (or break code). Should be manually maintained based on master.
That's it. I don't see a need for any added complexity to this simple
model. Feel free to destroy as you see fit, though!
I think this would work very well. When it comes time to roll out new
features, you could just merge master into stable and you've got a brand
new stable release, tag it, build an installer, and you're done.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
