From owner-freebsd-arch@FreeBSD.ORG Tue Dec 21 17:47:09 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 CA650106566B for ; Tue, 21 Dec 2010 17:47:09 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 94E848FC16 for ; Tue, 21 Dec 2010 17:47:09 +0000 (UTC) Received: by iwn39 with SMTP id 39so4462212iwn.13 for ; Tue, 21 Dec 2010 09:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=rc4a26UPCysg9crm9eZCOog1f/r7XSpkV0RVZYZay8c=; b=blrhaOPCIx5oTqzT/eIsYqu2J3Yw3Reb7e0zUqy3Q3YBQfRlji6VePqzOSPvCY4I7P u1Buf3FxROxgVyKhFV7zLyYbfyEuSehhMNOSJXNvFTW63tOYzlVqaEYEupwNBtqgXWHj SWaJN4y9XEKncepPCEBnVHtwRdiJs05AuzMzw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=hb6dNBQuaOySCtnyHduDs3Nvo2qqppTsHM93S7R/qY8lXePBNWLikjp1pcIVliOPgZ X0gkg9dL3dLV9940GxnJfJyP260OhQQn+N7oMguZmP1e1BYa1ruD0ZkEpI/PWyzEPv8g jbe0e+MVJHXmXe/cpJcIksJwKFFBowlZjtV8M= MIME-Version: 1.0 Received: by 10.231.11.200 with SMTP id u8mr5640872ibu.151.1292953628870; Tue, 21 Dec 2010 09:47:08 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.172.69 with HTTP; Tue, 21 Dec 2010 09:47:08 -0800 (PST) Date: Tue, 21 Dec 2010 09:47:08 -0800 X-Google-Sender-Auth: 29X6VuFRZLvkx5d2tZM5oiwUp8M Message-ID: From: mdf@FreeBSD.org To: FreeBSD Arch Content-Type: text/plain; charset=ISO-8859-1 Subject: 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, 21 Dec 2010 17:47:09 -0000 I suspect this has been discussed before but I wanted to bring it up again in light of my experience using FreeBSD as the base for a commercial product. Commercial life cycles can be rather long. For me, I started working on porting Isilon's code base to FreeBSD 7.1 in May of 2009, at the time knowing nothing about FreeBSD and extremely little about Isilon's code base. For reference, at the time 7.1 was the most recent RELENG_7 branch, and CURRENT had not yet been cloned into RELENG_8. For various business reasons, at the time we did not want to track CURRENT so settled on a local svn mirror of stable/7 to make pulling patches easier. Fast forward about 9 months and the merge project is complete, and tested, and we're all happy. But FreeBSD has moved on a bit, with 8.1 out any day now. Now fast forward another 6 months, and here we are today, with 7.4 about to come out and EOL the stable/7 branch, and the product based on FreeBSD stable/7 finally hitting GA. My point in all this is that commercial software endeavors can be multi-year efforts. But the support for stable/7 is pretty low now; I noticed over the last year that many MFC's went to stable/8 but not stable/7. So the question: Should FreeBSD support release branches for a longer time period? I am assuming that after 7.4 comes out only security fixes will be going into stable/7. The difficulty with supporting the release comes partly because of KBI/ABI changes. It may be that CURRENT has changed enough that it's just not practical to support a release that was initially cloned 2 1/2 years ago. For various reasons I am hoping that the next merge project we do locally will be to CURRENT, because that makes staying in sync with FreeBSD and returning our code to the community easiest. But making the business case isn't quite as simple. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Tue Dec 21 17:56:21 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 B66641065747; Tue, 21 Dec 2010 17:56:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5946D8FC15; Tue, 21 Dec 2010 17:56:21 +0000 (UTC) Received: by yie19 with SMTP id 19so529741yie.13 for ; Tue, 21 Dec 2010 09:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=meEgm8jAka6gswkxuGbEj1UZzGvPMkPUILuSKEzwYU0=; b=pbnhI3RyZt8SVcbNJbP3qpGrtigTgHTDfUZjqh7SNECfkvylu8Ke9KWPt00wjAE3XK zhRv1lzNDt8hiucZhY24ylR3I7ONjO65NGyApBHENONr3igryUzKb1FEiffgPU7bZOtH IFwYZ/PhjuieMYpMncZXDuLy2TD88XgJ74A7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=IiiUcEtGKXEvX/Cd5uRaGtr8K7v9O9B03f7ma2E1EwL1KDZKQlPMhmCjn+wjEyfk/s k9wOPDakdU/Xc1QgfpuWowF9HdoMsjtodOlrqakQaVMbESl2kTv6+KUgW4HBLQ2BYKI9 IyhjeS7N64yZLOwYd1lCWiNKiH7vvjFm8rSlI= Received: by 10.236.103.175 with SMTP id f35mr2051872yhg.27.1292954180506; Tue, 21 Dec 2010 09:56:20 -0800 (PST) Received: from starr-wireless.local (c-24-130-10-228.hsd1.ca.comcast.net [24.130.10.228]) by mx.google.com with ESMTPS id 72sm2959077yhl.38.2010.12.21.09.56.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Dec 2010 09:56:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Tue, 21 Dec 2010 09:56:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8A01BB52-1A71-4185-9120-F36F0B6C160D@gmail.com> References: To: mdf@FreeBSD.org X-Mailer: Apple Mail (2.1082) Cc: freebsd-arch@freebsd.org 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, 21 Dec 2010 17:56:21 -0000 On Dec 21, 2010, at 9:47 AM, mdf@FreeBSD.org wrote: > I suspect this has been discussed before but I wanted to bring it up > again in light of my experience using FreeBSD as the base for a > commercial product. >=20 > Commercial life cycles can be rather long. For me, I started working > on porting Isilon's code base to FreeBSD 7.1 in May of 2009, at the > time knowing nothing about FreeBSD and extremely little about Isilon's > code base. For reference, at the time 7.1 was the most recent > RELENG_7 branch, and CURRENT had not yet been cloned into RELENG_8. > For various business reasons, at the time we did not want to track > CURRENT so settled on a local svn mirror of stable/7 to make pulling > patches easier. >=20 > Fast forward about 9 months and the merge project is complete, and > tested, and we're all happy. But FreeBSD has moved on a bit, with 8.1 > out any day now. Now fast forward another 6 months, and here we are > today, with 7.4 about to come out and EOL the stable/7 branch, and the > product based on FreeBSD stable/7 finally hitting GA. >=20 > My point in all this is that commercial software endeavors can be > multi-year efforts. But the support for stable/7 is pretty low now; I > noticed over the last year that many MFC's went to stable/8 but not > stable/7. >=20 > So the question: >=20 > Should FreeBSD support release branches for a longer time period? I > am assuming that after 7.4 comes out only security fixes will be going > into stable/7. The difficulty with supporting the release comes > partly because of KBI/ABI changes. It may be that CURRENT has changed > enough that it's just not practical to support a release that was > initially cloned 2 1/2 years ago. >=20 > For various reasons I am hoping that the next merge project we do > locally will be to CURRENT, because that makes staying in sync with > FreeBSD and returning our code to the community easiest. But making > the business case isn't quite as simple. We're still stuck on 6.x to a large degree at IronPort :(... 8.x = -- what's 8.x :/...? So yes, it would be nice to have a longer lifecycle on some = releases, but I fear that the problem is most likely scalability and = that FreeBSD needs more automated tests. It can also painful backporting = features and bugfixes to old releases, but that's a different note that = I'm sure every developer on the list is already aware of. security folks = could answer this question a lot better (cperciva, simon, et all). Thanks, -Garrett= From owner-freebsd-arch@FreeBSD.ORG Tue Dec 21 20:01:40 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 E8E221065693; Tue, 21 Dec 2010 20:01:40 +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 A9DFF8FC1F; Tue, 21 Dec 2010 20:01:40 +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 36C4A46B0D; Tue, 21 Dec 2010 15:01:40 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 322448A009; Tue, 21 Dec 2010 15:01:39 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 21 Dec 2010 15:00:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012211500.16131.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 21 Dec 2010 15:01:39 -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: mdf@freebsd.org 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, 21 Dec 2010 20:01:41 -0000 On Tuesday, December 21, 2010 12:47:08 pm mdf@freebsd.org wrote: > I suspect this has been discussed before but I wanted to bring it up > again in light of my experience using FreeBSD as the base for a > commercial product. > > Commercial life cycles can be rather long. For me, I started working > on porting Isilon's code base to FreeBSD 7.1 in May of 2009, at the > time knowing nothing about FreeBSD and extremely little about Isilon's > code base. For reference, at the time 7.1 was the most recent > RELENG_7 branch, and CURRENT had not yet been cloned into RELENG_8. > For various business reasons, at the time we did not want to track > CURRENT so settled on a local svn mirror of stable/7 to make pulling > patches easier. > > Fast forward about 9 months and the merge project is complete, and > tested, and we're all happy. But FreeBSD has moved on a bit, with 8.1 > out any day now. Now fast forward another 6 months, and here we are > today, with 7.4 about to come out and EOL the stable/7 branch, and the > product based on FreeBSD stable/7 finally hitting GA. > > My point in all this is that commercial software endeavors can be > multi-year efforts. But the support for stable/7 is pretty low now; I > noticed over the last year that many MFC's went to stable/8 but not > stable/7. > > So the question: > > Should FreeBSD support release branches for a longer time period? I > am assuming that after 7.4 comes out only security fixes will be going > into stable/7. The difficulty with supporting the release comes > partly because of KBI/ABI changes. It may be that CURRENT has changed > enough that it's just not practical to support a release that was > initially cloned 2 1/2 years ago. That has been my concern from the beginning with the aggressive release schedule we adopted several years ago. None of the companies I have worked at were in a position to track FreeBSD release branches as often as they are created. The counter-argument that I have always heard is that vendors who use FreeBSD in this manner are free to skip branches, say, from 7 to 9. I'm a bit on the fence on this one. On the plus side, the the merges necessary to go from 6 to 7 or 7 to 8 were far easier than going from 4 to 5 (or 4 to 6). I think even 6 to 8 would likely be fairly manageable. OTOH, I know that as a developer it's a good bit of extra work to merge changes back to 2 stable branches (7 and 8) rather than just one. I do think that the current schedule was in large part a reaction to how long 5.0 took, but I also think that 5.0 was an aberration, and not necessarily the common case that all of our release planning should be based on. Had we not yet released 8.x I think 7.x would still have a good bit of life left in it. It is possible to merge at least some large changes to a stable branch (e.g. superpages to 7). I expect to start working on merging the vm_page locking changes to 8 in the near future for example. I think the current pace of releases probably works well for users (or at least the current pace of features). If we were to aggressively merge a lot of the changes in 9 to 8 for 8.3 then I could see putting off 9.0 for a while and giving 8.x a longer lifespan perhaps, but that it is too late to do that for 7, and I'm not sure if other developers would be up for that or not. I'm not entirely sure what the right answer is, but this is something that has worried me for a while. > For various reasons I am hoping that the next merge project we do > locally will be to CURRENT, because that makes staying in sync with > FreeBSD and returning our code to the community easiest. But making > the business case isn't quite as simple. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Dec 21 22:28:01 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 5388E106564A; Tue, 21 Dec 2010 22:28:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2688FC19; Tue, 21 Dec 2010 22:28:01 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A000B46B17; Tue, 21 Dec 2010 17:28:00 -0500 (EST) Date: Tue, 21 Dec 2010 22:28:00 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <201012211500.16131.jhb@freebsd.org> Message-ID: References: <201012211500.16131.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mdf@freebsd.org, freebsd-arch@freebsd.org 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, 21 Dec 2010 22:28:01 -0000 On Tue, 21 Dec 2010, John Baldwin wrote: > I'm not entirely sure what the right answer is, but this is something that > has worried me for a while. I see a few specific tensions to worry about, but they're not new ones. The questions, really, are whether significant downstreams run into the following problems: (1) Is our rate of change too great to allow useful upstreaming? (Regardless of "releases") (2) Is our security support lifetime for -STABLE branches too short to allow major products to be built on them and have the downstream product lifetime largely live within our lifetime? (3) Do old -STABLE branches stagnate too quickly with respect to device driver support such that they can't be used? (4) Are our point releases (.1 -> .2 -> .3) too large for downstreams to roll out as incremental point releases of their own products, extending their lifetimes? (5) Do ports/packages stop supporting a branch before the useful lifetime of a -STABLE-based branch, such that a derived produt has to locally maintain versions of {Apache, ...} rather than rely on project infrastructure? Looking at recent events, it strikes me that (3) is actually the most significant problem from the perspective of many vendors. They'd like new device drivers to keep going back to 7.4, 7.5, and 7.6, perhaps without significant software changes, so that they can keep shipping a product that has to run on new hardware, but doesn't require new OS features otherwise. Our improvements in thinking about KPI have helped there, as well, but there's more to do. I think there's also a potential confusion among some of our downstreams relating to our point releases. As Colin has pointed out, they're really best thought of as "service packs", not OS releases in a recent sense. Anyone building an embedded product/appliance should probably take the perspective that they will align delivery of an initial major release of their product with the .1/.2 of a FreeBSD branch, and that they will then ship occasional OS baseline updates to pick up new device drivers, bug fixes, minor software features, etc, at intervals after that. 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. There was a non-trivial discussion of whether a 7.4 should be cut at all, given its potential to product secteam (etc) support commitments for three major branches for an extended period. One thing we could do is better engage our downstream communities into helping to extend the lifetime of -STABLE branches by contributing to driver backports, long-term security maintenance, etc. If (random vendor handwave, no insult to Intel meant) Intel isn't interested in doing the backports of, say, {em, igb, ...} to 7.x, then that needs to be pushed by someone with a product or environment that requires them to be interested. We need to ensure that there are continuing developer communities reflecting the continuance of user communities. Robert From owner-freebsd-arch@FreeBSD.ORG Tue Dec 21 23:06:43 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 81B53106564A; Tue, 21 Dec 2010 23:06:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5CDAE8FC08; Tue, 21 Dec 2010 23:06:43 +0000 (UTC) Received: from [192.168.2.104] (host86-163-246-141.range86-163.btcentralplus.com [86.163.246.141]) by cyrus.watson.org (Postfix) with ESMTPSA id 1758C46B32; Tue, 21 Dec 2010 18:06:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <9194.1292972364@critter.freebsd.dk> Date: Tue, 21 Dec 2010 23:06:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0626B045-E0D7-4875-8B72-9CC705BD133D@FreeBSD.org> References: <9194.1292972364@critter.freebsd.dk> To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.1082) Cc: mdf@FreeBSD.org, John Baldwin , freebsd-arch@FreeBSD.org 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, 21 Dec 2010 23:06:43 -0000 On 21 Dec 2010, at 22:59, Poul-Henning Kamp wrote: > In message , = Robert Wats > on writes: >=20 >> Looking at 7.x, I'm struck by how much it has slowed down. There's a=20= >> significant user community, but not a significant developer = community. >=20 > This is a very important point to interpret correctly: >=20 > 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 >=20 > 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= From owner-freebsd-arch@FreeBSD.ORG Tue Dec 21 23:19:17 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 75BD9106564A; Tue, 21 Dec 2010 23:19:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3820A8FC17; Tue, 21 Dec 2010 23:19:16 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C7DE53F592; Tue, 21 Dec 2010 22:59:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id oBLMxOOP009195; Tue, 21 Dec 2010 22:59:24 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 21 Dec 2010 22:28:00 GMT." Date: Tue, 21 Dec 2010 22:59:24 +0000 Message-ID: <9194.1292972364@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: mdf@FreeBSD.org, John Baldwin , freebsd-arch@FreeBSD.org 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, 21 Dec 2010 23:19:17 -0000 In message , 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. If there are no developers who has an interest in MFC'ing back to 7.x, MFCs will not happen, no matter how much we talk about it. Trying to force developers to maintain multiple branches will not work, they have to take an interest. People/companies who wants to see more attention to older releases, need attack the problem from that angle: How to interest some developers in this. The easiest might simply be to dangle cash in front of developers: "We offer $500 to MFC driver foobar to 7.x" But that gets unwieldy fast and is generally less reliable than one could hope. 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. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Dec 21 23:48:56 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 C322A106564A; Tue, 21 Dec 2010 23:48:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx1.freebsd.org (Postfix) with ESMTP id 524BB8FC08; Tue, 21 Dec 2010 23:48:55 +0000 (UTC) Received: by gxk28 with SMTP id 28so4034686gxk.17 for ; Tue, 21 Dec 2010 15:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=khh5zA5+VCqz2G8QQq0ubd48/6xiwmxU0Ollj1YsUWI=; b=BWGRflDHJwlZ/6sQyzs8Lakz24shKROJ5affglPgHBhFHeOwbMrQfbkzfLoCMfafPP 82KfecGD6aZCgOXIEpkhmh5mZgW54sp8dnE4DbMAVWL3UlgM22Md1l51fZrgJCyHhWfp rYqJgD1sPwdDB9DRb6iGqDu0yD/ZZewUOU5Rc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MhBbJW5YQ0EvvOntijyQP0/V9Krc6HGduMW4Q+3USnGdFG14eWXZuuM/GB6V3R2K+W 4SAKf61dZ8sQpOo6W+l7X3emIoLx2G4lu1djdftleoQN3XQrtT5bcJ9+JIVsMcCVsB6j rWyKsEvILg+32DaK2xrUzYsNecA7T3kBpSnAg= MIME-Version: 1.0 Received: by 10.150.215.2 with SMTP id n2mr9513462ybg.55.1292973960433; Tue, 21 Dec 2010 15:26:00 -0800 (PST) Received: by 10.147.181.8 with HTTP; Tue, 21 Dec 2010 15:26:00 -0800 (PST) In-Reply-To: <0626B045-E0D7-4875-8B72-9CC705BD133D@FreeBSD.org> References: <9194.1292972364@critter.freebsd.dk> <0626B045-E0D7-4875-8B72-9CC705BD133D@FreeBSD.org> Date: Tue, 21 Dec 2010 15:26:00 -0800 Message-ID: From: Jack Vogel To: "Robert N. M. Watson" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: mdf@freebsd.org, Poul-Henning Kamp , freebsd-arch@freebsd.org 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, 21 Dec 2010 23:48:56 -0000 >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 wrote: > > On 21 Dec 2010, at 22:59, Poul-Henning Kamp wrote: > > > In message , > 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 01:45:03 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 CAF541065670; Wed, 22 Dec 2010 01:45:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-26.mx.aerioconnect.net [216.240.47.86]) by mx1.freebsd.org (Postfix) with ESMTP id A51318FC08; Wed, 22 Dec 2010 01:45:03 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oBM1SOg3011890; Tue, 21 Dec 2010 17:28:24 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 768382D6014; Tue, 21 Dec 2010 17:28:20 -0800 (PST) Message-ID: <4D115441.7010907@freebsd.org> Date: Tue, 21 Dec 2010 17:28:33 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Robert Watson References: <201012211500.16131.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: mdf@freebsd.org, freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 01:45:03 -0000 On 12/21/10 2:28 PM, Robert Watson wrote: > On Tue, 21 Dec 2010, John Baldwin wrote: > >> I'm not entirely sure what the right answer is, but this is >> something that has worried me for a while. > > I see a few specific tensions to worry about, but they're not new > ones. The questions, really, are whether significant downstreams > run into the following problems: > > (1) Is our rate of change too great to allow useful upstreaming? > (Regardless > of "releases") > > (2) Is our security support lifetime for -STABLE branches too short > to allow > major products to be built on them and have the downstream product > lifetime largely live within our lifetime? I think so.. places I have worked tend to need about a year to get a new release of their product out the door in practice, and if we jump to a new release every year, then as they jump, so do we, so they are 2 revisions back "again". Generally a company wouldn't want to go through the pain of an OS upgrade more than about once in three years and often it's longer.. It IS a pain for them. they have to actually retool all their testing and they have to re-certify tons of stuff, such as their build procedures. ALSO, with a new release comes a new set of ports. and THEY have to be re-certified too. > > (3) Do old -STABLE branches stagnate too quickly with respect to > device driver > support such that they can't be used? it does happen new motherboards with new devices can be a problem, but don't forget that the motherboards have to be certified too so that adds a lag there too. > > (4) Are our point releases (.1 -> .2 -> .3) too large for > downstreams to roll > out as incremental point releases of their own products, > extending their > lifetimes? > > (5) Do ports/packages stop supporting a branch before the useful > lifetime of a > -STABLE-based branch, such that a derived produt has to locally > maintain > versions of {Apache, ...} rather than rely on project > infrastructure? > > Looking at recent events, it strikes me that (3) is actually the > most significant problem from the perspective of many vendors. > They'd like new device drivers to keep going back to 7.4, 7.5, and > 7.6, perhaps without significant software changes, so that they can > keep shipping a product that has to run on new hardware, but doesn't > require new OS features otherwise. Our improvements in thinking > about KPI have helped there, as well, but there's more to do. > > I think there's also a potential confusion among some of our > downstreams relating to our point releases. As Colin has pointed > out, they're really best thought of as "service packs", not OS > releases in a recent sense. Anyone building an embedded > product/appliance should probably take the perspective that they > will align delivery of an initial major release of their product > with the .1/.2 of a FreeBSD branch, and that they will then ship > occasional OS baseline updates to pick up new device drivers, bug > fixes, minor software features, etc, at intervals after that. > > 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. There was a non-trivial discussion of whether a 7.4 > should be cut at all, given its potential to product secteam (etc) > support commitments for three major branches for an extended > period. One thing we could do is better engage our downstream > communities into helping to extend the lifetime of -STABLE branches > by contributing to driver backports, long-term security maintenance, > etc. If (random vendor handwave, no insult to Intel meant) Intel > isn't interested in doing the backports of, say, {em, igb, ...} to > 7.x, then that needs to be pushed by someone with a product or > environment that requires them to be interested. We need to ensure > that there are continuing developer communities reflecting the > continuance of user communities. Our developer community is really suffering from the global economic slowdown.. People are more pushed at work and have other items pressing on their time. Just saying "I'm not supporting 7.x" is one way to lose some of the load. > > Robert > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 01:45:04 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 02D7B1065674; Wed, 22 Dec 2010 01:45:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-26.mx.aerioconnect.net [216.240.47.86]) by mx1.freebsd.org (Postfix) with ESMTP id D16488FC0A; Wed, 22 Dec 2010 01:45:03 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oBM1S4TR011873; Tue, 21 Dec 2010 17:28:04 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 018B32D6011; Tue, 21 Dec 2010 17:28:02 -0800 (PST) Message-ID: <4D11542E.8020402@freebsd.org> Date: Tue, 21 Dec 2010 17:28:14 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Robert Watson References: <201012211500.16131.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: mdf@freebsd.org, freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 01:45:04 -0000 On 12/21/10 2:28 PM, Robert Watson wrote: > On Tue, 21 Dec 2010, John Baldwin wrote: > >> I'm not entirely sure what the right answer is, but this is >> something that has worried me for a while. > > I see a few specific tensions to worry about, but they're not new > ones. The questions, really, are whether significant downstreams > run into the following problems: > > (1) Is our rate of change too great to allow useful upstreaming? > (Regardless > of "releases") > > (2) Is our security support lifetime for -STABLE branches too short > to allow > major products to be built on them and have the downstream product > lifetime largely live within our lifetime? I think so.. places I have worked tend to need about a year to get a new release of their product out the door in practice, and if we jump to a new release every year, then as they jump, so do we, so they are 2 revisions back "again". Generally a company wouldn't want to go through the pain of an OS upgrade more than about once in three years and often it's longer.. It IS a pain for them. they have to actually retool all their testing and they have to re-certify tons of stuff, such as their build procedures. ALSO, with a new release comes a new set of ports. and THEY have to be re-certified too. > > (3) Do old -STABLE branches stagnate too quickly with respect to > device driver > support such that they can't be used? it does happen new motherboards with new devices can be a problem, but don't forget that the motherboards have to be certified too so that adds a lag there too. > > (4) Are our point releases (.1 -> .2 -> .3) too large for > downstreams to roll > out as incremental point releases of their own products, > extending their > lifetimes? > > (5) Do ports/packages stop supporting a branch before the useful > lifetime of a > -STABLE-based branch, such that a derived produt has to locally > maintain > versions of {Apache, ...} rather than rely on project > infrastructure? > > Looking at recent events, it strikes me that (3) is actually the > most significant problem from the perspective of many vendors. > They'd like new device drivers to keep going back to 7.4, 7.5, and > 7.6, perhaps without significant software changes, so that they can > keep shipping a product that has to run on new hardware, but doesn't > require new OS features otherwise. Our improvements in thinking > about KPI have helped there, as well, but there's more to do. > > I think there's also a potential confusion among some of our > downstreams relating to our point releases. As Colin has pointed > out, they're really best thought of as "service packs", not OS > releases in a recent sense. Anyone building an embedded > product/appliance should probably take the perspective that they > will align delivery of an initial major release of their product > with the .1/.2 of a FreeBSD branch, and that they will then ship > occasional OS baseline updates to pick up new device drivers, bug > fixes, minor software features, etc, at intervals after that. > > 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. There was a non-trivial discussion of whether a 7.4 > should be cut at all, given its potential to product secteam (etc) > support commitments for three major branches for an extended > period. One thing we could do is better engage our downstream > communities into helping to extend the lifetime of -STABLE branches > by contributing to driver backports, long-term security maintenance, > etc. If (random vendor handwave, no insult to Intel meant) Intel > isn't interested in doing the backports of, say, {em, igb, ...} to > 7.x, then that needs to be pushed by someone with a product or > environment that requires them to be interested. We need to ensure > that there are continuing developer communities reflecting the > continuance of user communities. out developer community is really suffering from the global economic slowdown.. people are more pushed at work and have other items pressing on their time. Just saying "I'm not supporting 7.x" is one way to lose some of the load. > > Robert > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 07:40:46 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 5DE55106566B; Wed, 22 Dec 2010 07:40:46 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 097278FC14; Wed, 22 Dec 2010 07:40:45 +0000 (UTC) Received: from [192.168.0.72] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp3.one.com (Postfix) with ESMTP id 3ED0F2403C2A; Wed, 22 Dec 2010 07:21:56 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-955--984780088; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: Date: Wed, 22 Dec 2010 08:21:56 +0100 Message-Id: References: <201012211500.16131.jhb@freebsd.org> To: Robert Watson X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: mdf@freebsd.org, freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 07:40:46 -0000 --Apple-Mail-955--984780088 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 21/12/2010 kl. 23.28 skrev Robert Watson: >=20 > 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.=20= Which pretty much sums up a dilemma in the development of FreeBSD, I = think. Developers want users to try out their new shiny stuff, but users = don't want to spend time upgrading. I think one of many things that would be great to do is to improve the = usability and coverage of the regression tests. This would take at least = some of the burden off developers who want to MFC their work. We already = have the tinderboxes, Coverity and Clang Static Analyzer, but apart from = pho's stress tests we don't have any automated runtime testing (as far = as I know). Erik= --Apple-Mail-955--984780088-- From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 08:52:21 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 201E2106566B for ; Wed, 22 Dec 2010 08:52:21 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9739C8FC1A for ; Wed, 22 Dec 2010 08:52:20 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id oBM8q3JE039124; Wed, 22 Dec 2010 09:52:18 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oBM8q2Qi039123; Wed, 22 Dec 2010 09:52:03 +0100 (CET) (envelope-from olli) Date: Wed, 22 Dec 2010 09:52:03 +0100 (CET) Message-Id: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-arch User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Wed, 22 Dec 2010 09:52:18 +0100 (CET) Cc: 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: Wed, 22 Dec 2010 08:52:21 -0000 Erik Cederstrand wrote: > Den 21/12/2010 kl. 23.28 skrev Robert Watson: > > 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. > > Which pretty much sums up a dilemma in the development of > FreeBSD, I think. Developers want users to try out their new > shiny stuff, but users don't want to spend time upgrading. For me, personally, one significant problem is that I don't have the resources to easily run several versions of FreeBSD at home. I have a stable/8 installation, but I can't easily install another one (i.e. stable/7) at the same time, which would be required for testing and support. Well, I could set up a dual-boot environment somehow with a second disk, but that's time-consuming and annoying. I also have to confess that my motivation to spend time supporting an "old" branch is somewhat low because I don't use that branch myself anymore for some time already. Probably quite a few developers are in a similar situation, I guess. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 09:08:24 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 35AA910656A5 for ; Wed, 22 Dec 2010 09:08:24 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id C54838FC08 for ; Wed, 22 Dec 2010 09:08:23 +0000 (UTC) Received: from [192.168.0.72] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp1.one.com (Postfix) with ESMTP id 0B6931BC0701C; Wed, 22 Dec 2010 09:08:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-966--978394340; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> Date: Wed, 22 Dec 2010 10:08:21 +0100 Message-Id: References: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> To: Oliver Fromme X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@FreeBSD.ORG 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: Wed, 22 Dec 2010 09:08:24 -0000 --Apple-Mail-966--978394340 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 22/12/2010 kl. 09.52 skrev Oliver Fromme: > For me, personally, one significant problem is that I don't > have the resources to easily run several versions of FreeBSD > at home. Wouldn't a jail be sufficient for work that stays in userland? For kernel work, I think a virtual machine would be much easier than = dual-boot. Virtuialbox seems to support FreeBSD as both host and client = (http://www.freebsd.org/doc/handbook/virtualization-host.html), although = I haven't tried using FreeBSD as a host. Erik= --Apple-Mail-966--978394340-- From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 10:01:26 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 671B2106566B; Wed, 22 Dec 2010 10:01:26 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 218F88FC12; Wed, 22 Dec 2010 10:01:26 +0000 (UTC) Received: from [192.168.2.104] (host86-163-246-141.range86-163.btcentralplus.com [86.163.246.141]) by cyrus.watson.org (Postfix) with ESMTPSA id 12BC046B32; Wed, 22 Dec 2010 05:01:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4D11542E.8020402@freebsd.org> Date: Wed, 22 Dec 2010 10:01:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201012211500.16131.jhb@freebsd.org> <4D11542E.8020402@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1082) Cc: mdf@freebsd.org, freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 10:01:26 -0000 On 22 Dec 2010, at 01:28, Julian Elischer wrote: >> (2) Is our security support lifetime for -STABLE branches too short = to allow >> major products to be built on them and have the downstream product >> lifetime largely live within our lifetime? >=20 > I think so.. places I have worked tend to need about a year to get a = new release of their > product out the door in practice, and if we jump to a new release = every year, > then as they jump, so do we, so they are 2 revisions back "again". > Generally a company wouldn't want to go through the pain of an OS = upgrade more than > about once in three years and often it's longer.. It IS a pain for = them. > they have to actually retool all their testing and they have to = re-certify tons of > stuff, such as their build procedures. ALSO, with a new release comes = a new set of ports. > and THEY have to be re-certified too. The extended support release model was introduced to address these = specific concerns, providing non-".0" releases that had a guarantee of a = minimum of two years security support from the day of release. It would = be interesting to know if this has in fact led to a preference for = building products and providing services on extended support releases. Looking at our current supported release table, I see that all but one = of the releases on the table is an extended support release, including = all non-".0" 7.x releases to date. For example, 7.1-RELEASE was shipped = 4 January 2009, and will go out of support on 31 January, 2011. That's = not a bad run. And if vendors slide along 7-STABLE, then they'll get two = years from the final release of 7.4, likely supporting them through = early 2013. We also now provide binary updates and binary upgrades -- less valuable = to appliance builders, but it would appear widely used by = service-oriented consumers. Feedback from vendors / consumers who are = using extended releases in preference to regular releases would be = welcome -- is the current balance there right? Most of the feedback I'm getting suggests that our policy and technology = changes in the last few years, bringing in extended support releases and = binary updates, have addressed those problem areas. Instead the concern = is more that -STABLE branches wrap up too quickly: if you start building = a product against .0, and ship with .1, then you may find yourself = trying to continue to support the product several years past our last .x = release, causing problems running on contemporary hardware due to stale = hardware support. And I worry a lot about the upstream problem: vendors = who have significant local changes that never go upstream because HEAD = is two major releases ahead. But I think we need vendors to tell us specific stories about exactly = where and how things have gone wrong -- Matthew's post is valuable in = that sense, as sometimes we just hear "grumble grumble releases too = fast", or "running into device driver problems with 6.x!". I did some = work with a customer recently in which it was almost impossible to test = the changes we made upstream on their actual product release version on = the basis of a lack of device driver support in 6.x, which no longer = supports ethernet and storage chipsets on many current motherboards. Robert From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 10:08:51 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 7F8221065670; Wed, 22 Dec 2010 10:08:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 550C48FC08; Wed, 22 Dec 2010 10:08:51 +0000 (UTC) Received: from [192.168.2.104] (host86-163-246-141.range86-163.btcentralplus.com [86.163.246.141]) by cyrus.watson.org (Postfix) with ESMTPSA id 0911246B32; Wed, 22 Dec 2010 05:08:34 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Wed, 22 Dec 2010 10:08:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <96AE5824-D19C-4CD2-9DC1-98D7D314CE1A@FreeBSD.org> References: <201012211500.16131.jhb@freebsd.org> To: Erik Cederstrand X-Mailer: Apple Mail (2.1082) Cc: mdf@freebsd.org, freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 10:08:51 -0000 On 22 Dec 2010, at 07:21, Erik Cederstrand wrote: > Den 21/12/2010 kl. 23.28 skrev Robert Watson: >=20 >> 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.=20= >=20 > Which pretty much sums up a dilemma in the development of FreeBSD, I = think. Developers want users to try out their new shiny stuff, but users = don't want to spend time upgrading. >=20 > I think one of many things that would be great to do is to improve the = usability and coverage of the regression tests. This would take at least = some of the burden off developers who want to MFC their work. We already = have the tinderboxes, Coverity and Clang Static Analyzer, but apart from = pho's stress tests we don't have any automated runtime testing (as far = as I know). We have an increasing quantity of moderately decent regression tests in = our tools/regression tree, but they are only run selectively and = moderately rarely. A very nice contribution someone could make would be: (1) Make it so a recursive regression run is easily accessible -- "make = tests ; make runtests" -- in the root or similar. (2) Set up a "test tinderbox", perhaps using a hosted server at Sentex, = and perhaps using virtual machines so that many versions can be run. (3) Arrange a report website and report e-mails identifying the = introduction of regressions in branches. One known problem with our regression suite is that it includes tests = that crash certain versions (and ideally not later versions), so we'd = need something flexible enough to skip tests known to fail on particular = branches in some usefully configurable way. All this would be extremely useful -- we can then start pulling in more = regression tests written by other communities (other *BSD, etc), and = push people to produce more tests when they fix bugs. It would be = especially nice to run our security regression tests regularly (testing = permissions, ACL semantics, inter-process protections, etc). Robert= From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 10:41:05 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 B18371065670; Wed, 22 Dec 2010 10:41:05 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 03FD68FC1E; Wed, 22 Dec 2010 10:41:04 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oBMAQsx6006736 Received: from gkeramidas-glaptop.linux.gr ([74.125.57.36]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oBMAQsx6006736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Dec 2010 12:27:00 +0200 From: Giorgos Keramidas To: Erik Cederstrand , Ulrich =?iso-8859-1?Q?Sp=F6rle?= =?iso-8859-1?Q?in?= References: <201012211500.16131.jhb@freebsd.org> Date: Wed, 22 Dec 2010 11:26:53 +0100 In-Reply-To: (Erik Cederstrand's message of "Wed, 22 Dec 2010 08:21:56 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: mdf@freebsd.org, Robert Watson , freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 10:41:05 -0000 --=-=-= Content-Type: text/plain On Wed, 22 Dec 2010 08:21:56 +0100, Erik Cederstrand wrote: >Den 21/12/2010 kl. 23.28 skrev Robert Watson: >> 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. > > Which pretty much sums up a dilemma in the development of FreeBSD, I > think. Developers want users to try out their new shiny stuff, but > users don't want to spend time upgrading. > > I think one of many things that would be great to do is to improve the > usability and coverage of the regression tests. This would take at > least some of the burden off developers who want to MFC their work. We > already have the tinderboxes, Coverity and Clang Static Analyzer, but > apart from pho's stress tests we don't have any automated runtime > testing (as far as I know). Having a good automated testing suite is something that's been bugging me for a while. We might have one in early 2011 though. I've recently finished porting ATF from NetBSD to stable/8 and uploaded most of the work at bitbucket: https://bitbucket.org/keramida/atf-stable8/ Most of the atf-xxx tools work 'ok', but there are still a few rough edges to think about and patch into the ATF tools. Then I'm going forward to /head during the next couple of weeks. During the first 2-3 months of 2011, I'll be able to bring over most of the automated tests from NetBSD and then write a few more for our own code. Having a 'unified' approach to testing, e.g. the ability to patch usr.bin/foo/Makefile and add something like: TESTS?= tests/foo_startup \ tests/foo_socket \ tests/foo_stuff is something I've been talking about with uqs@. I'll definitely feel really awesome if we can run, for example, something like: cd /usr/src && make test to generate a nice, automated test report for the entire src/ codebase. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0R0m0ACgkQ1g+UGjGGA7YkWgCfUuTg4WdPDTd0bQlVRztQbB1h emsAn1pu9XzSU4YppFOyj/WpMIYiULjj =A/re -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 11:36:23 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 3AFD7106564A for ; Wed, 22 Dec 2010 11:36:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D2A438FC16 for ; Wed, 22 Dec 2010 11:36:22 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 708E346B2A; Wed, 22 Dec 2010 06:36:22 -0500 (EST) Date: Wed, 22 Dec 2010 11:36:22 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Erik Cederstrand In-Reply-To: Message-ID: References: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Oliver Fromme , freebsd-arch@FreeBSD.ORG 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: Wed, 22 Dec 2010 11:36:23 -0000 On Wed, 22 Dec 2010, Erik Cederstrand wrote: > Den 22/12/2010 kl. 09.52 skrev Oliver Fromme: > >> For me, personally, one significant problem is that I don't have the >> resources to easily run several versions of FreeBSD at home. > > Wouldn't a jail be sufficient for work that stays in userland? And there are also reference boxes in the FreeBSD.org cluster that all FreeBSD developers have access to -- for example, ref7-amd64.FreeBSD.org. > For kernel work, I think a virtual machine would be much easier than > dual-boot. Virtuialbox seems to support FreeBSD as both host and client > (http://www.freebsd.org/doc/handbook/virtualization-host.html), although I > haven't tried using FreeBSD as a host. I've had lots of success using Virtualbox, both hosting and hosted on, FreeBSD, in our teaching environment. I also run FreeBSD with significant success under VMWare on Mac OS X. FreeBSD on Xen is improving but I've not managed to get a kernel debugging setup working there as yet. Robert From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 12:38:36 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 278A21065673 for ; Wed, 22 Dec 2010 12:38:36 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id B085E8FC12 for ; Wed, 22 Dec 2010 12:38:35 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oBMCcY9e056268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 13:38:34 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1293021514; bh=xYVIoymjFDEVdcnnIbXfXWhix95SsPVJWe0ORi1vHcM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=IQhQSiXHzyEDJNRHfn57JLghTmKg43BUlcilv4IJ2oBCQaLXyqSFDfqzikJ7p+u0P 8Luc/MP0N9Uv5A5Jy5h8giZFLOEyZ4vgV3n5w5hWHPHCxjZT22KRJsvrM7Wt5Edqfi ipkLU/USP/cHrH23uU6xeZEJ8VPHCnVG/UlWRgZc= Date: Wed, 22 Dec 2010 13:38:34 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Oliver Fromme Message-ID: <20101222123834.GN23098@acme.spoerlein.net> Mail-Followup-To: Oliver Fromme , freebsd-arch@freebsd.org References: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 12:38:36 -0000 On Wed, 22.12.2010 at 09:52:03 +0100, Oliver Fromme wrote: > Erik Cederstrand wrote: > > Den 21/12/2010 kl. 23.28 skrev Robert Watson: > > > 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. > > > > Which pretty much sums up a dilemma in the development of > > FreeBSD, I think. Developers want users to try out their new > > shiny stuff, but users don't want to spend time upgrading. > > For me, personally, one significant problem is that I don't > have the resources to easily run several versions of FreeBSD > at home. > > I have a stable/8 installation, but I can't easily install > another one (i.e. stable/7) at the same time, which would > be required for testing and support. Well, I could set up > a dual-boot environment somehow with a second disk, but > that's time-consuming and annoying. > > I also have to confess that my motivation to spend time > supporting an "old" branch is somewhat low because I don't > use that branch myself anymore for some time already. > Probably quite a few developers are in a similar situation, > I guess. I think this is the core "problem". Statistics[1] show, that most developers run some form of -CURRENT and also have some machines running the latest -STABLE tree. So, naturally, no-one is too thrilled about testing stuff for the pre-latest -STABLE tree. We should not try to have two stable branches overlap for that long. We are spreading our resources too thin here. CURRENT+STABLE makes sense, always. CURRENT+STABLE+STABLE might be nice for vendors, but in the end it's the developers doing the work, and they mostly only care about the one of the STABLES. We should not delude ourselves into thinking we can easily support two STABLE branches, that's just not happening. Uli [1] I just made this statistic up. From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 14:35:16 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 F1BB6106566B for ; Wed, 22 Dec 2010 14:35:16 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 769368FC19 for ; Wed, 22 Dec 2010 14:35:16 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id oBMEYwI6051203; Wed, 22 Dec 2010 15:35:13 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oBMEYwXA051201; Wed, 22 Dec 2010 15:34:58 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201012221434.oBMEYwXA051201@lurza.secnetix.de> To: erik@cederstrand.dk (Erik Cederstrand) Date: Wed, 22 Dec 2010 15:34:58 +0100 (CET) In-Reply-To: X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Wed, 22 Dec 2010 15:35:14 +0100 (CET) Cc: freebsd-arch@FreeBSD.ORG 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: Wed, 22 Dec 2010 14:35:17 -0000 Erik Cederstrand wrote: > Den 22/12/2010 kl. 09.52 skrev Oliver Fromme: > > > For me, personally, one significant problem is that I don't > > have the resources to easily run several versions of FreeBSD > > at home. > > Wouldn't a jail be sufficient for work that stays in userland? > For kernel work, I think a virtual machine would be much easier > than dual-boot. Well, it depends. In this thread, device drivers were mentioned in particular. You can't test those in jails or in virtual machines. For example, I would like to merge r210819 to stable/8 (it will have to wait until after the freeze, of course). But I can't easily test it on stable/7 because it's hardware-related. So I won't merge it to stable/7. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 14:55:40 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 3F7641065675 for ; Wed, 22 Dec 2010 14:55:40 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id D05198FC1B for ; Wed, 22 Dec 2010 14:55:39 +0000 (UTC) Received: from [192.168.0.72] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp1.one.com (Postfix) with ESMTP id 2DAF71BC0703B; Wed, 22 Dec 2010 14:55:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-1004--957558213; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <201012221434.oBMEYwXA051201@lurza.secnetix.de> Date: Wed, 22 Dec 2010 15:55:37 +0100 Message-Id: <958ECD0E-9825-4914-895F-D016CDC01D9B@cederstrand.dk> References: <201012221434.oBMEYwXA051201@lurza.secnetix.de> To: Oliver Fromme X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@FreeBSD.ORG 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: Wed, 22 Dec 2010 14:55:40 -0000 --Apple-Mail-1004--957558213 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 22/12/2010 kl. 15.34 skrev Oliver Fromme: >=20 > Erik Cederstrand wrote: >> Den 22/12/2010 kl. 09.52 skrev Oliver Fromme: >>=20 >>> For me, personally, one significant problem is that I don't >>> have the resources to easily run several versions of FreeBSD >>> at home. >>=20 >> Wouldn't a jail be sufficient for work that stays in userland? >> For kernel work, I think a virtual machine would be much easier >> than dual-boot. >=20 > Well, it depends. In this thread, device drivers were > mentioned in particular. You can't test those in jails > or in virtual machines. You have a point there. Hardware vendors should start offering virtual = hardware. At a discount, of course :-) Erik= --Apple-Mail-1004--957558213-- From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 14:58:36 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 DA9C0106564A; Wed, 22 Dec 2010 14:58:35 +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 AF79F8FC13; Wed, 22 Dec 2010 14:58:35 +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 59C5146B39; Wed, 22 Dec 2010 09:58:35 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C827E8A009; Wed, 22 Dec 2010 09:58:33 -0500 (EST) From: John Baldwin To: "Poul-Henning Kamp" Date: Wed, 22 Dec 2010 07:54:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <9194.1292972364@critter.freebsd.dk> In-Reply-To: <9194.1292972364@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201012220754.15161.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Dec 2010 09:58:33 -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: mdf@freebsd.org, Robert Watson , freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 14:58:36 -0000 On Tuesday, December 21, 2010 5:59:24 pm Poul-Henning Kamp wrote: > In message , 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. > > If there are no developers who has an interest in MFC'ing back to 7.x, > MFCs will not happen, no matter how much we talk about it. There is a fly in the ointment here though in that some developers _do_ have an interest in doing MFC's to 7.x and having a longer 7.x branch (for example). However, our current release structure makes that more painful since you have to merge changes across three branches. If .0 releases were more spread out then supporting 7.x would no longer meaning supporting 3 active branches, but back to just 2 branches. For much of the problems I need to solve at work, I am developing on 7.x (since that is what we use currently) and then "forwardporting" two branches forward to 9. > Trying to force developers to maintain multiple branches will not work, > they have to take an interest. Yes, but if we chose to have longer -stable branches we could also adjust our release schedule to compensate. We have _chosen_ this current model of relatively short -stable branches and frequent X.0 releases. > Companies who use Open Source are not adverse to paying for the > service they get, but somebody needs to make it easy for them. You should be careful to not ignore the feedback of companies who already _are_ paying for this service in some fashion (e.g. by employing committers who are allowed to participate in the community as well such as mdf@ or myself). These companies are already doing that, but one could make the argument that our current release structure works against their efforts. All that said, I do see benefits to the current model as well, and I am still playing around with ideas to see if I just need to switch to new major versions sooner. Maybe with FreeBSD 10 we should just follow the OS X model where major versions are actually minor versions instead. :) (So FreeBSD 10 would be 10.0, 11 be 10.1, etc.) People would certainly treat 10.0.1 and 10.0.2 as service packs at that point. :) Given that the merge from 6 to 7 and 7 to 8 has been far simpler than previous major versions, some of the trepidation from vendors about frequent releases may in fact be more of a perception problem that something like 10.x.y (or even 9.x.y?) could resolve. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 14:59:09 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 51DB21065675 for ; Wed, 22 Dec 2010 14:59:09 +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 201BF8FC0C for ; Wed, 22 Dec 2010 14:59:09 +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 BF85146B5B; Wed, 22 Dec 2010 09:59:08 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E0E368A01D; Wed, 22 Dec 2010 09:59:07 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 22 Dec 2010 09:42:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> <20101222123834.GN23098@acme.spoerlein.net> In-Reply-To: <20101222123834.GN23098@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201012220942.26579.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Dec 2010 09:59:08 -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: Ulrich =?iso-8859-1?q?Sp=F6rlein?= , Oliver Fromme 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: Wed, 22 Dec 2010 14:59:09 -0000 On Wednesday, December 22, 2010 7:38:34 am Ulrich Sp=F6rlein wrote: > On Wed, 22.12.2010 at 09:52:03 +0100, Oliver Fromme wrote: > > Erik Cederstrand wrote: > > > Den 21/12/2010 kl. 23.28 skrev Robert Watson: > > > > 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.=20 > > >=20 > > > Which pretty much sums up a dilemma in the development of > > > FreeBSD, I think. Developers want users to try out their new > > > shiny stuff, but users don't want to spend time upgrading. > >=20 > > For me, personally, one significant problem is that I don't > > have the resources to easily run several versions of FreeBSD > > at home. > >=20 > > I have a stable/8 installation, but I can't easily install > > another one (i.e. stable/7) at the same time, which would > > be required for testing and support. Well, I could set up > > a dual-boot environment somehow with a second disk, but > > that's time-consuming and annoying. > >=20 > > I also have to confess that my motivation to spend time > > supporting an "old" branch is somewhat low because I don't > > use that branch myself anymore for some time already. > > Probably quite a few developers are in a similar situation, > > I guess. >=20 > I think this is the core "problem". Statistics[1] show, that most > developers run some form of -CURRENT and also have some machines running > the latest -STABLE tree. So, naturally, no-one is too thrilled about > testing stuff for the pre-latest -STABLE tree. >=20 > We should not try to have two stable branches overlap for that long. We > are spreading our resources too thin here. >=20 > CURRENT+STABLE makes sense, always. CURRENT+STABLE+STABLE might be nice > for vendors, but in the end it's the developers doing the work, and they > mostly only care about the one of the STABLES. We should not delude > ourselves into thinking we can easily support two STABLE branches, > that's just not happening. Actually, CURRENT+STABLE+STABLE doesn't really work for the vendors either versus a CURRENT+STABLE where STABLE branches were created less often and lasted longer. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 15:49:55 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 989861065670 for ; Wed, 22 Dec 2010 15:49:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 305298FC08 for ; Wed, 22 Dec 2010 15:49:54 +0000 (UTC) Received: by wyf19 with SMTP id 19so5090550wyf.13 for ; Wed, 22 Dec 2010 07:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=9XaQwqVJElCBHE6gudVzcEnIAGe8pX5BYYPRW+Oic5Q=; b=TQEOt6LuXR2nM9mlL/6XbsmypSyc/NIuvhQHg0+710ERzddDqEkDzx8lfFV0QEBAIG lYK2MCHJT6sZMZWSvCoYfuI7Kw+S0cs2ICmpcF6dI1XTSEzMz7I5XbEXbXcm8GfsLNiS kde/ogeTxAElDawMzL4a/Iw3S39sw2IhUIQdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=iPt/nd1OAIHSl8MByg/dWCmprocjfeyu+/LCunRsqGmTkWh8lPTsnj3Yhq/N7Tqehy T12VShNMP9xJUPisSpgGA62fS7ovaNK65UntUrdU/q3LrGdLiYG/dukQIc8QH4JDqbOW zHNINLW/Dl81OOFuyHeJ2KGDDtZ2662BWkM/s= MIME-Version: 1.0 Received: by 10.216.154.3 with SMTP id g3mr7016023wek.3.1293031441360; Wed, 22 Dec 2010 07:24:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.173.213 with HTTP; Wed, 22 Dec 2010 07:24:01 -0800 (PST) Date: Wed, 22 Dec 2010 23:24:01 +0800 X-Google-Sender-Auth: Jm0BPZCHhdfnxOvIK-dbhwaf1rU Message-ID: From: Adrian Chadd To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Initial 802.11n / ath support merge plan 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: Wed, 22 Dec 2010 15:49:55 -0000 Hi all, I'd like to start the process for merging in my initial 802.11n support into -HEAD and -8. My 802.11n work can be broken into a few chunks. The details aren't exhaustive, but they give a good idea of the breadth of the development I've been doing here. What I'd like to do is commit bits and pieces of work, rather than just doing a big "code drop" that changes a whole lot of stuff. Then let it bake for time, let users test it, etc, before moving onto the next bits. * net80211 work: + mostly to handle some of the 802.11n station related bits - enough for 2.4ghz HT/20 association. I've not tried 5ghz 11n; and HT/40 doesn't yet seem to work for whatever reason; * if_ath HAL work: + move 91xx and 92xx support into different chipset directories in the ath_hal directory + added support for the AR9100 + merged in some changes from Linux ath9k + some chipset reset path refactoring/restructuring + a set of "hardware ops" to abstract out the per-chipset differences of the AR5416 and later chips - again, based on ath9k - to make it easier in the future to port ath9k code to our HAL + added new hooks to tidy up handling TX descriptor completion for multi-rate stuff * ath_rate work: + ath_rate_sample now knows about _basic_ 802.11n stuff; enough to TX MCS rates + ath_rate_sample now calls a HAL method to pull the multi-rate TX completion data out, rather than fondling the TX descriptors directly + ath_rate_sample provides the TX rate list as an array, rather than directly calling the HAL to set up the TX descriptor * if_ath work: + refactored out the TX, RX, beacon, TDMA and debug code into separate source files + enabled some 802.11n related bits facing net80211 + added basic non-aggregate 11n TX support (incomplete so far) + disabled multicast hw crypto for now - this breaks AES-CCMP encryption which is needed for 11n WPA What I'd like to do in the short short term: * merge in the net80211 changes into HEAD, then backport those to RELENG_8. This sets up the scene to support 802.11n in station mode, but shouldn't break existing setups; * maintain the ath/ath_hal/ath_rate stuff in my GIT tree for now, and release drop-in snapshots for people to play with (and I've verified that the code does work under RELENG_8 :-); What I'd like to do moving forward, beginning in early Jan 2011: * Bring over the changes to the rate control modules to tidy up how they fondle the hardware - these changes are reasonably self-contained * Bring over the ath_hal changes. This brings over the AR9100 support, the re-factored HAL structure and changes from ath9k. I could try to separate that work out into separate patches but it's likely going to be a lot of of work for little gain. * Let users then test the AR5416, AR9160, AR9280, AR9285 support - and then find/fix whatever bugs crop up there (and the bugs that still exist!) * Finally, once that's done, look at attacking the if_ath code to enable the initial 11n support. What do people think? Adrian From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 16:55:07 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 CC9501065675; Wed, 22 Dec 2010 16:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 78B668FC13; Wed, 22 Dec 2010 16:55:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CF81F41C7A8; Wed, 22 Dec 2010 17:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id jZj5PDmcgAEV; Wed, 22 Dec 2010 17:55:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id DEE6041C7A3; Wed, 22 Dec 2010 17:55:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7A22F4448F3; Wed, 22 Dec 2010 16:54:28 +0000 (UTC) Date: Wed, 22 Dec 2010 16:54:28 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Adrian Chadd In-Reply-To: Message-ID: <20101222165010.O6126@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Initial 802.11n / ath support merge plan 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: Wed, 22 Dec 2010 16:55:07 -0000 On Wed, 22 Dec 2010, Adrian Chadd wrote: ... > What I'd like to do in the short short term: > > * merge in the net80211 changes into HEAD, then backport those to > RELENG_8. This sets up the scene to support 802.11n in station mode, > but shouldn't break existing setups; > * maintain the ath/ath_hal/ath_rate stuff in my GIT tree for now, and > release drop-in snapshots for people to play with (and I've verified > that the code does work under RELENG_8 :-); > > What I'd like to do moving forward, beginning in early Jan 2011: > > * Bring over the changes to the rate control modules to tidy up how > they fondle the hardware - these changes are reasonably self-contained > * Bring over the ath_hal changes. This brings over the AR9100 support, > the re-factored HAL structure and changes from ath9k. I could try to > separate that work out into separate patches but it's likely going to > be a lot of of work for little gain. > * Let users then test the AR5416, AR9160, AR9280, AR9285 support - and > then find/fix whatever bugs crop up there (and the bugs that still > exist!) > * Finally, once that's done, look at attacking the if_ath code to > enable the initial 11n support. > > What do people think? Sounds like great work:-) As 8 is still frozen and you want to setttle this in HEAD for more than 3 days anyway have you considered posting a diff (or the diffs) for HEAD (and stable/8) to net@ for example to get broader testing? You might have done this already? It might be more painful to see if you get feedback but having things tested upfront rather than needing a couple of extra fixup commits later sounds wise. I am especially asking for the point of general infrastructure changes that affect everyone. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 17:13:05 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 A0334106575C for ; Wed, 22 Dec 2010 17:13:05 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f48.google.com (mail-bw0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id 35BDD8FC17 for ; Wed, 22 Dec 2010 17:13:04 +0000 (UTC) Received: by bwz8 with SMTP id 8so5535175bwz.7 for ; Wed, 22 Dec 2010 09:13:04 -0800 (PST) Received: by 10.204.60.79 with SMTP id o15mr6053406bkh.25.1293036634420; Wed, 22 Dec 2010 08:50:34 -0800 (PST) Received: from julie.lab.techwires.net (dslb-094-217-133-069.pools.arcor-ip.net [94.217.133.69]) by mx.google.com with ESMTPS id q18sm5145048bka.15.2010.12.22.08.50.32 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Dec 2010 08:50:32 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Wed, 22 Dec 2010 17:49:05 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012221749.05927.bschmidt@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Initial 802.11n / ath support merge plan 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: Wed, 22 Dec 2010 17:13:05 -0000 On Wednesday 22 December 2010 16:24:01 Adrian Chadd wrote: > Hi all, > > I'd like to start the process for merging in my initial 802.11n > support into -HEAD and -8. > > My 802.11n work can be broken into a few chunks. The details aren't > exhaustive, but they give a good idea of the breadth of the > development I've been doing here. > > What I'd like to do is commit bits and pieces of work, rather than > just doing a big "code drop" that changes a whole lot of stuff. Then > let it bake for time, let users test it, etc, before moving onto the > next bits. > > * net80211 work: > + mostly to handle some of the 802.11n station related bits - enough > for 2.4ghz HT/20 association. I've not tried 5ghz 11n; and HT/40 > doesn't yet seem to work for whatever reason; > > * if_ath HAL work: > + move 91xx and 92xx support into different chipset directories in > the ath_hal directory > + added support for the AR9100 > + merged in some changes from Linux ath9k > + some chipset reset path refactoring/restructuring > + a set of "hardware ops" to abstract out the per-chipset > differences of the AR5416 and later chips - again, based on ath9k - to > make it easier in the future to port ath9k code to our HAL > + added new hooks to tidy up handling TX descriptor completion for > multi-rate stuff > > * ath_rate work: > + ath_rate_sample now knows about _basic_ 802.11n stuff; enough to > TX MCS rates > + ath_rate_sample now calls a HAL method to pull the multi-rate TX > completion data out, rather than fondling the TX descriptors directly > + ath_rate_sample provides the TX rate list as an array, rather than > directly calling the HAL to set up the TX descriptor > > * if_ath work: > + refactored out the TX, RX, beacon, TDMA and debug code into > separate source files > + enabled some 802.11n related bits facing net80211 > + added basic non-aggregate 11n TX support (incomplete so far) > + disabled multicast hw crypto for now - this breaks AES-CCMP > encryption which is needed for 11n WPA > > What I'd like to do in the short short term: > > * merge in the net80211 changes into HEAD, then backport those to > RELENG_8. This sets up the scene to support 802.11n in station mode, > but shouldn't break existing setups; > * maintain the ath/ath_hal/ath_rate stuff in my GIT tree for now, and > release drop-in snapshots for people to play with (and I've verified > that the code does work under RELENG_8 :-); > > What I'd like to do moving forward, beginning in early Jan 2011: > > * Bring over the changes to the rate control modules to tidy up how > they fondle the hardware - these changes are reasonably self-contained > * Bring over the ath_hal changes. This brings over the AR9100 support, > the re-factored HAL structure and changes from ath9k. I could try to > separate that work out into separate patches but it's likely going to > be a lot of of work for little gain. > * Let users then test the AR5416, AR9160, AR9280, AR9285 support - and > then find/fix whatever bugs crop up there (and the bugs that still > exist!) > * Finally, once that's done, look at attacking the if_ath code to > enable the initial 11n support. > > What do people think? go, go, go! Let me know if I can help out somewhere. -- Bernhard From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 17:59:04 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 C28951065670 for ; Wed, 22 Dec 2010 17:59:04 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD728FC12 for ; Wed, 22 Dec 2010 17:59:04 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.3/8.13.6) with ESMTP id oBMHj7Wg039593 for ; Wed, 22 Dec 2010 11:45:07 -0600 (CST) (envelope-from mike@mail.karels.net) Message-Id: <201012221745.oBMHj7Wg039593@mail.karels.net> To: freebsd-arch@freebsd.org From: Mike Karels Date: Wed, 22 Dec 2010 11:45:07 -0600 Sender: mike@karels.net Subject: Re: Schedule for releases X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mike@karels.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:59:04 -0000 I'm replying to the thread as a whole rather than a specific message. I work for a security appliance vendor that may represent the worst case when it comes to supporting older FreeBSD releases. I spend a fair amount of time back-porting device drivers and other hardware support so we can run the older releases (back to 6.3) on new hardware. In fact, we haven't shipped a release based on 6.3 for two years, but we're still patching it to run on new hardware. Why so old, a FreeBSD developer asked recently? There are a number of factors, which are additive: - We have significant modifications to the system that have to be merged and retested in an OS upgrade. Of course, there is additional testing for an OS upgrade itself. - We try to do OS upgrades early in our release cycle, so our own software development will be done on the delivery platform. - We generally consider OS upgrades only for a major release of our own, usually a .0. These come less often than FreeBSD .0 releases. - We go through government certifications for some of our releases, but by no means all. These certifications take a long time. Many of our customers have to run the certified versions. We can sneak in new device drivers as a patch, but not an OS upgrade. - Security customers tend not to run our .0 releases, and often prefer not to upgrade to a major release for some time, e.g. a major network upgrade. For management and policy reasons, they want to keep their appliances at the same version, and upgrade to a major release is a lot of work. Even our internal customers aren't running a recent release. A few comments based on the above: - We realize that we're running an older release, and don't expect most of the improvements to be MFC'd. We know that we'll have to do some of the work to back-port drivers, etc, including testing. That said, it is helpful when the developers anticipate back-ports, e.g. leaving ifdefs in place for older versions of bus interface calls, vlan tags, etc. - We sometimes back-port other changes, such as TCP locking fixes that help performance. Considering some such things for MFC would be desirable. - Those of us doing backports could probably do a better job of sharing the results. On the other hand, I'm generally backporting to a specific release (currently 6.3 or 7.2) rather than -stable, and we're testing our software rather than FreeBSD. - Less frequent FreeBSD .0 releases would probabaly help us. - Changing the naming conventions might matter to some users, but wouldn't affect us much. I'm currently pushing for a 7.2 to 8.1 or 8.2 upgrade as part of a dot release, and the naming doesn't really matter to us. Mike From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 20:57:32 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 731651065675 for ; Wed, 22 Dec 2010 20:57:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5075C8FC16 for ; Wed, 22 Dec 2010 20:57:32 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CC0AC46B49; Wed, 22 Dec 2010 15:57:31 -0500 (EST) Date: Wed, 22 Dec 2010 20:57:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Karels In-Reply-To: <201012221745.oBMHj7Wg039593@mail.karels.net> Message-ID: References: <201012221745.oBMHj7Wg039593@mail.karels.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 20:57:32 -0000 On Wed, 22 Dec 2010, Mike Karels wrote: > - We sometimes back-port other changes, such as TCP locking fixes that help > performance. Considering some such things for MFC would be desirable. Just to comment on the specifics of this one: over the cource of 6.x, 7.x, and 8.x, I non-trivially improved locking in the TCP/UDP code. Some of those changes could be backported -- others couldn't be. Part of the reason I didn't merge some changes was our increasing attempt to provide stable KPIs and KBIs for kernel modules, especially as TCP offload support in device drivers became a reality. We're now going to hit the same issue in 9.x: I'm about to commit significant network stack locking and work distribution changes to improve TCP and UDP scalability, leading to multiplied performance on parallel systems. As of the interpretation of KPI/KBI compatibility we have today, these cannot be MFC'd to 8.x. I think there's a motivation to revisit our thinking on KPI/KBI so that we can merge them to 8.x in the future; I'll say more about this on the net@ mailing list in a month or so once the changes are in 9.x and have shaken out a bit. Robert From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 23:26:04 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 D78B21065675; Wed, 22 Dec 2010 23:26:04 +0000 (UTC) (envelope-from ade@FreeBSD.org) Received: from panix.lovett.com (panix.lovett.com [166.84.7.128]) by mx1.freebsd.org (Postfix) with ESMTP id AE1B48FC0A; Wed, 22 Dec 2010 23:26:04 +0000 (UTC) Received: from cpe-66-68-128-204.austin.res.rr.com ([66.68.128.204] helo=[172.16.32.150]) by panix.lovett.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PVXZz-0007Dj-W2; Wed, 22 Dec 2010 22:54:44 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ade Lovett In-Reply-To: <201012220942.26579.jhb@freebsd.org> Date: Wed, 22 Dec 2010 16:54:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1619C89A-904D-4C1E-BD53-75763E7A8CB0@FreeBSD.org> References: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> <20101222123834.GN23098@acme.spoerlein.net> <201012220942.26579.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1082) Cc: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= , Oliver Fromme , Ade Lovett , freebsd-arch@freebsd.org 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: Wed, 22 Dec 2010 23:26:04 -0000 On Dec 22, 2010, at 08:42 , John Baldwin wrote: > Actually, CURRENT+STABLE+STABLE doesn't really work for the vendors = either > versus a CURRENT+STABLE where STABLE branches were created less often = and > lasted longer. CURRENT+STABLE+STABLE doesn't really work too well for ports/packages = either. Indeed, it was only recently that it was = CURRENT+STABLE+STABLE+STABLE .. and there are sufficient enough changes = from 6.x->9.x (now 7.x->9.x) that causes a reasonable amount of pain. = 'grep -R OSVERSION /usr/ports' for infrastructure stuff (give or take): [lab:/usr/ports] 54% grep -R OSVERSION Mk/* | grep if | wc -l 16 for the tree as a whole: [lab:/usr/ports] 55% grep -R OSVERSION . | grep if | wc -l 1262 Further compounded by i386, amd64, and the few other architectures that = get things built for them on a semi-regular basis. Keeping packages up to date for all these combinations is, at a guess, = an order of magnitude more time-consuming than say, 'cd /usr/src; make = universe' and whilst the clang/llvm folks are doing an excellent job, in = the not too distant future, ports/ will be faced with = interesting_times.cn handling builds for two completely different base = compilers. Anything more than one STABLE, and one CURRENT, and folks will be = getting upset somewhere along the way, particularly when using FreeBSD = (src+ports/packages+doc) vs FreeBSD (src only). -aDe From owner-freebsd-arch@FreeBSD.ORG Thu Dec 23 00:30:54 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 8510D106566B for ; Thu, 23 Dec 2010 00:30:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 184AD8FC16 for ; Thu, 23 Dec 2010 00:30:53 +0000 (UTC) Received: by wwi17 with SMTP id 17so5663927wwi.1 for ; Wed, 22 Dec 2010 16:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=24+84aRO/pDmWL9m6SFbZU6whRlLPcNS/xjy90xPAPM=; b=szLl9yH1wkQ9xVvPH3SLnehK0sIWn/BF8QDZ/ScBkWR2iTDnrCdKWXnMR9HpsI4YeG 5vakSwaS3NPYHk6z7L+7DL2t+T3VI7OsKgr6mvd7MzAK8kyCDeztUqtYFXGP3l9hA59I VoWmWAMeIGuglx0P1ujN+CVSrazdvicD8XPgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Okz7l7KWLqKFlYTXZzBO8oftMIK5HMC4xExoo1OvHwB2LF1QO0cJcprKzPxmaBWKci eKUuyIwTd9OY/YsBQNuXhffR8zcFfkRVykBLN0+diHkS5PXQ2X4ElY9xiOMjGJuCfDF7 MTbn40t1GxIWHLajsRYxS5oQfO/yduLwgpLVU= MIME-Version: 1.0 Received: by 10.216.180.76 with SMTP id i54mr12223459wem.33.1293064251795; Wed, 22 Dec 2010 16:30:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.173.213 with HTTP; Wed, 22 Dec 2010 16:30:51 -0800 (PST) In-Reply-To: <20101222165010.O6126@maildrop.int.zabbadoz.net> References: <20101222165010.O6126@maildrop.int.zabbadoz.net> Date: Thu, 23 Dec 2010 08:30:51 +0800 X-Google-Sender-Auth: eFPUW-vwnSBXRtguULcHeNPaMjo Message-ID: From: Adrian Chadd To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Initial 802.11n / ath support merge plan 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: Thu, 23 Dec 2010 00:30:54 -0000 On 23 December 2010 00:54, Bjoern A. Zeeb wrote: [snip my 11n plans] >> What do people think? > > Sounds like great work:-) Ta! > As 8 is still frozen and you want to setttle this in HEAD for more > than 3 days anyway have you considered posting a diff (or the diffs) > for HEAD (and stable/8) to net@ for example to get broader testing? > You might have done this already? =A0 It might be more painful to see if > you get feedback but having things tested upfront rather than needing > a couple of extra fixup commits later sounds wise. =A0I am especially > asking for the point of general infrastructure changes that affect > everyone. I'll post diffs for the net80211 changes so they may be reviewed/tested. Those changes shouldn't -change- the existing case (ie, non-802.11n.) But they're a pre-requisite to actually have a functioning 802.11n station. Adrian From owner-freebsd-arch@FreeBSD.ORG Thu Dec 23 09:37:50 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 433F0106566C; Thu, 23 Dec 2010 09:37:50 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 901E98FC12; Thu, 23 Dec 2010 09:37:49 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.2, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_50 0.80) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oBN9bXv5012517 Received: from gkeramidas-glaptop.linux.gr ([74.125.57.36]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oBN9bXv5012517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Dec 2010 11:37:43 +0200 From: Giorgos Keramidas To: John Baldwin References: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> <20101222123834.GN23098@acme.spoerlein.net> <201012220942.26579.jhb@freebsd.org> Date: Thu, 23 Dec 2010 10:37:32 +0100 In-Reply-To: <201012220942.26579.jhb@freebsd.org> (John Baldwin's message of "Wed, 22 Dec 2010 09:42:26 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= , Oliver Fromme , freebsd-arch@freebsd.org 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: Thu, 23 Dec 2010 09:37:50 -0000 On Wed, 22 Dec 2010 09:42:26 -0500, John Baldwin wrote: > On Wednesday, December 22, 2010 7:38:34 am Ulrich Sp=F6rlein wrote: >> I think this is the core "problem". Statistics[1] show, that most >> developers run some form of -CURRENT and also have some machines >> running the latest -STABLE tree. So, naturally, no-one is too >> thrilled about testing stuff for the pre-latest -STABLE tree. >> >> We should not try to have two stable branches overlap for that >> long. We are spreading our resources too thin here. >> >> CURRENT+STABLE makes sense, always. CURRENT+STABLE+STABLE might be >> nice for vendors, but in the end it's the developers doing the work, >> and they mostly only care about the one of the STABLES. We should not >> delude ourselves into thinking we can easily support two STABLE >> branches, that's just not happening. > > Actually, CURRENT+STABLE+STABLE doesn't really work for the vendors > either versus a CURRENT+STABLE where STABLE branches were created less > often and lasted longer. Exactly! My intuition says that vendors don't really care if there are two, three, or any number or 'old stable' branches. All they care is that the stable branch they just baselined their source tree on will live long enough for their product to ship at least a couple of GA versions. I've worked at companies where we built products on Solaris 8, for example, long after the GA of Solaris 10. The fact that we had to jump forward across two major versions was slightly painful and required a non-negligible amount of manpower to pull it off. The fact that Solaris 9 was also 'supported' never really played much of a role in the decision to move to the latest release version. It was always a feature-based decision and not a time-based one. From owner-freebsd-arch@FreeBSD.ORG Thu Dec 23 19:36:09 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 611D41065673; Thu, 23 Dec 2010 19:36:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 284108FC12; Thu, 23 Dec 2010 19:36:08 +0000 (UTC) Received: by pxi1 with SMTP id 1so1208586pxi.13 for ; Thu, 23 Dec 2010 11:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=UWSXIxrC5CTvH+Mfrq3zrBBXgM13InXCurtvTCyjJ8I=; b=gYNz7W6My3+XkR1W9xc0z6ZcepmtwOmkhye1RbUMcr5aIqdNliDsMxqDfvq7kXSlCj NZMf9SOnhOK1wpLZrPaqZlw/edMZsLVga7r3+4TezM8nmwN+iCg+Ibp9Q1vdq32oqI3L 7Zx/CNiXkBHJGsyHzV3V9Xx63k6h9MM9zu+L8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=O6FBcpTtV5g04GQiXUDCggkdLyXqjkXxwRUNLlFx2nU0aDGaAzhnJWebFm09lnkY0z pLDOfbgGms+oDWAj+kqtFPVC+4OKk1wc5BKCPs2D5n5ZpvFySErbVxCiK3eIzASLpX6a 2tdJOzwjgn8zkpA1LvAuABCFqRKV6UISnRs0I= Received: by 10.142.11.5 with SMTP id 5mr6750853wfk.312.1293132965525; Thu, 23 Dec 2010 11:36:05 -0800 (PST) Received: from [10.16.14.246] ([166.205.143.245]) by mx.google.com with ESMTPS id w14sm11119546wfd.6.2010.12.23.11.35.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 11:36:02 -0800 (PST) References: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> <20101222123834.GN23098@acme.spoerlein.net> <201012220942.26579.jhb@freebsd.org> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <49D0851F-3145-43E4-BA22-24E4201BE496@gmail.com> X-Mailer: iPhone Mail (8C148) From: Garrett Cooper Date: Thu, 23 Dec 2010 11:35:44 -0800 To: Giorgos Keramidas Cc: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= , Oliver Fromme , "freebsd-arch@freebsd.org" 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: Thu, 23 Dec 2010 19:36:09 -0000 On Dec 23, 2010, at 1:37 AM, Giorgos Keramidas wr= ote: > On Wed, 22 Dec 2010 09:42:26 -0500, John Baldwin wrote: >> On Wednesday, December 22, 2010 7:38:34 am Ulrich Sp=C3=B6rlein wrote: >>> I think this is the core "problem". Statistics[1] show, that most >>> developers run some form of -CURRENT and also have some machines >>> running the latest -STABLE tree. So, naturally, no-one is too >>> thrilled about testing stuff for the pre-latest -STABLE tree. >>>=20 >>> We should not try to have two stable branches overlap for that >>> long. We are spreading our resources too thin here. >>>=20 >>> CURRENT+STABLE makes sense, always. CURRENT+STABLE+STABLE might be >>> nice for vendors, but in the end it's the developers doing the work, >>> and they mostly only care about the one of the STABLES. We should not >>> delude ourselves into thinking we can easily support two STABLE >>> branches, that's just not happening. >>=20 >> Actually, CURRENT+STABLE+STABLE doesn't really work for the vendors >> either versus a CURRENT+STABLE where STABLE branches were created less >> often and lasted longer. >=20 > Exactly! My intuition says that vendors don't really care if there are > two, three, or any number or 'old stable' branches. All they care is > that the stable branch they just baselined their source tree on will > live long enough for their product to ship at least a couple of GA > versions. >=20 > I've worked at companies where we built products on Solaris 8, for > example, long after the GA of Solaris 10. The fact that we had to jump > forward across two major versions was slightly painful and required a > non-negligible amount of manpower to pull it off. The fact that Solaris > 9 was also 'supported' never really played much of a role in the > decision to move to the latest release version. It was always a > feature-based decision and not a time-based one. For some groups, they are not dev resource limited, but QA resource limited,= so getting all of the core OS changes qualified and into a set of mature pr= oducts can be a real chore. This is one of the pain points for my group. -Garrett= From owner-freebsd-arch@FreeBSD.ORG Thu Dec 23 19:43:47 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 9049C1065672; Thu, 23 Dec 2010 19:43:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 58F138FC14; Thu, 23 Dec 2010 19:43:47 +0000 (UTC) Received: by pxi1 with SMTP id 1so1209625pxi.13 for ; Thu, 23 Dec 2010 11:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=ouqVKdk0SPV22Rvpxv/byWlTGcXIXJCeW5OjcLCVLGs=; b=LeyPze0Su2gO0I0c1xA0MCA7QR2HH8d8Ul+ciOfYs3hM5o2jgSDQZ7Eb5DeIsLH5Be vwJkHUShbwfrIOgSv96yvSM59lexJ/Sqe5UApQ0onlQTkhTaTiuS9yPzXxkjiPCI+ljD Gn+MknTF2dCa5dIOGruwjPfY0c+h64EtrE488= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=UDd1SQkoX4IqChoxHE8ZbPKBtaCKOY8k1C6f5g0B/OF+zfb8uE4fO1w6JLJRiLLkZf 9y/ZndDzNB76H0WeKYX8OX7fXvu+dBvrO4SkKEUhLv59j9xZNAz8nX0Shb6saqzIQZlW nfo+4vOU2YdTcSnKSVPoOPYsgBWQNbKcO8xvs= Received: by 10.142.136.3 with SMTP id j3mr6893131wfd.38.1293133426962; Thu, 23 Dec 2010 11:43:46 -0800 (PST) Received: from [10.16.14.246] ([166.205.143.245]) by mx.google.com with ESMTPS id w22sm11121727wfd.19.2010.12.23.11.43.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 11:43:45 -0800 (PST) References: <201012221745.oBMHj7Wg039593@mail.karels.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6E28302F-BF4B-43E7-B91D-826D5C06C220@gmail.com> X-Mailer: iPhone Mail (8C148) From: Garrett Cooper Date: Thu, 23 Dec 2010 11:43:26 -0800 To: Robert Watson Cc: Mike Karels , "freebsd-arch@freebsd.org" 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: Thu, 23 Dec 2010 19:43:47 -0000 On Dec 22, 2010, at 12:57 PM, Robert Watson wrote: >=20 > On Wed, 22 Dec 2010, Mike Karels wrote: >=20 >> - We sometimes back-port other changes, such as TCP locking fixes that he= lp performance. Considering some such things for MFC would be desirable. >=20 > Just to comment on the specifics of this one: over the cource of 6.x, 7.x,= and 8.x, I non-trivially improved locking in the TCP/UDP code. Some of tho= se changes could be backported -- others couldn't be. Part of the reason I d= idn't merge some changes was our increasing attempt to provide stable KPIs a= nd KBIs for kernel modules, especially as TCP offload support in device driv= ers became a reality. >=20 > We're now going to hit the same issue in 9.x: I'm about to commit signific= ant network stack locking and work distribution changes to improve TCP and U= DP scalability, leading to multiplied performance on parallel systems. As o= f the interpretation of KPI/KBI compatibility we have today, these cannot be= MFC'd to 8.x. I think there's a motivation to revisit our thinking on KPI/= KBI so that we can merge them to 8.x in the future; I'll say more about this= on the net@ mailing list in a month or so once the changes are in 9.x and h= ave shaken out a bit. Even though the network stack is relatively stable, I've run in to problems b= ackporting CPU identification fixes and filesystem fixes in 6.x and 7.x s.t.= I gave up because of the other dependent changes I had to pull in. Ran into= a similar issue with mfiutil/mfi. So it would be nice if things didn't chan= ge so much between minor versions. Thanks, -Garrett= From owner-freebsd-arch@FreeBSD.ORG Fri Dec 24 03:11:23 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 D7982106567A for ; Fri, 24 Dec 2010 03:11:23 +0000 (UTC) (envelope-from Staff@annunciasubito.com) Received: from relay2.tre.it (mail.tre.it [62.13.171.46]) by mx1.freebsd.org (Postfix) with ESMTP id 0790E8FC22 for ; Fri, 24 Dec 2010 03:11:22 +0000 (UTC) Received: from miummr0mt01.um.ced.h3g.it ([10.216.58.129]) by relay2.tre.it with ESMTP id oBO2iC3w023457-oBO2iC3x023457 for ; Fri, 24 Dec 2010 03:44:12 +0100 Received: from [192.168.0.102] ([10.94.23.166]) by miummr0mt01.um.ced.h3g.it (MOS 3.6.5-GR) with SMTP id BVW10053; Fri, 24 Dec 2010 03:43:33 +0100 (CET) Date: Fri, 24 Dec 2010 03:44:11 +0100 Mime-version: 1.0 From: To: Message-Id: <20101224034411.NILQELNQSQHPPV@annunciasubito.com> Original-recipient: rfc822;freebsd-arch@freebsd.org Content-Type: multipart/mixed; Boundary="--=BOUNDARY_1224344_MFSI_FBXV_PYEL_VUPG" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Buon Natale e felice anno nuovo 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: Fri, 24 Dec 2010 03:11:23 -0000 Questo messaggio C( in formato MIME. PoichC( il tuo programma di posta non comprende questo formato, una porta o tutto il messaggio potrebbe non essere leggibile. ----=BOUNDARY_1224344_MFSI_FBXV_PYEL_VUPG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-transfer-encoding: quoted-printable I Nostri siti di Annunci gratis: www=2Evucumbra=2Eit "NewS" www=2Eannunciasubito=2Ecom "consigliato" www=2Evetrinaannunci=2Enet "consigliato" www=2Eiltuoposts=2Eit www=2Eannuncifreschi=2Eit "NEWS" www=2Eannunciitalia=2Enet www=2Eannunciz=2Eit www=2Eannuncinews=2Ecom www=2Ewordannunci=2Eit www=2Eannuncissimi=2Eit www=2Eannunciannunci=2Ecom ----=BOUNDARY_1224344_MFSI_FBXV_PYEL_VUPG-- From owner-freebsd-arch@FreeBSD.ORG Sat Dec 25 11:50:22 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 39AA5106566B for ; Sat, 25 Dec 2010 11:50:22 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id B55618FC14 for ; Sat, 25 Dec 2010 11:50:21 +0000 (UTC) Received: from park.js.berklix.net (p5B22D157.dip.t-dialin.net [91.34.209.87]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id oBPBRwLq002407 for ; Sat, 25 Dec 2010 11:27:59 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id oBPBRlUw086197 for ; Sat, 25 Dec 2010 12:27:47 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id oBPBRtg8019001 for ; Sat, 25 Dec 2010 12:28:00 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201012251128.oBPBRtg8019001@fire.js.berklix.net> To: freebsd-arch@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 22 Dec 2010 09:52:03 +0100." <201012220852.oBM8q2Qi039123@lurza.secnetix.de> Date: Sat, 25 Dec 2010 12:27:55 +0100 Sender: jhs@berklix.com 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: Sat, 25 Dec 2010 11:50:22 -0000 For interest: An HP.com presentation recently said support for major releases is typically 13/14 years I recall. They have different business environment though. I'm not suggesting FreeBSD should do similar. Oliver Fromme wrote: > For me, personally, one significant problem is that I don't > have the resources to easily run several versions of FreeBSD > at home. > > I have a stable/8 installation, but I can't easily install > another one (i.e. stable/7) at the same time, which would > be required for testing and support. Well, I could set up > a dual-boot environment somehow with a second disk, but > that's time-consuming and annoying. Repartitioning is too tedious, so for last few few years I've been sacrificing maybe 7% of new disc space: I install with an MBR of 3 slices of eg 15 Gig + 4th slice of common space, eg 430 Gig). S1 installed with binaries, S4 with common data eg /usr/cvs & current ports etc. Later S2 & S3 get installed with newer BSD versions. Useful if some ports won't build during upgrade, & for recovery. I've not tried virtualbox with other slices yet, which would save reboot time, & avoid closing other processes eg X server & apps. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, or HTML or base 64. Avoid top posting, it cripples itemised cumulative responses. From owner-freebsd-arch@FreeBSD.ORG Sat Dec 25 19:17:48 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 83C0C106566C for ; Sat, 25 Dec 2010 19:17:48 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id 20B228FC15 for ; Sat, 25 Dec 2010 19:17:47 +0000 (UTC) Received: from [192.168.10.164] (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp1.one.com (Postfix) with ESMTP id 272161BC00BD1; Sat, 25 Dec 2010 19:17:45 +0000 (UTC) References: <201012221745.oBMHj7Wg039593@mail.karels.net> In-Reply-To: <201012221745.oBMHj7Wg039593@mail.karels.net> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--682631634; protocol="application/pkcs7-signature" Message-Id: From: Erik Cederstrand Date: Sat, 25 Dec 2010 20:17:44 +0100 To: mike@karels.net X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org 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: Sat, 25 Dec 2010 19:17:48 -0000 --Apple-Mail-2--682631634 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Mike, Den 22/12/2010 kl. 18.45 skrev Mike Karels: > - Those of us doing backports could probably do a better job of > sharing the results. On the other hand, I'm generally backporting > to a specific release (currently 6.3 or 7.2) rather than -stable, > and we're testing our software rather than FreeBSD. Thanks for taking the time to write your comments. What strikes me is = that we may have lots of non-FreeBSD developers working to backport = stuff in their own private trees. Possibly a lot of redundant work is = being done. Even though you're backporting to a specific release, and even though = you're only testing the work via your own software, would it not help = others and possibly even yourself if this FreeBSD-specific work lands in = the FreeBSD repository instead of your private tree? In my view you're = just as much a FreeBSD developer as people with commit access that are = scratching their own itches in CURRENT. Erik= --Apple-Mail-2--682631634--