Date: Thu, 5 Sep 1996 14:52:13 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: rkw@dataplex.net (Richard Wackerbarth) Cc: msmith@atrad.adelaide.edu.au, nate@mt.sri.com, current@freebsd.org Subject: Re: Latest Current build failure Message-ID: <199609050522.OAA09648@genesis.atrad.adelaide.edu.au> In-Reply-To: <v02140b0aae53e42aea3a@[208.2.87.4]> from "Richard Wackerbarth" at Sep 4, 96 09:25:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Richard Wackerbarth stands accused of saying: > > > >You don't have to 'modify' anything. If you want to see your plans in > >action, you should be setting up the service _in_parallel_. Just because > >you can't convert the whole community to your One True Policy instantly > >is no reason not to try it. > > Here I disagree. Unless, by policy, we eliminate the source of the problem, > we have gained nothing. Further, we neither have the collective resources, > nor avoid the confusion factor by adding another basically redundant > distribution. This paragraph is just totally beyond context, let alone content. You speak of "eliminating" some problem. I see lots of problems. None of them are going to be "eliminated" by policy changes. They may be mitigated by technology changes which will bring implicit policy with them. The FreeBSD project is (read Terry again) not policy-driven but technology-driven. Given human nature, reality and the current limits of the technology, policy simply gives named form to reality. Further, if you think that the "-recent" distribution that you're touting is redundant, why on earth do you bother? > Actually there is a minor change in that the mirrors would, in my scheme be > synced so that you could shift from one to another. *shrug* This can probably be done now. Is it important? Maybe - what is preventing you from proposing a technique for syncing them? This sounds like an excellent idea, but not one that impacts me terribly. > >Huh? Where is your test-build server? Where are your publically-released > >scripts that run 'make bootstrap;make world', and if the build fails > >restore the _entire_system_ to a previously-saved checkpoint state. > > You missed the point that that is a second phase. The users gain some from > the synchronization, but this step also prepares them for the next one. You are saying "I cannot do what I want", and then you are saying "the only things that I actually want to do are the second phase". You make no sense. > >> I cannot do "what I want". > > > >This doesn't follow from what you've just stated. The _only_ new element in > >your masterplan is the creation of the -recent thread, which as a direct > >derivative of -current, can be done by any site or sites currently > >using any of the -current update mechanisms. With access to sup/CVSup/CTM > >you can simulate reasonably accurately the master CVS repository from which > >all changes would be flowing. Then you can implement the downstream > >system(s) either with your own resources or with some volunteers. > > Poppycock! This works "by inspection". We simply have to get the > distribution sites to standardize on an already proven mechanism. "We" don't "have to" do anything. You, on the other hand, could do with trying to make your statements mean something. So far, I read you as saying : - You cannot use sup/ctm/whatever as a top-level feed to simulate the distribution process. (false) - Something works "by inspection". (What? What does "bu inspection" mean anyway?) - It is necessary to bring all of the FreeBSD distribution process under your heel. (Possibly; but not a move likely to endear you to anyone) > As for the "validation" stuff, you left out the migration path that said > that we could start by assuming that each release was OK. And now you aren't bothering to understand _me_. You can't "assume" that any state is OK. You have to take an arbitrary state, being the latest poll of the repository, and determine whether it is or is not OK. The validation process is the fundamental basis of the decision as to whether to hiccup -recent further along. (and as JDP saliently observed, this still won't help those who are Born to Lose, as they will be able to screw themselves just as well attempting to build a tree that wasn't validated on their particular system under their exact circumstances.) > The real thing that is different is that "current" would no longer exist in > quite the same way as a bunch of unsynchronized snapshots. If you are suggesting that I should not be able to track, as close as I care to chose, the bleeding edge, then you can take your neat ideas, fold them until they are all sharp corners, and attempt to pack your appendix with them from the wrong end. The current distribution system, as can be demonstrably shown, works quite well. If you want to add extra functionality to make life all the easier for those that find it difficult to deal with, that's wonderful. Suggesting, however, that your Grand Plan is so much better that it must replace everything is not going to convince anyone. > I cannot really give you anything of value until I have reworked the > distribution system. This is just total shite. I cannot possibly see you here with anything other than a childish expression insisting that nobody can play until _after_ they give you all the toys and you decide who gets what. You can produce, in pilot, a _complete_duplicate_ of the _entire_ distribution system, using exactly the same input as the real thing has. This is available to you _right_now_. > There is the "critical mass" question. Without the "help" of the > organization, this thing will never fly. The "organisation" is more than willing to help. You have Jordan offering you a blank cheque for hardware and disk space, you have the undivided attention of most of the build-process gurus and all of the core team, you almost certainly have a number of people who are more than willing to spend time helping you, and indubitably a larger number of people who, when presented with your implementation, will offer criticisms that you can benefit from. Once your system is working in pilot, you will attract people to it, and it will then develop the "critical mass" necessary to be adopted. You can't apply for a "critical mass" grant though - you have to attract it all by yourself. Yet what do you do? You stand around and whine; rapidly convincing all of us that your wonderful new build/distribution/whatever system is about as realised and likely as JMJ's all-singing tape driver. > I am unwilling to tackle such a major project by myself without official > approval. It is a case of shooting at a target that moves faster than I > can. Uhh. This point was dealt with over a week ago, and I am amazed that someone of your self-professed "professionalism" cannot possibly comprehend the response that you were given. > I've tried to explain it. All I get in reply is "You have to complete it > and show me before I will discuss it" Are you familiar with the term "pilot project"? You have been given carte blanche to go ahead with the pilot, and your current unwillingness is telling those who might be considered the project reviewers that your proposed project is no more than a vehicle for your vanity and self-importance. The only obstacles in your path are the ones that you are imagining for yourself; there are plenty of unkind conclusions that could be drawn from this, but it's probably better to be generous and just assume that you're thick. Prove Us Wrong. Please? -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609050522.OAA09648>