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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
