Dear OE folks,
it is great that the minutes of the meetings get published. Thank you. Am Donnerstag, den 24.02.2011, 09:20 -0700 schrieb Tom Rini: […] > Not clear in the summary but from the logs is that we want to, as part > of making this be transparent, publish guidelines for how this will > work, based on what poky is doing now. The high level plan is to follow > the contrib tree model that poky has which means sending pull requests > (which in turn also post the patches to the ML for review). > > For changes that don't have a tree to pull from, someone with write > access would need to pick them up. XBMC is using also an approach with pull requests. The Linux kernel is doing that also. Is there documentation on how pull requests, merges and bisecting works together? My problem is that pull requests are based on a certain commit in origin/master. After the request is sent most of the time several commits are pushed to origin/master in the mean time, so a merge is necessary “polluting” the commit history. With my current knowledge I find it very difficult to track down bad commits especially if commits break the builds in between. Does `git bisect` take care of that itself? How do the Linux developers deal with that problem, especially merge conflicts? Currently I like rebasing (fast fowarding) very much, but that puts strain on developers too because they always need to update their patches/commit to latest master. Thanks, Paul
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
