Next focus: PROCESS

[Dmitry Olshansky]

12/13/2012 12:13 AM, deadalnix пишет:
> Let me do some proposal. If people are happy with them, I can start some
> wikification.
>
> First here are the branch already existing :
>
> dev : development branch. It is used to merge new features.
> master : is the branch where the next version is stabilized (right now,
> 2.061). It receive only bug fix. eventually new features if the feature
> is of strategic importance.
> 2.60 : contains the current released version of D + bug fix.
>
> Release process :
>
> When branch 2.60 have enoug bug fixes to justify a new release, a tag is
> created (2.60.N+1). The amount and the importance of corrected bugs will
> dictate when the release is done?
>
> When master is stabilized enough, a new version of D can be released. A
> new branch s created from master, named 2.61 and a tag 2.61.0 is created :
>
> git checkout master
> git branch 2.61
> git checkout 2.61
> git tag 2.61.0
>
> Then, the dev version is merged into master and a new stabilization
> process begin :
> git checkout master
> git merge dev
>
> At some point, 2.60 will not receive any more bug fix, and will be
> considered very stable, or dead, depending on one's standard (both are
> kind of the same).
>
> I advice against maintaining a log of 2.XXX branches, as too much choice
> is as bad as no choice for the user, and it is no better for us. 2 is
> IMO the right amount.
>
> NB: I have chosen the 3 number system for branches names, this is up to
> debate, but as it is widely used in programming languages it is a good
> base. Anyway, let's not debate the name for too long, as it really don't
> matter, and concentrate on the workflow.

So far me likes.
>
> On Wednesday, 12 December 2012 at 16:14:44 UTC, Andrei Alexandrescu wrote:
>> Beyond that we need to have a wiki page with workflows:
>>
>> "To initiate a new feature"
>>
>
> A new feature is developed in its own branch. The reference is the dev
> branch. In git it goes as follow :
>
> git checkout dev
> git branch featureName
>
> Development of the feature.
>
> You can work on many feature at the same time; each one in its own
> branch. You initiate them the same way and switch from one another with
> git checkout.
>
> Before submitting a feature, it has to be reabsed as follow :
>
> git checkout featureName
> git rebase dev
>

Just make sure your local dev is always in sync with upstream!

Or rather add an 'upstream' remote as 
github.com/D-Programming-Language/phobos.git (dmd, druntime etc.) and 
always do:

git pull --rebase upstream dev
git push --force origin featureName

before submitting pull via github.

> When the feature is ready to inclusion into dev, the dev can make a pull
> request.
>
>> "To initiate a bug fix"
>>
>
> The same as for new feature, except that you start from the branch the
> bug is in. If the bug is in several branches, then the most stable one
> is choosen, as i is usually easier to bubble up the bugfix from a stable
> branch to dev than the other way around.
>
>> "To initiate a library addition without formal review"
>>
>> "To initiate a library addition with formal review"
>>
>> ...
>>
>
> I don't really know what to do here. I guess bug fixes on the library
> can be done the same way, but something specific probably have to be
> done with new modules.
>
>> All of these should be subsections in the documentation.
>>
>> "If your branch has conflicts"
>>
>
> If your branch has conflict, it is up to you to resolve them. The
> conflict will most likely occurs when rebasing. In such case, git status
> will inform you on which files are impacted. Edit the file to resolve
> the conflict and do git add file, then git rebase --continue .
>
> If you don't want to resolve the conflict now, you can abort the rebase
> by doing git rebase --abort
>
>> "If your branch became really messed up"
>>
>
> Well this one is difficult, because it is unclear what is wrong, so
> unclear ho to solve it.

I find it to be 'git reset' to some early point, stash changes, fast 
forward from the upstream version to the head of current branch and 
stash pop your local changes.

But it really depends on symptoms and what the end result should be 
discard changes?, save changes elsewhere but restore to something 
stable? which branch is messed up? It's an infinite list of questions.

> Is that good ?

I think it's good.

But personally I'd expect:

* master to be what you define as dev, because e.g. GitHub puts master 
as default target branch when making pull requests. Yeah, I know it's 
their quirk that it's easy to miss. Still leaving less burden to check 
the branch label for both reviewers and pull authors is a net gain.

* And what you describe as master (it's a snapshot or a pre-release to 
me) to be named e.g. staging.

And we can as well drop the dead branch 'dev' then.
-- 
Dmitry Olshansky