Date: Tue, 28 Dec 2010 10:05:36 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Subject: Re: Schedule for releases Message-ID: <201012281005.36372.jhb@freebsd.org> In-Reply-To: <20101227131140.H6126@maildrop.int.zabbadoz.net> References: <DB4D8AC7-25D6-4901-BBF9-77BEB956840B@cederstrand.dk> <20101222123834.GN23098@acme.spoerlein.net> <20101227131140.H6126@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, December 27, 2010 9:47:32 am Bjoern A. Zeeb wrote: > On Wed, 22 Dec 2010, Ulrich Sp=F6rlein wrote: >=20 > Hi, >=20 > > I think this is the core "problem". Statistics[1] show, that most > > developers run some form of -CURRENT and > ... > > [1] I just made this statistic up. >=20 > and I think you are just plain wrong here. Seriously I would bet that > >75% of the developers do not run some sort of head for their > day-to-day work. They might use it for compile (and boot and maybe > sometimes even some more) testing, they might run it in a VM, or a lab > machine but not on their servers, not on their notebooks and not on > their desktops they work with daily (and neither would I expect most > consumers of FreeBSD unfortunately). >=20 >=20 > I am still not convinced that whatever development model people and > companies use (and I heard of in here) is better than to just devel > on HEAD and if it works there merge it and backport it to your release > branch for QA and shipping. Sadly, I need to actually ship the development I do that is work-related, s= o I=20 do it on stable first and then forward port it to HEAD afterward. Other=20 changes that are not work-centric (e.g. PCI hacking) I do on HEAD directly.= =20 However, for tasks specific to what work needs, that model does not work. One key reason it does not work is that many bugs only show up in productio= n. =20 This was true for me at Y! as well as my current job. And we are _not_ goi= ng=20 to run HEAD in production. I simply can't sell that. So that means that w= hen=20 we do encounter various bugs, we have to debug and fix them on the -stable = we=20 currently use and later forward port to HEAD. > In addition if you work on HEAD, you find problems as they occur and > not years later when developers have long moved on to other projects > and it's a pain for them to task swap back to whatever for a branch > that indeed is only barely supported anymore. This does not work for bugs that only show up under production load (which = is=20 most of them). > If you do your daily/weekly/monthly regression tests for your > products you can catch that. If you run HEAD, you'll also catch it > timely to avoid binary searches of multiple quarters or years. It can be a lot of work to maintain support for compiling on multiple=20 platforms that companies may not (I know some of them definitely will not)= =20 want to invest extra time in. > Some of you have the infrastructure and I can understand that you cannot > share (most of) it but you could run it on plain FreeBSD as well and > show us the reports? In many cases if a company has local changes to FreeBSD, their software is= =20 heavily tied to those local modifications and will not run on stock FreeBSD. > Consider to do that regularly (it doesn't have to > be daily but maybe (bi-)weekly or monthly). "Budget" for it in terms of > infrastructure and employee time. It'll probably save you time (and > with that money) in the end and help us to improve the solid > foundation you are building your products on. I think this is an area of give and take though. Some companies already=20 budget time in that they employ committers and allow them to work on FreeBS= D=20 stuff that isn't strictly work-related part-time and merge things upstream = to=20 HEAD when possible. Is it too much to ask that the Project make that path = a=20 bit easier by making stable branches longer? There are some recent examples of companies funding work to go into HEAD fi= rst=20 that they plan to use a backport of (NFSLOCKD, the NFS server GSSAPI suppor= t,=20 SU+J, and infiband), so this model can certainly work. It probably also wo= rks=20 best for upstreamable new features which tend to be some of the largest dif= fs=20 where the features can be tested independently of a company's proprietary=20 software stack. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012281005.36372.jhb>