From owner-freebsd-current@FreeBSD.ORG Tue Jun 29 17:49:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B6B116A4CE for ; Tue, 29 Jun 2004 17:49:24 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C6C243D41 for ; Tue, 29 Jun 2004 17:49:23 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 4552 invoked from network); 29 Jun 2004 17:48:18 -0000 Received: from unknown (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 29 Jun 2004 17:48:18 -0000 Message-ID: <40E1AB5B.1090302@freebsd.org> Date: Tue, 29 Jun 2004 19:48:11 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Swiger References: <34706.1088497708@critter.freebsd.dk> <46A7D8A4-C9EF-11D8-99F8-003065ABFD92@mac.com> In-Reply-To: <46A7D8A4-C9EF-11D8-99F8-003065ABFD92@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Poul-Henning Kamp cc: current@freebsd.org Subject: Re: HEADSUP: ibcs2 and svr4 compat headed for history X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2004 17:49:24 -0000 Charles Swiger wrote: > On Jun 29, 2004, at 4:28 AM, Poul-Henning Kamp wrote: > >> In message <40DF2607.5020409@mac.com>, Chuck Swiger writes: >> >>> In other words, I care quite a bit about how "working, supported >>> functionality" gets transitioned to "no longer available". I'm not >>> happy with >>> the notion of "supported" -> "HEADS UP" -> one week -> gone. >> >> >> I don't think anybody would be happy with that, and that is not what >> was proposed in this case. > > > OK. While I thought your original "HEADS UP" was clear, perhaps you had > a less abrupt transition plan in mind. > > If you suggested that the ibcs/svr4 compatibility stuff should be marked > depreciated for 5.3, and give people until 5.4 time find someone willing > to do maintenance for the code, or give someone time to move this > functionality to ports, or find some other alternative, that might > receive more positive feedback. From what I have understood so far is that ibcs/svr4 already *is* broken in 5-CURRENT. However it does seem to work sufficiently well in 4-STABLE. Effectively it doesn't make any difference if it is removed now or later. The option to turn it into a maintained port, should indeed some step up to do that, is given regardless of removing it from stock 5-CURRENT right now. The code does not disappear, it is in attic for anyone to look at. From this perspective there is no compelling reason to hinder PHK from removing ibcs/svr4 from stock 5-CURRENT on next weekend, *unless* someone firmly commits himself until end of the week to fix those problems/bugs in ibcs/svr4 for 5-CURRENT to make it work again (at least as well as in 4-STABLE). Maybe the condition for removing it, is that at the same time he must move into a port that is marked broken right from the start. -- Andre