Re: [Gnumed-devel] Git and where to find production GNUmed source pending the next bug-fix release

[Karsten Hilbert]

On Tue, Jan 11, 2011 at 07:37:46PM -0800, Jim Busser wrote:

> Q1 - is each commit in Git labelled in the vcs as a "patch" and are such 
> patches all "applied" as part of the commit?

Each commit is a commit. Such commits can be exported in the
format of a "patch". Patches most often have one of several
"diff" formats.

> Q2 - I understand that in Gitorious (apart from clones) Karsten is 
> maintaining always at least two branches
> 
>       1) "master" --> bleeding edge code for both development and bug-patching
>               (maybe not labelled bug-patching when it's in master?)
> 
>       2) at least one production release branch, for bug-patching, currently 
> 0.8 branch
> 
>       http://gitorious.org/gnumed/gnumed/commits/rel-0-8-patches
> 
> … and this makes it possible that some time can elapse between a branch 
> receiving bug-fixes and when the next (bug-fix production release) gets
> 
>       tagged
>       packaged
> 
> … all correct?

Nearly.

Git contains *all* back branches under the name rel-0-x-patches. I am actively 
maintaining

a) master

        this is where active development *appears* (it does not
        *happen* there - it happens in "topic" branches in my
        local master-master)

        this eventually becomes the forking point for
        rel-<next>-patches

b) rel-<last-release>-patches

        this is where bug fixing occurs

        When a bug is found by someone in production I check
        whether I can find the bug in the branch the user is
        using. When found I go to the rel-<last-release> and
        check there. If found I fix it there. I then go to
        master and cherry-pick the fix from the back-branch.
        *Then* I decide whether to back-patch the fix to
        older branches.

c) rel-<some-older-branch>-patches

        In *some* cases it is useful to provide fixes for
        somewhat older branches (because those versions are
        included with stable long-term releases of distributions).

Before releasing either new version the version gets
*tagged* on the appropriate branch with a tag like
"rel-x-y-z" such that the exact released code can be
reaccessed easily. Such tags are signed with my private key
hence people can verify that I signed the tag.

> Q3 - during this interval, clicking the "Source tree" listing button will 
> show (along the right margin)
> 
>                       Branches:
> 
>                               master
>                               ooo
>                               rel-0-1-patches
>                               …
>                               rel-0-8-patches
> 
>                       Tags
> 
>                               TEST_STRUTS_0_02
>                               client
>                               …
>                               rel-0-1
>                               …
>                               rel-0-8-6
>                               …
> 
> and so if the vcs would get updated with fixes that get committed into branch
> 
>                               rel-0-8-patches
> 
> then it should be possible (before 0.8.7 is tagged / released) to download
> 
>                               rel-0-8-patches
> 
> as tar.gz and run (from vcs) code that already contains the bug fix patch?

I would assume that would work, yes !

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346