+1 to that. I would strongly suggest that we continue to commit to master first, like we've always done in llvm.
On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" < cfe-...@lists.llvm.org> wrote: > On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote: > > My only hesitation with this is that this requires use of cherry-pick, > > which is not idea. The way most git repositories work is to put > > everything that should go into a release branch in the release branch > > *first* and then merge the release branch to master, ensuring that > > everything going out in a release will make it into the next release. > > This is how the gitflow workflow works, for example. > > The model of "commit to oldest first" is IMO one of the most stupid > concepts I have ever seen in git "workflows". It is contrary to the way > software development works and essentially just a bad workaround for > broken cherry picks. I've seen more than one project starting to use > this model due to advocacy after deciding to use git, stumble around > with it for a release or two and then going back to a normal release > management approach. Even the argument you have presented here does not > make sense to me. Just because a change has been committed to a release > branch, doesn't mean it won't get replaced later. > > Joerg > _______________________________________________ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
