Re: more -current testers
> In my environment, I have a central build and file server, and then a > series of network booted crash machines. Hey, this is interesting. I planed to buy a serial terminal or simple pc which plays terminal for quite a long time, but delayed that until I will have moved to the new appartment, where my wife won't kill me for adding "another ugly pc" :-) That original scenario would mean I would use the second terminal box as work station to monitor and operate the main box. This network scenario reverses roles: the existing comfortable box would stay work station and used to inspect bare network boxes that just feature cpu, ram, and ethernet. A cheap solution and they could be hidden in the closet. > It's possible to replace the kernel out from under a machine while still > crashing/dumping/rebooting. This can dramatically reduce the > develop/compile/install/test/crash/repeat cycle by coallescing the test > and crash bits with the other bits, since you can compile while still > testing or crashing. Thats sounds interesting. > Occasional PXE bugs can be very frustrating. Some machines I've used have > no problem loading pxeboot from a different machine than the DHCP server. > A couple of others ignore the server specification in the DHCP response > and insist on trying to tftp pxeboot from the DHCP server. Did you do a write up of your experiences? Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
I would be happy to try and revise it as well, I think that many people would find booting diskless kernels (for debugging & development purposes) quite useful as well :) At 04:08 PM 3/1/2002 -0800, you wrote: >There is a 'diskless' manual page, /usr/src/share/man/man8/diskless.8. >It is somewhat out of date and it would be nice if it had a dhcpd.conf >example. It would be great if someone did a major rewrite of it. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > >:On Fri, 1 Mar 2002, Glenn Gombert wrote: >: >:>I have spent several months figuring how to do diskless mounts for >:> test kernels, run debuggers from serial terminals and do remote kernel >:> debugging with gdb, and spent lots and lots of time doing is as well. >:> Some 'up to date' "How To's" are really needed to support this kind of >:> debugging and testing efforts, the material in the FreeBSD manual is >:> helpful to a point, but much 'key' information on such subjects is just >:> not there and has to be dug out of mailing list archives and just >:> sending e-mails to various people who have done such things in the past >:> and ask for help, taking up their time...which could be saved with some >:> up-to-date documentation :)) >: >:If you want to start writing that stuff up for inclusion in the FreeBSD >:Handbook or some related location, I'd be happy to review it for content, >:since I use what sounds like a very similar development environment. >: >:In my environment, I have a central build and file server, and then a >:series of network booted crash machines. The central server has two >:ethernet cards, one going to the "outside world" for some definition of >:outside, and the other a dedicated development network. The server runs a >:DHCP server for the development network, a TFTP server to server copies of >:pxeboot(8) for the development network, and NFS exports of a /usr/netboot >:tree where I store the diskless roots, kernels, et al for the crash boxes. >:Typically, I'll use >: >: /usr/netboot/crash1.decoverly.watson.org >: /usr/netboot/crash2.decoverly.watson.org >: >:as the roots for each environment, point tftpd(8) at /usr/netboot as its >:root, and appropriately configure the DHCP server to point each host at >:the right root directory to pull down pxeboot, and for its later NFS root. >:I also hook up serial consoles for each box; currently working on remote >:power. >: >:Depending on what I'm working on, I may use the crash boxes in different >:ways. Frequently, I'll boot them entirely from the network, with a >:complete installkernel and installworld into their roots under >:/usr/netboot. However, if I'm doing filesystem related work, I may do >:more disk-centric installation mechanisms. I haven't tried the modified >:install floppy trick. >: >:Some cute tricks.. >: >:newfs is faster than fsck. If you need to use local filesystems on the >:box, and don't care about persistent data, it's a lot faster to newfs the >:file systems than do the file system check :-). If that's true for even >:one file system, it's an improvement. Sometimes I wonder if that wouldn't >:be a good change for all installs :-). >: >:Some boxes appear to have broken serial break support. There's a kernel >:option for an alternative break key that can be quite useful. I have this >:problem with two SGI boxes I'm using for various TrustedBSD-related >:things. >: >:I can configure the hard disks as dump devices, and by swapping back and >:forth between kernels, I can pull the dump over to the development server. >:It may be you can dump over the network, but perhaps not :-). >: >:It's possible to replace the kernel out from under a machine while still >:crashing/dumping/rebooting. This can dramatically reduce the >:develop/compile/install/test/crash/repeat cycle by coallescing the test >:and crash bits with the other bits, since you can compile while still >:testing or crashing. >: >:If you have multiple machines, you can easily allocate them to various >:projects, etc, etc. I have a couple of scripts that help populate a >:system the first time, by chrooting and running cap_mkdb, pwd_mkdb, etc, >:etc. I generally also tweak the rc.diskless[12] scripts a bit based on >:what I need. I also tend to enable remote root login and empty passwords >:for the crash box in sshd_config so that I can login into the machines >:once they come up very easily. >: >:Occasional PXE bugs can be very frustrating. Some machines I've used have >:no problem loading pxeboot from a different machine than the DHCP server. >:A couple of others ignore the server specification in the DHCP response >:and insist on trying to tftp pxeboot from the DHCP server. >: >:Robert N M Watson FreeBSD Core Team, TrustedBSD Project >:[EMAIL PROTECTED] NAI Labs, Safeport Network Services > >To Unsubscribe: send mail to [EMAIL PRO
Re: more -current testers
I would be happy to help with this, I will revise a section at a time in Developers Handbook on "Kernel Debugging" and then post it for review. I hope it helps others (and can save some precious time of other busy folks as well), I will try and have a section done by the end of next week :) At 06:58 PM 3/1/2002 -0500, Robert Watson wrote: >On Fri, 1 Mar 2002, Glenn Gombert wrote: > >>I have spent several months figuring how to do diskless mounts for >> test kernels, run debuggers from serial terminals and do remote kernel >> debugging with gdb, and spent lots and lots of time doing is as well. >> Some 'up to date' "How To's" are really needed to support this kind of >> debugging and testing efforts, the material in the FreeBSD manual is >> helpful to a point, but much 'key' information on such subjects is just >> not there and has to be dug out of mailing list archives and just >> sending e-mails to various people who have done such things in the past >> and ask for help, taking up their time...which could be saved with some >> up-to-date documentation :)) > >If you want to start writing that stuff up for inclusion in the FreeBSD >Handbook or some related location, I'd be happy to review it for content, >since I use what sounds like a very similar development environment. > >In my environment, I have a central build and file server, and then a >series of network booted crash machines. The central server has two >ethernet cards, one going to the "outside world" for some definition of >outside, and the other a dedicated development network. The server runs a >DHCP server for the development network, a TFTP server to server copies of >pxeboot(8) for the development network, and NFS exports of a /usr/netboot >tree where I store the diskless roots, kernels, et al for the crash boxes. >Typically, I'll use > > /usr/netboot/crash1.decoverly.watson.org > /usr/netboot/crash2.decoverly.watson.org > >as the roots for each environment, point tftpd(8) at /usr/netboot as its >root, and appropriately configure the DHCP server to point each host at >the right root directory to pull down pxeboot, and for its later NFS root. >I also hook up serial consoles for each box; currently working on remote >power. > >Depending on what I'm working on, I may use the crash boxes in different >ways. Frequently, I'll boot them entirely from the network, with a >complete installkernel and installworld into their roots under >/usr/netboot. However, if I'm doing filesystem related work, I may do >more disk-centric installation mechanisms. I haven't tried the modified >install floppy trick. > >Some cute tricks.. > >newfs is faster than fsck. If you need to use local filesystems on the >box, and don't care about persistent data, it's a lot faster to newfs the >file systems than do the file system check :-). If that's true for even >one file system, it's an improvement. Sometimes I wonder if that wouldn't >be a good change for all installs :-). > >Some boxes appear to have broken serial break support. There's a kernel >option for an alternative break key that can be quite useful. I have this >problem with two SGI boxes I'm using for various TrustedBSD-related >things. > >I can configure the hard disks as dump devices, and by swapping back and >forth between kernels, I can pull the dump over to the development server. >It may be you can dump over the network, but perhaps not :-). > >It's possible to replace the kernel out from under a machine while still >crashing/dumping/rebooting. This can dramatically reduce the >develop/compile/install/test/crash/repeat cycle by coallescing the test >and crash bits with the other bits, since you can compile while still >testing or crashing. > >If you have multiple machines, you can easily allocate them to various >projects, etc, etc. I have a couple of scripts that help populate a >system the first time, by chrooting and running cap_mkdb, pwd_mkdb, etc, >etc. I generally also tweak the rc.diskless[12] scripts a bit based on >what I need. I also tend to enable remote root login and empty passwords >for the crash box in sshd_config so that I can login into the machines >once they come up very easily. > >Occasional PXE bugs can be very frustrating. Some machines I've used have >no problem loading pxeboot from a different machine than the DHCP server. >A couple of others ignore the server specification in the DHCP response >and insist on trying to tftp pxeboot from the DHCP server. > >Robert N M Watson FreeBSD Core Team, TrustedBSD Project >[EMAIL PROTECTED] NAI Labs, Safeport Network Services > > > Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
There is a 'diskless' manual page, /usr/src/share/man/man8/diskless.8. It is somewhat out of date and it would be nice if it had a dhcpd.conf example. It would be great if someone did a major rewrite of it. -Matt Matthew Dillon <[EMAIL PROTECTED]> :On Fri, 1 Mar 2002, Glenn Gombert wrote: : :>I have spent several months figuring how to do diskless mounts for :> test kernels, run debuggers from serial terminals and do remote kernel :> debugging with gdb, and spent lots and lots of time doing is as well. :> Some 'up to date' "How To's" are really needed to support this kind of :> debugging and testing efforts, the material in the FreeBSD manual is :> helpful to a point, but much 'key' information on such subjects is just :> not there and has to be dug out of mailing list archives and just :> sending e-mails to various people who have done such things in the past :> and ask for help, taking up their time...which could be saved with some :> up-to-date documentation :)) : :If you want to start writing that stuff up for inclusion in the FreeBSD :Handbook or some related location, I'd be happy to review it for content, :since I use what sounds like a very similar development environment. : :In my environment, I have a central build and file server, and then a :series of network booted crash machines. The central server has two :ethernet cards, one going to the "outside world" for some definition of :outside, and the other a dedicated development network. The server runs a :DHCP server for the development network, a TFTP server to server copies of :pxeboot(8) for the development network, and NFS exports of a /usr/netboot :tree where I store the diskless roots, kernels, et al for the crash boxes. :Typically, I'll use : : /usr/netboot/crash1.decoverly.watson.org : /usr/netboot/crash2.decoverly.watson.org : :as the roots for each environment, point tftpd(8) at /usr/netboot as its :root, and appropriately configure the DHCP server to point each host at :the right root directory to pull down pxeboot, and for its later NFS root. :I also hook up serial consoles for each box; currently working on remote :power. : :Depending on what I'm working on, I may use the crash boxes in different :ways. Frequently, I'll boot them entirely from the network, with a :complete installkernel and installworld into their roots under :/usr/netboot. However, if I'm doing filesystem related work, I may do :more disk-centric installation mechanisms. I haven't tried the modified :install floppy trick. : :Some cute tricks.. : :newfs is faster than fsck. If you need to use local filesystems on the :box, and don't care about persistent data, it's a lot faster to newfs the :file systems than do the file system check :-). If that's true for even :one file system, it's an improvement. Sometimes I wonder if that wouldn't :be a good change for all installs :-). : :Some boxes appear to have broken serial break support. There's a kernel :option for an alternative break key that can be quite useful. I have this :problem with two SGI boxes I'm using for various TrustedBSD-related :things. : :I can configure the hard disks as dump devices, and by swapping back and :forth between kernels, I can pull the dump over to the development server. :It may be you can dump over the network, but perhaps not :-). : :It's possible to replace the kernel out from under a machine while still :crashing/dumping/rebooting. This can dramatically reduce the :develop/compile/install/test/crash/repeat cycle by coallescing the test :and crash bits with the other bits, since you can compile while still :testing or crashing. : :If you have multiple machines, you can easily allocate them to various :projects, etc, etc. I have a couple of scripts that help populate a :system the first time, by chrooting and running cap_mkdb, pwd_mkdb, etc, :etc. I generally also tweak the rc.diskless[12] scripts a bit based on :what I need. I also tend to enable remote root login and empty passwords :for the crash box in sshd_config so that I can login into the machines :once they come up very easily. : :Occasional PXE bugs can be very frustrating. Some machines I've used have :no problem loading pxeboot from a different machine than the DHCP server. :A couple of others ignore the server specification in the DHCP response :and insist on trying to tftp pxeboot from the DHCP server. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :[EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
On Fri, 1 Mar 2002, Glenn Gombert wrote: >I have spent several months figuring how to do diskless mounts for test > kernels, run debuggers from serial terminals and do remote kernel debugging > with gdb, and spent lots and lots of time doing is as well. Some 'up to > date' "How To's" are really needed to support this kind of debugging and > testing efforts, the material in the FreeBSD manual is helpful to a point, > but much 'key' information on such subjects is just not there and has to be > dug out of mailing list archives and just sending e-mails to various people > who have done such things in the past and ask for help, taking up their > time...which could be saved with some up-to-date documentation :)) So you are the PERFECT person to write it right? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
On Fri, 1 Mar 2002, Glenn Gombert wrote: >I have spent several months figuring how to do diskless mounts for > test kernels, run debuggers from serial terminals and do remote kernel > debugging with gdb, and spent lots and lots of time doing is as well. > Some 'up to date' "How To's" are really needed to support this kind of > debugging and testing efforts, the material in the FreeBSD manual is > helpful to a point, but much 'key' information on such subjects is just > not there and has to be dug out of mailing list archives and just > sending e-mails to various people who have done such things in the past > and ask for help, taking up their time...which could be saved with some > up-to-date documentation :)) If you want to start writing that stuff up for inclusion in the FreeBSD Handbook or some related location, I'd be happy to review it for content, since I use what sounds like a very similar development environment. In my environment, I have a central build and file server, and then a series of network booted crash machines. The central server has two ethernet cards, one going to the "outside world" for some definition of outside, and the other a dedicated development network. The server runs a DHCP server for the development network, a TFTP server to server copies of pxeboot(8) for the development network, and NFS exports of a /usr/netboot tree where I store the diskless roots, kernels, et al for the crash boxes. Typically, I'll use /usr/netboot/crash1.decoverly.watson.org /usr/netboot/crash2.decoverly.watson.org as the roots for each environment, point tftpd(8) at /usr/netboot as its root, and appropriately configure the DHCP server to point each host at the right root directory to pull down pxeboot, and for its later NFS root. I also hook up serial consoles for each box; currently working on remote power. Depending on what I'm working on, I may use the crash boxes in different ways. Frequently, I'll boot them entirely from the network, with a complete installkernel and installworld into their roots under /usr/netboot. However, if I'm doing filesystem related work, I may do more disk-centric installation mechanisms. I haven't tried the modified install floppy trick. Some cute tricks.. newfs is faster than fsck. If you need to use local filesystems on the box, and don't care about persistent data, it's a lot faster to newfs the file systems than do the file system check :-). If that's true for even one file system, it's an improvement. Sometimes I wonder if that wouldn't be a good change for all installs :-). Some boxes appear to have broken serial break support. There's a kernel option for an alternative break key that can be quite useful. I have this problem with two SGI boxes I'm using for various TrustedBSD-related things. I can configure the hard disks as dump devices, and by swapping back and forth between kernels, I can pull the dump over to the development server. It may be you can dump over the network, but perhaps not :-). It's possible to replace the kernel out from under a machine while still crashing/dumping/rebooting. This can dramatically reduce the develop/compile/install/test/crash/repeat cycle by coallescing the test and crash bits with the other bits, since you can compile while still testing or crashing. If you have multiple machines, you can easily allocate them to various projects, etc, etc. I have a couple of scripts that help populate a system the first time, by chrooting and running cap_mkdb, pwd_mkdb, etc, etc. I generally also tweak the rc.diskless[12] scripts a bit based on what I need. I also tend to enable remote root login and empty passwords for the crash box in sshd_config so that I can login into the machines once they come up very easily. Occasional PXE bugs can be very frustrating. Some machines I've used have no problem loading pxeboot from a different machine than the DHCP server. A couple of others ignore the server specification in the DHCP response and insist on trying to tftp pxeboot from the DHCP server. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
I have spent several months figuring how to do diskless mounts for test kernels, run debuggers from serial terminals and do remote kernel debugging with gdb, and spent lots and lots of time doing is as well. Some 'up to date' "How To's" are really needed to support this kind of debugging and testing efforts, the material in the FreeBSD manual is helpful to a point, but much 'key' information on such subjects is just not there and has to be dug out of mailing list archives and just sending e-mails to various people who have done such things in the past and ask for help, taking up their time...which could be saved with some up-to-date documentation :)) GG At 10:34 PM 3/1/2002 +0100, Cliff Sarginson wrote: >On Wed, Feb 20, 2002 at 10:56:05AM +0200, Maxim Sobolev wrote: >> Michael Lucas wrote: >> > >> > I understand that we're getting to that stage where we need more >> > -current testers. >> > >> > We all agree that the optimal thing would be to have hordes of very >> > sophisticated users who can debug problems on their own and submit >> > patches to fix all their issues. I would guess that we all also agree >> > that that's not going to happen. >> > >> > It seems that the best we can hope for is to educate some of the >> > braver users who are ready to take the next step and are willing to >> > donate some time to us. >> > >> > I'm considering doing a series of articles on testing FreeBSD-current, >> > including: setting up for kernel dumps, what to type at the debugger >> > prompt after a crash, filing a decent bug report, what to expect from >> > -current, and so on. I would also make it clear when to not bother >> > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, >> > enable WITNESS & try again."). This would be (I suspect) three >> > articles, running about a month and a half. >> > >> > The last time I checked, I get 12-15 thousand readers for each >> > article. One half of one percent uptake would (hopefully) be quite a >> > few bug reports. >> >Has some kind of conclusion been arrived at on this ? >It has gone quiet since Feb 20th, I am definitely interested. > >-- >Regards > Cliff Sarginson -- <[EMAIL PROTECTED]> > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
On Wed, Feb 20, 2002 at 10:56:05AM +0200, Maxim Sobolev wrote: > Michael Lucas wrote: > > > > I understand that we're getting to that stage where we need more > > -current testers. > > > > We all agree that the optimal thing would be to have hordes of very > > sophisticated users who can debug problems on their own and submit > > patches to fix all their issues. I would guess that we all also agree > > that that's not going to happen. > > > > It seems that the best we can hope for is to educate some of the > > braver users who are ready to take the next step and are willing to > > donate some time to us. > > > > I'm considering doing a series of articles on testing FreeBSD-current, > > including: setting up for kernel dumps, what to type at the debugger > > prompt after a crash, filing a decent bug report, what to expect from > > -current, and so on. I would also make it clear when to not bother > > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > > enable WITNESS & try again."). This would be (I suspect) three > > articles, running about a month and a half. > > > > The last time I checked, I get 12-15 thousand readers for each > > article. One half of one percent uptake would (hopefully) be quite a > > few bug reports. > Has some kind of conclusion been arrived at on this ? It has gone quiet since Feb 20th, I am definitely interested. -- Regards Cliff Sarginson -- <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers - are they WANTED yet?
At 9:00 PM -0500 2/21/02, Garance A Drosihn wrote: >At 1:08 PM -0500 2/19/02, Michael Lucas wrote: >>In an ideal world, you're correct. >> >>The real question here should have been: do those people who >>are actively committing rapidly to the tree want to see this >>happen? They are the people who will realistically have to >>deal with the PRs. > >I assume we'd still like 5.0 to "go -stable" in about 8-10 months, >so at which point to we start encouraging more people to jump >into it? It occurs to me that the "yet" that I added to this subject is a little misleading. Michael wasn't talking about articles which would appear this weekend... From Michael's original message: The last time I checked, I get 12-15 thousand readers for each article. One half of one percent uptake would (hopefully) be quite a few bug reports. My question to the community is: is it too early to do this? If I start now, the articles would probably appear April-May. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers - are they WANTED yet?
At 1:08 PM -0500 2/19/02, Michael Lucas wrote: >In an ideal world, you're correct. > >The real question here should have been: do those people who >are actively committing rapidly to the tree want to see this >happen? They are the people who will realistically have to >deal with the PRs. This is the main question of course, and I can't say that I've seen any of the really active developers comment on it. I do think it is important to get more people on -current, so I'm trying to do more with -current myself. So, for instance, I've already come across two small errors in -current which should certainly be fixed before 5.0 "goes -stable". However, looking at the bigger issues being discussed in -current right now, I expect it would be annoying if I bugged anyone about little cosmetic issues. I think if Michael writes up anything, it will certainly encourage more people to use current, including people who might very well start commenting on the little nit-picking items. Do the developers of current want that yet, or will they find it irritating to have people pointing out minor issues when they (the developers) are still trying to sort out some of the more major issues? Current is fine for me (at the moment at least, and if we ignore the topic of vmware...), and I do hope to write a few patches to fix the cosmetic things I do come across. But are the developers ready for maybe a hundred more people playing around with current, and reporting on all kinds of things? I assume we'd still like 5.0 to "go -stable" in about 8-10 months, so at which point to we start encouraging more people to jump into it? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
Michael Lucas wrote: > > I understand that we're getting to that stage where we need more > -current testers. > > We all agree that the optimal thing would be to have hordes of very > sophisticated users who can debug problems on their own and submit > patches to fix all their issues. I would guess that we all also agree > that that's not going to happen. > > It seems that the best we can hope for is to educate some of the > braver users who are ready to take the next step and are willing to > donate some time to us. > > I'm considering doing a series of articles on testing FreeBSD-current, > including: setting up for kernel dumps, what to type at the debugger > prompt after a crash, filing a decent bug report, what to expect from > -current, and so on. I would also make it clear when to not bother > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > enable WITNESS & try again."). This would be (I suspect) three > articles, running about a month and a half. > > The last time I checked, I get 12-15 thousand readers for each > article. One half of one percent uptake would (hopefully) be quite a > few bug reports. Excellent idea IMO. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
Hello, These proposed articles can only help. I've been following this list for a few years, I'm ready to contribute in my own small way :-) tom [EMAIL PROTECTED] Michael Lucas wrote: > I understand that we're getting to that stage where we need more > -current testers. > > We all agree that the optimal thing would be to have hordes of very > sophisticated users who can debug problems on their own and submit > patches to fix all their issues. I would guess that we all also agree > that that's not going to happen. > > It seems that the best we can hope for is to educate some of the > braver users who are ready to take the next step and are willing to > donate some time to us. > > I'm considering doing a series of articles on testing FreeBSD-current, > including: setting up for kernel dumps, what to type at the debugger > prompt after a crash, filing a decent bug report, what to expect from > -current, and so on. I would also make it clear when to not bother > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > enable WITNESS & try again."). This would be (I suspect) three > articles, running about a month and a half. > > The last time I checked, I get 12-15 thousand readers for each > article. One half of one percent uptake would (hopefully) be quite a > few bug reports. > > My question to the community is: is it too early to do this? If I > start now, the articles would probably appear April-May. > > Thanks, > Michael > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
Hi, i'm a freelance sys/net admin/architect who works with bsd (free/open) in France (Paris/Bordeaux). i'm reading your columns very regularly. Your writing are easy to understand and that's a good point ! I'm (for now) just following mailing lists (security, hackers, stable, current) and i want to help. I'm making progress slowly but surely. Soon i will be quite mature with bsd, and i will be able to report bugs, and later debug (at this time i'm playing with cvs and making worlds). if you write some docs, i will read them, and i will have time to report some bugs if you tell me how to do it right. I'm sticking with stable now (compiling once a day), but it's been times since i wanted to help the -current project; but i wouldn't have been efficient so i didn't do it. from my point of view, it is NOT too early. Go ahead !!! I think i'll be ready when your doc are finished. I understand that's it is only my point of view (and i can be considered as zero helper / poor joe user), but hey, it's one more potential tester :-) Even if i can't support what you (developpers) do the way you would like, i really appreciate the work you do on FreeBSD, and i try to show it by using and installing FreeBSD. Thanks ! Olivier (saturday i will buy a serial cable to start playing with ;-) ) On Tue, Feb 19, 2002 at 12:50:11PM -0500, Michael Lucas wrote: > I understand that we're getting to that stage where we need more > -current testers. > > We all agree that the optimal thing would be to have hordes of very > sophisticated users who can debug problems on their own and submit > patches to fix all their issues. I would guess that we all also agree > that that's not going to happen. > > It seems that the best we can hope for is to educate some of the > braver users who are ready to take the next step and are willing to > donate some time to us. > > I'm considering doing a series of articles on testing FreeBSD-current, > including: setting up for kernel dumps, what to type at the debugger > prompt after a crash, filing a decent bug report, what to expect from > -current, and so on. I would also make it clear when to not bother > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > enable WITNESS & try again."). This would be (I suspect) three > articles, running about a month and a half. > > The last time I checked, I get 12-15 thousand readers for each > article. One half of one percent uptake would (hopefully) be quite a > few bug reports. > > My question to the community is: is it too early to do this? If I > start now, the articles would probably appear April-May. > > Thanks, > Michael > > -- > Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] > my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons > > http://www.blackhelicopters.org/~mwlucas/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Olivier Cortes GPG 1024/46CE0A51 : 8DB6 A56C 00CA DA0F F77F 86EB E86A 803C 46CE 0A51 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: more -current testers
I run FreeBSD both at home and at work and I'd be happy to provide feedback on any bugs I come across. Your article on debugging and submitting a "proper" bug report would be helpful in making sure that any info I submit is useful. And I'm sure that there's a thousand others reading this and thinking the same thing. Keep up the good work. :) On Tue, Feb 19, 2002 at 12:50:11PM -0500, Michael Lucas wrote: > I understand that we're getting to that stage where we need more > -current testers. > > We all agree that the optimal thing would be to have hordes of very > sophisticated users who can debug problems on their own and submit > patches to fix all their issues. I would guess that we all also agree > that that's not going to happen. > > It seems that the best we can hope for is to educate some of the > braver users who are ready to take the next step and are willing to > donate some time to us. > > I'm considering doing a series of articles on testing FreeBSD-current, > including: setting up for kernel dumps, what to type at the debugger > prompt after a crash, filing a decent bug report, what to expect from > -current, and so on. I would also make it clear when to not bother > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > enable WITNESS & try again."). This would be (I suspect) three > articles, running about a month and a half. > > The last time I checked, I get 12-15 thousand readers for each > article. One half of one percent uptake would (hopefully) be quite a > few bug reports. > > My question to the community is: is it too early to do this? If I > start now, the articles would probably appear April-May. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
On Tue, Feb 19, 2002 at 12:50:11PM -0500, Michael Lucas wrote: > I understand that we're getting to that stage where we need more > -current testers. > > We all agree that the optimal thing would be to have hordes of very > sophisticated users who can debug problems on their own and submit > patches to fix all their issues. I would guess that we all also agree > that that's not going to happen. > > It seems that the best we can hope for is to educate some of the > braver users who are ready to take the next step and are willing to > donate some time to us. > > I'm considering doing a series of articles on testing FreeBSD-current, > including: setting up for kernel dumps, what to type at the debugger > prompt after a crash, filing a decent bug report, what to expect from > -current, and so on. I would also make it clear when to not bother > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > enable WITNESS & try again."). This would be (I suspect) three > articles, running about a month and a half. > > The last time I checked, I get 12-15 thousand readers for each > article. One half of one percent uptake would (hopefully) be quite a > few bug reports. > > My question to the community is: is it too early to do this? If I > start now, the articles would probably appear April-May. I think this is an absolutely splendid idea :) I have enough resources to run a STABLE system for my day-to-day use and also have a -CURRENT system I am more than willing to spend some time on. I think some good pointers on what is required to provide useful feedback (as opposed to bug reports that are not adequately filled in) and some practical tips would really encourage people. My first question is who or what is WITNESS :) -- Regards Cliff Sarginson -- <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
As someone who's just starting down this path as well, I'd say the sooner the better. Later, George To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
In an ideal world, you're correct. The real question here should have been: do those people who are actively committing rapidly to the tree want to see this happen? They are the people who will realistically have to deal with the PRs. On Tue, Feb 19, 2002 at 07:01:42PM +0100, Miguel Mendez wrote: > On Tue, Feb 19, 2002 at 12:50:11PM -0500, Michael Lucas wrote: > > Hi Michael, > > > It seems that the best we can hope for is to educate some of the > > braver users who are ready to take the next step and are willing to > > donate some time to us. > > Agreed. I think there are people out there willing to help and become > testers, they're just afraid of -CURRENT 'horror histories'. Running > -current is not a walk in the park, and no one should attempt to do any > serious work with it, but imho it's stable enough for your average mp3 > listening, web browsing and kde/gnome/whathaveyou usage. > > > > I'm considering doing a series of articles on testing FreeBSD-current, > > including: setting up for kernel dumps, what to type at the debugger > > prompt after a crash, filing a decent bug report, what to expect from > > -current, and so on. I would also make it clear when to not bother > > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > > enable WITNESS & try again."). This would be (I suspect) three > > articles, running about a month and a half. > > Sounds very good, and yes, most people disable witness so their system > doesn't crawl like a 286 :) > > > My question to the community is: is it too early to do this? If I > > start now, the articles would probably appear April-May. > > I don't think it's too early, IMHO it's a very good idea, having > specific info on how to use -CURRENT will be beneficial for the > community and atract more users to it. > > Cheers, > > -- > Miguel Mendez - [EMAIL PROTECTED] > GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt > EnergyHQ :: http://www.energyhq.tk > FreeBSD - The power to serve! -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
On Tue, Feb 19, 2002 at 12:50:11PM -0500, Michael Lucas wrote: > > It seems that the best we can hope for is to educate some of the > braver users who are ready to take the next step and are willing to > donate some time to us. > Very good idea. I probably qualify as a good representation of the type of users you are targetting. > I'm considering doing a series of articles on testing FreeBSD-current, > including: setting up for kernel dumps, what to type at the debugger > prompt after a crash, filing a decent bug report, what to expect from > -current, and so on. I would also make it clear when to not bother > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > enable WITNESS & try again."). This would be (I suspect) three > articles, running about a month and a half. > That sounds good. I'm more of a no-BS-get-down-to-business kinda guy though. I like quick instructions and explanations of why. I should be able to figure out most of the stuff through whatever comes out of this thread though. And there's always the handbooks... > My question to the community is: is it too early to do this? If I > start now, the articles would probably appear April-May. I'm not going to pretend I'm an authority on this, but I think it'd be a good time to start now. All I am more or less comfortable with is typing 'trace' and looking at stuff I don't know anything about :) Give people some time to experiment with how the tools work and why they do what they do. After they've had to use them for a little while and the feedback isn't complete garbage to them anymore, the bug reports will be much better and more concise (I'd hope so at least). That would give then -CURRENT branch a boost at a time when I would guess it'll really need it. Basically, people who are new to -CURRENT like me need some time and advice to get comfortable with the tools. Then we'll be of much more help than stumbling around blindly. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers
On Tue, Feb 19, 2002 at 12:50:11PM -0500, Michael Lucas wrote: Hi Michael, > It seems that the best we can hope for is to educate some of the > braver users who are ready to take the next step and are willing to > donate some time to us. Agreed. I think there are people out there willing to help and become testers, they're just afraid of -CURRENT 'horror histories'. Running -current is not a walk in the park, and no one should attempt to do any serious work with it, but imho it's stable enough for your average mp3 listening, web browsing and kde/gnome/whathaveyou usage. > I'm considering doing a series of articles on testing FreeBSD-current, > including: setting up for kernel dumps, what to type at the debugger > prompt after a crash, filing a decent bug report, what to expect from > -current, and so on. I would also make it clear when to not bother > filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, > enable WITNESS & try again."). This would be (I suspect) three > articles, running about a month and a half. Sounds very good, and yes, most people disable witness so their system doesn't crawl like a 286 :) > My question to the community is: is it too early to do this? If I > start now, the articles would probably appear April-May. I don't think it's too early, IMHO it's a very good idea, having specific info on how to use -CURRENT will be beneficial for the community and atract more users to it. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg34919/pgp0.pgp Description: PGP signature
more -current testers
I understand that we're getting to that stage where we need more -current testers. We all agree that the optimal thing would be to have hordes of very sophisticated users who can debug problems on their own and submit patches to fix all their issues. I would guess that we all also agree that that's not going to happen. It seems that the best we can hope for is to educate some of the braver users who are ready to take the next step and are willing to donate some time to us. I'm considering doing a series of articles on testing FreeBSD-current, including: setting up for kernel dumps, what to type at the debugger prompt after a crash, filing a decent bug report, what to expect from -current, and so on. I would also make it clear when to not bother filing a bug report (i.e., "You crashed, but had no WITNESS? Sorry, enable WITNESS & try again."). This would be (I suspect) three articles, running about a month and a half. The last time I checked, I get 12-15 thousand readers for each article. One half of one percent uptake would (hopefully) be quite a few bug reports. My question to the community is: is it too early to do this? If I start now, the articles would probably appear April-May. Thanks, Michael -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
