Date: Sat, 10 Jan 1998 14:24:54 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Alex Nash <nash@mcs.net> Cc: kong@kkk.ml.org, Studded@dal.net, current@freebsd.org, thyerm@camtech.net.au Subject: Re: Firewall in kernel? - Found it! Message-ID: <XFMail.980110142454.shimon@simon-shapiro.org> In-Reply-To: <199801101711.LAA07393@nash.pr.mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-Jan-98 Alex Nash wrote:
... Very interesting and convincing detailes ommited ///
> Executive summary: We're all working for free towards a common goal,
> let's not take people to task publically without knowing all the facts.
Working for free, maybe. Taking to task publicly, I do not feel I have
done that. If I did, I apologize.
It does seem that we have, as of late, a situation where submitted patches
do not even compile. This particular one is not the first, but maybe for
some of us, one too many.
There can, logically, be only two explanations for this trend:
a. People make changes, compile them locally, and submit the change
without verifying the change's impact on the rest of the system.
b. The process is flawed and allows for patches that are flawed to appear
correct.
I belive the truth to be a combination of the two. I belive the process is
flawed in places and I also witnessed patches being cheked in that are
clearly broken.
Having done somewhat of work in this area over the years, I belive there is
a satisfactory solution to this, but it is not an easy, nor simple one.
As a short-term solution, here is what I suggest:
a. All checked-in patches must be make in this manner:
1. Update your source tree via agreed, singular method (reduces race
conditions) to the moment.
I do that by running cvsup late at night, several times, until I
get ZERO changes.
2. Apply your patches to that fresh, new tree.
3. run ``make buildworld''. no need to re-install your machine - All
we are after here is a clean compile, not correct behavior.
4. cd /usr/src (or wherever your clean, just correctly built tree is)
5. cvs diff -c -N > ../my_patch
6. cvs commit...
Alternatively, consider serializing and checkpointing the process;
All diffs are sent to a central authority. There they are applied to a
master tree, compiled and then released to the commit tree. This cycle can
be automated and run once or twice a day. I'll be happy to help in this
matter.
The true solution is really much more complex and requires some serious
engineering. If I get interested response and the time, it may be an
interesting pilot project for a distributed database.
----------
Sincerely Yours,
Simon Shapiro
Shimon@Simon-Shapiro.ORG Voice: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980110142454.shimon>