Date: Tue, 3 Apr 2007 07:44:31 -0300 From: JoaoBR <joao@matik.com.br> To: freebsd-stable@freebsd.org Cc: Oliver Fromme <olli@lurza.secnetix.de> Subject: Re: ipfw add pipe broken? Message-ID: <200704030744.31905.joao@matik.com.br> In-Reply-To: <200704030853.l338rXZD050252@lurza.secnetix.de> References: <200704030853.l338rXZD050252@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704030744.31905.joao>