Re: Backport drivers from 4.1 to 4.0
I've been watching this thread, perhaps my comments are worth something, or are amusing. Executive summary: track -current. Make releases in step with OpenBSD. On Tue, 28 Aug 2007, Kevin Cheng wrote: Artur, Thanks, Upgrade code based on release of obsd is easy, but it would a big job to maintain early released of products based on previous version of obsd. For That sentence contains its own solution: do not maintain old versions. How would one maintain old versions if the underlying OS is frozen? Attempt to back-port fixes. You know this is hard. example, we would maintain 8 version of products from 3.3 to 4.0 if codes are upgraded every half years. How do you answer customers who ask why they can't run the up-to-date version of OpenBSD? If your salesman contacted me, saying I had to *downgrade* my OS to Open 3.3 to run your product, I would advise him to call me again when you can support the current OS. Perhaps you should evaluate your development and support cycle. If you support other host OS's besides OpenBSD, then perhaps it would be worth it to put your applications under control of CVS and your releases in some kind of nice package (like an OpenBSD port) and invest in the effort to get autoconf and related tools working with it. A nightmare for you: suppose you are several versions behind the OpenBSD release and a Category 5 bug afflicts all OS's derived from Tahoe TCP/IP code... Naturally, OpenBSD has the first patches out, but not for the antique versions you support. Now suppose OpenBSD has done something significant (like a.out-ELF, a new file system, big rewrite of code so that patches don't apply smoothly, removed support for something evil, whatever) since you last upgraded your apps, so that you can't just recompile and go. Your phones are ringing...your lead developer is on vacation...few of your clients have Old Version source code...A significant package (gnome or java, say ;-) ) is no longer available... Your software uses a bug-feature of gcc withdrawn after a class-action lawsuit... Suppose instead you had been tracking OpenBSD-current and keeping your apps compliant...[*] the patches for the Bug-of-the-Decade appear in -current in about three hours, another three hours and a snapshot is built, you get the snapshot, your apps compile and regress correctly. You then apply the patches for the other supported versions of Open (3 max), and notify your clients/users. You and Open are back in business first, before M$ can even issue a series of denials that Bug-of-the-Decade exists, or certain pseudo-free OS's can grovel and obtain NDAs from SCO. Instead of getting phone calls, you make them: Mr Valued Client, emergency update to counter Bug-of-the-Decade is available. Client: What bug is that? You: The one you no longer have to worry about. This makes for much goodwill with the client. [*] tracking -current and keeping your apps married to -current is how to make a smooth release of your stuff almost immediately after the OpenBSD release is made (or in the best case, simultaneously). An added benefit: as a commercial or other professional developer, you may well discover serious objections to or bugs with a newish feature of OpenBSD while it is in the embryonic phase -- these objections/bugs are easily fixed at this point, either by your end or OpenBSD's, depending. This benefits everyone. Dave
Re: Backport drivers from 4.1 to 4.0
Joachim and Nick, Thanks for the advice. I was just think about how to minimize the impact for production boxes based on previous release (4.0, 4.1...). Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joachim Schipper Sent: Monday, August 27, 2007 4:21 AM To: misc@openbsd.org Subject: Re: Backport drivers from 4.1 to 4.0 On Mon, Aug 27, 2007 at 02:42:34AM +0800, Kevin Cheng wrote: Hi Darrin, Thanks for reply. The reason is that we have bunch of files integrated with 4.0 and it would take us months to upgrade to 4.2 again. we just finished from 3.3 to 4.0 of upgrade few months ago, plus months of test to stabilize our 4.0 based applications. Should we just isolate one by one manually as safety approach? Any CVS that we can trace for what files been changed for specific drivers? E.g., 4.0-4.1. I'd like to point out that 4.0-4.2 will be *a lot* easier than 3.3-4.0. You can, of course, use any of the AnonCVS mirrors, linked from the home page. But that is still the wrong approach. Joachim
Re: Backport drivers from 4.1 to 4.0
Kevin Cheng [EMAIL PROTECTED] writes: Hi Darrin, Thanks for reply. The reason is that we have bunch of files integrated with 4.0 and it would take us months to upgrade to 4.2 again. we just finished from 3.3 to 4.0 of upgrade few months ago, plus months of test to stabilize our 4.0 based applications. Should we just isolate one by one manually as safety approach? Any CVS that we can trace for what files been changed for specific drivers? E.g., 4.0-4.1. this is such a bad idea. From experience I can tell you that it's much easier (in total) to upgrade your code once every 6 months than to do huge projects to do the same once every few years. //art Thanks, Kevin -Original Message- From: Darrin Chandler [mailto:[EMAIL PROTECTED] Sent: Monday, August 27, 2007 2:19 AM To: Kevin Cheng Cc: misc@openbsd.org Subject: Re: Backport drivers from 4.1 to 4.0 On Mon, Aug 27, 2007 at 01:33:34AM +0800, Kevin Cheng wrote: What would be the safe way to backport driver codes from 4.1 to 4.0, such as (/usr/src/sys/dev) ci, pcmcia, usb? For most values of safe the answer is none. With the upcoming 4.2 release, 4.0 will be unsupported. Your backports will be unsupported immediately. Is there some pressing reason why you can't upgrade/reinstall to a newer version? -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Backport drivers from 4.1 to 4.0
Artur, Thanks, Upgrade code based on release of obsd is easy, but it would a big job to maintain early released of products based on previous version of obsd. For example, we would maintain 8 version of products from 3.3 to 4.0 if codes are upgraded every half years. Kevin you would need to maintain released boxes based on early version of obsd The thing is to upgrade released products based on Should we just isolate one by one manually as safety approach? Any CVS that we can trace for what files been changed for specific drivers? E.g., 4.0-4.1. this is such a bad idea. From experience I can tell you that it's much easier (in total) to upgrade your code once every 6 months than to do huge projects to do the same once every few years.
Re: Backport drivers from 4.1 to 4.0
On 8/27/07, Kevin Cheng [EMAIL PROTECTED] wrote: Artur, Thanks, Upgrade code based on release of obsd is easy, but it would a big job to maintain early released of products based on previous version of obsd. For example, we would maintain 8 version of products from 3.3 to 4.0 if codes are upgraded every half years. Why would you maintain support for products going back to vastly unsupported versions of OpenBSD? If I had a product based on OpenBSD, I wouldn't give customers an excuse to keep themselves on older and unsupported releases. Do you want customers running 3.3 right now? They haven't been able to get patches for years now. In my experience at least part of the reason system designers choose OpenBSD as a basis for their solution is the security focus. You go that far out of date, you lose that advantage. Yes, the project has a release schedule. No, that doesn't make it easy to maintain the 5 year life cycle that other platforms like to advertise. It also doesn't mean that their schedule is superior or is even a good idea (or accurate). Some vendors are maintaining support for NT4 still; customer demand is driving that. It's stupid, and those that play that game are either really stupid or really good at getting risk acceptance documents signed off on. Or both. DS
Re: Backport drivers from 4.1 to 4.0
Kevin Cheng wrote: Upgrade code based on release of obsd is easy, but it would a big job to maintain early released of products based on previous version of obsd. For example, we would maintain 8 version of products from 3.3 to 4.0 if codes are upgraded every half years. Why? If you do an OS upgrade it leaves the old shared libraries around, so any installed apps should continue working. If you want OS version independence, then compile your app static.
Backport drivers from 4.1 to 4.0
Hi, What would be the safe way to backport driver codes from 4.1 to 4.0, such as (/usr/src/sys/dev) ci, pcmcia, usb? Thanks, Kevin
Re: Backport drivers from 4.1 to 4.0
On Mon, Aug 27, 2007 at 01:33:34AM +0800, Kevin Cheng wrote: What would be the safe way to backport driver codes from 4.1 to 4.0, such as (/usr/src/sys/dev) ci, pcmcia, usb? For most values of safe the answer is none. With the upcoming 4.2 release, 4.0 will be unsupported. Your backports will be unsupported immediately. Is there some pressing reason why you can't upgrade/reinstall to a newer version? -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Backport drivers from 4.1 to 4.0
Hi Darrin, Thanks for reply. The reason is that we have bunch of files integrated with 4.0 and it would take us months to upgrade to 4.2 again. we just finished from 3.3 to 4.0 of upgrade few months ago, plus months of test to stabilize our 4.0 based applications. Should we just isolate one by one manually as safety approach? Any CVS that we can trace for what files been changed for specific drivers? E.g., 4.0-4.1. Thanks, Kevin -Original Message- From: Darrin Chandler [mailto:[EMAIL PROTECTED] Sent: Monday, August 27, 2007 2:19 AM To: Kevin Cheng Cc: misc@openbsd.org Subject: Re: Backport drivers from 4.1 to 4.0 On Mon, Aug 27, 2007 at 01:33:34AM +0800, Kevin Cheng wrote: What would be the safe way to backport driver codes from 4.1 to 4.0, such as (/usr/src/sys/dev) ci, pcmcia, usb? For most values of safe the answer is none. With the upcoming 4.2 release, 4.0 will be unsupported. Your backports will be unsupported immediately. Is there some pressing reason why you can't upgrade/reinstall to a newer version? -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Backport drivers from 4.1 to 4.0
On Mon, Aug 27, 2007 at 02:42:34AM +0800, Kevin Cheng wrote: Hi Darrin, Thanks for reply. The reason is that we have bunch of files integrated with 4.0 and it would take us months to upgrade to 4.2 again. we just finished from 3.3 to 4.0 of upgrade few months ago, plus months of test to stabilize our 4.0 based applications. Should we just isolate one by one manually as safety approach? Any CVS that we can trace for what files been changed for specific drivers? E.g., 4.0-4.1. I'd like to point out that 4.0-4.2 will be *a lot* easier than 3.3-4.0. You can, of course, use any of the AnonCVS mirrors, linked from the home page. But that is still the wrong approach. Joachim
Re: Backport drivers from 4.1 to 4.0
Kevin Cheng wrote: Hi Darrin, Thanks for reply. The reason is that we have bunch of files integrated with 4.0 and it would take us months to upgrade to 4.2 again. we just finished from 3.3 to 4.0 of upgrade few months ago, plus months of test to stabilize our 4.0 based applications. Should we just isolate one by one manually as safety approach? Any CVS that we can trace for what files been changed for specific drivers? E.g., 4.0-4.1. what you are trying to avoid doing is easier than going the completely unsupported route of making a Frankenstein system. Routine upgrades of /at least/ once a year HAVE to be part of your OpenBSD plans. It is that simple. It's hard to do! is not a valid excuse, that means the rest of your plan is not properly designed. Most of the benefits you gained by using OpenBSD are negated by what you are (not) doing and attempting to get away with. Nick.
