RE: Upgrading 5.3 6.0 buildworld failure now in libmagic
-Original Message- From: Michael C. Shultz [mailto:[EMAIL PROTECTED] Sent: Friday, December 09, 2005 10:32 AM To: vizion Cc: 'Peter Jeremy'; 'Doug Barton' Subject: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic On Friday 09 December 2005 09:39, vizion wrote: Vison, you are much better at writting florid prose on how and why FreeBSD is such an awful OS run by a team of Techies who care nothing about end users needs than you are at reading and comprehending simple instructions. What you write is almost believable, your writing skill is very good and convincing, only in this particualr case I know you are completely wrong and your failure to follow the simplest advice is why your machine is now non operational. Quit crying about non relevent issues and concentrate on solving your real problem - getting that darn machine to boot up. One last thought, name one OS that has better documentation than FreeBSD please, comercial or otherwise. Maybe there is such a beast, if so I am very curious to know what it is called. Mike Rather than replying to the list I am emailing you direct and cc onl;y the individuals to whom you cc'd your original. Frankly I never ceased to be amazed at diversionary personalized attacks that seem to be a regular occurrence on freebsd lists whenever someone makes friendly but critical observations about freebsd. There is a touchyness there which is a big deterrent to the engagement of others and a tendency to paternalize which, on rare occasions, is an unspeakably ugly aspect of some freebsd interactions. I do not know the root cause of such over-defensiveness I am constantly amazed when old timers do not recognize it. It is time to grow up and I hope something will happen to discourage people from arguing ad personam. Your remarks seem to have been written with the deliberate intention of attacking the messenger rather than discussing the message. You did not even aspire to achieving accuracy. The fact the my system did upgrade successfully from 5.3 to 5.4 by following your advice does not give you the right to make false assumptions about a failed upgrade from 5.4 to 6.0 that is due to a combination of events that have nothing whatsoever to do with the topic under discussion, advice that has been given or even freebsd or its documentation. It turns out that a motherboard hardware failure was the casue of the upgrade failure.. hence I have to do a total rebuild because the motherboard is no longer available. And this is your excuse for attacking the FreeBSD organization? No and I have nott attacked the organization. The c ritic of the way in which documentation is not integrated ionto the freebsd development cycle was made long before there was any motherboard failure. I do wish you would stick to the facts. I'm sure everyone feels bad for you that you have to get a new motherboard. I am confused as to how better coordination between developers and technical writers could have prevented it from failing though. I have not made that suggestion - only you have put forward that notion -- come on laugh a bit - you are really being a bit wild and cranky over this chuckles. The motherboard failure occurred after the discussion on documentation not before GRINZ you really are missing the point here. As for the use of perjorative terminology (florid prose) and false accusations - I am really personally very disappointed in your reactions. What you seemed to be saying was that you were unable to counter my suggestions which were so unwelcome to you that you chose to attack me personally. Your suggestions were irrelevent to the problem at hand. My suggestions are very relevant to the documentary errors, omissions and lack of documentary integration that waste much of the time of many end users. My suggestions were, it is true, were off the original topic and came about as a response to someone else who complained about freebsd documentation and I responded to him. He was strongly critical because the documentation stated that direct upgrade from 5.3 to 6.00 was possible when, as you pointed out, it was not. I suggest you reread the whole thread with care and look at the sequence of events instead of massaging a false interpretation events to satisfy a desire to argue add personam.. tecnical help that is one thing, if you want to improve documentaion that is another topic with it's own mail list. I see this as more diversionary BS you could have said: Hey david -- sorry I should not have jumped to conclusions I am disappointed that you react that way to me and even more concerned that those who have been around far less years than I will be intimidated by this kind of BS Please grow up david One last point, either remove me from the reply to list or place the maillist
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Friday 09 December 2005 11:31, vizion wrote: -Original Message- From: Michael C. Shultz [mailto:[EMAIL PROTECTED] Sent: Friday, December 09, 2005 10:32 AM To: vizion Cc: 'Peter Jeremy'; 'Doug Barton' Subject: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic On Friday 09 December 2005 09:39, vizion wrote: Vison, you are much better at writting florid prose on how and why FreeBSD is such an awful OS run by a team of Techies who care nothing about end users needs than you are at reading and comprehending simple instructions. What you write is almost believable, your writing skill is very good and convincing, only in this particualr case I know you are completely wrong and your failure to follow the simplest advice is why your machine is now non operational. Quit crying about non relevent issues and concentrate on solving your real problem - getting that darn machine to boot up. One last thought, name one OS that has better documentation than FreeBSD please, comercial or otherwise. Maybe there is such a beast, if so I am very curious to know what it is called. Mike Rather than replying to the list I am emailing you direct and cc onl;y the individuals to whom you cc'd your original. Frankly I never ceased to be amazed at diversionary personalized attacks that seem to be a regular occurrence on freebsd lists whenever someone makes friendly but critical observations about freebsd. There is a touchyness there which is a big deterrent to the engagement of others and a tendency to paternalize which, on rare occasions, is an unspeakably ugly aspect of some freebsd interactions. I do not know the root cause of such over-defensiveness I am constantly amazed when old timers do not recognize it. It is time to grow up and I hope something will happen to discourage people from arguing ad personam. Your remarks seem to have been written with the deliberate intention of attacking the messenger rather than discussing the message. You did not even aspire to achieving accuracy. The fact the my system did upgrade successfully from 5.3 to 5.4 by following your advice does not give you the right to make false assumptions about a failed upgrade from 5.4 to 6.0 that is due to a combination of events that have nothing whatsoever to do with the topic under discussion, advice that has been given or even freebsd or its documentation. It turns out that a motherboard hardware failure was the casue of the upgrade failure.. hence I have to do a total rebuild because the motherboard is no longer available. And this is your excuse for attacking the FreeBSD organization? No and I have nott attacked the organization. The c ritic of the way in which documentation is not integrated ionto the freebsd development cycle was made long before there was any motherboard failure. I do wish you would stick to the facts. I'm sure everyone feels bad for you that you have to get a new motherboard. I am confused as to how better coordination between developers and technical writers could have prevented it from failing though. I have not made that suggestion - only you have put forward that notion -- come on laugh a bit - you are really being a bit wild and cranky over this chuckles. The motherboard failure occurred after the discussion on documentation not before GRINZ you really are missing the point here. As for the use of perjorative terminology (florid prose) and false accusations - I am really personally very disappointed in your reactions. What you seemed to be saying was that you were unable to counter my suggestions which were so unwelcome to you that you chose to attack me personally. Your suggestions were irrelevent to the problem at hand. My suggestions are very relevant to the documentary errors, omissions and lack of documentary integration that waste much of the time of many end users. My suggestions were, it is true, were off the original topic and came about as a response to someone else who complained about freebsd documentation and I responded to him. He was strongly critical because the documentation stated that direct upgrade from 5.3 to 6.00 was possible when, as you pointed out, it was not. I never said this, must have been someone else. I suggest you reread the whole thread with care and look at the sequence of events instead of massaging a false interpretation events to satisfy a desire to argue add personam.. tecnical help that is one thing, if you want to improve documentaion that is another topic with it's own mail list. I see this as more diversionary BS you could have said: Hey david -- sorry I should not have jumped to conclusions I am disappointed that you react that way
RE: Upgrading 5.3 6.0 buildworld failure now in libmagic
snip One last point, either remove me from the reply to list or place the maillist back on it, thank you. I think you owe me an apology - but I doubt I will get it. Your correct, you won't. I think you mean you are ? It is a writer's credibility that is at stake if they choose to argue ad personam, or make patently incorrect and illogical statements and then do not apologize afterwards. Your loss - not mine Take care david ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: Well having run many very large scale projects myself I find it difficult to accept either implication of this perspective. There's a massive difference between running a large commercial project and running a large open source project using volunteers. On a commercial project, you can direct someone to do something and they have a choice of either doing it or finding another job. On a volunteer project, there's a limit to how far you can push someone to do something they don't enjoy before they just leave. The first implication is that we should be complacent about it and not seek to find a method to improve the process. I don't think anyone is suggesting this. In my experience, the FreeBSD project is always open to process improvements - this is especially obvious in the documentation and release engineering areas. Most of our really top notch developers are actually very bad at documenting their work (I don't mean bad at being timely with it, I mean that they are bad at DOING it), and frankly their time is better spent elsewhere. That is a judgment call - franky my experience has been that developers who are bad at ensuring their work is well documentated are second rate rather than top rate developers. Software developers are notoriously poor at writing documentation for non-technical people. There are probably very few developers who enjoy writing end-user documentation (and can write). In my experience, especially on large projects, it's rare for developers to write the end-user documentation. They may write a rough outline but it's the technical writers who actually do the documentation. The problem is finding people with technical writing skills who are interested in helping with FreeBSD. It's also worth noting that a number of FreeBSD developers are not native English speakers. It's probably unreasonable to expect them to write polished English documentation. What I have found works in development is to create team relationships that cover design, development and documentation. I agree that this is a good approach. It's similar to the 'surgical team' approach that Brooks recommends in The Mythical Man-Month. I think that this does happen to some extent in FreeBSD but agree it could be more widespread. (Though it is probably harder to put it into practice in a distributed, volunteer project than when the team share a cubicle). My view would be that the freebsd project might do well to consider implementing a no release without quality documentation assurance policy. ... development is so good. It deserves better and more professional attention to the role of end user documentation. Are you volunteering? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Thu, Dec 08, 2005 at 08:34:42PM +1100 I heard the voice of Peter Jeremy, and lo! it spake thus: On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: development is so good. It deserves better and more professional attention to the role of end user documentation. Are you volunteering? It should be noted that this sort of response often comes across rather sneering and snarky, but (most of the time, anyway) it's really not meant to. It often DOES translate pretty directly to Yes, that would be nice, and it would be really great if somebody who was interested and capable were to grab the reins and do it. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
From: Peter Jeremy [EMAIL PROTECTED] Date: 2005/12/08 Thu AM 01:34:42 PST To: Vizion [EMAIL PROTECTED] CC: Doug Barton [EMAIL PROTECTED], freebsd-stable@freebsd.org Subject: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: Well having run many very large scale projects myself I find it difficult to accept either implication of this perspective. There's a massive difference between running a large commercial project and running a large open source project using volunteers. Not really I have done both and found that shared values and community collaboration work the same. On a commercial project, you can direct someone to do something and they have a choice of either doing it or finding another job. Well that kind of development environment (rule by dictat) does not work very well. Developers are people who are engaged in a collaborative process. If you encourage them to think like prima donas then they will behave like prima donas rather than as part of an integrated team. On a volunteer project, there's a limit to how far you can push someone to do something they don't enjoy before they just leave. Push has it limitations everywhere.. goals and communal rewards are better in both volunteer and commercial projects. The first implication is that we should be complacent about it and not seek to find a method to improve the process. I don't think anyone is suggesting this. In my experience, the FreeBSD project is always open to process improvements - this is especially obvious in the documentation and release engineering areas. The question is about the degree of committment to process change not whwther it is absent or present. The critique is there is tooo little comitment to process change and too much resistance to greater concentration on the quality of user docuimentation and the significance of that work in the developmenmt cycle. Most of our really top notch developers are actually very bad at documenting their work (I don't mean bad at being timely with it, I mean that they are bad at DOING it), and frankly their time is better spent elsewhere. That is a judgment call - franky my experience has been that developers who are bad at ensuring their work is well documentated are second rate rather than top rate developers. Software developers are notoriously poor at writing documentation for non-technical people. There are probably very few developers who enjoy writing end-user documentation (and can write). In my experience, especially on large projects, it's rare for developers to write the end-user documentation. NOTE I said F:ranky my experience has been that developers who are bad at ENSURING their work is well documentated are second rate rather than top rate developers. The work of the technical writer needs to influence development at the design stage! It does not matter whether the developer does or does not write the the documentation but it does matter whether the developer is COMIITED to both ensuring that there is proper documentation AND that the documentation process is an integral part of the development process that influences its outcome. They may write a rough outline but it's the technical writers who actually do the documentation. The outline for user documentation needs to be structured BEFORE development begins NOT as an afterthought. In a well structured development environment documentation is part of DESIGN not post design implementation . That is because thinking about end user at the design stage is necessary if the outcome of the process is going to be user centric. The problem is finding people with technical writing skills who are interested in helping with FreeBSD. Freebsd needs to reorganize the way it develops if it is going to interest techn ical writers. No technical writer wants to be associated with writing documnets for developments that have been poorly designed for the end user. Clearing up someone else's mess is no fun. If you treat technical writers as people who come along afterwards and pick up yopur trash OF COURSE you will not get them involved. You need to ask WHY it is difficult to get them. It is because freebsd does not produce software with a focus on end user satisfaction. This is a chicken and egg problem that can only be solved by a fu8ndamental shift both the focus of development objectives and the development process. It's also worth noting that a number of FreeBSD developers are not native English speakers. It's probably unreasonable to expect them to write polished English documentation. What I have found works in development is to create team relationships that cover design, development and documentation. I agree that this is a good approach. It's similar to the 'surgical team' approach that Brooks recommends in The Mythical Man-Month. I think
Re: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
From: Matthew D. Fuller [EMAIL PROTECTED] Date: 2005/12/08 Thu AM 08:01:47 PST To: Peter Jeremy [EMAIL PROTECTED] CC: Doug Barton [EMAIL PROTECTED], freebsd-stable@freebsd.org, Vizion [EMAIL PROTECTED] Subject: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic On Thu, Dec 08, 2005 at 08:34:42PM +1100 I heard the voice of Peter Jeremy, and lo! it spake thus: On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: development is so good. It deserves better and more professional attention to the role of end user documentation. Are you volunteering? It should be noted that this sort of response often comes across rather sneering and snarky, but (most of the time, anyway) it's really not meant to. It often DOES translate pretty directly to Yes, that would be nice, and it would be really great if somebody who was interested and capable were to grab the reins and do it. Do you mean the response sounds like freebsd documentation chuckles See my last email for a response to that one ! ATM I am struggling on a win machine because my local server once more refused to upgrade to 6.0 and this time has bombed outcompletely - looks nlike a complete rebuild david -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: Upgrading 5.3 6.0 buildworld failure now in libmagic
Peter Jeremy wrote: On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: That is a judgment call - franky my experience has been that developers who are bad at ensuring their work is well documentated are second rate rather than top rate developers. Software developers are notoriously poor at writing documentation for non-technical people. There are probably very few developers who enjoy writing end-user documentation (and can write). My personal expectation is *not* that the FreeBSD developers tell me what a cdrom is. My expectation is that they tell me what works, what doesn't, and warn me about whats in the middle. Trust me, there are damn few non-technical people installing FreeBSD, and I'm pretty sure both of them gave up in sysinstall. I can read (most) code and I can search PR's. However, if it's 2 am and my server has puked on it's shoes during an upgrade due to an undocumented issue the developer knew about, I'm not going to recommend FreeBSD to anyone other than as a hobby for single men with beards. In my experience, especially on large projects, it's rare for developers to write the end-user documentation. They may write a rough outline but it's the technical writers who actually do the documentation. The problem is finding people with technical writing skills who are interested in helping with FreeBSD. It's also worth noting that a number of FreeBSD developers are not native English speakers. It's probably unreasonable to expect them to write polished English documentation. Again, I'm not asking them to write chapters in the handbook and I understand (and assumed) they may not be native English speakers. How hard is it to get a, ata.c broke with via 666 sata chipset under heavy load? If I have a via 666 sata chipset, now I know to go looking in the code. Even if don't go looking in the code, I know that I might want to look at a different adapter. Don't tell me whats little more than a subject line of a mail message is beyond even a junior non-English speaking coder and a few minutes with a translation program. Are you volunteering? Yes, I'd like to help, not that I think my writing skills are all that great. But no if the developers won't be forthcoming with details. P.S. I'm not picking on the ata code or it's owners. It was just a module name I knew off hand. jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Thursday 08 December 2005 08:57, [EMAIL PROTECTED] wrote: From: Peter Jeremy [EMAIL PROTECTED] Date: 2005/12/08 Thu AM 01:34:42 PST To: Vizion [EMAIL PROTECTED] CC: Doug Barton [EMAIL PROTECTED], freebsd-stable@freebsd.org Subject: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: Well having run many very large scale projects myself I find it difficult to accept either implication of this perspective. There's a massive difference between running a large commercial project and running a large open source project using volunteers. Not really I have done both and found that shared values and community collaboration work the same. On a commercial project, you can direct someone to do something and they have a choice of either doing it or finding another job. Well that kind of development environment (rule by dictat) does not work very well. Developers are people who are engaged in a collaborative process. If you encourage them to think like prima donas then they will behave like prima donas rather than as part of an integrated team. On a volunteer project, there's a limit to how far you can push someone to do something they don't enjoy before they just leave. Push has it limitations everywhere.. goals and communal rewards are better in both volunteer and commercial projects. The first implication is that we should be complacent about it and not seek to find a method to improve the process. I don't think anyone is suggesting this. In my experience, the FreeBSD project is always open to process improvements - this is especially obvious in the documentation and release engineering areas. The question is about the degree of committment to process change not whwther it is absent or present. The critique is there is tooo little comitment to process change and too much resistance to greater concentration on the quality of user docuimentation and the significance of that work in the developmenmt cycle. Most of our really top notch developers are actually very bad at documenting their work (I don't mean bad at being timely with it, I mean that they are bad at DOING it), and frankly their time is better spent elsewhere. That is a judgment call - franky my experience has been that developers who are bad at ensuring their work is well documentated are second rate rather than top rate developers. Software developers are notoriously poor at writing documentation for non-technical people. There are probably very few developers who enjoy writing end-user documentation (and can write). In my experience, especially on large projects, it's rare for developers to write the end-user documentation. NOTE I said F:ranky my experience has been that developers who are bad at ENSURING their work is well documentated are second rate rather than top rate developers. The work of the technical writer needs to influence development at the design stage! It does not matter whether the developer does or does not write the the documentation but it does matter whether the developer is COMIITED to both ensuring that there is proper documentation AND that the documentation process is an integral part of the development process that influences its outcome. They may write a rough outline but it's the technical writers who actually do the documentation. The outline for user documentation needs to be structured BEFORE development begins NOT as an afterthought. In a well structured development environment documentation is part of DESIGN not post design implementation . That is because thinking about end user at the design stage is necessary if the outcome of the process is going to be user centric. The problem is finding people with technical writing skills who are interested in helping with FreeBSD. Freebsd needs to reorganize the way it develops if it is going to interest techn ical writers. No technical writer wants to be associated with writing documnets for developments that have been poorly designed for the end user. Clearing up someone else's mess is no fun. If you treat technical writers as people who come along afterwards and pick up yopur trash OF COURSE you will not get them involved. You need to ask WHY it is difficult to get them. It is because freebsd does not produce software with a focus on end user satisfaction. This is a chicken and egg problem that can only be solved by a fu8ndamental shift both the focus of development objectives and the development process. It's also worth noting that a number of FreeBSD developers are not native English speakers. It's probably unreasonable to expect them to write polished English documentation. What I have found works in development is to create team relationships that cover design, development and documentation. I agree that this is a good approach. It's similar
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
secmgr wrote: Doug Barton wrote: + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. Or as another poster said, just say latest RELENG_5 prior to upgrade Based on recommendations from this thread and from kris, I changed the wording to be more generic, and added the same text to the UPGRADING file in HEAD, and RELENG_6. Well, if it's common knowledge, lets see it documented. We're only talking a few lines in the handbook or the release notes, not an entire chapter. I did my bit. I'm sure that the freebsd-doc folks are eagerly anticipating your patches, since this is such an easy thing to add. :) rant3 My frustration comes from the fact that this seems to be getting worse, not better. From your perspective that may be true, however from a more general perspective I don't agree. C'est la vie. In addition, every time I bring this up, I'm told (usually by someone with a freebsd.org address) that, oh we all know/knew about that or, it's common knowledge. I have been very careful to say that I agree that our documentation can always be improved. I've also been very careful to say that the only way this will happen is if someone steps up to do it. I realize that's not the answer you're looking for, but it's the only one we have, and all the elegantly phrased rants, descriptions of what we should be doing for you (and how we should be doing it), and other things that you (pl.) wish were so won't change that. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
Vizion wrote: Well I do not want to not thank those who have made the upgrades viable. The value of their work should not be underrated. That's a step in the right direction, thanks. :) There is however a perennial problem that freebsd documentation has always been seen as behind and seperate from the development process rather than an integral part of that process. You're right, however that is just the way it is. Most of our really top notch developers are actually very bad at documenting their work (I don't mean bad at being timely with it, I mean that they are bad at DOING it), and frankly their time is better spent elsewhere. The documentation is light years ahead of where it was 11 years ago when I started using FreeBSD for one simple reason. Interested users stepped up and helped make it better. That's the only way that things improve in an open source project. FWIW, I added a paragraph to the UPDATING file in both HEAD and RELENG_6 that describes why updating to the latest code in the installed branch is a good idea before trying a major version upgrade. Hopefully that will help the next person who stumbles over this same issue. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Wednesday 07 December 2005 13:01, the author Doug Barton contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: Vizion wrote: Well I do not want to not thank those who have made the upgrades viable. The value of their work should not be underrated. That's a step in the right direction, thanks. :) There is however a perennial problem that freebsd documentation has always been seen as behind and seperate from the development process rather than an integral part of that process. You're right, however that is just the way it is. Well having run many very large scale projects myself I find it difficult to accept either implication of this perspective. The first implication is that we should be complacent about it and not seek to find a method to improve the process. The second implication is that top notch developers do not care about end user comfort. My experience is that most do care but they needa helpful environment to achieve food documentation. Most of our really top notch developers are actually very bad at documenting their work (I don't mean bad at being timely with it, I mean that they are bad at DOING it), and frankly their time is better spent elsewhere. That is a judgment call - franky my experience has been that developers who are bad at ensuring their work is well documentated are second rate rather than top rate developers. What I have found works in development is to create team relationships that cover design, development and documentation. Unfortunately this does go against the somewhat individualistic elitist relationship that is unnecessarily sustained by the implications I referred to earlier (neither of which I buy and both of which seem to me to be condescending nonsense). My view would be that the freebsd project might do well to consider implementing a no release without quality documentation assurance policy. Such a policy forces design and development to integrate their work with whoever has been identified as responsible for user documentation (whether that is the designer, developer or a seprate documentation person or team. This encourage the preparation of user documentation as part of the project rather then an afterthought (that depends upon members of the hoi poloi. The documentation is light years ahead of where it was 11 years ago when I started using FreeBSD for one simple reason. Interested users stepped up and helped make it better. That's the only way that things improve in an open source project. OK so some of that talent needs to be harnessed and integrated into the development process. In this day and age we need to believe that user documentation provides a paradigm for design and development not design and development a paradigm for documentation. The latter view characterized development in the early 70,s and 80's. I thought we had moved beyond that. FWIW, I added a paragraph to the UPDATING file in both HEAD and RELENG_6 that describes why updating to the latest code in the installed branch is a good idea before trying a major version upgrade. Hopefully that will help the next person who stumbles over this same issue. Thank you so much for what you do. I trust that you will understand that recomendations for improvement are made BECAUSE the quality of design and development is so good. It deserves better and more professional attention to the role of end user documentation. my two pennorth Doug -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
Doug Barton wrote: How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. Or as another poster said, just say latest RELENG_5 prior to upgrade This is an open source project. The only way that things improve is if people help make it better. It's also worth pointing out that this issue of upgrading to the latest version of the branch you're in has been common knowledge for, basically, always; so if the folks that wrote the release notes neglected to include it, it's understandable. (Although, as you point out, potentially frustrating for new(er) users.) Well, if it's common knowledge, lets see it documented. We're only talking a few lines in the handbook or the release notes, not an entire chapter. If RE wants to change the requirements for upgrading, then how bleeping hard would it be to update either release notes or errata. It's not so much that I now need to do multiple upgrades (ok, that IS pretty annoying), it's that I'd never of known unless I followed this thread. Ok, so, after you calm down a bit, why don't you write a message to [EMAIL PROTECTED] and mention this issue. rant3 My frustration comes from the fact that this seems to be getting worse, not better. In addition, every time I bring this up, I'm told (usually by someone with a freebsd.org address) that, oh we all know/knew about that or, it's common knowledge. In the case of the vinum/gvinum/gmirror trainwreck, I got silence, even though I strongly suspect multiple people knew there were problems, but just didn't want to talk about them. I'd gladly help document some of this, but I'm not the one who knows where the skeletons are snoozing (at least till I trip on a femur) So whats the big issue with letting the rest of us in on the secrets? I'm not looking for a book, just a line or two saying here be dragons somewhere /other /than the basement of the planing department in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard' (apologies to Doug Adams). /rant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic building static magic library ranlib libmagic.a cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/apprentice.c -o apprentice.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/apptype.c -o apptype.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/ascmagic.c -o ascmagic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/compress.c -o compress.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/fsmagic.c -o fsmagic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/funcs.c -o funcs.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/is_tar.c -o is_tar.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/magic.c -o magic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/print.c -o print.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/readelf.c -o readelf.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/softmagic.c -o softmagic.So building shared library libmagic.so.2 cat /usr/src/lib/libmagic/../../contrib/file/Header /usr/src/lib/libmagic/../../contrib/file/Localstuff /usr/src/lib/libmagic/../../contrib/file/Magdir/xo65,v /usr/src/lib/libmagic/../../contrib/file/Magdir/virtutech,v /usr/src/lib/libmagic/../../contrib/file/Magdir/uuencode,v /usr/src/lib/libmagic/../../contrib/file/Magdir/netbsd,v /usr/src/lib/libmagic/../../contrib/file/Magdir/allegro /usr/src/lib/libmagic/../../contrib/file/Magdir/sccs /usr/src/lib/libmagic/../../contrib/file/Magdir/sysex /usr/src/lib/libmagic/../../contrib/file/Magdir/xdelta /usr/src/lib/libmagic/../../contrib/file/Magdir/zyxel /usr/src/lib/libmagic/../../contrib/file/Magdir/riff,v /usr/src/lib/libmagic/../../contrib/file/Magdir/games /usr/src/lib/libmagic/../../contrib/file/Magdir/vicar /usr/src/lib/libmagic/../../contrib/file/Magdir/mlssa /usr/src/lib/libmagic/../../contrib/file/Magdir/geos /usr/src/lib/libmagic/../../contrib/file/Magdir/fsav /usr/src/lib/libmagic/../../contrib/file
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic Update to 5.4 before trying to update to 6.0. Kris pgpf2p3434d7o.pgp Description: PGP signature
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
Kris Kennaway wrote: On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, Dec 06, 2005 at 02:36:05PM -0700, secmgr wrote: Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? I tried to say that you have to update to 5.4 before you can update to 6.0, i.e. updates from older versions are not supported. It may be easier to do a binary upgrade (i.e. download release media and use the upgrade option). Kris pgphYPjbZzGAM.pgp Description: PGP signature
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 23:46, Kris Kennaway wrote: On Tue, Dec 06, 2005 at 02:36:05PM -0700, secmgr wrote: Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? I tried to say that you have to update to 5.4 before you can update to 6.0, i.e. updates from older versions are not supported. It may be easier to do a binary upgrade (i.e. download release media and use the upgrade option). At least with a vanilla install of 5.3, I had no problem going directly to 6.0. This was an extremely basic install, and I only did it because I lost my 6.0-R cd :) A. -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates. -- anon | [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: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 13:28, the author Kris Kennaway contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic Update to 5.4 before trying to update to 6.0. Thank you Kris You are a mine of information as always. I do wish there was some consistency in updating about this.. I asked on this list whether I needed to upgrade to 5.4 before mocing to 6 and the advice suggested that I could go straight from 5.3 to 6 but there we are -- guess that's life chuckles Presumably it would be safest to delete /usr/src/* and cvsup with tag=RELENG_5 Thanks again david -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 14:15, the author Vizion contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tuesday 06 December 2005 13:28, the author Kris Kennaway contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic Update to 5.4 before trying to update to 6.0. Thank you Kris You are a mine of information as always. I do wish there was some consistency in updating about this.. I asked on this list whether I needed to upgrade to 5.4 before mocing to 6 and the advice suggested that I could go straight from 5.3 to 6 but there we are -- guess that's life chuckles Presumably it would be safest to delete /usr/src/* and cvsup with tag=RELENG_5 Thanks again david Just an additional question if some one has time to answer. Should I upgrade my ports from 5.4 as well prior to moving to 6? I have a large ports installation on the system I am upgrading. david -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, 6 Dec 2005, Vizion wrote: Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic You should first upgrade to the latest 5-STABLE (cvs tag RELENG_5), then you should be able to upgrade to 6-STABLE (cvs tag RELENG_6). hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, 6 Dec 2005, Vizion wrote: Just an additional question if some one has time to answer. Should I upgrade my ports from 5.4 as well prior to moving to 6? No, that's not needed. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 14:36, the author Doug Barton contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, 6 Dec 2005, Vizion wrote: Just an additional question if some one has time to answer. Should I upgrade my ports from 5.4 as well prior to moving to 6? No, that's not needed. Thanks again david -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
Kris Kennaway wrote: On Tue, Dec 06, 2005 at 02:36:05PM -0700, secmgr wrote: Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? I tried to say that you have to update to 5.4 before you can update to 6.0, i.e. updates from older versions are not supported. It may be easier to do a binary upgrade (i.e. download release media and use the upgrade option). Kris Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. This is one of my pet peeves with FreeBSD. You can read the Release Notes, the UPDATING, the ERRATA, the HARDWARE, thinking you've prepped yourself for the upgrade, and still be screwed. If RE wants to change the requirements for upgrading, then how bleeping hard would it be to update either release notes or errata. It's not so much that I now need to do multiple upgrades (ok, that IS pretty annoying), it's that I'd never of known unless I followed this thread. I've run into this while installing since 4.4, and it's gotten really bad since the whole 5.3 mess. Now it's deja vu all over again. jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, Dec 06, 2005 at 05:23:42PM -0700, secmgr wrote: Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? I tried to say that you have to update to 5.4 before you can update to 6.0, i.e. updates from older versions are not supported. It may be easier to do a binary upgrade (i.e. download release media and use the upgrade option). Kris Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. You're right, as others have also pointed out. Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. This is one of my pet peeves with FreeBSD. You can read the Release Notes, the UPDATING, the ERRATA, the HARDWARE, thinking you've prepped yourself for the upgrade, and still be screwed. If RE wants to change the requirements for upgrading, then how bleeping hard would it be to update either release notes or errata. This didn't happen here, so you don't need to be upset at RE. Kris pgpdXD8SIxbxN.pgp Description: PGP signature
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, 6 Dec 2005, secmgr wrote: Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. 5.4-STABLE is newer. :) Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. This is one of my pet peeves with FreeBSD. You can read the Release Notes, the UPDATING, the ERRATA, the HARDWARE, thinking you've prepped yourself for the upgrade, and still be screwed. This is an open source project. The only way that things improve is if people help make it better. It's also worth pointing out that this issue of upgrading to the latest version of the branch you're in has been common knowledge for, basically, always; so if the folks that wrote the release notes neglected to include it, it's understandable. (Although, as you point out, potentially frustrating for new(er) users.) If RE wants to change the requirements for upgrading, then how bleeping hard would it be to update either release notes or errata. It's not so much that I now need to do multiple upgrades (ok, that IS pretty annoying), it's that I'd never of known unless I followed this thread. Ok, so, after you calm down a bit, why don't you write a message to [EMAIL PROTECTED] and mention this issue. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, December 6, 2005 19:44, Doug Barton wrote: On Tue, 6 Dec 2005, secmgr wrote: Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. 5.4-STABLE is newer. :) Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. Sorry to butt in but.. Doesn't the definition of -STABLE change, for all intents and purposes, by the minute? What next, versions prior to 5.4-STABLE as of MMDD ? + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. This is getting closer to the truth. Why don't you just say update to the most recent RELENG_5 before attempting. Future proof, no room for confusion. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 16:50, the author Allen contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, December 6, 2005 19:44, Doug Barton wrote: On Tue, 6 Dec 2005, secmgr wrote: Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. 5.4-STABLE is newer. :) Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. Sorry to butt in but.. Doesn't the definition of -STABLE change, for all intents and purposes, by the minute? What next, versions prior to 5.4-STABLE as of MMDD ? + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. This is getting closer to the truth. Why don't you just say update to the most recent RELENG_5 before attempting. Future proof, no room for confusion. Well I do not want to not thank those who have made the upgrades viable. The value of their work should not be underrated. There is however a perennial problem that freebsd documentation has always been seen as behind and seperate from the development process rather than an integral part of that process. I do not know whether that historical habit is changeable. I suspect it is the only major disadvantage from what I would personally describe as a somewhat technologically centred meritocratic school of governance for the freebsd project. Some improved cohesion between the desire to meet the developmental needs and a desirable objective to provide an end user-centric operation is, to my mind desirable. On the other hand freebsd has prospered in the past by devotion to reliance upon idiosyncratic individual initiatives and that does not blend well with co-operatively integrated plans to similtaneously meet the twin goals I identify. On the whole the result is a A for freebsd when we all want an A++ chuckles Certainly better documentation for the upgrade path between 5.3 and 6.0 would have saved me a h*** of a lot of time.. but there it is.. live does not hand out many A++s Thank you top everyone who helped. I have now successfully upgarded to 5.4 and am about to begin the last leg of this journey towards 6.0. my two pennorth david -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
From: Vizion [EMAIL PROTECTED] To: freebsd-stable@freebsd.org, [EMAIL PROTECTED] Date: Tue, 6 Dec 2005 19:41:30 -0800 Cc: Doug Barton [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] Subject: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 16:50, the author Allen contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, December 6, 2005 19:44, Doug Barton wrote: On Tue, 6 Dec 2005, secmgr wrote: Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. 5.4-STABLE is newer. :) Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. Sorry to butt in but.. Doesn't the definition of -STABLE change, for all intents and purposes, by the minute? What next, versions prior to 5.4-STABLE as of MMDD ? I believe I've seen exactly this type of notation in UPDATING over the years, in both 4.x 5.x. + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. This is getting closer to the truth. Why don't you just say update to the most recent RELENG_5 before attempting. Future proof, no room for confusion. [...snip...] There is however a perennial problem that freebsd documentation has always been seen as behind and seperate from the development process rather than an Maybe (hmm, even probably :) but I've found documentation, announcements, errata, etc. (*manpages*) for FreeBSD to be *much* better, more relevant up to date than, umm, other opensource systems. Compared to FreeBSD, other systems' documentation/manpages seem haphazard in some cases even nonexistent. integral part of that process. [...snip...] Certainly better documentation for the upgrade path between 5.3 and 6.0 would have saved me a h*** of a lot of time.. but there it is.. live does not hand out many A++s I would guess that it says 5.3 instead of 5.4 due to oversight, e.g. it was written/documented/recommended before 5.4 was out. Maybe that's (part of) the basis for the Handbook's recommendation of reading the -stable list if you indeed want to track past -RELEASE. :) Thank you top everyone who helped. I have now successfully upgarded to 5.4 and am about to begin the last leg of this journey towards 6.0. my two pennorth david -- Mine too I guess :) -kc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, Dec 06, 2005 at 11:24:31PM -0500, Kenneth W Cochran wrote: Certainly better documentation for the upgrade path between 5.3 and 6.0 would have saved me a h*** of a lot of time.. but there it is.. live does not hand out many A++s I would guess that it says 5.3 instead of 5.4 due to oversight, e.g. it was written/documented/recommended before 5.4 was out. Maybe that's (part of) the basis for the Handbook's recommendation of reading the -stable list if you indeed want to track past -RELEASE. :) I've corrected myself already in previous replies, but to try and put this to rest, I was mistaken when I said that 5.4 was required. Others have already confirmed that clean 5.3 installations may be directly upgraded to 6.0. The problem experienced by the OP must have had another cause. The upgrade to 5.4 may have corrected it for him. Kris pgpbOFo0MhqI7.pgp Description: PGP signature
