github release procedure

[Johannes Pfau]

Am Fri, 04 Jan 2013 00:40:03 +0100
schrieb "foobar" <foo at bar.com>:
> 
> Let's clarify a bunch of things here:
> 1. There is no overhead with maintaining many feature brunches.
I didn't mean the overhead of the branches itself. I meant the overhead
of merging those first into master. Then later determining if master is
stable (how?) and then merging into staging. The wiki says this is
useful to allow fixing integration bugs. I think with mostly bugfixes
there won't be many integration bugs. And merging into staging always
requires someone to do it, which is imho overhead (regarding "human
resources", not technical).

> 2. Feature branches can be safely removed after their contents 
> have been merged. This is useful for avoiding clutter.
sure
> 3. There is no need to re-review the _same_ code on each branch 
> it is merged to. That's just plain stupid.
Well, the wiki says things are merged into staging if they are
considered sufficiently stable. Who determines what is stable and how?

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

Sure, this is why I said mixing cherry picking and merging is not a
good idea. As long as you only cherry pick into a branch and never
merge into that branch or merge it back there is no issue.

I missed the detail that you suppose basing bugfix branches on the
oldest applicable release branch. That should be made very clear in the
wiki.

I just think that this process is counter-productive for dmd as most
changes are bugfixes and regressions are caused by bug fixes as well.
Applying _every_ bugfix in older releases has a high risk of
reintroducing regressions (and / or breaking user code. If the compiler
didn't enforce const in some situations, fixing it is a bug fix. But
fixing it will break user code - so you have a 2.061 that works for
users and a 2.061.1 which breaks code).

It makes more sense to me to only fix regressions that were introduced
with the base release. So 2.061.1 would only fix regressions introduced
in 2.061. (This can still be done by basing that fix on the latest
applicable version and merging back into master / staging).

Also the lowest applicable version for most dmd bugs is probably 2.01.
So if we start this process now, we'll still be fixing bugs in 2.061 in
10 years, then merging into 2.062, 2.063.... Here "lowest _supported_
applicable version" makes more sense imho, where supported needs to be
defined (e.g. 2 releases). This is not a big problem if we only talk
about regressions, but I'd still prefer "lowest _supported_ applicable
version"

> 5. There is no problem developing bug_fixes on separate topic 
> branches.
As we already do.
> 6. There is no problem merging back to master.
As long as there are no cherry picked commits into that branch. AFAIK
we have already cherry picked commits from master into staging. Then
merging staging back into master is not good - It will probably work
but as you said cherry picking duplicates commits and we'll therefore
merge identical changes with different ids.

We should probably delete staging and start again as soon as the
workflow is clear to everyone.

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

I don't have common wisdom from cvs/svn ;-)
Merges are not that easy if you want to merge only a single commit or
skip certain commits. Although you can tell merge to skip commits it's
in no way easy. http://stackoverflow.com/a/729723/471401

It's  probably best to not get into this situation. The workflow
described on the wiki can indeed work well without cherry picking.

But what was done till 2.061 was basing bug fixes on the master branch.
If you want to get these into a release branch without features, etc
cherry-picking is way easier than merging.