Date: Thu, 18 Sep 2008 15:28:55 -0700 From: Jo Rhett <jrhett@netconsonance.com> To: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: Upcoming Releases Schedule... Message-ID: <CE6D20D5-523A-4F83-9CE2-B04B6FF798B1@netconsonance.com> In-Reply-To: <20080918220213.GA94268@sysmon.tcworks.net> References: <CB36FE28-D125-4C22-B5DE-1001515DD8A6@netconsonance.com> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <alpine.BSF.1.10.0809061159410.28840@fledge.watson.org> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <alpine.BSF.1.10.0809162043380.64176@fledge.watson.org> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <alpine.BSF.1.10.0809180022580.13100@fledge.watson.org> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <alpine.BSF.1.10.0809181935540.16464@fledge.watson.org> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <20080918220213.GA94268@sysmon.tcworks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> lambert@lambertfam.org
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org
> "
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CE6D20D5-523A-4F83-9CE2-B04B6FF798B1>