Re: Upcoming Releases Schedule...

On Sep 18, 2008, at 12:01 PM, Robert Watson wrote:
So far, this conversation has largely consisted of you telling us that you don't like what we're doing and demanding that we change.

I'm not sure what is going on in your life to make you so defensive that someone saying "I have resources, I can help. Here's the problem I'd like to address" makes you think they are "demanding". Nobody is "demanding" anything (that I have seen in this conversation).

Take a deep breath, stop taking this personal - which I assume you are when you talk about "demanding" and let's talk about this. Most of the rest of your post is valid.

Let's consider three more productive avenues by which you can offer assistance with the problem of how to increase branch support lifetimes:

(1) Become a contributor to the community by developing and maintaining
patches against unsupported branches, especially against older releases
such as 4.x and 5.x where the branches are open for commits but have
fallen out of support status. I can't promise the results will

We have no 4.x or 5.x systems nor do we have any interest in maintaining those. So perhaps a good idea, but not something I can help with.

I *did* offer to work on maintenance for 6.2, but was told it would be rejected by the developers. Would I extend effort to do exactly what I am talking about -- extending the support lifetime for very recent releases? Absolutely. If its in a form useful for the community as a whole.

If I have to do this on my own (what we are doing internally now) then the FreeBSD community leverages nothing from the effort, and we're not changing the resources limitations at all.

(2) Become a contributor to the community by identifying members of the
existing developer team for whom additional funding would enable them to
spend more time working on and supporting FreeBSD and providing that
funding. Consider approaching the FreeBSD Foundation formally to seek
matching grant funding for the project.

We have funded projects, we continue to fund projects. Most of our funding right now is aimed at people who don't have the time to work on it, money or no. But again, funding does not improve the resources problem in most cases. Many $EMPLOYERs find it easier to have an employee allocate 10-20% of their work to a project than to get cash allocations for the same.

(3) Become a contributor to the community by working with an existing or new
company that provides support for FreeBSD commercially, and discussing

Nobody who does FreeBSD support on a paid basis can generally solve the kind of problems we find. I have tried these kind of things in the past with both FreeBSD and Linux, and in every case I was significantly better at finding/fixing/patching bugs than anyone on the team. The ones I could not address (usually device driver issues) the support team could do nothing more than forward a bug report to the developer. And in general, they were less good at including relevant details and debug output than I was. In short, it's a non-op.

official EoL date for the project. Companies like FreeBSD Mall have
strong relationships with the project, and in the past have contributed
significantly to efforts such as release engineering. It's not hard to
imagine a company along those lines using something along th elines of a

Robert, here we go again. You have given several options, not a single one of which will provide more resources to the release team. The only thing you've successfully done is given me three different ways to eff off and leave you alone. Apparently, more resources is not in your interest.

Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and other randomness

freebsd-stable@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"