From owner-freebsd-stable@FreeBSD.ORG Tue Apr 3 10:44:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA65016A401 for ; Tue, 3 Apr 2007 10:44:38 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id B5F5F13C487 for ; Tue, 3 Apr 2007 10:44:37 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l33AiXZL067293; Tue, 3 Apr 2007 07:44:33 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Tue, 3 Apr 2007 07:44:31 -0300 User-Agent: KMail/1.9.5 References: <200704030853.l338rXZD050252@lurza.secnetix.de> In-Reply-To: <200704030853.l338rXZD050252@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704030744.31905.joao@matik.com.br> X-Spam-Status: No, score=-99.9 required=5.0 tests=ALL_TRUSTED,AWL, J_CHICKENPOX_23, MR_DIFF_MID, TW_PF, USER_IN_WHITELIST autolearn=no version=3.1.8 X-Spam-Checker-Version: Antispam Datacenter Matik msrv.matik.com.br X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Oliver Fromme Subject: Re: ipfw add pipe broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 10:44:38 -0000 On Tuesday 03 April 2007 05:53, Oliver Fromme wrote: > > Well, FreeBSD is mostly a volunteer project, so people work > on it when they have time. we all know that, we could discuss the general issue deeply which might be= =20 usefull but might be misunderstood by people, anyway I like to answer your= =20 points but first I like to make clear that this is NOT a personal issue and= I=20 am not angry with Julian or anyone else, it is merely the issue itself so I= =20 hope you're all cool with this and nobody starts yelling. > > Admittedly, you're right that any changes should be tested. > But in reality it's not always that easy. Some changes are > complex so that not all possible things can be tested. And I do not agree with "can not be tested", this was eventually ok in 97's ipf= w=20 code ... > some changes _seem_ trivial and obviously don't need to be > tested (especially if a nearly identical change ran for > months in -current), but then that might turn out to be a > mistake. Errare humanum est. (Translation: shit happens.) > ;) thanks for the latin translation but of course it happens, but is not th= e=20 point > > please do it all or don't do it, ipfw is an mature and essential part > > where we do not espect such sudden surprises in releng6 to happen > > First, if you absolutely don't want surprises, then you > should run RELENG_6_2, not RELENG_6. If you run RELENG_6, > you should be prepared and able to deal with breakages. ok, as you say shit happens but we should be aware of where it happens, som= e=20 exotic driver or hardware, let's say here sk,nve or re - ok, BUT ipfw=20 certainly is not experimental code and do not depend on hardware as long yo= u=20 have any which runs fbsd > (Even if it's unusual that RELENG_x breaks, it does happen > sometimes. The FreeBSD Handbook chapter "staying stable" > contains appropriate warnings.) like I said before, the playground is CURRENT for this and you talk about t= he=20 handbook, then let's read all: "... the general assumption that they have=20 first gone into FreeBSD-CURRENT for testing ..." (I guess this is meant for= =20 new code but law for mature code) this assumption is important because it is kind of rule, common sense like = =20 speeding a Ferrari over a bumpy street it might break but a Fiat not, so th= is=20 would not be a suprise but cooking the motor at 80mph on a highway is not t= he=20 thing we need to be prepared for and is certainly a bad thing where the car= =20 maker should look at before releasing it and so I feel right to say, essential and mature code *needs* to be tested= =20 extensively before committing it, exotic or new code not This makes more sense today as FreeBSD has an important position, but not o= nly=20 has it but also has to defend it. This makes it necessary that the common=20 sense of responsibility "is there" and this is the next assumption, a=20 comitter should have this responsibility. (which certainly does not exclude= =20 the risc of errors, but reduce it) Also no secret and common sense is that releng_6 is widely used on producti= on=20 servers. So ipfw is not supposed to be broken. My personal suggestion is that certain code like ipfw needs to be marked fo= r=20 double check, so there should be one other responsible reviewing AND testin= g=20 it before comitting it, this probably is the only way to prevent or reduce= =20 the error rate > > And second, it's not a big deal to go back to Friday's > sources until Julian had time to fix the issue, is it? no it is not but it is not the point thank's =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br