Date: Wed, 4 Sep 1996 21:25:36 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: nate@mt.sri.com, current@freebsd.org Subject: Re: Latest Current build failure Message-ID: <v02140b0aae53e42aea3a@[208.2.87.4]>
next in thread | raw e-mail | index | archive | help
>Richard Wackerbarth stands accused of saying: >> >> Not in this case. This involves a policy change for the distribution >> of FreeBSD. THere is no way that I can modify the distribution >> channels without the "blessing" of the 'core'. > >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. >> At the top, we have those who either have direct access to the master tree >> or are willing to live with CVSup'ed images taken from it. >> >> At the next level, we have frequent snapshots of the tree. These are >> clocked by the ctm-cvs generator (every 6 hours, I believe). I would have >> the sup mirrors use this as their distributable product. > >So far there is nothing new here. All this is already in place. I didn't claim it was new. I am simply trying to be complete; to explain it. 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. >> The third level would be the "current" (or as someone said, "recent") tree. >> It would also be synced to the above mentioned distributions. However, the >> distribution can be delayed or skipped until some verfication of the >> "buildability" has been established. > >So you are proposing that there be a -recent thread, which is qualified as >'the last -current that survives a full build'. Ok, no problem there. >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. >> 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. As for the "validation" stuff, you left out the migration path that said that we could start by assuming that each release was OK. 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 your plan works, more will join the bandwagon. If it sinks, we don't go >down with you. I cannot really give you anything of value until I have reworked the distribution system. There is the "critical mass" question. Without the "help" of the organization, this thing will never fly. If I have to compete on your terms, I might as well start yet another BSD derivative where I get to be "top dog". I don't want to do that, but your attitude continues to make it more attractive. >> Neither can I demonstrate a working modification to the make system without >> first removing a bunch of inappropriate absolute file references. But I >> cannot get anyone to agree to make those changes until I demonstrate that >> it all works. > >And? Take your system, make the changes, submit a set of diffs and some >descriptions of what they do and then advocate them. 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. >You seem to think that the only way to 'demonstrate' something is by >forcing everyone else to 'walk this way' and refusing to explain it >beforehand. 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b0aae53e42aea3a>