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