ipfw add pipe broken?

[JoaoBR]

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 
usefull but might be misunderstood by people, anyway I like to answer your 
points but first I like to make clear that this is NOT a personal issue and I 
am not angry with Julian or anyone else, it is merely the issue itself so I 
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 ipfw 
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 the 
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, some 
exotic driver or hardware, let's say here sk,nve or re - ok, BUT ipfw 
certainly is not experimental code and do not depend on hardware as long you 
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 the 
handbook, then let's read all: "... the general assumption that they have 
first gone into FreeBSD-CURRENT for testing ..." (I guess this is meant for 
new code but law for mature code)

this assumption is important because it is kind of rule, common sense like  
speeding a Ferrari over a bumpy street it might break but a Fiat not, so this 
would not be a suprise but cooking the motor at 80mph on a highway is not the 
thing we need to be prepared for and is certainly a bad thing where the car 
maker should look at before releasing it

and so I feel right to say, essential and mature code *needs* to be tested 
extensively before committing it, exotic or new code not
This makes more sense today as FreeBSD has an important position, but not only 
has it but also has to defend it. This makes it necessary that the common 
sense of responsibility "is there" and this is the next assumption, a 
comitter should have this responsibility. (which certainly does not exclude 
the risc of errors, but reduce it)
Also no secret and common sense is that releng_6 is widely used on production 
servers. So ipfw is not supposed to be broken.

My personal suggestion is that certain code like ipfw needs to be marked for 
double check, so there should be one other responsible reviewing AND testing 
it before comitting it, this probably is the only way to prevent or reduce 
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
-- 

João







A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br