On 11/30/2012 04:40 AM, Robert wrote:
On Fri, 2012-11-30 at 07:31 +0100, Rob T wrote:
One quick suggestion before I call it a day, is for there to be
an "experimental branch" for the great minds behind D to play
around with (eg UDA's etc). We probably don't want experimental
stuff going directly into a branch that is destined for stable.
Unstable should be for items that are relatively finalized in
terms of design and agreement that the concept is to be
eventually incorporated into stable, i.e., moving a new feature
into unstable starts the refinement process towards a stable
release of that feature.
Totally agreed. In the development branch only already finalized things
should be merged.
Having official experimental branch(es) is a good idea. I think the
things people are working on should be easily accessible. So other
people can contribute and test the stuff. These branches should then
also be included in dpaste.dzfl.pl. Maybe a dmd-experimental project,
where people can get access to, very easily. So they can push their
branches there. It should be as easy for people to try out experimental
things as to try out things from the development branch, to get as much
early testing as possible. Automatic creation of binary releases would
also be cool.
So the workflow could be something like:
1. Document on a dedicated wiki page that you start working on feature X
or bug fix Y.
2. Get started on a private/semipublic feature branch.
3. As soon as you got something push it to dmd-experimental
4. Continue to work and improve things there
5. Experimental branches are considered for inclusion in devel.
I think you would end up targeting experimental to prevent clashes with
other stuff that has also yet to be merged. From what I see, whatever
you call it, upstream should remain upstream. Maybe its a good Idea,
but I would consider that out of our hands.
A Testing branch that new features are pulled to after inclusion in
upstream would be nice, and allow Testing to handle it's own releases
and have it's own guarantees. That would enable the short term releases
and early testing. But I do not want to interfere with devel.
6. Things are tested in an integrated way in devel, with binary releases
every two months or so. (Much like we have now)
7. At predefined intervals you branch of a release branch and stabilize
things further.
8. Release branch is merged in dmd-stable/master
Someone posted this, as why not to use feature branches:
http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be
Fixin to sleep, I'll watch it in the morning and respond.
I personally don't think that feature branches are the problem, but more
a lack of communication. If people work on the same stuff you get merge
conflicts, that is granted, so you should know on what people are
working before starting to work. A wiki page where you add a link to
your feature branch and what you are currently working on and
dmd-experimental could help in this regard.
This is a a question for Walter et al to answer.
I don't think we should define their workflow, In fact I'd prefer that
the devel remain completely under Walter's domain. Testing branch could
be useful, though.
