From owner-freebsd-current Thu Jun 20 12:33:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA03268 for current-outgoing; Thu, 20 Jun 1996 12:33:02 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA03263 for ; Thu, 20 Jun 1996 12:32:58 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA10856; Thu, 20 Jun 1996 13:32:51 -0600 Date: Thu, 20 Jun 1996 13:32:51 -0600 From: Nate Williams Message-Id: <199606201932.NAA10856@rocky.sri.MT.net> To: Chuck Robey Cc: Nate Williams , FreeBSD current Subject: Re: When gcc-2.7.2 hits ctm In-Reply-To: References: <199606201355.HAA09538@rocky.sri.MT.net> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > That's why I suggested specifically killing the mailing of the gcc, and > > > allowing folks to separately ftp the ctm update of that one. > > > > What would you have the developers do. > > > > 1) Fix bugs, add code, make things better > > 2) Do administration work.. > > No, it's much simpler than that, Nate. This is the first time I've seen > that a ctm update threatens to be this large. Chances are, it will > continue to be rare. I don't worry about anything smaller than about 5 > megs, and that seems to cover most contingencies. But you don't know if it will. > I don't want to hamstring developers either. I am asking for a one time, > extraordinary, suspension of one ctm mailing, the big one that handles > the new gcc. No other ones, no affect on any developers, no effect on > any suppers, and the only effect on ctm users is that they have to get > ONE update via ftp. A developer has to kill CTM and re-start it, developers are getting CTM via email no longer and have to ftp by hand, and developers have to go determine if the gcc CTM update will be too big. > Doesn't sound like too big a request to me. Neither does having you unsubscribe from the list until it blows over. > I could do the unsubscribe bit, if there will be at least 12 hours > warning of the update. Why do you need 12 hours in advance? Peter's said it will happen 'Real Soon Now' a couple days ago, so it'll happen pretty quick now. What's a little more work that you have to do to hand-integrate some smaller CTM patches vs. making everyone else have to do extra work? > I don't think that's a good idea, altho I'll do it, because I don't > think that mailing out huge numbers of copies of a 25 MB mailbomb is a > good idea in general. Point it, this is a one time thing, I think it > justifies a one time response that won't put anyone out. Why is this a one-time thing, and where did 25MB come in? If it happens once time, it can happen again, the next time someone upgrades gcc/groff, or one of the big packages. I really feel that you are in the minority here, and you're making the majority of the folks suffer because of your limits. And, even if you are in the majority the warning was given, so un-subscribe from the automatic mailing and *everything* will be exactly the same *except* that it won't require any hand-on changees from the 'administration'. And, those folks who have the resources to handle a 25MB/5MB/1MB file won't be punished for it. All of the tools to solve the problem ae in your hands already, so there's no need to interfere except to make your life easier and someone else's life more difficult. Nate