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" <[email protected]>:
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/[email protected]
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/[email protected]?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.
