Upcoming Releases Schedule...
Jo Rhett
jrhett at netconsonance.com
Thu Sep 18 19:24:53 UTC 2008
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
More information about the freebsd-stable
mailing list