Date: Sat, 4 Dec 1999 11:31:09 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: "Matthew N. Dodd" <winter@jurai.net> Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern subr_bus.c Message-ID: <Pine.BSF.4.05.9912041114220.45044-100000@semuta.feral.com> In-Reply-To: <Pine.BSF.4.20.9912041353490.10542-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 4 Dec 1999, Matthew N. Dodd wrote: > On Sat, 4 Dec 1999, Matthew Jacob wrote: > > > This is a ridiculous proposition, you wanting me to spend about 500 to > > > 1000 Euro, just to make your life easier. If you can't fix typo's when > > > > No, I want folks be competent and responsible integrators. And I'll > > back this with over 20 years experience in this area. > > I don't think anyone is against clean tree build testing; its the > expectation that everyone should have to come up with the hardware to do > their own testing in a reasonable amount of time. [ Just my opinion about rational shared source development - I'm not trying to start a flame war here. There are some toolsets in the world (not open sourced) that automate a lot of this and making it less of an issue, but they're not really available to us. In larger companies, there are integration groups that do this for a living so that development engineers don't have to do this. That's not available here either. ] I mostly agree. It's unreasonable to expect everyone to be like me and spend 2-4K$/yr on FreeBSD specific h/w whether or not I have a customer to pay me to do so or not. I'm mostly concerned with kernel cleanliness- because if that doesn't work the rest of it doesn't matter. I mean, I really don't care if trek is broken today. I believe it *is* reasonable to ask the following: If you make a change to the kernel, clearly you must have compiled it and tested it yourself. Please make sure that you do a compile and test with up to date merged sources *before* the CVS commit. If, during the merge/update for the last test, somebody has changed sys/param.h and you have to rebuild completely, well, that's bad luck for you[1]. If you have all architectures supported, please do this for both architectures unless the files you change do not affect the other architecture at all. If you make a change to the kernel and do not have the other architecture to work with, please utilize the resources that FreeBSD.org has (will) provide to at least *compile* the kernel. There should be an alpha (beast.cdrom.com) up nearly all the time just for this purpose. Because this is inconveniently separate from the source you're merging/committing, doing a cvs update on beast (e.g.) and compiling there *after* you commit (post checking in this case) is reasonable. It's unreasonable to expect everyone to do a complete makeworld for single fixes in user space. However, a compile on both architectures in playplens for both of the affected source is not unreasonable. It would not be reasonable to expect every commit to be audited this way. Clearly if you're doing a batch of commits, testing/compiling after all the pieces are in is another way. In a global shared source base, windows of time while things are in transition in -current are to be expected. However, getting the test compile done before leaving for a 3 day weekend would be heartily applauded. [1]: it was this step that had me at the office until 8PM last night building a stupid entire kernel for NetBSD-sparc. Speed is so relative. After starting out with "I'm at link phase for the kernel- let's go have lunch" you'd think that watching a SS10 crawl through a kernel build would seem fast. It doesn't. > > I'd submit that a set of central systems able to handle patch-sets in a > batch manner would satisfy eveyone if turnaround could be delivered in a > reasonable amount of time (say 2 to 4 hours?). > > Does someone want to get handy with perl, formail, and procmail and create > such a beast? > > I'm fairly sure that the cvs commit checker could verify that the checkin > had an approved MD5 signature. > I would think that this could be done within a VPN for FreeBSD.org. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9912041114220.45044-100000>