Request to back out Luigis polled-net patch in -stable.
phk at critter.freebsd.dk
Sun Jul 3 00:05:09 GMT 2005
In message <firstname.lastname@example.org>, Garance A Drosihn writes:
>Poul-Henning included one comment about "track records" which may
>have been a bit harsh, but if you ignore that one sentence than
>everything he said seemed pretty reasoned (ie, "calmly thought out",
>as opposed to "emotional outburst"), and pretty reasonable.
I would like to defend that comment, and I apologize for it sounding
harsh, it was simply meant as a flat statement of fact on my part.
We have committers in the project who gets things right the first
time around, every time, on time, on schedule, under budget
and with a global reduction of green-house gasses as a side effect.
When Bruce Evans commits something one can virtually rest assured
that it has been throughly tested ever since he originally wrote
it in 1974 and that several satelites and ICBMs wouldn't work
and the cold war would not have ended without that patch.
Then we have other committers who drag a trail of death and destruction
through a sequence of more and more frantic commits until they
finally (by accident ?) gets it right enough that the tree isn't
broken anymore. (I wont mention names here).
These are the two extremes, between them you will find the rest of us.
Now, for something to go into -stable, there are certain standards,
we have haggled over them from time to time.
For a new feature to go into -stable, there has to be very very good
reasons not to take the detour around -current.
In particular there has to be a very good and convincing argument
that something _will_ go into -current, so that we don't introduce
a feature in -stable which the next major release will simply not
have: We don't need to disappoint our users any more than we
need to with our major releases.
Luigi has a track record of delivering some very smart code to
FreeBSD, I'm a big fan of his IPFW and DUMMYNET stuff, and I far
prefer them to IPFILTER.
I even think Luigi is a great guy, and I'm happy to see him being
a "Professor of FreeBSD Networking" (well, not quite but...) at his
University in Italy.
But that doesn't change the fact that Luigis code has never been a
"working first time thing wihtout a hitch" for us.
There has always been some issues to work out, some things to move
around a bit, things which need a bit of generalization and so on.
In other words: Luigi is a perfectly normal FreeBSD committer.
And that means that he should follow the rules we have for -stable:
he doesn't clear the bar to cold commit a new feature into -stable.
In particular it should not when it is not convincingly argued
that we will be able to integrate the new features in -current any
I'm not against his code, I just don't want it to go straight into
If the argument holds that -stable and -current has diverged too
much for it being feasible to go the usual "into -current, then
MFC" walk, then we need to reexamine the entire "-current/-stable"
setup and maybe add a 4-CURRENT development-branch from which things
get merged to 4-STABLE.
(Having worked in multi-branch environments like that, I would be
strongly against any such thing and I think anyone who has tried
to navigate the cisco IOS version maelström in recent years
are likely to be against as well).
So in summary my position is:
Luigi stuff should be backed out of -stable.
Luigi should figure out how to do this right in SMPng/-current and
implement it there. Then when we have some experience with it, we
can decide on a rational basis if it should be MFC'ed, (or committed
cold into -stable if the MFC doesn't make sense).
And of course Luigi is more than welcome to distribute his change
as a patch against -stable, just like Jun-Itoh does with his ALTQ.
(I don't know if Peter has -stable in P4, but that could be one way
to make it easier for Luigi to maintain the patch if he had a branch
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
More information about the freebsd-net