Date: Tue, 31 Oct 1995 12:30:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dyson@freefall.freebsd.org (John Dyson) Cc: jdl@chromatic.com, terry@lambert.org, current@freebsd.org Subject: Re: *MORE* FS problems, please fix! Message-ID: <199510311930.MAA10342@phaeton.artisoft.com> In-Reply-To: <199510310456.UAA13740@freefall.freebsd.org> from "John Dyson" at Oct 30, 95 08:56:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Well, if I can't get patches committed, the least I can do is > > > complain about problems and hope someone else can get their possibly > > > identical patches committed instead. > > > > > > ... > > > > > > Whoever reimplements this change (my patches aren't "good enough") > > > should note that it will be about as large in scope as the patches > > > I already submitted for FS layering. This means that you probably > > > don't stand a chance of success unless you have commit priviledges. > > > Such bitterness is not appropriate or called for. Any changes > that are based upon Terrys' work will give him credit -- even if > they are not identical!!! There is lots of stuff going on right now > and I want to review the stuff before committing it. For the first two years > that I was on the FreeBSD team, I did not commit any code at all. Everything > was subject to review, in fact I demanded it -- and grossly overloaded > David in the process. The "bitterness" was conditional on the elided text. The phrasing of the parenthetical expression was intentional: it was meant to convey the point that if the patches were not "good enough" per the elided text's usage of the phrase, that something similar would have to be implemented anyway. Certainly eliding the text makes me seem more frustrated than I am. > > Wait. I don't get it. I've been using FreeBSD for a solid year. > > I've been watching this list for just under a year. I've personally > > noted that almost everything Terry has said has had some kernel of > > truth to it even if he had to argue his point *again* and *again*. > > And maybe some of it was tainted with personal agenda occasionally, > > but we all do that to a certain extent. > > Terry does have some very interesting ideas -- and sometimes I enjoy > reading his discussions. Since one person on the team had problems > testing the specific changes in question, I would like to verify and > check them out. If I don't David would!!! Note that even though I > respect him (and others on the team do also), sometimes various > people don't always agree with his positions. That is okay though, > David doesn't always agree with mine also!!! Paul was already doing this, at least at one time, thoguh it has several times gotten to the point of a one parenthesis or otherwise obvious change causing the full patch set to be rejected. I think that the correction of such minor things, especially if the review process is to be protracted as it has always been in the past, should not require rejecting the full patch set to the author. With -current, there is no hope of a patch set not based on the idea of a CVS merge being "correct" when it touches the system call interfaces and all of the underlying file systems. The addition of interfaces in the time between the production of the first set of patches and their "review" is what caused the initial failures. The reordering of read-only-file system rejection (actually, I think the reordering pushing it below the FS layer was correct: for union FS's, a union may comprise a RO FS and one or more RW FS's) was the reason for the second rejections. Part of the problem is that I can't run -current localy if I expect to be able to spend time coding instead of catching up. Probably the correct thing to do would be to have taken the patches vs. the revision tags, temporarily tagged a vendor branch, cvs ci'd the patched files into the branch, and merged the branch into the main line code. Either I'm considered responsible for checking in, or I'm considered responsible for keeping in sync with -current, but I can't do both. Part of my annoyance is that there is a 6-7 file threshold (easily overwhelmed by interface change patches like mine) after which it is impossible to keep -current with the update lag given the other activity in the tree. So I'm prepared to abdicate keeping up with -current in favor of allowing someone with commit privs to roll the changes forward in keeping with other peoples concurrent work in the affected areas. Before anyone goes off on a tear, this means I'm not willing to keep patches current over another six week period wherein they are constantly going out of date because of changes that don't undergo the same level of scrutiny. This doesn't mean that I won't keep hacking code, but it does mean that some of the stuff I do will be on a take-it-or-leave-it basis, and I don't care which you do. Instead, I'll probably concentrate on making sure the patches are applicable to any BSD 4.4 derived source base so that someone will use them somewhere. > It looks like the patches might be out-of-date, but they are still > interesting. It is impossible for patches to more than 3-4 files simultaneously to be anything *BUT* "out of date" without a CVS merge facility. I've been fighting a losing battle with demands that the patches apply cleanly to "this hours -current" when the revision tags should have been sufficient to "cvs merge" them in with a hell of a lot less effort than I've been expending. > > Am I missing something fundamental? I don't think should piss > > Terry off and have him leave the FreeBSD project in a huff. It > > I don't want to "piss" Terry off either, but I haven't included > any structural changes without peer-review, and I am not likely > to either. You would not believe DG's and my phone bills. Mine > has been as high as $600/mo talking to DG!!! Not because DG is > "better" than me or more "experienced" than me (he isn't, he is > different than me and can spend more time thinking about architectural > issues than I can sometimes), but I do talk to him ALOT, keeping him > up-to-date on proposed changes. I'm not pissed off. I'm just frustrated with a process that makes large scale contributions almost impossible to achieve for anyone without direct commit priviledges, through no lack of desire on my part. That's all. I'm not asking for commit priviledges, I'm asking for process change for patches from people without commit priviledges.. > > just wkouldn't be right. So where are the negative vibes coming > > from, Moriarty? > > I think the problem is with mis-communication and mis-understanding > on the part of the parties involved. IT will work out, because the > parties do have the best intentions. I've been chasing -current for six weeks now to get changes in that I require for additional work, which don't change the functionality directly, and which put the code in line with the FS design documents at ftp.cs.ucla.edu. I'm not going to hold additional work another six weeks. I agree with David, that it will work out one way or another; no one's intentions are in question. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510311930.MAA10342>