Re: how to get more logging from GEOM?
On Jul 15, 2008, at 8:35 AM, Oliver Fromme wrote: I had exactly the same problems on a machine a few months ago. It had also been running for about two years, then started freezing when there was high CPU + disk activity. It turned out that the power supply went weak (either the power supply itself or the voltage regulators on the main- board). Replacing PS + mainboard solved the problem. I have removed these drives and installed them in another machine and had exactly the same symptoms. I built a new machine fresh with 7.2 (in case it was due to the upgrade process) and installed these ports and experienced the exact same problem. That's why I am here. Physical or localized issues have already been ruled out. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can I get a committer to mark this bug as blocking 6.4-RELEASE ?
On Nov 26, 2008, at 1:12 PM, Ken Smith wrote: Unfortunately no. As John indicated in the earlier thread BIOS issues tend to be extremely hard to diagnose and so far it seems like its specific to this one motherboard. Given this problem does cause issues with installs I'd be willing to provide ISOs built at the point we've done the Errata Notice that fixes the problem. But its too nebulous an issue to hold up the release itself for. It does *not* cause an issue with installs. Installs work fine. It prevents booting an installed operating system. This appears to affect *ALL* of the Intel multi-cpu motherboards, including 3 generations of Rackable systems. The only reason it is nebulous is because absolutely nobody bothered to investigate the issue. I've been asking for what information would help. I've offered to setup serial consoles, or even ship systems, to anyone who would work on this problem. This is very big problem that will affect thousands of freebsd servers. Ken, the complete lack of action taken by FreeBSD to even CONSIDER investigating a significant bug reported during the testing process is shocking. And it truly puts a lie to those who continue to claim that we should be more active in the testing process. Every time I have done this, I'd found significant issues that affect a significant portion of the user base and COMPLETELY prevent deployment of a given release, and absolutely nothing has been done to even investigate the reports, nevermind address them. Congradulations. Good Job. If you aren't going to accept bug reports, why exactly do you release testing candidates at all? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb keyboard dying at loader prompt
Just FYI we are seeing the exact same problem with PS/2 keyboards and the 6.4 loader, so this may not be a USB-only issue. The complete lack of response to serious bug reports about 6.4-REL is fairly shocking. On Nov 28, 2008, at 5:24 AM, Andriy Gapon wrote: I did more testing and it seems that our loader does have something to do with the problem. If I boot to memtest86 the keyboard keeps working. If I pause boot menu, wait for many minutes, the keyboard still works. If I escape to loader prompt, this when the keyboard stops working after a few seconds. Not sure how to explain this. I think I've seen some changes to reduce memory usage of loader, I will try them to see if that would make any difference for my situation. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can I get a committer to mark this bug as blocking 6.4-RELEASE ?
for testing 6.4 (I went a bought a whole stack of systems *JUST FOR THIS*) and filed PRs and followed up, and couldn't get much more than it sounds like this kind of response ... seriously, would you invest a lot of time testing a very unstable release under those conditions? I mean jesus, 6.4 is supposed to be truly stable and yet you're willing to ship it not working with dozens of nearly identical reports of the same symptoms for both 6.4 and 7.1? Think seriously about what happened here, and how exactly I'm supposed to convince any executive of the logic of trying to test 7.1, when we're stuck on 6.3 until/if 6.5, which will be screwed for support? I mean seriously? The problem BTW is *EXACTLY* why I proposed the revisions to the support policy I did. Now you're stuck supporting 6.4 for 2 years, and you won't want to release 6.5 because you'll end up supporting three 6.x releases at the same time. Which would suck. Which is exactly what my proposed change to the policy would have fixed. FreeBSD has usually been a solid product on the more stable releases. It's really unfortunate that the release management is so willing to ignore the evidence which leads to major releases with serious flaws, and on top of that seems to take delight in marking the known flawed releases as the long support releases. Brilliance. Just plain brilliant, top to bottom. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
confirming bugs is bad behavior, etc.
On Dec 1, 2008, at 11:59 AM, George V. Neville-Neil wrote: I have mostly stayed away from these threads because they've often devolved into unproductive finger pointing. Please leave the hyperbole out of your posts, or at least attempt to cut it back. People on these lists are working quite hard to solve problems for the whole of the FreeBSD community and your posts, such as this one, are not helping us to move forward. My posts have always been directed at solving very real, operational problems with using FreeBSD on server platforms, which is exactly the stated goal for freebsd. I have always offered not only problems, but resources to help test or evaluate the issues, and serious considerations for ways to improve the process. Yes, you're right. Threads I start about real problems always devolve into unproductive finger pointing. That would be the freebsd developers attacking the reporter for identifying a real, operational problem. Take a look at the posts of the FreeBSD developers, and view for yourself the unprofessional attacks and personal insults hurled by them at people who are simply trying to get real problems resolved. And yet, instead of asking your developers to stop violating the posted rules of the mailing list, you are asking a bug reporter who simply informed another bug reporter that their problem was both widespread and not limited to USB devices to stop posting to the list. Because god knows that yes we saw it too and it's widely reported is bad behavior. Much worse that personal attacks which are strictly against the list rules. Yes, I'm sure that the personal attacks really do help drive freebsd development forward. Much more so than me bringing resources and actually testing things does. Now that Core has clearly spoken their mind on this issue, by refusing to ask freebsd developers to avoid violating the list charter and then publicly calling out someone for just saying yeah, it's a widely reported problem ... leaves any doubt that positive change is going to happen here. Your request is accepted. I'm unsubscribing now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can I get a committer to mark this bug as blocking 6.4-RELEASE ?
On Dec 1, 2008, at 12:25 PM, Xin LI wrote: What I proposed is, to *narrow down* the problem so we can diagnose further, since nobody has idea at the moment about how the problem was, we do need to have further information, or, to get the whole 6.3-6.4 diff reviewed, which is (in my opinion) not an optimal use of developers' time. I got your request at the beginning of a vacation period where I was out of town. I had explicitly requested that 6.4 be blocked for this issue. I didn't think that just my problem would be enough to hold it up, but I apparently never even considered that -REL would happen without even responding to my request. Since nobody had responded to my request, and several posts had gone out about more testing for 7.1 (which had the same loader and the same problems) I assumed that 6.4 was similarly delayed. Had anyone said you needed this information pronto I would have canceled my Thanksgiving plans and spent the day in the lab testing this for you. For that matter, I had already pulled a diff of 6.3 to 6.4 and was working my way through it trying to find the relevant parts. If you would have identified the relevant portions, I would have happily tried backing out some of the changes on a per-component basis to figure it out. In short, tell me what you wanted/needed, and I would have done it ASAP. It's apparently irrelevant now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
no priority on the console?
As per my previous message, I've spent about 3 months trying to debug a problem that was causing all disk I/O to go very slowly. One of the things which made this nearly impossible to diagnose was the absolute lack of priority given to the console. Logging in on the console would take 12-15 minutes. Hitting enter on the console would usually take between 3 and 5 minutes. This doesn't seem right to me. Can someone explain why the console isn't given a very high priority? Why not? What other mechanism does the sysadmin have for debugging, at a time when SSH logins either fail, or take up to an hour to complete? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
smartd long self-test causes drives to hang
I've spent about 3 months tracing down what was causing my personal colo box to start getting sluggish right around dawn every Saturday morning. It took so long because some mornings I simply couldn't pull my head out of my tail enough to do proper debugging. The cause was *really slow* filesystem response time. No cron jobs in that period. No specific process ran any slower than another, although I eventually learned that ones which did no file i/o were fine. And finally I realized that just ls -la was very slow (~1 minute) even after I had killed off every disk-using process in the system. SMTP and HTTP in particular were basically fubar. No data loss, just *real slow*. Nothing other than a soft reboot ever solved the problem.Even leaving it running only minimal processes for 24 hours didn't bring it back to normal. Finally I was browsing through Jeremy Chadwick's list of known ATA problems and spotted his comments about smartd self-tests causing problems. Sure enough, my long self test was scheduled for 5am on Saturday mornings. Rechecking the observed slow-down periods confirmed that the problem never became visible before 5am. (sometimes it took up to 45 minutes before things slowed down enough to set off monitoring alarms) So, long story short, if you're having weirdness in system time response - check the smartd configuration, and try disabling the self tests. The short self test I was running daily didn't appear to affect anything, but the long test was just bringing the system to just shuddering and limping at best. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Can I get a committer to mark this bug as blocking 6.4-RELEASE ?
This is now filed as PR 129149 http://www.freebsd.org/cgi/query-pr.cgi?pr=129149 Given the nature of this bug, can I persuade someone to mark this as blocking 6.4-RELEASE ? On Nov 5, 2008, at 3:41 PM, Jo Rhett wrote: On Oct 27, 2008, at 8:51 AM, John Baldwin wrote: On Friday 24 October 2008 02:48:13 pm Jo Rhett wrote: So I booted up by CD and used Fixit mode to switch the system to boot via serial (keyboard detached), but this gathered me even less. /boot.config: -Dh Consoles: internal video/keyboard serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/4062144kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED] Plugging back in the monitor after lockup showed only a single char more: ([EMAIL PROTECTED] This confirms it is hanging in one of the two BIOS routines to output a character. One thing you can do would be to boot up and do the following: dd if=/dev/mem bs=0x400 count=1 of=idt.out dd if=/dev/mem bs=64k iseek=15 count=1 of=bios.out Then place those files some place I can fetch them. Both files are at http://support.netconsonance.com/freebsd/ FYI, this is notable -- the keyboard does not respond at the boot prompt. I mean the menu where you can escape to the loader prompt, with the fat freebsd ascii art. No keyboard presses are observed here. This is also true for the boot menu on the 6.4 installation CD too. No problems with 6.2 or 6.3 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smartd long self-test causes drives to hang
On re-reading the message I realized that my message was in danger of being content-free. gmirror whole-disk mirror of seagate 300gb drives $ atacontrol list ATA channel 0: Master: ad0 ST3300622A/3.AAH ATA/ATAPI revision 7 Slave: ad1 ST3300622A/3.AAH ATA/ATAPI revision 7 $ gmirror list Geom name: gm0 State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 575427344 Providers: 1. Name: mirror/gm0 Mediasize: 300069051904 (279G) Sectorsize: 512 Mode: r5w5e6 Consumers: 1. Name: ad0 Mediasize: 300069052416 (279G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 3917165570 2. Name: ad1 Mediasize: 300069052416 (279G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 3874187635 On Nov 24, 2008, at 12:48 PM, Jo Rhett wrote: I've spent about 3 months tracing down what was causing my personal colo box to start getting sluggish right around dawn every Saturday morning. It took so long because some mornings I simply couldn't pull my head out of my tail enough to do proper debugging. The cause was *really slow* filesystem response time. No cron jobs in that period. No specific process ran any slower than another, although I eventually learned that ones which did no file i/o were fine. And finally I realized that just ls -la was very slow (~1 minute) even after I had killed off every disk-using process in the system. SMTP and HTTP in particular were basically fubar. No data loss, just *real slow*. Nothing other than a soft reboot ever solved the problem.Even leaving it running only minimal processes for 24 hours didn't bring it back to normal. Finally I was browsing through Jeremy Chadwick's list of known ATA problems and spotted his comments about smartd self-tests causing problems. Sure enough, my long self test was scheduled for 5am on Saturday mornings. Rechecking the observed slow-down periods confirmed that the problem never became visible before 5am. (sometimes it took up to 45 minutes before things slowed down enough to set off monitoring alarms) So, long story short, if you're having weirdness in system time response - check the smartd configuration, and try disabling the self tests. The short self test I was running daily didn't appear to affect anything, but the long test was just bringing the system to just shuddering and limping at best. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can I get a committer to mark this bug as blocking 6.4-RELEASE ?
So boot from CD, go to LIVE filesystem, mount my root and copy only / boot/kernel? Are there any other modules I should copy, or settings I should change? On Nov 24, 2008, at 1:51 PM, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jo Rhett wrote: This is now filed as PR 129149 http://www.freebsd.org/cgi/query-pr.cgi?pr=129149 Given the nature of this bug, can I persuade someone to mark this as blocking 6.4-RELEASE ? My wild guess is that this is somehow related to SMP handling since the installation process would install a SMP kernel, but the default CD- ROM kernel is UP for 6.x. Could you please try if you have the same problem with UP kernel? (Copy from LiveCD or something) On Nov 5, 2008, at 3:41 PM, Jo Rhett wrote: On Oct 27, 2008, at 8:51 AM, John Baldwin wrote: On Friday 24 October 2008 02:48:13 pm Jo Rhett wrote: So I booted up by CD and used Fixit mode to switch the system to boot via serial (keyboard detached), but this gathered me even less. /boot.config: -Dh Consoles: internal video/keyboard serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/4062144kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED] Plugging back in the monitor after lockup showed only a single char more: ([EMAIL PROTECTED] This confirms it is hanging in one of the two BIOS routines to output a character. One thing you can do would be to boot up and do the following: dd if=/dev/mem bs=0x400 count=1 of=idt.out dd if=/dev/mem bs=64k iseek=15 count=1 of=bios.out Then place those files some place I can fetch them. Both files are at http://support.netconsonance.com/freebsd/ FYI, this is notable -- the keyboard does not respond at the boot prompt. I mean the menu where you can escape to the loader prompt, with the fat freebsd ascii art. No keyboard presses are observed here. This is also true for the boot menu on the 6.4 installation CD too. No problems with 6.2 or 6.3 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkrIc8ACgkQi+vbBBjt66BVUACcDLDK7Ubugt2sto8WKAYfxF0L 93cAoI3bJ/7YcKQeVUmWTO9R2tOCOf6W =dEk9 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Want one of the affected systems for your lab? (Was: 6.4 RC1 locks up solid on first reboot)
John, I can ship you one of these machines for your own testing if you like. Or send me a public key and I can give you SSH access to the console serial port, whichever would be easiest for you to get what you need. Let me know how I can help. On Nov 5, 2008, at 3:41 PM, Jo Rhett wrote: On Oct 27, 2008, at 8:51 AM, John Baldwin wrote: On Friday 24 October 2008 02:48:13 pm Jo Rhett wrote: So I booted up by CD and used Fixit mode to switch the system to boot via serial (keyboard detached), but this gathered me even less. /boot.config: -Dh Consoles: internal video/keyboard serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/4062144kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED] Plugging back in the monitor after lockup showed only a single char more: ([EMAIL PROTECTED] This confirms it is hanging in one of the two BIOS routines to output a character. One thing you can do would be to boot up and do the following: dd if=/dev/mem bs=0x400 count=1 of=idt.out dd if=/dev/mem bs=64k iseek=15 count=1 of=bios.out Then place those files some place I can fetch them. Both files are at http://support.netconsonance.com/freebsd/ FYI, this is notable -- the keyboard does not respond at the boot prompt. I mean the menu where you can escape to the loader prompt, with the fat freebsd ascii art. No keyboard presses are observed here. This is also true for the boot menu on the 6.4 installation CD too. No problems with 6.2 or 6.3 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3Ware 9000 series hangs under load
Jo Rhett wrote: The driver logs all useful stuff, and the SEC logfile surfer does a good job of notifying you quickly. I can send you an SEC configuration for that if you want. On Nov 16, 2008, at 10:06 PM, Oliver Lehmann wrote: Hm - what is SEC? Simple Event Correlator http://kodu.neti.ee/~risto/sec/ and /usr/ports/sysutils/sec Best damn logsurger evar! *giggle* -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible regression in ifconfig under7.0 - removes valid default route
This is a bug in my mind, but it's not a regression. FreeBSD has done this for at least 10 years now. If you are changing the IP of an interface, you *must* do a semicolon chained command to a route add default. It's been true for as long as I can remember. On Nov 17, 2008, at 11:11 AM, Steven Hartland wrote: I believe there may be a regression in the behaviour of ifconfig or possibly just something I've never experienced before. Basically when changing the IP of one of our machines, it suddenly became inaccessible. After some investigation it turned out the machine was inaccessible from anything other than the local VLAN and continued diagnostics determined that the process of changing the IP had also removed the default route. This was clearly unexpected behaviour as the new IP was on the same VLAN as the old IP and hence no routing table updates should be required. I don't have any older machines to test this on but I believe we have done this procedure in the past without any such issues so wanted to raise it here to see if anyone else has had experience with it. Even if this isn't a regression it may well be something worth fixing as its quite unexpected behaviour which could render a machine totally inaccessible. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3Ware 9000 series hangs under load
Philip Murray wrote: Anyway, I stopped running 3dmd (or 3dm2 I think it's called now) to monitor it, and the crashes went away. It's had hundreds of days uptime since. We have never used 3dm2, and the 9500 units have been rock solid for us. I've never been game enough to try newer versions of 3dm, but a cronjob of tw_cli allows me to monitor it now without the lockups. Might not be your problem, but it's worth a shot if all else fails. The driver logs all useful stuff, and the SEC logfile surfer does a good job of notifying you quickly. I can send you an SEC configuration for that if you want. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3Ware 9000 series hangs under load
On Nov 12, 2008, at 12:37 PM, Philip Murray wrote: I just installed sysutils/tw_cli from ports, and it sets up some 'periodic' scripts for you. To be precise it puts 407.status-3ware- raid in /usr/local/etc/periodic/daily Don't use that. It's a very old version of the code. Use the binary version of tw_cli that matches the firmware on your controller. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.4-RC2 available...
On Nov 3, 2008, at 8:57 AM, Ken Smith wrote: The second Release Candidate for FreeBSD 6.4 is now available. FreeBSD 6.4-RC2 should be the last of the public test builds for the FreeBSD 6.4 release cycle. Unless a big show-stopper is found from this round of testing we should begin the 6.4-RELEASE builds in about a week and a half. We encourage you to test out 6.4-RC2 and report any problems by submitting PRs or via email to the freebsd-stable list. I would love to, but it's still not available on the download area. Er, i386 isn't anyway. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.4 RC1 locks up solid on first reboot
On Oct 27, 2008, at 8:51 AM, John Baldwin wrote: On Friday 24 October 2008 02:48:13 pm Jo Rhett wrote: So I booted up by CD and used Fixit mode to switch the system to boot via serial (keyboard detached), but this gathered me even less. /boot.config: -Dh Consoles: internal video/keyboard serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/4062144kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED] Plugging back in the monitor after lockup showed only a single char more: ([EMAIL PROTECTED] This confirms it is hanging in one of the two BIOS routines to output a character. One thing you can do would be to boot up and do the following: dd if=/dev/mem bs=0x400 count=1 of=idt.out dd if=/dev/mem bs=64k iseek=15 count=1 of=bios.out Then place those files some place I can fetch them. Both files are at http://support.netconsonance.com/freebsd/ FYI, this is notable -- the keyboard does not respond at the boot prompt. I mean the menu where you can escape to the loader prompt, with the fat freebsd ascii art. No keyboard presses are observed here. This is also true for the boot menu on the 6.4 installation CD too. No problems with 6.2 or 6.3 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.4-RC2 available...
On Nov 5, 2008, at 3:29 PM, Jo Rhett wrote: On Nov 3, 2008, at 8:57 AM, Ken Smith wrote: The second Release Candidate for FreeBSD 6.4 is now available. FreeBSD 6.4-RC2 should be the last of the public test builds for the FreeBSD 6.4 release cycle. Unless a big show-stopper is found from this round of testing we should begin the 6.4-RELEASE builds in about a week and a half. We encourage you to test out 6.4-RC2 and report any problems by submitting PRs or via email to the freebsd-stable list. I would love to, but it's still not available on the download area. Er, i386 isn't anyway. Ignore this. Apparently Camino caches the results of FTP directories. You have to explicitly hit reload to get the directory again, even if the results are days or weeks old. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.4 RC1 locks up solid on first reboot
On Oct 23, 2008, at 1:08 PM, John Baldwin wrote: Has anyone filed a PR on this problem, or contacted John Baldwin? Yes, but debugging these hangs is very non-trivial. It likely involves disassembling the BIOS and trying to see where it can get stuck in a loop. John, is there anything I can do to provide you with more useful information about this problem? The board is a Tyan S2720 2 2.66G Intel Processors 4 Gigabytes of RAM 2 36G ST336607LC Cheetah drives While playing around randomly I found something interesting. If the keyboard is attached while booting, you get the problem I reported before: Loading /boot/defaults/loader.con \ But if you boot without a keyboard it gets beyond that point and then pci0: ACPI PCI bus on pci0b Fatal trap 12; page fault while in kernel mode cpuid = 0; apic id = 00 ...a bunch of other stuff. I can't capture this because I can't type fast enough. Also noteworthy, I can't hit 6 to set console to comconsole so that I could cut/paste this. It really seems like there are major problems around the keyboard. (and no such problems with 6.3) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.4 RC1 locks up solid on first reboot
So I booted up by CD and used Fixit mode to switch the system to boot via serial (keyboard detached), but this gathered me even less. /boot.config: -Dh Consoles: internal video/keyboard serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/4062144kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED] Plugging back in the monitor after lockup showed only a single char more: ([EMAIL PROTECTED] On Oct 24, 2008, at 11:41 AM, Jo Rhett wrote: On Oct 23, 2008, at 1:08 PM, John Baldwin wrote: Has anyone filed a PR on this problem, or contacted John Baldwin? Yes, but debugging these hangs is very non-trivial. It likely involves disassembling the BIOS and trying to see where it can get stuck in a loop. John, is there anything I can do to provide you with more useful information about this problem? The board is a Tyan S2720 2 2.66G Intel Processors 4 Gigabytes of RAM 2 36G ST336607LC Cheetah drives While playing around randomly I found something interesting. If the keyboard is attached while booting, you get the problem I reported before: Loading /boot/defaults/loader.con \ But if you boot without a keyboard it gets beyond that point and then pci0: ACPI PCI bus on pci0b Fatal trap 12; page fault while in kernel mode cpuid = 0; apic id = 00 ...a bunch of other stuff. I can't capture this because I can't type fast enough. Also noteworthy, I can't hit 6 to set console to comconsole so that I could cut/paste this. It really seems like there are major problems around the keyboard. (and no such problems with 6.3) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.4 RC1 locks up solid on first reboot
John, is this perhaps the problem seen with 7.0, discussed here? http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-05/msg00437.html On Oct 24, 2008, at 11:41 AM, Jo Rhett wrote: On Oct 23, 2008, at 1:08 PM, John Baldwin wrote: Has anyone filed a PR on this problem, or contacted John Baldwin? Yes, but debugging these hangs is very non-trivial. It likely involves disassembling the BIOS and trying to see where it can get stuck in a loop. John, is there anything I can do to provide you with more useful information about this problem? The board is a Tyan S2720 2 2.66G Intel Processors 4 Gigabytes of RAM 2 36G ST336607LC Cheetah drives While playing around randomly I found something interesting. If the keyboard is attached while booting, you get the problem I reported before: Loading /boot/defaults/loader.con \ But if you boot without a keyboard it gets beyond that point and then pci0: ACPI PCI bus on pci0b Fatal trap 12; page fault while in kernel mode cpuid = 0; apic id = 00 ...a bunch of other stuff. I can't capture this because I can't type fast enough. Also noteworthy, I can't hit 6 to set console to comconsole so that I could cut/paste this. It really seems like there are major problems around the keyboard. (and no such problems with 6.3) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.4 RC1 locks up solid on first reboot
On Oct 22, 2008, at 9:27 PM, Milan Obuch wrote: I did not investigate on this issue too much, but there is an workaround - copy older /boot/loader over newer one. In my case, I am rebuilding whole world often, and now /boot/loader seems to not build correctly for me. Older one is ~ 250 kB, rebuilt will be ~ 185 kB, and freezes. 6.4's boot loader is 221k 6.3's boot loader is 217k Copying 6.3 boot loader to the 6.4 solved the keyboard lockup problem, but it still panics during the boot. At last now I get the entire panic to the serial console so I can cut/paste. cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06d01cd stack pointer = 0x28:0xc1020ad8 frame pointer = 0x28:0xc1020ae4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 0 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.4 RC1 locks up solid on first reboot
On Oct 24, 2008, at 6:21 PM, Jeremy Chadwick wrote: | By Jo Rhett [EMAIL PROTECTED] | [ 2008-10-24 21:13 +0200 ] On Oct 22, 2008, at 9:27 PM, Milan Obuch wrote: I did not investigate on this issue too much, but there is an workaround - copy older /boot/loader over newer one. In my case, I am rebuilding whole world often, and now /boot/loader seems to not build correctly for me. Older one is ~ 250 kB, rebuilt will be ~ 185 kB, and freezes. 6.4's boot loader is 221k 6.3's boot loader is 217k Copying 6.3 boot loader to the 6.4 solved the keyboard lockup problem, but it still panics during the boot. At last now I get the entire panic to the serial console so I can cut/paste. There are known problems with some BIOSes and USB Legacy support. Said BIOS option allows a USB keyboard and mouse to be emulated as PS/2 for operating systems which lack a USB stack, such as MS-DOS -- and more importantly, bootloaders! The FreeBSD bootloader only understands AT/PS2 keyboards, which is why that BIOS option is needed. Not related to Aragon's problem with a USB keyboard, but in my case the keyboard is USB and there are no USB devices at all plugged in. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.4 RC1 locks up solid on first reboot
I haven't had time to investigate, but after installing 6.4RC1 on a machine I've been using with 6.3 for a few months, it installs painlessly but on the first and subsequent reboots you see BTX Loader 1.00 blah blah blah ... Loading /boot/defaults/loader.con \ At this point you have a hard refreeze -- no keyboard control, however I can reboot it from the Phantom card. System: Rackable C2004, dual Intel 2.66 processors, 4gb RAM, disk drive on built in SCSI port Absolutely nothing special, boots and runs 6.2 and 6.3 without a flaw. I'll have more time to investigate on Friday. Anything specific that would be more or less useful to debug in particular? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: proposed change to support policy for FreeBSD Releases
Hi, Colin. Any news/thoughts on where we are with this? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: proposed change to support policy for FreeBSD Releases
On Sep 25, 2008, at 9:32 AM, Lowell Gilbert wrote: I'm not clear on how this helps. We don't know if there will be a need to produce a 6.5 release, so there's no way to judge whether 6.4 should be designated final or not. The only logical answer is to do so, which leaves a substantial chance that there will end up being more than one final release on the 6.x line. That's not a particularly desirable situation. In fact, it's worse, because if 6.5 happens, it will probably be because there were problems with 6.4 serious enough that we'd rather people move to 6.5 anyway (at least for critical systems). You are exactly right. I am proposing that we stop trying to guess whether or not it is a final release. A release will be supported until the next release + N months (N is currently being debated I guess) or 24 months if there is no followup release. This effectively solves both of the problems you've very accurately named above. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: proposed change to support policy for FreeBSD Releases
On Tue, 2008-09-23 at 13:37 -0700, Jo Rhett wrote: Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. A release which is not the final minor release of a branch will be additionally supported by a minimum of 6 months past the release date of the succeeding version. For example X.1 will be supported for 12 months or until 6 months past the release date of X.2, whichever comes later. Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. On Sep 25, 2008, at 7:53 AM, Tom Evans wrote: Isn't this a non-pragmatic way of looking at this? Currently, as long as there are no serious issues with 6.4, 6.4 will be supported for 24 months from release. This is abundantly clear from both prior history and what secteam say. No, it's not. The secteam has repeatedly said that they don't know yet, and can't know yet, whether or not to support 6.4 for 12 or 24 months. This is the problem I am trying to solve. Guessing at this requires foresight, psychic abilities that nobody has. I believe it's a lot more pragmatic to simply say we will support it for 24 months *unless* a major problem forces another release and stop trying to be psychic. To my mind, this entire discussion is bikeshed painting that ends up with semantic arguing about what a 'final' release is. It's not semantics. It's a very serious issue with overlapping support periods that cause businesses to stay back on older releases, which means they contribute no resources to testing new releases. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 23, 2008, at 12:45 AM, Ian Smith wrote: I mean seriously, if you were to say We will support 6.4 for 24 months *unless* we find it necessary to release 6.5 then I'd be totally happy. But that's not what is being said. I believe that's exactly what has been said. rwatson@ and simon@ have both made it exceedingly clear, to me anyway, that if 6.4 is to be the last release on the 6.x branch - as appears to be likely but cannot be stated definitely at this time, for reasons clearly given and understood - then it will indeed be supported for 24 months. It doesn't seem reasonable to expect 24 months stated support for 6.4 if it turns out not to be the last release - that would then apply to 6.5. Have you read any of the existing thread? Right now 6.4 will go out of support 3 months before 6.3. Which might or might not change at some point in the future. Isn't this obviously a fairly major problem for any business or even any person to want to spend any time to test/evaluate/etc 6.4? What I proposed in my message (which you completely ignored) was an incremental support policy that builds on each release, instead of actually promoting the idea of skipping releases. This may not be a good idea -- it was just a toss out there, but it makes a lot more sense than the existing policy. Could you at least respond to the issues raised here? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 23, 2008, at 12:45 AM, Ian Smith wrote: It also doesn't seem reasonable to expect that decision to be rushed in advance of the necessary evaluation of the success or otherwise of both 6.4 and 7.1 releases - especially when we're talking about these being only a month or so away anyway. Let me try to say this one other way. If you want businesses or anyone really who doesn't have unlimited time and energy to help evaluate, test, etc this release prior to it coming out, shouldn't you make it worth their while? Supporting 6.3 for longer than 6.4 doesn't make it worth anyone's time or attention to evaluate 6.4. Which means that it becomes significantly more likely that 6.4 will ship with a major problem that could or should have been caught in pre- release testing. The current policy of not deciding until after the fact for support periods could in fact be implemented with a reasonable policy that doesn't require a psychic to determine the likely failure or not of a release. I've proposed one. I'm sure that there are better ways to say it, but I'd really appreciate it if you guys would take the problem seriously. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
proposed change to support policy for FreeBSD Releases
Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems better. Old text: Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. Proposed (starting point for discussion for) new text: Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or 'Final'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. A release which is not the final minor release of a branch will be additionally supported by a minimum of 6 months past the release date of the succeeding version. For example X.1 will be supported for 12 months or until 6 months past the release date of X.2, whichever comes later. Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. OBSERVATIONS: 1. This avoids the need for the well-documented chicken-and-egg problem of trying to guess which release is the final release. 2. This is a consistent policy in line with many other vendor policies. 3. This rewards forward movement in the branch. And finally, as I've done the match carefully, 4. It would appear to *reduce* rather than enlarge the support requirements for the security team. Unless a minor release comes out less than 6 months after a previous release, only two versions would ever be supported at the same time. In recent history 3 minor releases in the same branch have been supported more often than not. Example under current policy: 6.5 comes out in July of 2009. For July - October the security team will need to support 3 releases: 6.3, 6.4 and 6.5. From November 2009 through January 2010 the security team will need to support 6.3 and 6.5, but not 6.4. Revised under the existing policy: Support for 6.3 expires in April of 2009. (more than 12 months past release and 6 months after the release of 6.4). Support for 6.4 expires in January of 2010. Support for 6.5 would expire in July of 2011 or 6 months after the release of 6.6. ^NOTE: this example is probably unfeasible since 6.3 already has a published support period ended in January 2010, but this will prevent a similar occurrence happening in future releases. Note2: This new policy would not change the support period for 6.4 if it is the final release, but it does completely resolve the need to guess whether or not it will be the final release. The notable change that I believe will encourage business participation in the testing/evaluation process is that 6.4 is guaranteed to be supported either 24 months, or at least 6 months past the release date of 6.5. (recent history suggests this would be 15-19 months). This encourages businesses to test and evaluate 6.4 NOW, rather than waiting until a decision about the support policy is made. Repeat from the top: nobody is demanding anything. I think this policy would make a lot more sense, and would promote forward movement. Feel free to correct me if we overlooked anything. Thanks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
John, we're already committed to upgrade to 6.3 (since it will currently be supported longer than 6.4). 6.2 support isn't part of this conversation, it has entirely revolved around support periods for upcoming releases. On Sep 23, 2008, at 1:10 PM, John Baldwin wrote: Jo, so it seems to me that you could just start by maintaining your own set of extended support patches for the FreeBSD releases you care about. I don't think you have to be a committer or secteam@ member to do this. It does mean that you might not be able to fix a bug in, say, 6.2 at the same exact time the advisory goes out at first, but you could take the patch from the advisory and apply it to your local 6.2 tree and then update your cumulative patch (would probably want to use some sort of source code control for this where you basically branch from FreeBSD X.Y where X.Y is a vendor branch of sorts). That would let you build the street cred, as it were, to be able to get the patches directly into FreeBSD more easily. To start with it is probably going to be a bit slow as far as getting things committed directly to FreeBSD proper as it means finding a committer who has the time to test and review your patch and then commit it. However, the Unofficial FreeBSD 6.2 Patchset can be updated more quickly since it is something that would be under your control. Also, doing this will give you insight into exactly what is required to support a release after it is EOL'd in a much more direct fashion than an e-mail thread. -- John Baldwin -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: proposed change to support policy for FreeBSD Releases
On Sep 23, 2008, at 4:45 PM, Colin Percival wrote: jonathan michaels wrote: On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems better. Thanks for the suggestions, but it might have helped to avoid confusion if you had contacted the FreeBSD security team privately before announcing your ideas here... I'm sorry, I'm confused. This spawned from an ongoing conversation on this list. Rather than have the dialog spin around, I figured it would be better to post a specific example of what I thought. No it hasn't. The FreeBSD Security team hasn't agreed to anything yet. Yes, absolutely to that. As posted this is my own idea, adjusted some based on input from various others, none of whom are on the freebsd security team. I'd love to hear what the freebsd security team thinks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
you're going to do this is put our employee on your security response team, I think you'd see a lot of raised eyebrows there as well. That's the point. I've never said anything like that. And a software company would totally understand the question as originally phrased. What resource limitations prevent you from supporting this product for a longer period? Any company would fairly promptly come back with an answer. FWIW, there are at least 3 companies whose software product is supported on FreeBSD, or with Apache, or various other things because of my integration work for them. We approached them and said We would like you to support XYZ. What do you need to do this? The software company chatted with us about it, and everyone decided it was easier to have me do the integration work for them as opposed to paying them more. (other companies we paid for them to do the work, etc) This is how things work. You ask a question, somebody answers the question and you sit and chat about solutions that meet everyone's needs. This situation with FreeBSD has been downright shocking because I've never before in my life been attacked for saying We need this. How can I help? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 20, 2008, at 12:04 PM, Gary Palmer wrote: Actually Robert, to be fair to Jo, I suspect it is more proper to say $COMPANY wants extended support lifetimes. What can I, or $COMPANY, do to help make that happen?. I think its been misinterpreted as Jo saying Let me do the work. He has offered to see if his company will let him help on company time, but I do not believe the constraint is quite as you phrased it above. The goal is the same, but throw it open to a wider contraint set - what resources does the project need to make it happen? Money? Test labs? Server hosting? Twinkies? Exactly. Thank you for phrasing it so very well. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 20, 2008, at 1:56 PM, Simon L. Nielsen wrote: 2 years for each supported branch would be excellent, although I'm open to alternatives. Right now 6.4 will EoL before 6.3 will :-( Eh, where did you get that information? AFAIK the EoL date of 6.4 has not yet been decided (and I should know though of course I could have I asked specifically on this list. First I was told it hadn't been decided. My response was to point out that this makes it very hard for a company to decide to commit resources to test it, if there may never be a reasonable chance for deployment. Then I was told it was 1 year, or perhaps just 6 months if it was ruled to be an unstable version. Either answer is less than 6.3's support period. If, when we get closer to the actual release, still is the plan for 6.4 to be the last RELENG_6 release I'm almost certain 6.4 will be a Extended Support release. That would be excellent. As soon as you know if this will be true, I'll be able to convince $EMPLOYER to allow me to spend time testing this release. If its not an extended support release, then it will expire before 6.3 (which is already tested) and thus $EMPLOYER gains no value in the effort. FWIW, this is why I'm in favor of consistent support periods. When you align the business benefit with the community benefit, you can get the business to help improve the community product. (remainder snipped to a different subject line) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Release team resources
Thank you for answering the resources problem in detail, I appreciate it. For what secteam support of the base system costs, it's mainly time for the members of the security team which is the cost. The more branches, the more time is required. This is not a linear cost and has multiple parts to it: ... There is also a cost in hardware for supported branches though this is less of an issue. ... The more releases are supported, the more disk-space is also needed for freebsd-update mirrors. Again, far from an unsolvable problem by any means, but also a factor This is what I suspected, but having the detail backing it up helps tremendously. Has there been done any work on metrics for the support needs? Obviously these are a bit of hand waving because the number and type of security problems are hard to predict, but it does help to provide a useful model for understanding costs In specific, is it known how many man-hours would be necessary to extend support for a recent release? NOTE that I am not trying to extend the support for 4.x or 5.x or even 6.x once 8 has shipped. I think that 2 full releases is perfectly reasonable. I'm just asking about the recent releases. While I'm not going more into the general discussion of how long to support branches, I will note that as rwatson has said - adding more people to secteam is not as simple as it sounds (though we are in the process of expanding right now). I assumed not. I was curious to what extent outside people could help support the process, while leaving commits to the internal people. For example, for everything except the jail vulnerability in the last 4 years the security problems were related to third party utilities, and were widely published in security mailing lists. Someone without a commit bit could certainly build the patch, test the patch on relevant versions, etc. Likewise, if a patch was created for the latest version, an outside person could test the patch on a desired-to-support build, confirm that it works and/or change the patch as necessary for the older build (like when third party utility versions were different between major releases). Is the overhead of supporting these not-committers such that it is not useful for the secteam as a whole? (obviously the longer term goal would be to determine which of the outside testers would be useful for promoting within the group) Newer patches also wouldn't make it to freebsd-update as that is managed by secteam. For my needs/desires I'd rather focus on something that would get pushed to freebsd-update. We have had one case where a committer was interested in supporting an older release and back-ported patches from security advisories for a while. The patches for the older releases were then reviewed in each case by the security team before commit, but that only lasted for a while and was a couple of years ago AFAIR. In theory this could happen again if the Security Officer at the time is OK with it - I haven't talked with Colin about this in a while, so I can't recall is position. There would still need to be committer which is the interface to secteam and do the commits. Most issues (though of course not all) which gets advisories are not public at the time of the advisory, so a fix to older branches would be likely be delayed some compared to initial disclosure. As noted above, very few of the security releases were based on information not available to the general public (who read security- related mailing lists, anyway) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 21, 2008, at 1:57 AM, Robert Watson wrote: This is precisely what we already do -- we guarantee we will support the last release on a branch for 24 months after the release. The point of concern being discussed is that we can't tell you for sure which minor release will be the last release at the time that release goes out the door, because the extent to which we keep releasing on old branches depends in large part on how the new branch looks. I think you are using last release in a different way. the last release is always the most release release. Right now 6.3 will have support for longer than 6.4 will, which is the nature of the problem I raised. If you always supported the most recent release for 24 months then we wouldn't have any problem. I mean seriously, if you were to say We will support 6.4 for 24 months *unless* we find it necessary to release 6.5 then I'd be totally happy. But that's not what is being said. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 22, 2008, at 12:41 PM, Robert Watson wrote: Lack of human resources, to use a vile term, is currently the limiting factor. What happens when that is cleared is another question, but in the end there aren't a whole lot of paths to greater efficiency here: ... This is an inherently manual process because security patches touch a variety of parts of the system and each has different implications, the tendency for vulnerabilities to come in classes, etc. Great, thanks. Do we have any idea how much additional human resources would be necessary to extend the support period? because there was significant divergence and maintaining three active development branches at once (5.x, 6.x, and 7.x) was a serious stretch. I've never suggested maintaining 3 different release versions, and I wouldn't suggest trying. When Sun, Microsoft, et al decide that they don't have the resources to support 3 major revisions, it's a pretty good reason to think that FreeBSD can't either ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release team resources
On Sep 22, 2008, at 1:08 PM, Robert Watson wrote: I'm not sure I agree with this analysis ... Counting on my fingers, that's 7 FreeBSD-specific, 4 that lie in code we basically maintain, and 8 that are in externally maintained software. Seems like a pretty even split. Acknowledged, sorry I was working from memory and forgot that the things we had to patch for already went through a does it affect us filter :-( You're right. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 22, 2008, at 1:32 PM, Robert Watson wrote: Long answer: we're under-manned for our current commitments, and have seen longer advisory cycles than we would like. My guess is that we could eat the first 25% of a person just catching up on current obligations so as to reduce latency on advisories, handle back-analysis of reports that don't appear to be vulnerabilities but we'd like to be sure, etc. Another hand-wave: 50%-75% of a person would allow us to move into extending our obligations as well as put more resources into proactive work. You don't have to be on the security team to work on security work (and many people who do aren't), but certainly one obligation that comes with being on the team is to try to proactively address vulnerability classes and improve infrastructure for issuing advisories, providing updates, etc. All hand-waving, understand. Depends a lot on the person, the season (reports don't arrive at a constant rate), etc. Thanks for the detail, and I think we all understand the necessary vagueness. Is a person 40 hours a week? So if I could commit 10 hours a week, I'm 1/4 of a person in this context? (assuming there was enough trust/etc that I could even do the work -- just for discussion) Tricky balance -- if you cut a major release every 18-24 months, you have a 24-month support cycle on the final point release on each branch, and you continue to release minor releases after the .0 of the next branch in order to allow .0's to settle for a bit before forcing migration forward, it's hard not to end up in the many- branch support game. That's true. I've never been a huge fan of release often in production systems ;-) That being said, I was working on Debian when they went through the Woody/Sarge era, and frankly I think that distinct production/ development tracks work even less well so it's not like I have useful advice here ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 22, 2008, at 1:54 PM, Robert Watson wrote: This is precisely what we already do -- we guarantee we will support the last release on a branch for 24 months after the release. The point of concern being discussed is that we can't tell you for sure which minor release will be the last release at the time that release goes out the door, because the extent to which we keep releasing on old branches depends in large part on how the new branch looks. I think you are using last release in a different way. the last release is always the most recent release. Right now 6.3 will have support for longer than 6.4 will, which is the nature of the problem I raised. If you always supported the most recent release for 24 months then we wouldn't have any problem. My calendar disagrees with you on this point -- 18 months from September, 2008, is after 24 months from January, 2008. And I think it's much more likely the release will go out in October. As I understand it, 6.3 will EoL in January of 2010. 6.4 will EoL in October of 2009. This is the head-scratcher that leaves me so very confused, and unable to figure out how to explain this to a businessperson. If it worked as you said -- the latest release is guaranteed 24 months but any previous release support ends at some point after the next release is out, then it's easy to explain to management. Doing this upgrade gives you a minimum of 24 months of support I mean seriously, if you were to say We will support 6.4 for 24 months *unless* we find it necessary to release 6.5 then I'd be totally happy. But that's not what is being said. I think we pretty much are saying that: whatever the final release is will be supported for 24 months. 6.4 will likely be it on 6.x, but we're not 100% committed to that being the final decision because we want to see 7.1 shake out well. Again, how do you explain that? And how do you explain a 3 month window where 6.3 is supported longer than 6.4? (not trying to be accusative or demanding, it's just a fairly odd situation) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 22, 2008, at 2:56 PM, Doug Barton wrote: I'd also like to point out that there is another chicken-egg problem that has been glossed over in this thread. You have said many times that it's hard for a company to devote resources to testing a given release candidate without knowing in advance how long that release will be supported. Several people (including Robert, who is part of the release team) have said that we can't make a firm conclusion on how long a given release will be supported until we have a pretty good idea how successful a given release will be, which requires people actually testing and using it. Do you see the problem? Yes, I do. And I'm confused as to why the release cycle is structured to keep this problem going. This is your own chicken and egg, and it's a fairly easy one to solve. Nobody else is creating the chicken and egg for FreeBSD, it's being created by the existing policy. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 22, 2008, at 3:46 PM, Robert Watson wrote: The key point here holds, however: I think we should not ever be in the position of telling people that support lifetime on a release has been reduced. I agree. However, there are other ways of doing this than to create overlapping windows of support. (totally whistling in the wind for a moment) This isn't an absolute number, but what about something like this? (it should probably be rewritten) -REL will be supported for a minimum of 12 months. It will be extended if * if no other release of the major version is planned, it will be extended 12 additional months. (24 total) * if another release is planned, it will be supported for 3 months past the date of the next release. This isn't actually all that much different from the actuality of your existing practice, but it provides a reasonable guideline that a business can understand. It's also always incrementally forward, and doesn't reward a business for staying behind on a previous release - like your existing policy is doing right now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
First, I'd like to thank you for taking the time to respond to this seriously. I hope you'll read my reply in the very serious, and not accusative tone it is meant. (I am a little tired and fried at the moment, I may not use the best phrasing. I hope I do.) On Sep 19, 2008, at 4:20 AM, Robert Watson wrote: This is the same answer I gave Lowell, but let me expand on it slightly. Our community grants rights (read also: responsibilities) on the basis of credibility in the community. Here's a possible plan: ... work for supported branches. This in turn may convince them that they should invest their time in mentoring you for a FreeBSD commit bit, and potentially join the security or release engineering teams once you've established that you are a member of the developer team who works well with others, does good technical work, and who is in it for the long haul. Look, I understand what you're saying here. And I don't discredit or disagree that it shouldn't be handled this way. But what you have addressed is a stepwise integration policy of a developer, and does not address how to get a business to commit those resources. Why? Because you are asking for the business to commit the resources without a goal. No, I'm not saying that FreeBSD has to guarantee anything. We both know that guarantees on open source projects aren't worth much. What I'm saying is that your scoped outline has no goal. Nothing to even reach for. Except maybe perhaps a commit bit for me. If I had wanted a commit bit, I'm sure I would have one by now. I'm not particularly worried about that. I don't even really care to have one (though I would if that was necessary). But that's the highest goal of your outlined scope. A commit bit. What's missing? A. A goal B. An assessment of the requirements to reach that goal ...etc To get a business to commit resources to a project there must be an actual goal. And to reach that actual goal there must be both (a) a plan to get there, (b) a reasoned assessment of the effort involved, etc etc and (z) the effort taking place to reach that goal. Obviously (z) matters and perhaps you can say it matters most. But no sane business tries to do (z) without a clear idea of what (a)(b)(...) is. If you've seen the appropriate Southpark episode: Step 3: Profit! Dude, what's step 2? (1) It doesn't give the immediate gratification of seeing the official support status extended for releases. However, as you say, you're already doing the work. I'm honestly confused by this statement, because I can't imagine anything about the proposed work being immediate no matter how it was approached. and that have they confidence of the security team that will be able to work with appropriate discretion in protecting the confidential and often critical security information we receive. Unless the security problem is reported internally within FreeBSD alone (very few problems are) I usually have the security details long before you release patches. I don't see this as much of a hindrance if any. Don't take this as a personal slight -- none of this says you aren't able to work with others, that you don't have the technical skills, that you don't have the time, aren't willing to make the commitment, or that you lack adequate discretion. Rather, it's saying that the way we evaluate people for participation in the project is that they have a track record of these things in the community. In a largely online and volunteer community, that's the way it works. There's *nothing* wrong with what you have said. What you have said makes perfect sense from an integration perspective. But I don't think it addresses the issues at hand -- businesses need to have explicit goals and at least a haphazard guess at the requirements to reach those goals before they'll commit resources. I don't see these problems as being in conflict. In fact, I would personally suggest that most of the resources you need to improve your releases don't need commit bits. I personally have no objection at all to running all patches through another set (or two, or three) of eyeballs. It's a damn good practice ;-) It's unlikely to slow me down one bit. ^^^ you may know more about the resource limitations and why commit bits are necessary to relieve your resource strain. In that situation, please educate me. Or everyone. In particular, I'll be happy to buy you coffee/beer/poison of choice at your leisure if that would make this easier. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote: To get a business to commit resources to a project there must be an actual goal. [1] The FreeBSD project would have to commit resources too. Its community Of course. This is what the requirements analysis is ;-) For (a), (b), and (z), this is where you come in. Define the goal. Make a plan to get there. Assess the effort involved. Convince your employer that (a), (b) and (z) is worth it to him/her and that the result of (z) will convince the FreeBSD project to commit the resources needed to integrate it. If they're happy, start working on (z) and bring it to the FreeBSD project when you think it's ready. Of course. If this was something that could be done without working with the freebsd developers, do you think I would put up with this kind of abuse? I'd much rather have something I could just go and do ;-) The issue is that nobody is willing to answer the question: what resources are too limited to provide longer support? How can we help? This the elephant that everyone ignores. To develop a plan, you need to know the limitations. Once those are spelled out, you sit down and try to determine what resources are necessary to achieve a certain goal. Then you find those resources, etc etc... Without input from the current release team extending the support schedule is not possible. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 19, 2008, at 8:57 PM, David N wrote: How long are you expecting support for a RELENG to last, 1, 2, 3 years? 5 years? (comparison, Ubuntu LTS is 3 years, security updates) 2 years for each supported branch would be excellent, although I'm open to alternatives. Right now 6.4 will EoL before 6.3 will :-( Are you after support for a RELENG_X or RELENG_X_Y? What are you expecting from the support? Security only? Drivers? Ports? The answer of similar people in this situation might vary. For our needs, security only is fine. Obviously I'd be willing to assist with an effort that tried to provide more support. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote: On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote: Without input from the current release team extending the support schedule is not possible. Inquiry - is release team the constraint? I don't know. I asked why not, and was told the release team said this was all they could do with the resources they have. No further information has been provided. Or to put it another way, what to you is support in terms of FreeBSD releases. As far as I am aware, if you stick on a RELENG_X_Y_Z_RELEASE tag then the most you get is security fixes. No new features, no new drivers, no bugfixes. So if I am interpreting things correctly, you are asking for security fixes to be ported to RELEASE tagged branches for longer? That is what I and my $EMPLOYER want yes, although as I said I am willing to support other efforts. (ie I am unlikely to be the difference between make or break on this effort, so if more support was something that got other businesses involved enough to achieve that change, then) So is release team the contrained resource in your problem? I am not denying that *any* part of the FreeBSD team is not resource constrained, but I'm wondering if you're examining the correct area. That's a good question I don't have the answer to. Nobody has actually defined the problem to me beyond the statement above. This is why it's difficult to determine how to best proceed. Until the real problems are laid on the table (so to speak) I haven't the foggiest idea where/how/when to help, nor whether or not my or anyone else's assistance would be useful. (one assumes it would) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote: You seem to be *demanding* quite a lot lately. I have demanded nothing. I have made a suggestion or two -- presented the background which pretty much everyone agrees with, made some suggestions about how to improve it. My last post was expressing amusement about watching every developer dance around the topic, skipping over the relevant part -- how do we improve things? We could improve things. We could get more resources. Why not consider the topic? That's not demanding. Check your dictionary. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 6:32 AM, Wilko Bulte wrote: Indeed, there is no easy solution. Extending support lifetime takes more resources of course. And my e-mails have always discussed ways to get more resources. Recently we even had a group of people trying to arrange for more explicit corporate support for testing and release process. For some reason unclear to me, not a single developer has stepped up and said Great. Here's how we could use you... The entire concept of getting *more resources* is the elephant in the room that everyone seems intent to avoid considering. Maybe, just maybe, there is some reason why FreeBSD doesn't want more people helping. Or ... something. I haven't the vaguest clue. If there is some reason why getting paid people to work on testing and release cycle is a bad idea, would someone please stand up and explain? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 8:21 AM, Freddie Cash wrote: Maybe I'm missing something here, but it seems like Jo just wants to argue for the sake of arguing. You are missing a lot. You're not reading even half of what I am saying. re: ignored. I don't ignore anything. If something is answered clearly I tend to address topics which aren't resolved. But the section you quoted is your worst example -- If you look at my reply, you'll notice that not only did I not ignore it, I replied to that section with concerns about fluctuating schedules that this document presents. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
First, thanks for taking the question seriously ;-) On Sep 18, 2008, at 8:47 AM, Dylan Cochran wrote: problem can't be solved just by extending time with the hope that the resources will be allocated (no offense to your character, but that No offense taken. I would never suggest we do anything based on hope. In my company's specific case, we'd want to work out the details of exactly how much time we'd commit and what our goal was in committing that time. (besides the obvious giving back to the community part which we do anyway) Most of the people that I know personally who are interested in this topic are in similar situations. They would want to discuss the necessary resources to achieve a specific goal, and make specific commitments on the amount of time they could give. I seriously don't know anyone who wanders into any situation saying oh, maybe if I help out the tooth fairy will visit me! ;-) That said, I know little about the multi-architecture problems you present here so I can't offer much other commentary, other than: problem is best solved not by arguing how to work around the symptoms, but to analyze and solve the parent problems that may not be so obvious. I suspect this above statement applies to every problem the release and testing teams have. What is necessary to get consensus to even discuss the issues involved? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: So far, this conversation has largely consisted of you telling us that you don't like what we're doing and demanding that we change. I'm not sure what is going on in your life to make you so defensive that someone saying I have resources, I can help. Here's the problem I'd like to address makes you think they are demanding. Nobody is demanding anything (that I have seen in this conversation). Take a deep breath, stop taking this personal - which I assume you are when you talk about demanding and let's talk about this. Most of the rest of your post is valid. Let's consider three more productive avenues by which you can offer assistance with the problem of how to increase branch support lifetimes: (1) Become a contributor to the community by developing and maintaining patches against unsupported branches, especially against older releases such as 4.x and 5.x where the branches are open for commits but have fallen out of support status. I can't promise the results will We have no 4.x or 5.x systems nor do we have any interest in maintaining those. So perhaps a good idea, but not something I can help with. I *did* offer to work on maintenance for 6.2, but was told it would be rejected by the developers. Would I extend effort to do exactly what I am talking about -- extending the support lifetime for very recent releases? Absolutely. If its in a form useful for the community as a whole. If I have to do this on my own (what we are doing internally now) then the FreeBSD community leverages nothing from the effort, and we're not changing the resources limitations at all. (2) Become a contributor to the community by identifying members of the existing developer team for whom additional funding would enable them to spend more time working on and supporting FreeBSD and providing that funding. Consider approaching the FreeBSD Foundation formally to seek matching grant funding for the project. We have funded projects, we continue to fund projects. Most of our funding right now is aimed at people who don't have the time to work on it, money or no.But again, funding does not improve the resources problem in most cases. Many $EMPLOYERs find it easier to have an employee allocate 10-20% of their work to a project than to get cash allocations for the same. (3) Become a contributor to the community by working with an existing or new company that provides support for FreeBSD commercially, and discussing Nobody who does FreeBSD support on a paid basis can generally solve the kind of problems we find. I have tried these kind of things in the past with both FreeBSD and Linux, and in every case I was significantly better at finding/fixing/patching bugs than anyone on the team. The ones I could not address (usually device driver issues) the support team could do nothing more than forward a bug report to the developer. And in general, they were less good at including relevant details and debug output than I was. In short, it's a non-op. official EoL date for the project. Companies like FreeBSD Mall have strong relationships with the project, and in the past have contributed significantly to efforts such as release engineering. It's not hard to imagine a company along those lines using something along th elines of a Robert, here we go again. You have given several options, not a single one of which will provide more resources to the release team. The only thing you've successfully done is given me three different ways to eff off and leave you alone. Apparently, more resources is not in your interest. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Thu, 18 Sep 2008, Jo Rhett wrote: And my e-mails have always discussed ways to get more resources. Recently we even had a group of people trying to arrange for more explicit corporate support for testing and release process. For some reason unclear to me, not a single developer has stepped up and said Great. Here's how we could use you... The entire concept of getting *more resources* is the elephant in the room that everyone seems intent to avoid considering. On Sep 18, 2008, at 12:22 PM, Robert Watson wrote: No, we're just waiting for you to go ahead and do it. Um, how? I suspect you're being sarcastic, but I'll take this at straight value. I have repeatedly said I could commit X resources, and I know others who are likewise willing to make a proposal for the same with their employer, if our efforts could help improve Y problem. Not a single person, *not one*, has ever taken the proposal seriously enough to sit down and discuss with me what kind of resources are necessary to solve this problem. Seriously, go back and read every reply to me on this or the other thread. Every one says We aren't going to do it. No, we'd love it if more people were paid to work on things like this, but there are two practical problems: (1) finding people, and (2) paying them. At the moment I will only speak for myself, so let's start there. I write code. I do integration and testing for a living. I currently maintain a number of ports, including cfengine -- which I personally added the PKGMGR code to for FreeBSD support. My employer is paying my salary, and is willing to dedicate some of my time to the FreeBSD project as a whole. (already does in fact, on the table is to increase that amount) (1) you've found me and (2) I'm already being paid. There are others in the same situation. All of us are busy people -- we have jobs, we have houses with mortgages, etc, and those of us who are already spending a lot of time on FreeBSD are probably pretty maxed out without adding more to our plates. You seem to have a lot of energy to burn sending e-mail about how to improve the world, and I think what the rest of us would like to see is that energy get turned to the more practical part of the problem. As would I. If we could focus on how to improve the situation which has been very well described, we'd be doing something. I don't think you have any idea how frustrating it has been -- I'm here. I'm ready to help. We need to determine how to do this... and nobody will even discuss the problems with me. (if this was a port or a single component then I'd just go run away and do it myself. But the release process is obviously much more complex and I couldn't possibly replicate it or extend it in any fashion from the outside) If you are literally standing there with money that you can't figure out how to spend, contact the FreeBSD Foundation Board with a specific proposal regarding the amount of money and what you're trying to accomplish. Perhaps we can help you identify people who would take the money, companies that might want to be involved, help provide some matching funding, etc. However, it needs to be at least a strawman concrete proposal, because waving hands only gets you so far. And it has to be something worth taking time away from all the other things busy people get up to in life, such as optimizing network stacks, fixing file system bugs, supporting releases, etc, or the endeavour has hurt rather than helped. From our experience, there is a lot more money than there is people's time to address the problem. (as you note above and in the final sentence here) I'm trying to offer something -- more people, already paid, to provide more assistance. But since this involves the release process, we'd have to be integrated into the effort to be useful. FYI: this message is the first I've seen that is going somewhere good. I hope you'll take what I am saying seriously. I'm going to stop replying to many of the other subthreads because they aren't going anywhere good, and I'm probably replying too often anyway. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 12:25 PM, Mike Tancsa wrote: I am not familiar with your company nor any developers that work for you. Perhaps you could elaborate on how you have contributed to FreeBSD ? This domain is my vanity domain, actually. Well not vanity but the domain I use on the rare occasions when I do paid work for other companies. (used to be a lot more, is significantly less now) And no developers work for me. When I sold out my contract got an explicit no head count ;-) I likey ;-) In my $EMPLOYER the main proposal would be to dedicate more of my time. The others contribute at random, but I don't see that changing much due to their existing commitments. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote: I am sorry, I meant, what have you contributed currently or in the past to FreeBSD ? i.e. what code, or money or physical resources (hardware) or time testing code ? I do a lot of testing and patches regarding components we use. Search the PRs. I maintain several ports. I built freebsd package management into cfengine, and greatly extended the package management functionality above and beyond to support every operation freebsd can take on a package. We host numerous freebsd developers in our facility for nearly nothing. We pay for development of features that we need but don't have the appropriate skills to fix ourselves. We sponsor freebsd promotional activity, like the MeetBSD conference coming up this November. In short, we support FreeBSD in every way that I am aware of there is to support it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 1:20 PM, Lowell Gilbert wrote: I've kind of lost the drift, but it sounds to me as though Jo Rhett is tentatively offering to take on extended support for 6.2, but not earlier versions. Aside from programming skills, what would Jo need to bring to the table in order to provide that back to the project? Is that a reasonable statement of what's on discussion here? [Sorry for putting words into people's mouths, but I need a more concrete discussion in order to be sure I know what anybody actually means.] Thank you. If you don't mind I'd prefer to widen the scope a touch because 6.2 will eventually go away, and frankly it is probably better to look forward than to resurrect an unsupported version. So I would probably state: Jo's $EMPLOYER has significant interest in longer support for -REL versions. Enough to fund my time supporting the mainstream project. What would Jo (or anyone else in a similar situation) need to bring to the table in order to provide back to the project? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 2:03 PM, Mike Tancsa wrote: I had a search and I see some PRs you have submitted, but I guess you commit under a different @freebsd.org email address ? I don't commit. I submit and others commit. This hasn't really been a handicap ;-) Thats most excellent! I think people would take your suggestions with greater gravity if you reminded them with a few URLs to point out the various commit messages that say, sponsored by netconsonance etc. Or perhaps a few of these numerous developers could speak up on your behalf? Again, netconsonance is Jo and a few random others that contract via the company to avoid having to create their own company. The We in most of my discussions is my $EMPLOYER.And you can see their logos and name listed in numerous places. We pay for development of features that we need but don't have the appropriate skills to fix ourselves. That then went back into FreeBSD ? Can you give examples ? I ask all this as you really, really want things to change, and you say you have \ I'm sorry, but I have neither the time nor the interest in trying to provide a FreeBSD resume to someone. This is a tangent, and never in my experience has a tangent moved the original discussion forward. Are you in a position to make changes? What role in this do you have? What value is there answering these questions? (which have been answered many times if you google for them) I'd rather just drop this tangent. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
I agree with pretty much everything you've said here, with the obvious
exception that I don't know what's involved in the release management
process to do as you've said.
Also for my own self, rather than resurrect 6.2 I'd personally rather
focus on what we could do to extend the support period for 6.4. And
other releases going forward.
In particular, I'd like to highlight what you said here because you've
said very clearly what I've been trying (apparently not so well) to
say for some time now:
In this way, the companies which are already paying their people to
apply security fixes to old releases can donate the work which is
already being done back to the project. Hopefully they will end up
sharing the load so that they reap the benefits of work done by other
companies which are paying people to do the same things.
Thanks.
On Sep 18, 2008, at 3:02 PM, Scott Lambert wrote:
I don't have a dog in this fight. I'm just writing this message
because
it looks to me like there is a lot of talking past one another going
on
between people who are basically in violent agreement with one
another.
I am hoping that wording things differently will lead to understanding
on both sides. I may have completely misinterpreted both sides.
Spoken
languages are too ambiguous.
Here is the boiled down gist of my interpretation of a possible way to
go forward with this; bad pseudo code:
RESOURCES='Jo and the others he seems to know of who back port fixes
to
their production versions of unsupported versions of
FreeBSD.'
For i in RELENG_X_Y (where X_Y is not a currently supported
version of FreeBSD); do
grant maintenance commit access for $i to ${RESOURCES}
done;
Now for the code documentation:
Maybe one of the ${RESOURCES} could build some web application whereby
people could sign up to be a community extended support resource for
RELENG_X_Y until $date_in_the_future. Perhaps a letter of commitment
from ${RESOURCE}s ${EMPLOYER} would be required before accepting the
candidate for work on RELENG_X_Y.
Then the existing developers or core team could approve their
application/access and provide a mentor if they aren't currently
commiters. (This is some extra work for the existing people. But
hopefully the rewards would be worth the minimal? effort.)
Eventually, the mentor pool could be wholly from ${RESOURCES}. Much
of the approval of new candidates would be from the same pool. The
whole thing might have to be conditional on ${RESOURCES} bringing the
necessary tinderbox type hardware to do basic QA on their extended
support branches. With enough ${RESOURCES} signed up, they might be
able to get hardware from ${DONORS} other than themselves.
The ${RESOURCES} people could gang up on which RELENG_X_Ys they want
to
support. They can support them for as long as they have people on the
team who are interested in supporting them. Presumably, these people
would be working for companies which have made a commitment to use
RELENG_X_Y for N years.
In this way, the companies which are already paying their people to
apply security fixes to old releases can donate the work which is
already being done back to the project. Hopefully they will end up
sharing the load so that they reap the benefits of work done by other
companies which are paying people to do the same things.
So long as the requirements for a back port to the ${RESOURCES}
supported branches are the same as to an officially supported branch,
there shouldn't be much chance of harm. Perhaps they are only allowed
to back port fixes which have been approved for a supported
RELENG_X_Y.
Eventually, if enough ${RESOURCES} sign up, they might be able to
release X.Y.z distribution media. If they only provide the media for
CD/DVD purchase, the revenue might help to provide for QA tinderboxes
for the ${RESOURCES} supported work.
We might even end up with more people who are familiar with the
release
process and volunteer to work on RELENG_X_Y from initial release all
the way through normal end of support and into the community extended
support period.
I think that would provide, as much as is possible, for the don't
make
extra work for the existing developers requirement as well as giving
these resources a way to put up or shut up. I could be wrong.
--
Scott LambertKC5MLE Unix
SysAdmin
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote: I think FreeBSD is getting in a difficult position now because there's so much cool new stuff being shoe-horned in, but without the necessary volume of contributors to back it up with testing and bug fixes. On Sep 15, 2008, at 11:56 PM, Mark Linimon wrote: We're interested in suggestions about how to get more people involved with testing and bug fixes. There's certainly no lack of demand for the features -- all the way from running on inexpensive wireless routers all the way up to 'enterprise- grade' distributed storage solutions. (These are real examples from various mailing lists.) So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? As I have said to you directly in personal e-mail, the maintenance schedule is creating a chicken and egg problem. If companies weren't forced to run internal distribution and release management on their own, they could allocate more resources (ie volunteers -- PAID ones!) to testing and release management of the main distribution. To speak personally from my own experience: our business can not afford to pay me to help develop a release effort with an unknown maintenance period (6.4-REL). Since we need to have a clear maintenance window for any installed/upgraded host, we are forced to provide that support internally. If we had known (and longer than 12 month) maintenance periods for a given release, then I could avoid maintaining this infrastructure internally and would have somewhere in the neighborhood of 20 hours a month I could dedicate to testing and bug fixes of FreeBSD as a whole. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 16, 2008, at 12:38 AM, Matthew Seaman wrote: On 'long term support of release branches' -- a volunteer project is always going to struggle to provide this without some form of income to support the necessary hardware and personnel resources needed. Or in other words, if FreeBSD users want the same sort of support structure as they can get from a commercial vendor, it's going to take a commercial vendor to supply it. FreeBSD Corporation anyone? I disagree. The entire advantage of open source is the advantage provided by shared interest in a working product. Each party can put in a little and the product is improved for everyone. If we remove the factors that hamstring companies from providing more resources to assist, then you can get more resources working on the problem - to everyone's benefit. I'm not kidding when I say that nearly everyone I know who uses FreeBSD in their company spends a lot of time managing their internal distribution. (And every reply to this topic on this mailing list has echoed the exact same statement.) None of the ones I know personally have any interest in doing this, and would be happier focusing their effort on the mainstream release. A bunch of us made proposals to our $EMPLOYERs to make this happen, but there was no apparent interest from the release team so the effort was abandoned. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Mon, 15 Sep 2008, Jo Rhett wrote: Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? On Sep 16, 2008, at 12:47 PM, Robert Watson wrote: The FreeBSD Project, as with any other company or organization, responds to events as they occur. We try to plan ahead, and when things go better or worse than expected, we sometimes change the plans. As far as I know we've never *shortened* the expected support timeline for any branch or release, but we have on occasion lenthened them when we feel it's important to do so. I'm not sure what other answer is possible. No other answer. But nobody has yet provided what the EoL period is going to be. I have no problems with a period being extended ;-) But the business needs to know the minimum EoL for a given release to determine if upgrading to that release is viable. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently I understand what you mean, but the statement is blatantly false as stated. Anyone selling software to the US Government *must* specify (or meet, depending) a minimum support period, and must also specify a cost the agency can pay to extend the support period. Not relevant to FreeBSD -- just qualifying the statement as it stands. For the obvious comparison, Solaris versions have well- published release and support periods, usually upwards of 8 years. Obviously they have more resources to do this, I'm just pointing out that the statement you made is incorrect as stated. and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) Your limitation is resources, right? You've calculated what you can support based on the resources you have, right? We are talking about ways to increase the resources available to you... right? So the math on which the conclusions are reached then changes. So lets figure out... what do the basis numbers need to be to change the support period? Obviously this is a bit of hand waving. These numbers are unlikely to be empirical. But try. Examine the concept of having increased resources. What do you need. How do you need it, to make a real change? Please stop avoiding even considering what people are offering to you. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 5, 2008, at 1:19 PM, Ben Kaduk wrote: Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. I don't remember seeing any speculation about 6.4 being an extended release, so, EoL is 12 months after release, whenever that actually happens. Okay, so 6.3 will EoL at roughly the same time as 6.4. Why should anyone spend any effort on 6.4? That's the difference between a long-term-support branch and a regular branch; many OSes do that. If you want to run the same machines for a long time and not have to do a huge battery of tests (at the expense of getting new features and better performance in the interim), you use long-term branches. The regular branches that get released later, will then become unsupported at the same time as the (older) long-term branch. Yes, it's poor when a long-term branch goes EoL before there's another one ready to take its place, but if the new one isn't ready, then you just use whichever regular release is current and then snag a long-term release when it becomes available. Yes, it's more work, but that's life. Is it just me, or does this make no sense at all? This does make it clear to me why the release team can't find the resources to do longer support. Who can convince their company to put resources into the mainstream release effort, when this kind of cycle basically forces every company to run their own internal release process. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 6, 2008, at 4:06 AM, Robert Watson wrote: Unfortunately, it's a little hard to tell at time-of-release whether a particular release will become extended life or not. This is because extended support status is dependent on the success of the release ... from earlier branch adopters. How long we keep release 6.x releases will depend entirely on how successful 7.x is; I think there's a reasonable expectation that 6.4 or 6.5 will be the last 6.x release, in which case we would want to grant it extended support status. But what happens depends a lot on how successful 7.1 is. My hopes are high, but there's nothing like real-world deployment to shed light on things :-). Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. I was also told that I should have been more active in the release cycle process for 6.3, etc. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? How does one talk to management about getting resources assigned to help with the freebsd release testing process, when one cannot make any valid predictions for that release will even be supported long enough to justify the effort involved in upgrading? What you are saying is completely reasonable from a developers point of view. But those of us who use freebsd in an environment which requires extensive testing and long-term planning for support have trouble with this. In short, I can't imagine how I could possibly make any business case to get support for helping the freebsd dev/rel process at all. Why? Because frankly we're going to be forced to run our own internal release management process instead. I guess this is not surprising, as this appears to be what every other business using significant amounts of freebsd in production are doing today. My point to you is that if this wasn't being forced upon every company that uses FreeBSD, those companies could commit more resources to help the core (main branch, whatever - not Core) freebsd development. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Where can one find the expected EoL for these releases? On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: http://www.freebsd.org/security/security.html#supported-branches To quote from the above web site: (snip) On Sep 4, 2008, at 6:36 AM, Wesley Shields wrote: These are the existing releases. I believe Jo was looking for EoL for 7.1 and 6.4 once they are released. Yes, thank you. The answer to that is not clear - nor do I know if it should be clear yet. I don't know when the type of support decision is made, but I suspect it's not this early in the process. The release date for 6.4 is ~30 days away, isn't it? Also given that we've previously seen overlaps such that a newer version is only supported to the same EoL as the older version, that would pretty much dictate that spending resources on testing 6.4-REL and/or upgrading would be futile. To go back to the original statements made at the time: you should consider the lifetime of the release before you invest resources in it. That means we need to know the lifetime to determine how much resources to apply to testing it, yes? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Where can one find the expected EoL for these releases? I've poked around the website and can't find any notes mentioning this, although several people have been making posts suggesting that people should review the EoL schedule when planning their upgrades. On Aug 22, 2008, at 5:51 AM, Ken Smith wrote: We're about to start the release cycle for FreeBSD-7.1 and FreeBSD-6.4. The proposed schedule for the major events of the cycle is: Freeze August 29 BETASeptember 1 Branch September 6 6.4-RC1 September 8 7.1-RC1 September 15 6.4-RC2 September 22 7.1-RC2 September 29 6.4-REL October 6 7.1-REL October 13 I haven't posted the schedule on the Web site yet, I'll try to get that done over the weekend. On Monday I'll switch RELENG_7 and RELENG_6 over to say they are 7.1-PRERELEASE and 6.4-PRERELEASE respectively as a heads-up that there will likely be higher-than-normal developer activity MFC-ing stuff before code freeze starts. Odds get higher that if you do updates using RELENG_7/RELENG_6 branches during this period you *might* wind up with a tree that isn't quite right because you happened to catch it part way through a developer doing a multi-step commit. We had been procrastinating on saying definitively whether we thought 6.4-REL would be the last of the RELENG_6 releases to see how well things went with 7.X (if 7.0-REL was a total disaster we'd have considered doing a 6.5-REL). It seems that 7.0-REL went well and RELENG_7 in general seems to be in good shape so we now expect 6.4-REL to be the last of the RELENG_6 releases. Thanks. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
chipset causing locks.
Thanks for the note. No, just a coincidence. The chipset is a VIA ProSavageDDR KM266. But thanks for bringing that up ;-) FWIW, as others have speculated enabling more logging from GEOM produced nothing. It does appear to be a hardware failure of some sort. On Jul 18, 2008, at 11:29 PM, Peter Wemm wrote: On Wed, Jul 16, 2008 at 2:42 PM, Jo Rhett [EMAIL PROTECTED] wrote: On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: Every time it is rebuilding ad0. Every single boot in the last two weeks. On Jul 11, 2008, at 9:49 AM, Clifton Royston wrote: That just means that it halted without a proper shutdown. If it crashes, the mirror isn't stopped properly, so it's marked dirty, so it must rebuild it. It is the precise analogy of finding all the file systems dirty on boot and fscking them, following a crash. Thanks for the clarification. Dang, I hoped I was on to something. This is really off on a tangent, but I thought I'd mention it on the off-chance that it fit your problem. Recently there have been grumblings about heat problems with certain nvidia chipsets on consumer boards. Apparently, there is some process issue, if you believe trade rags like theinquirer.net etc. Apparently there is some issue with heat damage over time. Consumer motherboards with passive cooled (no fan) heat pipes etc seem to be particularly vulnerable. I use the word apparently because it is far from a verified fact. However, I've got two motherboards, one running freebsd, one running windows, with nvidia chipsets. Both used to be fine with onboard IDE activity. Both now use raid controllers so the IDE interfaces have been idle for a good year or so. Something came up and I had to use the IDE interfaces for a lot of data transfer. Suddenly, both machines are flakey. The windows machine blue screens under load. My freebsd box just turns off (motherboard appears to power off, but the power supply is on still). The same happens when I use a linux boot disk, so I know its not FreeBSD's fault. The common factor seems to be that the motherboards are now about a year and a half old. They both have the same nvidia south bridge that theinquirer.net was trashing. Both used to work fine, now have problems with IDE. and now I recalled the article and started wondering... Do you, by any wildly remote chance, have an nvidia based motherboard? I believe the fault I'm seeing is the system asserting a fatal error by doing a HT ECC flood to halt everything. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to get more logging from GEOM?
On Jul 11, 2008, at 4:48 AM, Ronald Klop wrote: You can try going into the kernel debugger to see where it is hanging. Debugging via a serial cable is also very easy. I don't know the details, but there is a lot of info in the Freebsd handbook. Put this in google 'freebsd handbook kernel debug'. Thanks for the reply. I'm familiar with these options, but as the system is currently running GENERIC and trying to compile a kernel would guarantee to cause the problem to occur... I could probably keep hacking at it until I finally get everything compiled, but... Ugh. I guess this option doesn't appeal very much. Are there any other options available? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to get more logging from GEOM?
On Jul 11, 2008, at 8:58 AM, Roland Smith wrote: After about 2 weeks of watching it carefully I've learned almost nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now running healthd without complaints) it's not based on any given network traffic... however it does appear to accompany heavy cpu/ disk activity. It usually dies when indexing my websites at night (but not always) and it sometimes dies when compiling programs. Just heavy disk isn't enough to do the job, as backups proceed without problems. Heavy cpu by itself isn't enough to do it either. But if I start compiling things and keep going a while, it will eventually hang. Is there anything else I should be looking at? Power supply or motherboard would be my first guess. If the system went offline, I agree. But it's clearly a kernel deadlock, since the system remains pingable, answers TCP connections, etc etcc but doesn't respond. No TCP negotiation, no response on the console, etc. It's higher level activity which isn't working... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to get more logging from GEOM?
On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: Every time it is rebuilding ad0. Every single boot in the last two weeks. On Jul 11, 2008, at 9:49 AM, Clifton Royston wrote: That just means that it halted without a proper shutdown. If it crashes, the mirror isn't stopped properly, so it's marked dirty, so it must rebuild it. It is the precise analogy of finding all the file systems dirty on boot and fscking them, following a crash. Thanks for the clarification. Dang, I hoped I was on to something. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
how to get more logging from GEOM?
About 10 days ago one of my personal machines started hanging at random. This is the first bit of instability I've ever experienced on this machine (2+ years running) FreeBSD triceratops.netconsonance.com 6.2-RELEASE-p11 FreeBSD 6.2- RELEASE-p11 #0: Wed Feb 13 06:44:57 UTC 2008 [EMAIL PROTECTED] :/usr/obj/usr/src/sys/GENERIC i386 After about 2 weeks of watching it carefully I've learned almost nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now running healthd without complaints) it's not based on any given network traffic... however it does appear to accompany heavy cpu/disk activity. It usually dies when indexing my websites at night (but not always) and it sometimes dies when compiling programs. Just heavy disk isn't enough to do the job, as backups proceed without problems. Heavy cpu by itself isn't enough to do it either. But if I start compiling things and keep going a while, it will eventually hang. My best guess is that geom is having a problem and locking up. There's no log entry before failure to back this idea up, but I think this because during boot I see the following: ad0: 286168MB Seagate ST3300622A 3.AAH at ata0-master UDMA100 GEOM_MIRROR: Device gm0 created (id=575427344). GEOM_MIRROR: Device gm0: provider ad0 detected. ad1: 286168MB Seagate ST3300622A 3.AAH at ata0-slave UDMA100 GEOM_MIRROR: Device gm0: provider ad1 detected. GEOM_MIRROR: Device gm0: provider ad1 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. GEOM_MIRROR: Device gm0: rebuilding provider ad0. Every time it is rebuilding ad0. Every single boot in the last two weeks. Is this any way to get more logging from geom, to confirm or deny this theory? Is there anything else I should be looking at? FWIW, this never happened before the p11 patch to 6.2. I don't know if that is related or not. Obviously, I can't upgrade to 6.3 if heavy cpu/disk activity kills the system. No, I don't have any other insights. I'm not prone to posting duh help me please! posts, so I'm quite a bit frustrated by this one. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no serial console for ttyd0 HP Blade
I'll bet you that sio is deciding that com1 or not, it's sio1 (not sio0) which can be fixed with the changes I mention below. On Jul 1, 2008, at 11:38 PM, Ulf Zimmermann wrote: I take that back, on blades the virtual serial is on COM1. On Tue, Jul 01, 2008 at 11:36:51PM -0700, Ulf Zimmermann wrote: Also remember that the blades have 2 serial ports, one can be accessed via a dongle in the front of the blade and I believe that is what usual would be called COM1 by default. The virtual serial via ilo takes up the COM2 by default. This is at least the default on DL series servers and I haven't checked into using the virtual serial on the Blades we have. On Tue, Jul 01, 2008 at 09:42:16PM -0700, Jo Rhett wrote: This rhymes with sio deciding that your TTY is something other than ttyd0. We had this same problem on Rackable -- even though the proper tty was setup 0x3f8 irq 4 it was being assigned to sio1. You can see this by 'grep sio /var/log/messages' The only fix for this is to edit /boot/device.hints and reassign the flags to the sio1 interface, like so: hint.sio.1.at=isa hint.sio.1.port=0x3F8 hint.sio.1.flags=0x10 hint.sio.1.irq=4 hint.sio.0.at=isa hint.sio.0.port=0x2F8 hint.sio.0.irq=3 On Jul 1, 2008, at 8:23 AM, Marian Hettwer wrote: I installed a recent (as of today) RELENG_7 on one of our HP Blades. Unluckily my serial output stops right when a getty at ttyd0 should kick in. So I'm blind for the rest of the startup. Very unfortunate. The boot menu, as the bootup itself is printed out on serial console until: da0: COMPAQ RAID 0 VOLUME OK Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: 139947MB (286611840 512 byte sectors: 255H 32S/T 35124C) Trying to mount root from ufs:/dev/da0s1a bce0: link state changed to DOWN bce0: link state changed to UP bce1: link state changed to UP Which is, what I think, the point when init should take over and spawn a serial console on ttyd0, according to my /etc/ttys: # grep ttyd0 /etc/ttys ttyd0 /usr/libexec/getty std.9600 vt100 on secure # cat /boot/loader.conf comconsole_speed=9600 console=vidconsole,comconsole # A comma separated list of console(s) boot_multicons=-D # -D: Use multiple consoles boot_serial=-h # -h: Use serial console # uname -a FreeBSD db46-202.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Jul 1 14:59:43 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/ sys/ GENERIC amd64 The blade itself is a HP BL465c G5 Any ideas? I don't have this blade for a long time, so I'm a bit in a hurry. In fact, right now I'm testing this setup against a Debian 4.0 with Linux 2.6.25.9 under MySQL load, and up until now the machine looks good. If I wind up with a fully working, nearly as fast and stable as our linux boxes installation, I'd might be able to convince the boys at work to give FreeBSD a try. And in a 600 server setup, I'd be thrilled to do so :-) So lets get started with this serial console issue... which is indeed a pain :( TIA, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no serial console for ttyd0 HP Blade
On Jul 2, 2008, at 1:04 AM, Marian Hettwer wrote: puuuh, well, with your suggested change, I do get a login prompt now (at ttyd1 it says), but I don't see any bootup messages anymore. It seems that the sio0 is irq 4 while booting and becomes irq3 later. That's odd. If I remember correctly, one was able to configure the mapping of serial ports in the BIOS (in regards to those HP blades). Perhaps that helps. I'll give it a shot and if I found a way to have boot messages and the login getty, I'll drop a [solved] mail to this list. So the boot loader uses 0x3f8 irq 4 no matter what it's mapped to. Second stage does something similar, but After you've loaded the kernel it does mappings to sio0 and sio1 and these may be different. This is why you have to screw with device.hints so that all three stages are using the same device. Jul 1 15:13:57 db46-202 kernel: sio0: Standard PC COM port port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 It's pretty clear from your grep command that sio0 is 0x2f8 irq 3, but the boot loader always uses 0x3f8 irq 4. You have to change these until the device which has 0x3f8 irq 4 has the flags 0x10 option, which is what makes it the console. NOTE: I think this whole parade sucks, and the kernel should believe device.hints ... but there is no apparent interest in solving this problem (even when a bounty is offered), and I don't do enough device driver development these days for it to be worth my time. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no serial console for ttyd0 HP Blade
This rhymes with sio deciding that your TTY is something other than ttyd0. We had this same problem on Rackable -- even though the proper tty was setup 0x3f8 irq 4 it was being assigned to sio1. You can see this by 'grep sio /var/log/messages' The only fix for this is to edit /boot/device.hints and reassign the flags to the sio1 interface, like so: hint.sio.1.at=isa hint.sio.1.port=0x3F8 hint.sio.1.flags=0x10 hint.sio.1.irq=4 hint.sio.0.at=isa hint.sio.0.port=0x2F8 hint.sio.0.irq=3 On Jul 1, 2008, at 8:23 AM, Marian Hettwer wrote: I installed a recent (as of today) RELENG_7 on one of our HP Blades. Unluckily my serial output stops right when a getty at ttyd0 should kick in. So I'm blind for the rest of the startup. Very unfortunate. The boot menu, as the bootup itself is printed out on serial console until: da0: COMPAQ RAID 0 VOLUME OK Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: 139947MB (286611840 512 byte sectors: 255H 32S/T 35124C) Trying to mount root from ufs:/dev/da0s1a bce0: link state changed to DOWN bce0: link state changed to UP bce1: link state changed to UP Which is, what I think, the point when init should take over and spawn a serial console on ttyd0, according to my /etc/ttys: # grep ttyd0 /etc/ttys ttyd0 /usr/libexec/getty std.9600 vt100 on secure # cat /boot/loader.conf comconsole_speed=9600 console=vidconsole,comconsole # A comma separated list of console(s) boot_multicons=-D # -D: Use multiple consoles boot_serial=-h # -h: Use serial console # uname -a FreeBSD db46-202.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Jul 1 14:59:43 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ GENERIC amd64 The blade itself is a HP BL465c G5 Any ideas? I don't have this blade for a long time, so I'm a bit in a hurry. In fact, right now I'm testing this setup against a Debian 4.0 with Linux 2.6.25.9 under MySQL load, and up until now the machine looks good. If I wind up with a fully working, nearly as fast and stable as our linux boxes installation, I'd might be able to convince the boys at work to give FreeBSD a try. And in a 600 server setup, I'd be thrilled to do so :-) So lets get started with this serial console issue... which is indeed a pain :( TIA, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tracking -stable in the enterprise
On Jun 25, 2008, at 3:46 AM, Peter Wemm wrote: No. Why on earth would we do that? if we wanted to cause ourselves that much pain for no good reason, we'd go get a pencil and stab ourselves in the eye. We don't upgrade machines that have been deployed unless there is a good reason to. This makes sense. But for personal curiosity sake, what if Yahoo needed to stick with supported FreeBSD releases? How would you deal with updating that many machines every 12 months? Would that be possible in your business? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
tracking -stable in the enterprise
On Jun 23, 2008, at 7:51 AM, John Baldwin wrote: FWIW, Yahoo! tracks -stable branches, not point releases. I'm curious about this (and stealing the dead thread). How does one track -stable in an enterprise environment? I assume that what you mean is we pick points in -stable that we believe are stable enough and create a snapshot from this point that we test and roll out to production ...? Am I wrong? I mean, I guess Yahoo has enough resources to literally run every commit to -stable through a full test cycle and push it out to every machine, but my mind boggles to imagine the manpower cost of doing so. (and to justify the manpower cost versus the gain from doing so...) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tracking -stable in the enterprise
On Jun 25, 2008, at 3:46 AM, Peter Wemm wrote: Correct. We roll our own build snapshots periodically, but we also keep a pretty careful eye on what's going on in the -stable branches. Okay, that makes sense to me ;-) I mean, I guess Yahoo has enough resources to literally run every commit to -stable through a full test cycle and push it out to every machine, but my No. Why on earth would we do that? if we wanted to cause ourselves that much pain for no good reason, we'd go get a pencil and stab ourselves in the eye. Yes, we are definitely on the same page. Thanks for the clarification ;-) We don't upgrade machines that have been deployed unless there is a good reason to. Do you deploy machines for longer than 1 year? How do you deal with security patches in the longer term? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Closing the Jo Rhett argument
On Jun 9, 2008, at 4:25 PM, Joe Kelsey wrote: Jo Rhett has clearly stated (in offline reply) that they do not participate in the -BETA and-RC cycles leading up to -RELEASE, so they therefore do not have any issues with -RELEASE and EoL to raise. Actually, they still have the same complaints to raise about EoL, but since they refuse to participate in the -RELEASE process, they do not have valid points to raise. I ask that everyone please stop communicating with the persona known on this list as Jo Rhett unless and until they participate in the - BETA, -RC, and -RELEASE process. You cannot raise any sort of valid I'd really like to ignore this post because it would appear Joe Kelsey is insane (not kidding, read below). But just in case someone believes this, I have quoted here my entire reply to Joe Kelsey (only one reply). You'll notice that there is no mention of the release cycles. It wasn't part of the topic at all. Um, no. My post was not titled I can't upgrade to 6.3 for a reason. The problem is the very limited EoL times set for the releases. And I'm not talking about reading the CVS logs and assuming anything. I have a customer using the exact same hardware we are using who is the reporter of some serious problems with 6.3. They were forced to stop rollout of 6.3 because of them. Their untouched 6.2 machines continue to run fine. This is why I said guaranteed to fail. The main problem is the constant release churn. There *were* a lot of people willing to invest time/money/machines to provide longer EoL for releases. I was asking for information to determine what resources were necessary and how to best apply them. (this detail is necessary because we were going to put together a proposal to take to our respective $EMPLOYERs and get financial support behind this) I suspect your heart is in the right place, but your actual post is of the nature of 1. Take the stated information and resolve it to something else 2. Make the stated person sound like an idiot for your own interpretation of it 3. repeat again and again for a few more paragraphs. Perhaps you should just once assume that the poster is competent, knows exactly what they saying, and means what they say? I didn't say guaranteed to fail because I had a bad dream about it. I said it because I have a 6.3 system in the test lab showing the exact same failure. Why was I not showing the output in this thread? BECAUSE THE THREAD WAS SUPPOSED TO BE ABOUT POLICY AND SUPPORT RESOURCES. Seriously, next time you find yourself thinking that someone else is an idiot, take a step back and try, just try to put yourself in their shoes. Try and imagine that this person is competent, and is being honest about what they say. And before you ask, I did do this when I wrote this message. I suspect your heart is in the right place. I usually believe this in other people, it makes my world a happier place to be. The first time mention of BETA and RC cycles came up was in his reply to me, which was full of personal insults and attacks like the following, so I discarded it without reply: I see no reason to assume competence on your part since you have demonstrated no competence. ... I don't need to assume anything about you. You have demonstrated your idiocy to everyone on the list. Please keep your insane rants to yourself in the future. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 1:39 AM, Peter Jeremy wrote: On 2008-Jun-04 22:22:33 -0700, Jo Rhett [EMAIL PROTECTED] wrote: And please stop with the loaded language. I'm not asking anyone to work for me. I am suggesting that it is perhaps too early to EoL 6.2 because 6.3 isn't ready yet. So you have stated. When asked to provide evidence to backup that statement, you have refused. Since you are the one claiming that 6.3 isn't ready yet, the onus is on you to put up or shut up. Sorry, Peter to have annoyed you, but this kind of language is useless for accomplishing anything other than pissing me off. I'm not going to go there. And I never refused anything, simply indicated that I didn't have time at that moment. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 2:45 AM, Steven Hartland wrote: You are still fail to take to the time to even tell people what these bugs are, no ones a mind reader! People are trying to help you here but all I'm hearing is a child like It doesn't work fix it, with no willingness to even explain what it is or provide resources to test if someone found the time to investigate your issues. Given this I don't see how you can expect these so called issues to ever get fixed. I think you are misunderstanding the point at hand. I'm not trying to address specific issues. (I'd be happy to in another thread next week). This thread was created to address the overall well-documented list of bugs in 6.3, which is the *only* supported stable version of the operating system. (7.0 is even less stable) The most stable (by numbers of bugs and numbers of reported problems) is 6.2. I see no valid reasoning that can be backed up by numbers as to why 6.2 should be EoL. That's the point I'm addressing. The specific bugs that affect us are not necessarily relevant to the overall stability. And anyone can do the same searches on the bug list to confirm these numbers for themselves. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 4:34 AM, Adrian Chadd wrote: If its of major concern for you, then allocate some man hours, grab the /usr/src/sys diffs between RELENG_6_2_0_RELEASE and RELENG_6_3_0_RELEASE. The others on the list have stated over and over again that they haven't seen any issues and would like to know precisely what they are. While I appreciate their concern for the specifics, I think those should be addressed in another thread. This thread was meant to question the overall stability issues that pretty much anyone can view for themselves in the freebsd-questions/hardware/scsi mailing lists and queries in the open bug reports. If stability is your main concern then you could throw some resources at fixing 6.3 or throw some resources at backporting security fixes to 6.2. I will apparently be backporting the security fixes myself until 6.4 ships. I'm sure noone has an agenda to squish the FreeBSD version you're using for any reason other than there aren't enough people volunteering / being paid to work on back-porting security fixes. This is perhaps the real topic that needs to be addressed. Can we get some more details on the issues involved here? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
(Top posted because I didn't want to snip what you said) Bruce, all of what you said below is well known. I understand and don't have any problem with this. You seem to be trying to address something I wasn't asking about -- certifications, etc and such. Not a concern. The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? On Jun 5, 2008, at 5:03 AM, Bruce M. Simpson wrote: It is worth remembering that FreeBSD is an open source project, and it's maintained on a best-effort basis -- it is offered for free and without any warranty. Like any other open source project, risk management and change management becomes a two-way street, because that's the trade-off struck with the open source model. The risks, as well as the benefits, have to be factored in carefully to your company's technology strategy, as I'm sure you're aware. I'm very surprised that the 6.3 train has been a big issue for you, although speaking from the development side of the fence, there are a lot of moving targets, and vendor support of the OS does play a part. It is difficult to offer any more specific advice without knowing in more detail exactly what's causing such problems for you, although I see you've offered general pointers, the folk directly involved need to be pointed at direct information. The FreeBSD Project just doesn't have the resources to do compatibility testing on the scale of e.g. Windows Hardware Quality Labs, as I'm sure you are also aware. I take on board what you say about your organisation holding back on an upgrade because there are PRs filed for the hardware you use, and having worked in an investment banking environment, I understand this level of conservatism is warranted. However, I point out again: it's the open source model, and where hardware compatibility is concerned, it really is a case of suck it and see. Always has been, no different anywhere else. Open source requires user participation. Microsoft run the WHQL because their status as a going concern depends on it. I'm pleased to hear about your offer of hardware resources for developers. However, this is only part of the problem. To my mind, you need to find the right people, with the right skills, to deal with the issues, and quite often, those guys are already in demand, and thus their time can attract a high value. Open source succeeds because money is not the only motivation. The alternative is DIY, and that is the point. If you need firm guarantees about support, consider contracting with someone to do that. Many companies using FreeBSD already outsource this kind of support requirement to 3rd parties. There are also FreeBSD hardware vendors who support FreeBSD as a platform. If you want someone to take responsibility, make 'em an offer. thanks, BMS -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 5:51 AM, Jeremy Chadwick wrote: If the exact regression between 6.2 and 6.3 can be tracked down, great. If it's in a specific driver, CVS commit logs or cvsweb will come in handy. Otherwise, if it's some larger piece of code (ohai i revamped the intrupt handlar!), chances of finding it are slimmer. I'm a bit disappointed that Jo hasn't explicitly mentioned what's broken in 6.3 that's affecting him, because that might help everyone. Heck, I'll even add it to my Commonly reported issue wiki page. PRs would be good, but I'll gladly take past mailing list discussions. I will start a new thread with the specific issues that concern my environment upon my return. I'd like to keep the specific issues separate from the overall policy question, because they are very different in my mind. Jo's opinion is reasonable, but the bottom line is that the FreeBSD Project folks will always win the argument once the it's best-effort trump card is played; the convo has to end once it's on the table. Yes, but it often gets played too often too fast. It's worth having a discussion of the policy goals. I'm not saying that this isn't the very best that FreeBSD can do -- maybe it is. I just couldn't find any documentation of why dropping 6.2 makes a lot of sense, so I was hoping to get a clear answer for that. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 6:09 AM, Dag-Erling Smørgrav wrote: If you have issues with 6.3, your time would be better spent reporting them (by which I mean describe them in detail) than waving your hands in the air and yelling at people. Must you resort to nonsense and hyperbole? I'd said nearly a dozen times that the issues I have aren't specifics. I am questioning the overall policy for EoL here. Even if it was known to work properly on my hardware the overwhelming amount of bugs in 6.3 indicates an unstable release. The diffs between 6.3 and 6-STABLE are greater than the diffs between 6.2 and 6.3 last time I checked. I can't understand the logic in having only a single supported version of the OS, especially one which so many known/reported/fixed-post- release bugs. And please don't respond if you can't avoid resorting to hyperbole like what I quoted above. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Hi, John. Thanks for your update and I'll keep your experience in mind. As stated in previous messages, I'll open new threads in the appropriate lists about any specific driver issues (with details) that I am concerned about. This thread was intended to deal with the overall policy issue for dropping 6.2 in just barely more than a year.. On Jun 5, 2008, at 7:23 AM, John Baldwin wrote: On Wednesday 04 June 2008 01:20:56 pm Jo Rhett wrote: Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 to 6.3. But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. It totally understand obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for known deadlocks and kernel panics that were errata candidates for 6.2 that never made it into RELENG_6_2 but all of them are in 6.3). We also have many machines with bge(4) and from our perspective 6.3 has less issues with bge0 devices than 6.2. Given the real world experience I have, your claims of instability w/ o even testing 6.3 border on silly. Also, when it comes to bge(4), you need to be _very_ specific about what chipsets you are using and comparing those with the chipsets in the bug reports you read. The bge(4) driver in particular covers a vast range of different hardware variations and is a bit of a hodge-podge itself. If there is a problem with a 5705 card then it may be specific to just 5705 parts and not affect 575x, etc. parts. Again, with 3ware, there are two different drivers (twe(4) vs twa(4)) and again, you need to be more specific with which driver you are using and which model controllers you have. -- John Baldwin -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
please stop being nasty to people.
On Jun 5, 2008, at 8:01 AM, Kris Kennaway wrote: Uh yeah, this has been in place for *years*. Have you actually read the support announcements? They are public ;) ... Yes, and this is the FreeBSD definition of long term support. Don't like it? Do something about it. Kris, is this kind of repeated nastiness necessary? Most everyone who has posted on this thread cares deeply about FreeBSD and does what they can to support it. What do you hope to gain by being nasty to them? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 8:39 AM, Kris Kennaway wrote: There has been nothing of value offered in this thread, and it's only served to piss off a number of developers who already put huge amounts of volunteer time into supporting FreeBSD, and who take pride in the quality of their work. I'm honestly sorry to hear that. I tried very hard with the very limited time I had available to me to phrase it clearly as a policy/ support issue and not to put the blame on any developer. There are number of issues in projects I support that are waiting on time from me too, so I can hardly point any fingers in that direction. We *all* have less time to work on this stuff than we might want. Asking the volunteers to a) fix unspecified problems that the submitter will not name in detail but which are OMG SHOWSTOPPER YOU MUST FIX In rereading my quotes I may have not been clear on something. The vast majority of these bugs have already been fixed. (not in a state that needs help identifying was what I said trying to cover both that and known bugs without a fix yet) However, the fixes are not available in a -RELEASE version of the operating system. This is why EoLing 6.2 and forcing people to upgrade to a release with lots of known issues is a problem. Obviously you have to choose between developer time/effort to create a release candidate and the effort required to backdate security patches to 6.2. I don't know the reasons (which is why I created this thread) but my guess was the latter was easier than the former... b) donate even more unpaid time to supporting branches because it seems like a good compromise (!) shows a complete failure of understanding and frankly beggars belief. Although the insults aren't helpful, I agree with you. I created this thread because I have a failure of understanding. I'd appreciate some enlightenment of the real costs involved (and how we could help if possible). That's why I created this thread. Such people are not acting as supporters of the project, however well-intentioned they may believe themselves to be. You seem quite willing to make enemies. I'm not your enemy, and we'd both probably get a lot more work done if you stopped treating me like one. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 8:39 AM, Adrian Chadd wrote: The OP stated argh argh sky is falling with 6.3! but hasn't yet listed PRs which indicate this to be happening. He's offered hardware in a week or two - which is great! - but what irks the developers is the large amount of noise and absolutely no useful information. Anyone can say its broken!.. Adrian, your other comments are smart and valid. Why is this kind of hyperbole necessary? I never said anything tragic or emergency or anything like that. I questioned the practicality of having a single supported release with significant known bugs in it. It will take pretty much all the time I spend supporting FreeBSD os and applications away to focus entirely on backporting security patches back to 6.2. I know of several other organizations facing the same problem. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 8:39 AM, Adrian Chadd wrote: So yes, the way to contribute is to get involved. If you think there's a real desire to take FreeBSD-6.2 (as an example) and continue supporting security patches and critical bugfixes, versus the larger-scale changes which seem to have gone on in /usr/src/sys then just get together a group, generate some patches and submit them. Splinter groups, in my experience, tend to create duplicate work loads and make things harder, not easier. They seem to be useful only when there is a deadlock in the core team, and so far FreeBSD has avoided that. I would rather focus my efforts on something that produces more effective results. This is the reasoning behind my question: why drop 6.2 and 6.1 at the same time? What is the real cost of supporting 6.2 until a new stable version ships? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 8:53 AM, Patrick M. Hausen wrote: So he should at least be able to name the relevant PRs. Or name at least one. Then nobody would complain. I'm sure somebody would complain ;-) but yeah, valid. Unfortunately I was on my 3rd day of less than 3 hours sleep and had to leave in less than 9 hours from my post, with 12 hours of work to do before then. I really honestly didn't have the time. I wanted to hold the post until I returned, but last time I did that I got dozens of accusations of sitting on it and speaking sooner, etc etc. I was hoping in my wishes-were-horses brain that someone would provide some insight into the issues that made obsoleting 6.2 a good idea, so that on my return I could determine how best to focus my efforts. But stating it's all well documented without providing evidence doesn't help. I for one was not able to find any open PRs that deal specifically with 3ware hardware and 6.3, but not 6.[0-2]. ... Agreed, but he should name the PRs he's referring to. You know, my crystal ball is at the shop for a check, and it seems like everybody else's is, too. Because focusing on the specifics never helps with policy issues. Every time I raise a policy issue and someone asks for specific bugs relevant, I answer them and the overall policy issue degrades into the merits of the specific problem, and usually into insults from people who don't understand why I don't replace X piece of hardware. The overall policy question gets lost. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 8:58 AM, Chris Marlatt wrote: I can certainly relate to a potentially standoff'ish approach that's been seen recently. It's easy to take people's criticism as completely negative regardless what is said. To be honest though - people are using FreeBSD because it's a good project to say the least. A few negative comments doesn't mean they think the whole project is trash. Excluding the fact that we're all human and have emotions / ego, you have to agree that such a hostile approach isn't really the best thing. Thank you. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 9:34 AM, Ken Smith wrote: As for re-defining extended support to mean 4 or 5 years instead of just two it's not clear us doing that (except for anomolies like 4.11) is really in your best interests. :-) 2 years would be perfectly fine in my mind. I'd love to see 2 years of support for 6.2-RELEASE. 6.2 was (and *is* AFAIK) the most stable release of FreeBSD since 4.11 and it came out the door with less than 12 months of support intended. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 10:27 AM, Doug Barton wrote: I'm pretty sure the only person that's going to matter to is you. ... This isn't the '80's, and we aren't in grade school. See above on taking no for an answer. Doug, is this really necessary? Is this kind of response going to help? Chris, please accept my apology for having created this thread as it seems to have become nothing more than an opportunity for people talk nastily to others. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 10:27 AM, Doug Barton wrote: It's quite possible what was proposed is an awful idea and if it is so be it. But it would appear as though it wasn't even considered. On the contrary. This, and lots of other ideas have been given very careful consideration and have been rejected due to lack of resources. There, feel better? Seriously folks, it's not as if we don't _want_ to be able to provide better, longer, faster, $whatever support. We're just trying to be realistic about what we can reasonably do with what we have available. Doug, would you possibly (without attacking me?) give some insight into the issues here? This is what I was asking: what prevents supporting 6.2 ? Where could I best apply some of my time to improve the situation? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 10:31 AM, Steven Hartland wrote: I have no sympathy for anyone who's going to moan about a previous release being desupported that isn't willing to put the effort in to make the issues they are seeing get fixed. How do you know I haven't? Point of fact, I have. This thread was not about the specific bug fixes not yet available in a -RELEASE. This thread was to question the reasoning behind obsoleting 6.2 so very quickly. It's a policy issue, not a single bug report. It has more to do with the X results column in a PR search than any single one of the entries. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 10:38 AM, Doug Barton wrote: When you do come back, your first message should contain a list of PRs that you're concerned about, and confirmation (per jhb's message) that you have the _exact_ hardware that is referred to in them. If you can't provide that, don't bother. That's a very separate issue. I was asking about the policy reasoning. Fixing all of the bugs affecting my environment won't help me until they are -RELEASE, which is going to a take a lot of resources. A lot more than supporting 6.2, right? If not, please educate me. And please stop being nasty. I'd said much the same thing over the last 5 days, but I haven't once uttered a word about you not reading what has already been said repeatedly. Nor does that topic interest me. I am curious about the policy issue involved here. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Mark, I'm confused by this message. You direct your message to me, but quote Kris and Chris and then using those comments attack me. I think you may have my own comments confused. Finally, I haven't asked for anything you are attacking me for here. You are apparently restating what you think I said into things and attacking me for those ... or something. I'm entirely confused by this message, sorry :-( On Jun 5, 2008, at 11:18 AM, Mark Linimon wrote: On Thu, Jun 05, 2008 at 05:39:36PM +0200, Kris Kennaway wrote: You seem awful hostile - do you really think that's the best way to represent the project you're involved with? When confronted with what you are doing is wrong, but I am not going to tell you what it is because if you cared you'd already know (my summary of your past postings in this thread)? Possibly not 'best' but 'understandable'. The option provided seems like a fairly good compromise to both interests. Pick 6.3 (or anything the release team wishes) to support for a longer period of time. If you want FreeBSD to be supported the same as a commercial product, and you be able to dictate the terms, then it's not going to happen completely via volunteer effort. At some point some money is going to have to change hands. Either you pay someone at your company to do support, or you hire someone external. Then you get to dictate what is supported and for how long. Otherwise, all you can do is to suggest. A consensus statement signed off on by one person is the former -- not the latter. Now to add my own frustration to the list ... I next note that _after_ you said you had no more time to continue with this thread for now (and thus could not yet give us pointers to specific failures and any corresponding PR numbers), you are still replying to email. Since you still seem to have some time, let me help you do a little research here. Checking the PRs that you have submitted that are still current, none of the src-related ones are from anything newer than 6.0R: http://www.freebsd.org/cgi/query-pr-summary.cgi?originator=Jo+Rhett There are some resources to help you find already-submitted PRs to reference if it will help. (The latter 2 are new, and are attempts by the bugbusting team to flag 'well-known problem' and 'PR indicates regression'): http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html Now I'll admit the following is a less-obvious query of the database, but it's my attempt to show regressions that we have already flagged in 6.3: http://www.freebsd.org/cgi/query-pr-summary.cgi?release=%5EFreeBSD+6.3category=kerntext=regression So these 4 links should give you some quick ways to generate some PR numbers for us. Finally, here are some statistics about PR count: relall kern ------ 6.0210 91 6.1217 81 6.2396 102 6.3167 56 7.0563 140 To me, this doesn't look like an overwhelming case for 6.3 being worse off than 6.2. Yes, I'm sure there are regressions: there are in any release. mcl -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
console access
On Jun 5, 2008, at 11:35 AM, Paul Schmehl wrote: It's not quite that simple. To do that, I have to block out time to drive 45 miles during my supposed off hours and do the upgrade there. Because, if it breaks networking and I'm at home, the server will be down for at least an hour until I can drive to the hosting company, get access to the server and restore the old kernel. Paul, you should arrange with your colocation provider to get an out of band serial connection to the system, and configure the console to go to the serial port. We provide that for free at $EMPLOYER and most other places I know of do it for free or nominal charge. Obviously an operation like ours has lights-out access to everything, but we have a dozen or so freebsd developers as customers, and they routinely rebuild their machines entirely without ever visiting the facility. GNN in particular lives in Japan these days so a colo visit would take him a day or two... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 3:02 PM, Peter Jeremy wrote: I agree that he has made those statements - and those statements may even be true. When asked to provide details of the bugs or references to those problems, he has refused. Random, unsubstantiated claims are hardly evidence of anything. I didn't refuse, I said it wasn't relevant. I also offered to provide the list and hardware and time resources for testing if any developer needed it after June 11 (ie when it was physically possible to do so) for anyone who wanted to chase the individual issues. But the individual issues aren't the problem. No single problem would usually warrant that kind of attention. It's the overall amount of issues that concerns me. To summarise, so far the OP has made a series of unsubstantianted claims about vaguely defined problems on vaguely defined hardware. When asked for more details, he has refused. Exactly what do you expect the FreeBSD developers to do? Perhaps answer the question which was asked, instead of trying to drag the conversation down into specific bug reports? No single specific bug report is relevant to the overall topic. Fixing a single bug won't improve the situation. Anyway, I've said this a dozen times now so I won't be repeating it. You are welcome to continue ignoring it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
