Re: Upcoming Releases Schedule...
Andrew Snow wrote: Another thing that I believe would help: Voting on PRs. Currently a maintainer has no idea if a PR is due to one guy's flakey hardware or if 50 people have had the same problem and are waiting for a fix. For each major problem report, there are probably many people who tried FreeBSD on particular hardware and just silently gave up when it failed. You might even find that people don't even know what a PR is or how to report it. Maybe a dialog during the install telling people about the PR system might be helpful. Ability to vote up on a PR on the freebsd website would give maintainers a tool to see which PRs are affecting the userbase. Andrew - Andrew ___ 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: floppy disk controller broken
On Wed, Sep 17, 2008 at 05:13:39PM -0400, John Baldwin wrote: On Wednesday 17 September 2008 11:04:33 am Michel Talon wrote: Hello, when testing FreeBSD-7.1-BETA i discovered that the floppy disk controller doesn't work correctly. Trying to format a floppy (perhaps with bad blocks) i get: Processing fdformat: ioctl(FD_FORM): Device not configured instead of the normal E letter. I then checked the same problem is present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in 2006! Of course the floppy disk driver is particularly messy, but this is not pretty. (*) i386/103862: Error with fdformat It looks like the ioctl to format a track used to never report failures from the controller. The newer driver does. What I've done with fdformat is to make it just ignore the errors in userland instead. Try this: Index: fdformat.c === --- fdformat.c(revision 183112) +++ fdformat.c(working copy) @@ -75,8 +75,7 @@ f.fd_formb_secno(i) = il[i+1]; f.fd_formb_secsize(i) = secsize; } - if(ioctl(fd, FD_FORM, (caddr_t)f) 0) - err(EX_OSERR, ioctl(FD_FORM)); + (void)ioctl(fd, FD_FORM, (caddr_t)f); } static int -- John Baldwin This doesn't work any more. This time i get niobe# fdformat fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing done. where only the first E takes some time to be printed, and all subsequent ones are printed instantaneously, that is all other formatting is not tried. In principle the formatting process must try each of the sectors in turn, and can come up with a series of V and F. Moreover, trying to write to the floppy: niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror dd: /dev/fd0: Input/output error 5+0 records in 4+0 records out 2048 bytes transferred in 4.054404 secs (505 bytes/sec) I don't expect such result. Traditionnally writing works, while reading may fail. Here reading fails with incoherent messages: dd: /dev/fd0: Device not configured 3+0 records in 3+0 records out 1536 bytes transferred in 2.595216 secs (592 bytes/sec) repeated a large number of times. But nothing in dmesg, contrary to the tradition which showed the defective sectors. In conclusion i am under the impression that the in kernel driver is severely botched. Of course nobody uses floppies any more, but this is quite ugly. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3 reboot -d doesn't work
Jeremy Chadwick wrote: On Wed, Sep 17, 2008 at 01:03:46PM -0400, Ed Maste wrote: On Wed, Sep 17, 2008 at 09:25:37AM -0700, Jeremy Chadwick wrote: On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote: I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 [...] reboot -d ... dumping 255M 2 chunks Then nothing - the system doesn't reboot and I have to hard reset it. When it comes back up there is no crash file in /var/crash [...] It's a known problem. If when the machine reboots, you forcefully enter single-user, you should be able to get the kernel dump using savecore. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 Your PR doesn't look like Stephen's problem to me, since according to his description the system hangs when trying to do the dump so there won't be anything on the disk for savecore to save. You're right, thanks Ed. His when it comes back up there is no crash file is what threw me for a loop. Stephen, does the problem *only* happen when using the -d flag, or does the system lock up on reboot in general? If the latter, try using one or both of the following sysctls: hw.acpi.handle_reboot=1 hw.acpi.disable_on_reboot=1 If the lesser, I've no idea. The problem only happens when I do the reboot -d. If I do reboot it comes back ok. I have tried it on two different platforms 1) a Biostar TForce 6100 mainboard with an AMD dual core processor 2) a Soekris net5501 with the same results. I get the dumping message and then it hangs and I have to hard reset the box. Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ 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...
Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. 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) You seem to be *demanding* quite a lot lately. Wilko ___ 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, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote: Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. 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) You seem to be *demanding* quite a lot lately. Jo has a point, though. I'm certain he's looked at the situation from the developers' point of view, and in response, I'd recommend others try to look at it from his, even if others consider it silly or unreasonable. It's a frustrating situation, and there's no snap-your-fingers-voila solution for it, other than extending support lifetimes per release. Mark's graphs show release lifetimes are getting shorter, which I doubt Jo would have a problem with, assuming each new release was somehow guaranteed (more or less, cut me some slack) to not break previous releases' binaries and so on. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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...
Quoting Jeremy Chadwick, who wrote on Thu, Sep 18, 2008 at 06:18:40AM -0700 .. On Thu, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote: Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. 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) You seem to be *demanding* quite a lot lately. Jo has a point, though. I'm certain he's looked at the situation from the developers' point of view, and in response, I'd recommend others try to look at it from his, even if others consider it silly or unreasonable. It's a frustrating situation, and there's no snap-your-fingers-voila solution for it, other than extending support lifetimes per release. Indeed, there is no easy solution. Extending support lifetime takes more resources of course. Wilko ___ 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...
Maybe I'm missing something here, but it seems like Jo just wants to argue for the sake of arguing. First Jo wrote: 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. To which Robert Watson replied, giving the minimums asked for: Well, a starting answer is the policy found on http://security.FreeBSD.org/: 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. And yet Jo completely ignored that, and focused in on something completely unrelated: 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) Jo: You know the minimum support period for each release, before it is released. You know what the earliest EoL time will be for each release as it is released. What more do you want? -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_7: something is very wrong with UDP?
It seems to be something is very wrong with UDP on latest RELENG_7 Well some symptoms I have seen today when I was trying to boot newly compiled RELENG_7 on my laptop: a) rc scripts indefinitely waiting on logger to be completed during the boot ( devd and ifconfig are good examples) b) Sporadic DNS request failures c) traceroute prints 0.00 like response time for every host d) was unable to reboot my laptop performing shutdown -r ( due to logger/syslog related issues I think) e ) I was unable to start X session ( it seems to be freezes laptop because I was unable to switch to another virtual console even) csup backout to date=2008.09.15.12.00.00 and recompiling the kernel fixes this issue for me. Is anybody experiencing the same issues with fresh RELENG_7? Unsure it is my local issues though ___ 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, Sep 18, 2008 at 12:25 AM, Jo Rhett [EMAIL PROTECTED] wrote: 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) My opinion on this matter may be considered radical, but I do think it should be at least recorded, if not impartially considered. While this 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 promise is made by a lot of people, and it doesn't always work out that way; particularly in environments with ingrained and blind politics where the money flows can change based on pride and/or sheer ignorance), it may be advantageous to treat the root causes. One of the biggest (and most prominent, though not obviously so) issues is the lack of concurrency with regards to releases. With the default system, having multiple freebsd releases side by side (both different versions, and different architectures) is infeasible. This makes the choice more critical, while hindering flexibility. The necessity of long support schedules is one of the symptoms. The fact that you have to choose, and then to change the choice you must clean up, back up, and create a new environment in order to test on a different release/architecture (release in this context includes kernel, a chroot is incomplete for testing), has two major effects: it hinders users from being able to selectively test newer releases with their software stack/hardware selection, with no adverse (within reason; obviously bugs like disk corruption will still happen) changes that will prevent them from reverting. While it may not please the accountants, cleaning up the namespace and allowing safe concurrency of releases will increase the /legitmate/ feasibility of using FreeBSD on a large scale. Oh, I forgot to mention, this is far from a pipe dream. I have a working environment with this capability, and I use it whenever I am able. This isn't to say it is the only cause, it is one of many, and I would never even claim it was a magic bullet. But it is my opinion that this 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. There's my two cents on the matter. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy disk controller broken
Michel Talon wrote: John Baldwin wrote: It looks like the ioctl to format a track used to never report failures from the controller. The newer driver does. What I've done with fdformat is to make it just ignore the errors in userland instead. Try this: Index: fdformat.c === --- fdformat.c(revision 183112) +++ fdformat.c(working copy) @@ -75,8 +75,7 @@ f.fd_formb_secno(i) = il[i+1]; f.fd_formb_secsize(i) = secsize; } - if(ioctl(fd, FD_FORM, (caddr_t)f) 0) - err(EX_OSERR, ioctl(FD_FORM)); + (void)ioctl(fd, FD_FORM, (caddr_t)f); } static int This doesn't work any more. This time i get niobe# fdformat fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing done. where only the first E takes some time to be printed, and all subsequent ones are printed instantaneously, that is all other formatting is not tried. In principle the formatting process must try each of the sectors in turn, and can come up with a series of V and F. Moreover, trying to write to the floppy: niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror dd: /dev/fd0: Input/output error 5+0 records in 4+0 records out 2048 bytes transferred in 4.054404 secs (505 bytes/sec) I don't expect such result. Traditionnally writing works, while reading may fail. Maybe I misunderstand what you're saying, but ... When I try to write to a floppy that has *not* been successfully formatted, I very much expect to get Input/output error. Anything else would be a bug. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The most important decision in [programming] language design concerns what is to be left out. -- Niklaus Wirth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy disk controller broken
On Thu, Sep 18, 2008 at 06:18:45PM +0200, Oliver Fromme wrote: Michel Talon wrote: John Baldwin wrote: It looks like the ioctl to format a track used to never report failures from the controller. The newer driver does. What I've done with fdformat is to make it just ignore the errors in userland instead. Try this: Index: fdformat.c === --- fdformat.c(revision 183112) +++ fdformat.c(working copy) @@ -75,8 +75,7 @@ f.fd_formb_secno(i) = il[i+1]; f.fd_formb_secsize(i) = secsize; } - if(ioctl(fd, FD_FORM, (caddr_t)f) 0) - err(EX_OSERR, ioctl(FD_FORM)); + (void)ioctl(fd, FD_FORM, (caddr_t)f); } static int This doesn't work any more. This time i get niobe# fdformat fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing done. where only the first E takes some time to be printed, and all subsequent ones are printed instantaneously, that is all other formatting is not tried. In principle the formatting process must try each of the sectors in turn, and can come up with a series of V and F. Moreover, trying to write to the floppy: niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror dd: /dev/fd0: Input/output error 5+0 records in 4+0 records out 2048 bytes transferred in 4.054404 secs (505 bytes/sec) I don't expect such result. Traditionnally writing works, while reading may fail. Maybe I misunderstand what you're saying, but ... When I try to write to a floppy that has *not* been successfully formatted, I very much expect to get Input/output error. Anything else would be a bug. Best regards Oliver The floppy has certainly be formatted, in the past. Perhaps i remember badly, i have not used floppies since years, but in this case the behavior with Windows, Linux and ancient FreeBSD was that you could write to the floppy, but could encounter errors while reading. Using dd conv=noerror allowed to recover the valid part. Under Windows you could very well use floppies partly damaged with bad blocks or tracks. Here the driver seems to bail out at the first error, so that the above commands run much faster than they should, a few seconds, while something of the order of a minute should be more realistic. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy disk controller broken
On Thu, Sep 18, 2008 at 08:32:50PM +0200, Michel Talon wrote: On Thu, Sep 18, 2008 at 06:18:45PM +0200, Oliver Fromme wrote: Michel Talon wrote: John Baldwin wrote: It looks like the ioctl to format a track used to never report failures from the controller. The newer driver does. What I've done with fdformat is to make it just ignore the errors in userland instead. Try this: Index: fdformat.c === --- fdformat.c(revision 183112) +++ fdformat.c(working copy) @@ -75,8 +75,7 @@ f.fd_formb_secno(i) = il[i+1]; f.fd_formb_secsize(i) = secsize; } - if(ioctl(fd, FD_FORM, (caddr_t)f) 0) - err(EX_OSERR, ioctl(FD_FORM)); + (void)ioctl(fd, FD_FORM, (caddr_t)f); } static int This doesn't work any more. This time i get niobe# fdformat fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing done. where only the first E takes some time to be printed, and all subsequent ones are printed instantaneously, that is all other formatting is not tried. In principle the formatting process must try each of the sectors in turn, and can come up with a series of V and F. Moreover, trying to write to the floppy: niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror dd: /dev/fd0: Input/output error 5+0 records in 4+0 records out 2048 bytes transferred in 4.054404 secs (505 bytes/sec) I don't expect such result. Traditionnally writing works, while reading may fail. Maybe I misunderstand what you're saying, but ... When I try to write to a floppy that has *not* been successfully formatted, I very much expect to get Input/output error. Anything else would be a bug. Best regards Oliver The floppy has certainly be formatted, in the past. Perhaps i remember badly, i have not used floppies since years, but in this case the behavior with Windows, Linux and ancient FreeBSD was that you could write to the floppy, but could encounter errors while reading. Using dd conv=noerror allowed to recover the valid part. Under Windows you could very well use floppies partly damaged with bad blocks or tracks. Here the driver seems to bail out at the first error, so that the above commands run much faster than they should, a few seconds, while something of the order of a minute should be more realistic. I swore in older FreeBSD (2.x days?) there was a command which was actually used for dealing with bad sectors on floppy disks. I might be thinking of badsect(8), can't remember... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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 Wed, 17 Sep 2008, Jo Rhett wrote: Please stop avoiding even considering what people are offering to you. 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. 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 immediately fall into the official project umbrella, but consider Colin Percival's freebsd-update as an example of what can be accomplished by someone outside the project when they find a niche. What started out as an external software project (freebsd-update) is now a core system update tool, and Colin has gone from being a random guy with some code to our security officer. (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. (3) Become a contributor to the community by working with an existing or new company that provides support for FreeBSD commercially, and discussing with them ways that they could provide support for branches past their 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 support subscription to fund community-centered support for branches. And those companies may be able to help you identify developers who can do the work, as well as play an active role in seeking further customers with similar interests. Robert N M Watson Computer Laboratory University of Cambridge ___ 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: RELENG_7: something is very wrong with UDP?
On Thu, 18 Sep 2008, Oleg V. Nauman wrote: It seems to be something is very wrong with UDP on latest RELENG_7 Well some symptoms I have seen today when I was trying to boot newly compiled RELENG_7 on my laptop: a) rc scripts indefinitely waiting on logger to be completed during the boot ( devd and ifconfig are good examples) If you hit ctrl-t while these are waiting, what is the output? b) Sporadic DNS request failures I don't know what your comfortable level with debugging tools is, but if you're happy using tcpdump, etc, I think I'd recommend diagnosing this directly that way. I'd probably do something like this: (1) Start by deleting all but one nameserver entry in /etc/resolv.conf. Confirm that you can still reproduce the problem. (2) Use dig(1) and tcpdump(1) to watch wire-level DNS behavior -- do you see queries go out? Do you see replies come back? Is dig waking up and seeing the replies when they arrive, or is there a delay or hang in dig? If dig hangs, what does ctrl-t show the sleep state (wmesg) is? Could you also use procstat -k on the dig process to generate a kernel stack trace for it? c) traceroute prints 0.00 like response time for every host d) was unable to reboot my laptop performing shutdown -r ( due to logger/syslog related issues I think) Could you try killing syslogd by hand and see if it dies? If not, can you use procstat -kk to generate a stack trace for it? e ) I was unable to start X session ( it seems to be freezes laptop because I was unable to switch to another virtual console even) csup backout to date=2008.09.15.12.00.00 and recompiling the kernel fixes this issue for me. This is approximately the date of my last UDP MFC. Could you try backing out just src/sys/netinet6/udp6_usrreq.c revision 1.81.2.7 and see if that helps? (specifically, restore the use of sosend_generic instead of sosend_dgram) Could you confirm that either you're not using any kernel modules from ports, or that if you are, you have recompiled them with your most recent update? Could you try compiling your kernel with WITNESS to see if we get any extended debugging information? Is anybody experiencing the same issues with fresh RELENG_7? Unsure it is my local issues though I'm not experiencing them, but these sorts of things can be quite subtle and workload-dependent. Robert N M Watson Computer Laboratory University of Cambridge ___ 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: RELENG_7: something is very wrong with UDP?
On Thu, Sep 18, 2008 at 06:05:43PM +0300, Oleg V. Nauman wrote: c) traceroute prints 0.00 like response time for every host Interesting, since traceroute bases the RTT on the amount of time it takes between the initial packet sent (see below) and the time it receives the ICMP port unreachable response. Yes, I am fully aware traceroute uses UDP as the default protocol to induce said ICMP. That said, does the erroneous behaviour go away when using -P tcp? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: 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. No, we're just waiting for you to go ahead and do it. 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? 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. 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. 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. Robert N M Watson Computer Laboratory University of Cambridge ___ 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...
At 03:11 PM 9/18/2008, Jo Rhett wrote: committing that time. (besides the obvious giving back to the community part which we do anyway) 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 ? ---Mike ___ 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...
At 03:39 PM 9/18/2008, Jo Rhett wrote: 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 ? 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. 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 ? ---Mike ___ 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 9:23 PM, Jo Rhett wrote: On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: 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. Are you seriously insisting that a minor release should be supported for more than a year? I think that's pretty exceptional already for any piece of software, and yet you want to extend that? I don't know what your line of work demands, but maybe you're not as constrained as you think you are? The support lifetime of FreeBSD 6 (the major release) is estimated to be up to somewhere in 2010, according to the release information, which seems to satisfy your needs. To me this is a rhetorical question only, I have no way to apply any answers I get to these questions. I'm not involved in the FreeBSD project or in your line of work, I'm just a humble user and supporter. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:74,48d2afa510139919116692! ___ 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...
Jo Rhett [EMAIL PROTECTED] writes: 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. 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.] ___ 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...
At 04:13 PM 9/18/2008, Jo Rhett wrote: 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 had a search and I see some PRs you have submitted, but I guess you commit under a different @freebsd.org email address ? 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. 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? 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 resources to offer, yet you seem to have alienated a LOT of people from previously similar threads (http://freebsd.monkey.org/freebsd-stable/200806/msg00037.html) You advocate that people not reject your offers of help and resources, yet at the same time respond to developers who actually do a LOT of work and were going to look at what you have to offer by way of bug reports that you are way too busy to oblige http://freebsd.monkey.org/freebsd-stable/200806/msg00069.html Perhaps if you posted some references to success stories you have had with the FreeBSD developer community at large, this would help make your case. ---Mike ___ 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, Lowell Gilbert wrote: Jo Rhett [EMAIL PROTECTED] writes: 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. 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.] What Jo needs to do is what we expect from other participants in the project who want to take on positions of responsibility: build a long-term track record of contributions so that we can trust that when they agree to take on obligations (and we advertise those claims, be it by changing branch lifetimes, accepting WIP feature contributions, etc), they will be fulfilled. Developers offer to mentor new contributors and help shepherd their work when they see that the contributor both has a clear technical contribution to offer *and* that they build necessary rapport and confidence that the investment of time by the mentor is worthwhile. Everyone on this list is a busy person and values their time, and mentoring a developer is a highly non-trivial investment of time, and in most cases, it's a donation of personal time. It is potentially very rewarding, but a lot of work. Robert N M Watson Computer Laboratory University of Cambridge ___ 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, Sep 18, 2008 at 05:03:05PM -0400, Mike Tancsa wrote: At 04:13 PM 9/18/2008, Jo Rhett wrote: 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 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 think Jo has a freebsd.org account or mail address. Netconsonance is more or less Jo's own personal/contracting thing, as I understand it, while one of his employers is SVColo (who you WILL see mentioned in commit messages). 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 resources to offer, yet you seem to have alienated a LOT of people from previously similar threads (http://freebsd.monkey.org/freebsd-stable/200806/msg00037.html) You advocate that people not reject your offers of help and resources, yet at the same time respond to developers who actually do a LOT of work and were going to look at what you have to offer by way of bug reports that you are way too busy to oblige http://freebsd.monkey.org/freebsd-stable/200806/msg00069.html I'm sorry to see that this thread has reached the point where Jo's character has come into question. This path is too commonly taken within this community (read: BSD); the equivalent of doing burn-outs in a parking lot (lots of smoke, zero gain). If Jo's character is truly under scrutiny, be aware that I will stand up for him, as I've interacted with him professionally (read: at my day job, for network outages or other anomalies -- and no, my day job is unrelated to my signature). What surprises me is, sans Robert, everyone seems to be taking what Jo says as a form of flaming, borderline trolling. But in all my years (including on IRC, which should give you some insight to what my definition of troll is), I don't know of anyone who would spend this amount of effort and time discussing an issue at length if they did not have professional and/or personal interest in it. If Jo was just stirring up the ants, this topic wouldn't keep coming up. Likewise, SVColo would not have donated money to meetBSD if they didn't care; and for SVColo to care, that means there's a professional reliance on something (in this case, FreeBSD). Jo is often that representative. I do not deny the mails are heated, and express both frustration and concern, but I don't see anything insulting in them. Possibly this topic could be discussed amongst interested parties at meetBSD. I will be there, and would be more than happy to participate in such a discussion -- or at least take notes. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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...
On Thu, Sep 18, 2008 at 12:23:45PM -0700, Jo Rhett wrote:
On Sep 18, 2008, at 12:01 PM, Robert Watson wrote:
(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.
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]
Re: Upcoming Releases Schedule...
Quoting Jo Rhett, who wrote on Thu, Sep 18, 2008 at 11:58:00AM -0700 .. 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. I do not need a dictionary thank you very much. Wilko ___ 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: floppy disk controller broken
You could try formatting the floppy in a USB drive. Someone was going to pick this up, finish it off, and commit it, but I haven't heard back from them: http://people.freebsd.org/~bms/dump/tools/ufdformat/ ___ 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...
At 05:46 PM 9/18/2008, Jo Rhett wrote: I'd rather just drop this tangent. Me too. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
