Date: Fri, 10 Dec 2021 01:36:10 +0100 (GMT+01:00) From: Roland Illig <roland.il...@gmx.de> Message-ID: <b029a6de-3111-40be-83cc-8dbf3a917...@gmx.de>
| I guess there's really no way around running the whole build before each | commit, to reach a build success rate of 99.9 %. What I tend to do, where possible, is make a bunch of changes during the day starting from a known buildable HEAD (in my case, day does not necessarily, or even often, match daylight very closely at all, but that's irrelevant), related changes or just plain random ones, then do a release build while I sleep. If it works, then after I am properly awake, go about doing all the appropriate commits, fairly close together. Then if no-one else left the build in a broken state, cvs update everything, and start another build, just to verify it still all builds cleanly. While that happens, I can be doing whatever else needs doing, more changes for the next set, or just walking the dog... If I go for a while not making any changes, I do the cvs update and build cycle again before starting back working on the code. This handles all the "change broke everything" issues (including set list issues) but not always the "change broke my port" problems, so you also need to watch the releng buildbot stats, and if some ports stop building, go look at the logs to see if my change might have caused tha The b5 i386 build broke e-mail helps, but i386 is just one alt port. Do remember that there is very rarely and pressing urgency for changes you are making to get committed. A delay of a few days from change complete to change committed generally hurts no-one. kre ps changes to things that cannot break the build, like man page sources, TODO, CHANGES,.. and often comments, if you are fairly convinced that nothing else will care are not much helped by build testing, so that can often be ommitted. Tests however are not in that category ... not working properly can be ok, not building is not.