cvs commit: src/sys/kern kern_kse.c
sgk at troutmask.apl.washington.edu
Thu Nov 15 12:31:25 PST 2007
On Thu, Nov 15, 2007 at 01:08:03PM -0700, Scott Long wrote:
> Robert Watson wrote:
> >On Thu, 15 Nov 2007, Julian Elischer wrote:
> >>>>"no matter how small the change, use diff + patch to move it across."
> >>>After applying the patch on your commit machine, is it too difficult
> >>>to actually retest before committing? This would catch the broken
> >>>commit before it becomes a Tinderbox issue.
> >>>Seems to be a QA problem on your part.
> >>yes.. but I can't do a compile from my mac. (my commit machine). The
> >>answer is to be rigorous about how I move the patch from the build
> >>machine to the commit machine.
> >>This is a temporary situation. new infrastructure will let me commit
> >>from my build machine again.
> >I find having a copy of Parallels (or VMWare) around very useful for
> >precisely this situation -- it means that even when I have only the Mac
> >around I can easily do a local test build. The various VM packages
> >certainly have their limitations, but they're far better than nothing.
> And to be fair, there are habitual build breakers and there are
> non-habitual build breakers. Julian, IMHO, falls mostly into the
> latter category, yet I see people focus on him disproportionally.
> Funny. Kinda. Not.
I'm not focusing on Julian. I'm focusing on the process. No one
should be committing a patch that touchs functioning code to src/
without proper testing. Moving a patch from a build machine to
a commit machine and then having to hand apply the patch is prone
More information about the cvs-all