I've never seen this actually add value before. All it does is shift where things break. We're not having cross-pull request conflicts. We're having simple "it doesn't work" breakage. Whether that shows up on a build from the trunk or an integration branch, the bottom line is it's broken and it causes work to revert them.
I'm not opposed to trying it, but I don't really have the extra time to invest in a project I see as being not-useful. I encourage those that do to do so though since I could easily be wrong. It wouldn't be the first time. Later, Brad On 6/3/2011 8:44 AM, Andrei Alexandrescu wrote: > Sounds like a reasonable approach to me. Recent experience indicates that > even if the pull request author tests on one > platform, it can't be expected the code will work for all. > > Brad? > > Andrei > > On 6/3/11 10:08 AM, Martin Nowak wrote: >> With the recent inflation of merging pull requests and reverting them I >> wonder if it would >> make sense to use integration branches. >> >> The proposed workflow would be. >> >> - merge pull request to integration branch of dmd/druntime/phobos, i.e. >> multiple merges >> are stashed into the same branch >> - if auto testing or something else fails revert merge and discuss >> follow ups on github >> - after everything is sorted out merge the complete pull request into >> master >> - from time to time the integration branch needs to be synced with master >> most likely when not too much pulls are merged into it >> >> That way pull requests can stay open until being functional and merged >> to master. >> The maintenance overhead should be fairly low. >> The auto tester would need to test two sources and sometimes one needs >> to reset the integration branch. >> >> martin _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
