Date: Mon, 24 Jul 2000 22:04:10 +0400 From: "Andrey A. Chernov" <ache@nagual.pp.ru> To: "Jordan K. Hubbard" <jkh@zippy.osd.bsdi.com> Cc: Warner Losh <imp@village.org>, Marcel Moolenaar <marcel@cup.hp.com>, Will Andrews <andrews@technologist.com>, Marcel Moolenaar <marcel@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc Makefile src/include Makefile src/release Makefile src/release/picobsd/build Makefile.mfs src/release/picobsd/custom Makefile.mfs src/release/picobsd/dial Makefile.mfs src/release/picobsd/install Makefile.mfs Message-ID: <20000724220410.A32323@nagual.pp.ru> In-Reply-To: <25873.964459115@localhost>; from jkh@zippy.osd.bsdi.com on Mon, Jul 24, 2000 at 10:18:35AM -0700 References: <20000724085030.A28936@nagual.pp.ru> <25873.964459115@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 24, 2000 at 10:18:35AM -0700, Jordan K. Hubbard wrote: > solutions were flawed in this whole sad chain of events. You can't > just commit something and then ignore a good week's worth of moaning > and screaming about it in various lists which you SHOULD be reading > without expecting something to happen. Don't try to create false impression of my actions. Lets re-construct real historycal things flow: 1) -L was commited, to mtree and Makefiles which undo the defaults change I do very long time ago. At this moment too many people want different mtree behaviour in some situations and attempt to fix it in different ways which are not logical and increase incompatibility with mtrees in other BSD camps. I undestand that the best way was not to change defaults but add an option instead. 2) Since I need some sleep, I note people that right at this moment they need to install mtree manually, via HEADS UP. 3) I go sleep and when wake up to commit next round of fixes, like 'make world' one, I'll see Jordan report that 'make world' broken, I already know this. 4) Next two my commits fix 'make world' on -current which is required test for changes. Remember that for -current there is no critical time bottle neck like releasing needs, etc. We have precedents of broken 'make world' for -current even for longer time. 5) The next problem is upgrading from 4.0 to -current arise which I am completely unaware and it was not self-explained from discussions or commit messages. This problem is from two parts. First part is strtofflags() which I am not responsible and next part is -L. 6) Warner fix strtofflags() problem in mtree Makefile. 7) Marcel back out my changes without even noticing me. 8) I try to communicate with Marcel and Warner to find the ways to solve this properly and Warner finally shows his good will and intention to cooperate coming with fix but not Marcel which simple ignoring this subj. after backing out. 9) Marcel comes and back out mtree -L changes too (!), continue the crude way his choose, but now this was even worse because approved by Jordan, I mean his leading position in the project which means that project now driven out of cooperation to brute force ways. 10) It is impossible to participate in such project. 11) Since it is practical conclusion and not emotional, I am very willing to return in any time when leading attitude driving project out of cooperation changed. I am very willing to communicate and discuss the best technical ways to resolve problems that arise as result of my changes too. As I already note, Warner shows good way to settle this. > Andrey basically did a hit-and-run on the tree and then declined to > participate seriously in the discussion and suggested fixes which > followed, a decision which makes any subsequent accusation of It is not true. > dysfunctional communication or attitudes somewhat surrealistic at > best. "Let he who is without sin..." While surrealistic is a true compliment, pointing back to me is poor way to argue. In any case during the project runtime I never back out someone changes in such crude way, when I back out something by mistake I restore it after discussion. > If Andrey still wants to leave the project over one comparatively > small set of changes then that's his perogative and he'll be missed. In this case not the size of changes matters, but the non-cooperative way people deals with changes, _any_ changes. > He certainly won't be leaving because of what the principals did, No, just because this reason. Marcel is relatively new and not know some things but not you. > this affair and I hope that other committers have learned a valuable > lesson about how *not* to do things from it. Yes. I think that this can happens to everyone work, if nothing changed. -- Andrey A. Chernov <ache@nagual.pp.ru> http://ache.pp.ru/ 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?20000724220410.A32323>