From owner-freebsd-arch@FreeBSD.ORG Tue Dec 28 15:20:14 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DFC2106566B for ; Tue, 28 Dec 2010 15:20:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 458228FC1B for ; Tue, 28 Dec 2010 15:20:14 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A680446B06; Tue, 28 Dec 2010 10:20:13 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ABD798A009; Tue, 28 Dec 2010 10:20:12 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 28 Dec 2010 10:05:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101222123834.GN23098@acme.spoerlein.net> <20101227131140.H6126@maildrop.int.zabbadoz.net> In-Reply-To: <20101227131140.H6126@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201012281005.36372.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 28 Dec 2010 10:20:12 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Bjoern A. Zeeb" Subject: Re: Schedule for releases X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 15:20:14 -0000 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