On 19/05/2011 23:31, Peter Kümmel wrote:
On 19.05.2011 14:55, Vincent van Ravesteijn wrote:
On 19-5-2011 14:04, Richard Heck wrote:
On 05/19/2011 03:03 AM, Vincent van Ravesteijn wrote:
about the model so even my dumb brain
gets it. it was written that only maintainer is expected to
determine whats go
into-stable trunk and what does not and that we will benefit from
better review
model so i naturally wonder what does it mean.
It means exactly what it says. The maintainer will decide when to
move a
feature into trunk-stable. In the meantime a feature can mature
until it's
really finished and/or doesn't introduce bugs.
For what it's worth, my sense is that your idea is that there should be
two things that both, in some way, correspond to current trunk. Let's
call them trunk-devel and trunk-stable.
(i) trunk-devel is actually more like current trunk. People would be
asked to develop stuff in a gitbranch, but they would be free to merge
their changes into trunk-devel when they thought they were ready, much
as we do now. This is what the adventurous would be encouraged to use
for testing.
(ii) trunk-stable is really what's new; changes only go into
trunk-stable when the maintainer is convinced they are fully cooked.
One
could think of trunk-stable as intended always to be rc-quality, so
that, if we decided to release next month, the only question would be:
what is there in trunk-devel could be gotten ready by then? People who
want or need access to new features could use trunk-stable without any
real fear of instability, including instability from massive
refactorings.
The reason to develop features, etc, in gitbranches is that it makes
maintaining this kind of set-up much easier.
I think when it's put that way, it seems sensible. Am I missing
something?
You're exactly right!
I thought I did put it that way ;). But writing prose isn't my strongest
point apparently.
I also haven't understood it right before Rich explanation (but I did
not read all messages)
But this way of branching looks good to me: I simply work on a feature
branch, commit to this
branch and then push to master (like committing to trunk). The when
the feature is ready
it is already in master (because I already have push to master after
each commit)
You of course shouldn't push to master initially. The logical step by
step procedure is this:
1) You create a _local_ feature branch
git checkout -bkuemmel/my-new-feature
2) You develop _locally_ by committing into your feature branch.
<develop>
git commit -a
<develop some more>
git commit -a
...
3) When you think you are ready to publicize, you can now push your
feature branch to a new _remote_ branch that will track your local branch:
git push kuemmel/my-new-feature
Before doing that you are of course free (and encouraged) to cleanup the
local history of your branch. Note that this does not mean that your
feature is ready, only that you want to let others know about what you
are doing and maybe get some help. This is basically the same as sending
a patch to the list for comments.
4) some other people might join in the development of your feature so be
sure to pull the branch periodically:
git pull kuemmel/my-new-feature
5) develop some more, commit some more, push some more, etc
6) You feature now deserves a broader visibility, it is time to merge it
into trunk-devel. But first merge it locally and make sure everything is
OK and up to date
git checkout trunk-devel
git pull
git merge kuemmel/my-new-feature
<fix everything that needs to be fixed>
git push trunk-devel
7) Your receive a lot of feedback so you want to develop some more -> go
back to step 2
8) Your feature is ready and stable -> ask Vincent to merge it into
trunk-stable
but not in
the stable branch, where is is selected by Vincent.
But a question remains: Could I pull from master (with all the other
unfinished features)
after I've started my feature branch, wouldn't this pollute my branch
with the other
features and making the push to stable impossible?
You always develop within_your_ branch, not within master (will would be
trunk-devel in our case); so there should be no pollution at all!
Conflicts are fixed at merge time, not during development.
Abdel.
