On Mon, 22 Sep 2008, Jo Rhett wrote:
Again, what you are saying makes a lot of sense, and I have no problem with
it. We're just missing the crucial bit -- what is it going to take to reach
that goal? Regardless of commit bits, etc and such forth. Is 10 hours a
week of one person enough? Does it really need 4 people with 10 hours a
week? How do we get from here to there?
This is where I think we're missing each other. Achieving a commit bit --
sure, no problem with what you have outlined. But you haven't finished the
thought enough to confirm whether me having a commit bit would solve the
problem we are trying to solve.
I mean honestly, is one person with a commit bit and some time enough to
solve the problem? I've been involved with enough projects to know that the
real answer might be, "no, we actually have all the people we need with
commit bits but our infrastructure makes doing this difficult right now".
Lack of human resources, to use a vile term, is currently the limiting factor.
What happens when that is cleared is another question, but in the end there
aren't a whole lot of paths to greater efficiency here: for each
vulnerability, we generally start with the HEAD of the tree working back by
age, for each branch identifying:
- Whether the vulnerability, or broad class of vulnerabilities, exists
- If the same patch applies, whether it fixes all instances of the problem in
the next branch as well
- Generate commit candidate
- Test builds and runs
- Generate binary updates
- Generate appropriate security advisory information
This is an inherently manual process because security patches touch a variety
of parts of the system and each has different implications, the tendency for
vulnerabilities to come in classes, etc. None of us remembers the format
string vulnerability's arrival on the scene fondly since it became necessary
to modify the compiler to try to mechanically sweep the tree for similar
issues, for example.
The older a branch, the more likely it is that it requires a different
analysis and a different patch, hence the sigh of relief when 5.x fell off the
support list -- not because it was a bad branch, but because there was
significant divergence and maintaining three active development branches at
once (5.x, 6.x, and 7.x) was a serious stretch.
<long essay elided>
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
