github release procedure

[Russel Winder]

On Fri, 2013-01-04 at 00:40 +0100, foobar wrote:
[…]
> Let's clarify a bunch of things here:
> 1. There is no overhead with maintaining many feature brunches.

Which is why Git is superior to Mercurial for the sort of process going
on here.

> 2. Feature branches can be safely removed after their contents 
> have been merged. This is useful for avoiding clutter.

See above :-)

> 3. There is no need to re-review the _same_ code on each branch 
> it is merged to. That's just plain stupid.

I am not so sure on this. A changeset in a different context is a
different changeset, which is why Mercurial is the way it is and why it
has some benefits overf Git.  The effect of a code change in one branch
is not necessarily the same as the effect of the same change in a
different branch. However review is not the right tool here, CI is. Each
and every branch in the mainline must have a CI listener that runs all
the code on every commit.

Branches in the mainline are CVCS thinking, not wrong, but must be
treated as an integral part of the project, hence the CI requirement.
Branches held in forks of the mainline have no such requirement, but
people should run all the tests after each commit as a matter of
professionalism. Others can of course pull these feature branches into
their own fork repository for working on. This is the DVCS way.
Eventually of course commit to the mainline is required otherwise a
project fork has been made.

> 4. Chery picking is a HORRIBLE idea for managing releases and 
> should only be used on development. Chery-picking COPIES commits 
> and thus loses the connections in the history graph.

Agreed.

> 5. There is no problem developing bug_fixes on separate topic 
> branches.

See 1 above. Git makes this trivially easy.

> 6. There is no problem merging back to master.

See 1 above. Git makes this trivially easy.

> 7. Let me say this again. Merges are cheap and easy in git. So 
> are re-merges. Avoiding merges is an artifact of client-server 
> designs such as SVN and is NOT compatible with Git's conceptual 
> model.

It is important to note that Mercurial has different properties again,
so leads to different workflow. Given the choice has been Git then Git
workflows apply.

Every developer should be keeping master as a mirror of the mainline
master and working on feature branches. When a changeset is accepted
after review, the committer commits to the mainline and then everyone
can pull and garbage collect, and in the process delete the feature
branch they have.

I tend to fork the mainline repository locally and also on GitHub and
then manually link my two forks. This means "git pull" locally pulls all
branches from the mainline repository. I work on feature branches pushed
to my GitHub fork, people can then pull them as they wish. You have to
remember to fetch from all the remote branches you are tracking. I can
then make a pull request on my GitHub fork and still continue to track
the mainline locally.

> I suggest to read about how git works and how best to utilize its 
> features, and NOT apply common wisdom from CVS/SVN/RCS which are 
> based on a _completely different_ conceptual model.

Indeed.

Star model has a role in DVCS, the mainline repository is the mainline
from which all else stems. But not all traffic has to be routed through
it with Git. People can share feature branches between themselves to
collaborate to create a pull request without ever having to use the
mainline. That is the whole point.

It means that the mainline committer role is not to do all the
development work, but is to coordinate and mentor activity which they
then review and when happy merge into mainline.

No-one should ever be doing development on master.

No-one should ever push to mainline without someone at least knowing
they are about to do it and have previously checked the work.

No mainline repository should ever be without a full CI.

http://d.puremagic.com/test-results/

Looks like part of a solution.  It should also provides artefacts for
download and install as nightly releases.  It assumes there is only
master in the repository. If there are any other branches in the
mainline repository then where are the CIs for those?

In my clone of DMD I see master, staging, dmd-1.x branches. Given DMD is
a single branch development, I don't see a need for staging. I shall
have to go through all the email to find the rationale, unless someone
has a short paragraph rationale.

What I find really bizarre is that the tags v2.061 and v1.076 are on
branches other than master. To me the whole Git history looks a mess,
essentially broken. I suggest some serious rebasing and merging to make
the history consistent with the version numbering.

The questions to ask:

If I want to create a feature branch, which branch do I use as a base?

Is staging just the 2.x maintenance branch?

When do changes on master make it to staging?

Should staging and dmd-1.x branch HEADS be moved forwards on the branch?

Sorry if this is all answered somewhere, just point me at the URL where
the answers are explained.  

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130104/a07074a5/attachment-0001.pgp>