I agree with pretty much everything you've said here, with the obvious
exception that I don't know what's involved in the release management
process to do as you've said.
Also for my own self, rather than resurrect 6.2 I'd personally rather
focus on what we could do to extend the support period for 6.4. And
other releases going forward.
In particular, I'd like to highlight what you said here because you've
said very clearly what I've been trying (apparently not so well) to
say for some time now:
In this way, the companies which are already paying their people to
apply security fixes to old releases can donate the work which is
already being done back to the project. Hopefully they will end up
sharing the load so that they reap the benefits of work done by other
companies which are paying people to do the same things.
Thanks.
On Sep 18, 2008, at 3:02 PM, Scott Lambert wrote:
I don't have a dog in this fight. I'm just writing this message
because
it looks to me like there is a lot of talking past one another going
on
between people who are basically in violent agreement with one
another.
I am hoping that wording things differently will lead to understanding
on both sides. I may have completely misinterpreted both sides.
Spoken
languages are too ambiguous.
Here is the boiled down gist of my interpretation of a possible way to
go forward with this; bad pseudo code:
RESOURCES='Jo and the others he seems to know of who back port fixes
to
their production versions of "unsupported" versions of
FreeBSD.'
For i in "RELENG_X_Y" (where X_Y is not a currently "supported"
version of FreeBSD); do
grant maintenance commit access for $i to ${RESOURCES}
done;
Now for the code documentation:
Maybe one of the ${RESOURCES} could build some web application whereby
people could sign up to be a "community extended support" resource for
RELENG_X_Y until $date_in_the_future. Perhaps a letter of commitment
from ${RESOURCE}s ${EMPLOYER} would be required before accepting the
candidate for work on RELENG_X_Y.
Then the existing developers or core team could approve their
application/access and provide a mentor if they aren't currently
commiters. (This is some extra work for the existing people. But
hopefully the rewards would be worth the minimal? effort.)
Eventually, the mentor pool could be wholly from ${RESOURCES}. Much
of the approval of new candidates would be from the same pool. The
whole thing might have to be conditional on ${RESOURCES} bringing the
necessary tinderbox type hardware to do basic QA on their extended
support branches. With enough ${RESOURCES} signed up, they might be
able to get hardware from ${DONORS} other than themselves.
The ${RESOURCES} people could gang up on which RELENG_X_Ys they want
to
support. They can support them for as long as they have people on the
team who are interested in supporting them. Presumably, these people
would be working for companies which have made a commitment to use
RELENG_X_Y for N years.
In this way, the companies which are already paying their people to
apply security fixes to old releases can donate the work which is
already being done back to the project. Hopefully they will end up
sharing the load so that they reap the benefits of work done by other
companies which are paying people to do the same things.
So long as the requirements for a back port to the ${RESOURCES}
supported branches are the same as to an officially supported branch,
there shouldn't be much chance of harm. Perhaps they are only allowed
to back port fixes which have been approved for a supported
RELENG_X_Y.
Eventually, if enough ${RESOURCES} sign up, they might be able to
release X.Y.z distribution media. If they only provide the media for
CD/DVD purchase, the revenue might help to provide for QA tinderboxes
for the ${RESOURCES} supported work.
We might even end up with more people who are familiar with the
release
process and volunteer to work on RELENG_X_Y from initial release all
the way through normal end of support and into the community extended
support period.
I think that would provide, as much as is possible, for the "don't
make
extra work for the existing developers" requirement as well as giving
these resources a way to "put up or shut up." I could be wrong.
--
Scott Lambert KC5MLE Unix
SysAdmin
[EMAIL PROTECTED]
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]
"
--
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]"
