Schedule for releases

[Jack Vogel]

>From my perspective its not so much the work of 'back porting', like my
drivers
that's trivial. The issue from a developer standpoint is support, its a lot
of work
to keep tests going on multiple releases, and when there are bugs worrrying
about
repro, etc..

I take my que mainly from customers, what they need, and how important that
is
to Intel, not sure if that's typical or atypical, but whichever :)

Jack


On Tue, Dec 21, 2010 at 3:06 PM, Robert N. M. Watson <rwatson at freebsd.org>wrote:

>
> On 21 Dec 2010, at 22:59, Poul-Henning Kamp wrote:
>
> > In message <alpine.BSF.2.00.1012212215320.36028 at fledge.watson.org>,
> Robert Wats
> > on writes:
> >
> >> Looking at 7.x, I'm struck by how much it has slowed down.  There's a
> >> significant user community, but not a significant developer community.
> >
> > This is a very important point to interpret correctly:
> >
> >       FreeBSD is whatever its developers make it be.
>
> Agreed entirely.
>
> > A more structured and more desirabe option is to channel such funds
> > through either the foundation or a commercial entity, who then pays
> > developers to pay attention to 7.x
> >
> > Companies who use Open Source are not adverse to paying for the
> > service they get, but somebody needs to make it easy for them.
>
> Yeah, I think we pretty much agree on this: someone needs to do the work
> within the community. I don't doubt dozens of companies (if not many more)
> are busy back-porting drivers locally to 6.x/7.x, etc, and it would be nice
> to (a) amortize that cost, making it cheaper to use FreeBSD in said
> products, and (b) get it out into the community so everyone benefits. It's
> possible to imagine different models working there, and possibly more than
> one at once. I think the obvious starting point actually is in the device
> driver space, and possibly through the support efforts already being made in
> companies. It's useful for our community, however, to discuss whether we
> have any technical/social obstacles that would limit that (i.e., would
> $vendor not like it if third parties maintained their drivers in branches
> they no longer QA for), and whether we can take any specific actions to
> support those efforts.
>
> There are lots of other factors involved here too, of course, but I think
> there's probably some moderately accessible work that if done, will make the
> world a better place :-).
>
> Robert_______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>