[Geany-devel] Plan ahead (to fail to plan is to plan to fail)

[Colomban Wendling]

Le 03/10/2011 18:20, Jiří Techet a écrit :
> On Mon, Oct 3, 2011 at 17:29, Colomban Wendling
> <lists.ban at herbesfolles.org> wrote:
>> Le 03/10/2011 06:15, Lex Trotman a écrit :
>>> [...]
>>
>> Agreed with the strong branching scheme,
>> http://nvie.com/posts/a-successful-git-branching-model/ feels good to me.
> 
> I just went through the blog post and I must say I disagree with more
> things than I agree:
> 
> 1. The split between master and develop is completely unnecessary. I
> don't see a reason why there should be a separate branch for releases
> (i.e. commits with tags). The post says that a merge to master is a
> release by definition. I prefer to do things the way everyone else
> does them - a commit with a tag is a release by definition. Moreover,
> everyone expects master is the trunk so I can imagine people will be
> really confused when they clone a repository and build Geany from
> sources because master in the above model is a dead space between
> releases.

Agreed, totally.  It's not like Git is expected to be the primary source
for people wanting the release, in which case making it the default
would maybe make sense.

> 2. I agree with non-fast-forward merges of feature branches. These
> branches however have to be real feature branches where work
> concentrates on implementing a single feature (e.g. GTK 3 support).
> For instance I have a branch for_review with random bugfixes and minor
> features which shouldn't be treated as a feature branch and which can
> even be rebased on top of master (If you have a look at GTK, you see
> only a small number of merges - with bugfix-like commits there's very
> small danger that someone else bases work on them.)

Yeah, agreed too.  What I like in the blog post's workflow is that
*every* single feature gets its own incubation branch, not only "big"
ones.  This cleans up "master" state, and makes reading the history easier.

> 3. I wouldn't make release branches before the actual release - I
> think having releases directly on master is just fine. This means some
> slowdown in development but individual developers will have their
> feature branches where they can continue working and which will be
> merged to master after the release anyway. Geany isn't a project with
> such a wild development it should cause any trouble. Maintenance
> branch for a dot release can be created immediately after the release
> commit before post-release version increment.

Not completely sure.  Actually during 0.21's freeze, Nick created the
unstable branch and worked on it.  OK, with a DVCS he could've created a
local one (I do have one myself) and rebased it later, but OTOH, it
prevents his changes from being seen by others.

But one can also argue that if the development branch isn't the release,
the release don't get as much attention as it should...

So I don't have a strong opinion on this, both seems OK to me, yours is
more wide spread.

> 4. Hotfix branches: if a fix is a single commit, it can be directly
> applied to master and cherry-picked to maintenance branch. If the fix
> is more of a feature-branch nature, the feature branch for the fix can
> be created and once finished, it can be merged both to master and to
> the maintenance branch.

Agreed.

> This means the workflow I suggest is very similar to the present
> workflow; actually I believe it's the workflow used by most projects
> and the most common-sense one. I'm afraid I'd get quickly lost in the
> workflow suggested by the blog post and I don't see real benefit for
> Geany with such a workflow.

Actually, I agree with barely all you points, but the difference seems
to be I don't see this as being so different than the blog's post --
maybe because I basically read it as "ideas" rather than bible... my bad
for not having been more careful when I said it, thanks to you for
having reacted and argued :)

Basically the idea I like is that *every* feature incubates in its
branch, not only "big" ones.

Anyway we'd have to write a hacking doc on the way to use the repo, so
we can amend it the way we want :)


Cheers,
Colomban