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

[Jiří Techet]

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 :
>> Hi All,
>>
>> Now we have 0.21 released I thought it was worthwhile looking at the
>> path ahead, and since we have the possibility of some quite
>> significant changes, maybe starting a plan of attack so that not too
>> much effort is wasted.
>>
>> The big things I see right now that have had some work are:
>>
>> 1. change to DVCS and hosting, and possible changes to process that
>> forces/enables (to my mind the process issues are more important than
>> the DVCS itself)
>
> Yep -- though I think I'm missing something ti your sentence... I don't
> get the meaning of "and possible changes to process that forces/enables"
>
>> 2. change to Glade 3 (entails GTK change)
>>
>> 3. support for GTK3 (needs above and might entail a further GTK change)
>>
>> 4. support for plugins in non-C, non-compiled languages (as full
>> plugins, and the VM/interpretor as a plugin itself so core doesn't
>> need to be changed to add more languages)
>>
>> 5. session support (has been sitting in a branch for a while)
>>
>> 6. patches in the queue (some are getting a bit old)
>>
>> 7. bugfixes
>
> Seems reasonable as future plans, not sure all would fit in a single
> release... well, we'll see how fast things goes anyway :)
>
>>
>> 8. call it 1.0
>
> Or 1.22, it's what is in SVN now.
>
>> roughly from the most disruptive to least disruptive.
>>
>> Then there are all the bright new things that will inevitably come up :)
>>
>> My main suggestion is that it would be best to do the change to the
>> VCS first, then it won't disrupt the other things.  And get the
>> process bedded down (stable branch, develop branch, version branches
>> ...) and call that 1.0.
>
> 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.

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.)

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.

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.

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.

Cheers,
Jiri