github release procedure

[foobar]

On Thursday, 3 January 2013 at 20:42:39 UTC, Johannes Pfau wrote:
> Am Thu, 03 Jan 2013 21:17:08 +0100
> schrieb "Rob T" <rob at ucora.com>:
>
>> On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei 
>> Alexandrescu wrote:
>> > On 1/3/13 1:58 PM, Walter Bright wrote:
>> >> As I suggested to Jacob, if the wiki lists git command 
>> >> sequences, it
>> >> should be complete (like a script), and not full of 
>> >> assumptions about
>> >> other commands that need to be inserted.
>> >
>> > I think this is a pertinent point - the process proposed at 
>> > github is incomplete and scantily motivated. Can the experts 
>> > make one more pass through it?
>> >
>> > Thanks,
>> >
>> > Andrei
>> 
>> I'm rather concerned when I see comments that suggest that the 
>> purpose of the staging branch was not understood in the 
>> slightest. There's a lot of discussion on the issue here 
>> http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com
>
> Sorry, but I'm not sure if we have a consensus on some things 
> discussed
> there:
> This is probably the best summary:
> http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com?page=16#post-woyboqigqbkqjxmshppn:40forum.dlang.org
>
>
> "4. Feature can than be further refined and _integration bugs_ 
> can
> be fixed by the general dev team."
>
> What's the overhead for many small feature branches? DMD work is
> probably 90% small bug fixes and 10% bigger features. So most 
> of the
> time there are no "integration bugs" and we just waste man power
> reviewing commits again and copying those into staging?
>
>
> "When the "dev" branch is considered stable enough by the team
> (exact criteria to be defined later), the changes are merged to
> the _2nd level of integration_ - the "staging" branch. This
> allows for a wider audience to test and provide real-world
> feedback."
>
> The exact criteria would be kinda important. But as we have 
> many small
> bugfixes which are merged every day I don't see how the master 
> branch
> would suddenly get more "stable".
>
>
> What I am most concerned about are the timespans discussed:
> "I propose to go for a yearly release of the
> stable branches with one year support (In the beginning)."
>
> The wiki discussion page even mentions "I don't think 4 months 
> are a
> ridiculously long time for staging if the release is made every 
> 3
> years."

Let's clarify a bunch of things here:
1. There is no overhead with maintaining many feature brunches.
2. Feature branches can be safely removed after their contents 
have been merged. This is useful for avoiding clutter.
3. There is no need to re-review the _same_ code on each branch 
it is merged to. That's just plain stupid.
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.
5. There is no problem developing bug_fixes on separate topic 
branches.
6. There is no problem merging back to master.
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.