On 04/15/15 10:15, Jordan Justen wrote: > On 2015-04-10 02:14:01, Zeng, Star wrote: >> Laszlo, >> >> Try to update codebase to SVN R17161 for your build failure. Sorry >> for the inconvenience. > > Star, Bob, why was it committed without giving edk2-devel a chance to > review it? The same might be said of 17161, but in the case of a build > break, maybe a shortcut is more acceptable. > > Mike, do you have any thoughts about why this seems to happen so > often? > > Bob, my feedback is that the commit message seems to indicate that > this one commit is doing several things. So often that leads to > difficulties if issues arise. I'm not sure how long Laszlo spent > investigating this, but with 'one big change' like this it can often > increase the debug time substantially.
Gerd's continuous integration repo / Jenkins instance at <https://www.kraxel.org/repos/jenkins/edk2/> tends to catch build errors very quickly, and it sends an email to Gerd and myself. Sometimes the build error is caused by one of our downstream patches not applying any longer, but it also catches genuine (upstream) build problems. I got lucky this time with the repro & analysis. The former only took a local build, and the #error directive (and its context) were quite helpful in the analysis, as far as I remember. Posting all patches to the list (and splitting them up better) would be important in general, but it would also greatly help if Intel operated an in-house build farm where developers could submit builds in some form. Minimally, all "popular" DSCs / platforms should be built, with all (or most) of the supported toolchains. I'll also use the opportunity to plug git again -- one *really* has no chance at splitting up patches nicely without git. It is simply impossible. The way I develop new code with git is as follows (I'm sure quite a few people share the same method): Let's assume that I mostly understand what I want to develop, ie. I have some clear-ish design or set of requirements in my mind. First, I write the new code. Most of the time I *attempt* to write the code in logical stages right off the bat (ie. try to break it up into logical patches). Most of the time, I *fail* at that, and the git commit history either becomes a string of not extremely logically split up patches (that might not all build, even), or just ends up a few mammoth patches (basically, brain dumps). Assuming it works and passes my tests, I move to the second phase -- work the code into a series of patches that: - is logically structured - helps reviewers review in bite-sized chunks - is bisectable (builds at every stage) - still passes tests at the end The second phase has the following characteristics: - it is no less time consuming than the first phase (ie raw development) - it forces the developer to think about the code in layers; it takes a conscious, dedicated effort - it is *impossible* to do without git. There's a number of "git tricks" one has to learn, but then productivity skyrockets (compared to that person's own prior productivity). Here's the list of commands I most frequently use: - "git rebase -i": obviously - "git checkout -b": sometimes it really helps to explore or stash ideas on another branch - "git cherry-pick" -- steal individual patches from those side branches - "git add -p" -- stage individual hunks for a commit from a larger edit - "git notes edit" -- track vN -> v(N+1) changes per-patch, for a resubmit, without cluttering the commit log - "git checkout -p COMMIT -- path1 path2 ... pathn" -- this command is incredibly useful for splitting up patches during a rebase. It allows one to bring in (ie. stage) the state of the tree at some other (later) commit, hunk-wise, and commit those hunks as a separate patch. - "gitk", for reviewing the series from a distance, and for fetching commit IDs easily. - "git log" and "git blame" to figure out what patch some questionable code belongs to, so that I can fix it up in the right patch during the next rebase. I also have a small (trivial) script that checks out patches on a branch in succession, and builds the tree at each (and also lets me test it if I want to). The second phase takes conscious dedication, and it has two goals: help others understand the code (which is a first class goal, at least where reviews are enforced), and help finding bugs later on via bisection. If those aren't goals, then there's no reason to do it. If they *are* goals however, then it still takes "git" to achieve them. ... Okay, I'll step off my soapbox, thanks for your patience. Thanks Laszlo ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
