Re: FreeBSD9 and the sheer number of problem reports
On 2/26/12 10:30 AM, Erich Dollansky wrote: No matter what effort you put into testing, you can never achieve the robustness of an older release. I still have 7.4 running on one. This can stay until next year. So, why do you want to run the latest release on an important machine? You can, but you are not in a position to complain then. Erich Do you not see this as a *huge* problem ? This means even fewer testers, again ! This weekend I replaced a server, moved it from 6.4-STABLE to 8.3-PRERELEASE. Hell, as far as I'm concerned it could have stayed on 6.4-STABLE to be honest, but I needed to replace the hardware which was getting old. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Linimon wrote: On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: it is release engineering who could establish a little bit more time between code-freeze and RELEASE As you will see from the (very) long discussion that you are about to read, there has to be a compromise. As it was, the release process was too long, not too short. Yes, we would like to get more testers pre-release, but that seems to be more easily said than done. Ideas appreciated. You will also see in the thread that: - it is not possible to release bug-free code, and in fact - it is not possible to release code with no regressions whatsoever if you are to ever release anything at all. To summarize: yes, we do care: and yes, these are classical software engineering problems that can only be dealt with, not solved completely. well said, of course a dead-line is necessary, as well as pursuing perfection is dangerous matter :) anyway, this thread brought little suggestion or possible solutions but lots of declaration of facts and personal interest on the table IMO such a discussion should be strictly FreeBSD oriented and so I see a or the missing point, a declaration of FreeBSD, what is it, for whom is it and what does it, this statement is nonexistent, or not clear enough. This miss affect not only users opinion but also developers work. furthermore, plans or schedules may be perfect within it's own restrictions, but only as good as the outcome so the outcome must be controlled How? ... setting the goal are you interested in bumping the version number up or do you want to come up with something better than the former version? If yes, what is it? Without goal nobody can deliver predictable and defined results steeling a good comparison from that thread you mentioned, I would say, with the right goal you _CAN_ herd cats, instead of pied pipers put some mice on the street :) again IMO the version number race is suspicious and could(should) be changed into a goal-race, then, when the goal is achieved, the the version number may go up with goal the outcome can be controlled, without it is loose end it should exist a dead-line, but goal-oriented and so should be extendable in case of failure Resuming, I would do - [re]define FreeBSD - setting the next release goal - scheduling - go then accompanying the ongoing work (control), assuring that the sub-projects are within the limits, new ideas only can go into the next schedule, a no-matter-what position of engineering is important of course we deal with FreeBSD source, ports is a different matter and can not be merged tester? I would say it could be easier to have more of them, eventual they are already there, but they are unknown, quiet for certain reasons, language, skills, etc when a problem appears, point of sight is often missing, the user who pops up has a problem, he has no interest in blaming somebody or whatever, he like to solve the problem, so giving advices as RTFM or similar does not help a bit, neither how to use, how to write, how to spell or whatever other personal issue are arising. Most do not come back after RTFM or do not even post because they heard it already once so I would say, it does not matter how wired the PR arrives, it should be handled by same criteria as above. What is the goal? Finding problems in the FreeBSD code. So it does not matter which language the guy talks, if he knows C+/- or whatever bothers you, be smart and find out what the problem is there are several related issues, I would start by splitting the mailing list page on FreeBSD. Confusing for a user, he wouldn't know which list. Directing people on first sight to a general mailing list, perhaps no developers in it, or who has people-skills only and drain the results you want ... under any cost of selfishness before the bullets fly, I am not criticizing anybody, the tech-syndrome is natural, techs and users do not speak the same language, techs always will classify users as stupid and users always will classify techs as arrogant, or at least friction is natural. That is a global unchangeable fact and we have to live with it. So mix it up or separate it in prole of better results. It is very easy, with machines we do it already, we write drivers ... As above, what do you want? More PRs? ok, then again it is answered by the goal you set. Well treated a lot of testers will appear. - -- H -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9LTgoACgkQvKVfg5xjCDw8tgCfSU/IsV7S22d5AaNKiLYYwh7Z W40An1OKxF2T275x3pMwZBXTFpGYzuBQ =2ucy -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi, On Monday 27 February 2012 16:34:02 H wrote: Mark Linimon wrote: On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: furthermore, plans or schedules may be perfect within it's own restrictions, but only as good as the outcome so the outcome must be controlled How? ... setting the goal could it be that you want to replace them? http://www.freebsdfoundation.org/ Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On 02/27/12 10:41, Erich Dollansky wrote: Hi, On Monday 27 February 2012 16:34:02 H wrote: Mark Linimon wrote: On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: furthermore, plans or schedules may be perfect within it's own restrictions, but only as good as the outcome so the outcome must be controlled How? ... setting the goal could it be that you want to replace them? http://www.freebsdfoundation.org/ Erich I know it is not polite answering with a question, so I beg your pardon and do it anyway do you really believe somebody (user, future user, curious) go to this site when looking for freebsd description, download and install? further, where is it? we all are working with software, we know very well what we do with grey-zone-matter ... it is 0|1 ... all between is /dev/null ... or exit ... so do not assume that people do like guessing very much, they find it by banging their head on it or they go home -- H signature.asc Description: OpenPGP digital signature
Re: FreeBSD9 and the sheer number of problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Felder wrote: On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot m...@my.gd wrote: Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. Then stick with the 8.x train until it's no longer supported. Also, don't you know the rule about running .0 releases in production? :) 9.0 had LOTS of changes. They were very important. It's going to take a while for the community to fully absorb them and bugs to be worked out. We don't have enough testers of -CURRENT to prevent this. Everything seemed stable (ie, no release blockers) for the people running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was released. But as always, TEST TEST TEST and please have a proper staging/test environment before you throw your production into 9.x. that is all understandable but the point should not be forgotten ... I mean certainly -RELEASE __is__ the production release so, few testers is no excuse, still more when that is a known issue, so a bigger time frame would be the solution until the var _seemed_stable change into _is_stable of course, that is not always so easy but also think of side effects, few_testers could change into still_less when FreeBSD prove to have unstable releases - -- H -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9J83UACgkQvKVfg5xjCDw7ggCfTpMhHuGqetRHUbKmBmCfRMwn d04An3f8UIdfvtee47NYCS+EjqCk+1t7 =fJbU -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi, On Sunday 26 February 2012 15:55:17 H wrote: Mark Felder wrote: On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot m...@my.gd wrote: that is all understandable but the point should not be forgotten ... I mean certainly -RELEASE __is__ the production release there is not the production release here. There are always at least two. so, few testers is no excuse, still more when that is a known issue, so a bigger time frame would be the solution until the var _seemed_stable change into _is_stable Stable has here a different meaning. It just means that nothing will change at the interfaces anymore as long the error is not hidden there. 5.2 and 5.21 was such an example if I remember right. of course, that is not always so easy but also think of side effects, few_testers could change into still_less when FreeBSD prove to have unstable releases No matter what effort you put into testing, you can never achieve the robustness of an older release. I still have 7.4 running on one. This can stay until next year. So, why do you want to run the latest release on an important machine? You can, but you are not in a position to complain then. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Dollansky wrote: Hi, On Sunday 26 February 2012 15:55:17 H wrote: Mark Felder wrote: On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot m...@my.gd wrote: that is all understandable but the point should not be forgotten ... I mean certainly -RELEASE __is__ the production release there is not the production release here. There are always at least two. whatever, the question is not the how many, it is the word BETA or PRE change to RELEASE and we should not turn this into some word-fiddling important is maintain the understanding for that word, because there are lot of not_developer_people out what seems forgotten is what is here in the second part: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/lessons-learned.html what developers understand, mean or think does not matter, the _user_ should be able to understand and believe in this word RELEASE, what IMO is pretty clear so please do not argument with me or anybody else, it is merely a pretty fair and neutral opinion about RELEASE meaning backed on what is stated on the page above, it seems to be the procedure, which eventually needs revision, because we humans always will fail somewhere H so, few testers is no excuse, still more when that is a known issue, so a bigger time frame would be the solution until the var _seemed_stable change into _is_stable Stable has here a different meaning. It just means that nothing will change at the interfaces anymore as long the error is not hidden there. 5.2 and 5.21 was such an example if I remember right. of course, that is not always so easy but also think of side effects, few_testers could change into still_less when FreeBSD prove to have unstable releases No matter what effort you put into testing, you can never achieve the robustness of an older release. I still have 7.4 running on one. This can stay until next year. So, why do you want to run the latest release on an important machine? You can, but you are not in a position to complain then. Erich - -- H -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9KBosACgkQvKVfg5xjCDz/6QCglZ7CI24iBYcicY7X1Qsffdwt 3T8AnA5SVaESL7m3TYCuznJAu2usw9nW =x/DV -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi, On Sunday 26 February 2012 18:16:53 Chris Rees wrote: On 24 February 2012 01:35, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote: This is NOT a troll. This is NOT a flame. Do NOT hijack this thread to troll/flame. allow them some fun too. Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( Did you read deeply into the strategy behind the releases? If I remember right, the odd numbers are a little bit more experimental compared to the even numbers. For myself, I try to stick with even numbers whenever possible. If I install FreeBSD on a serious machine, I never use x.0. It must be at least x.1. There's no such odd/even number policy with FreeBSD-- I think you're thinking of another OS ;) maybe something got stuck in my head with the move from 4 to 5. How easy was the move to 6 then? Independent of this, it is still true that there is always the older branch available when a new one opens at .0. You're right that x.0 is slightly more experimental in general though (by its nature, it must be). And has nothing to do with FreeBSD as such. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi, On Sunday 26 February 2012 17:16:43 H wrote: Erich Dollansky wrote: On Sunday 26 February 2012 15:55:17 H wrote: Mark Felder wrote: I mean certainly -RELEASE __is__ the production release there is not the production release here. There are always at least two. whatever, the question is not the how many, it is the word BETA or PRE change to RELEASE and we should not turn this into some word-fiddling it is just logic. 10 is currently ALPHA, 8.3 is currently BETA, there might be soon a RC1 and the release. important is maintain the understanding for that word, because there are lot of not_developer_people out What should developer do after no errors have been reported anymore in an RC? I would suggest that they release their stuff. what seems forgotten is what is here in the second part: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/lessons-learned.html what developers understand, mean or think does not matter, the _user_ should be able to understand and believe in this word RELEASE, what IMO is pretty clear Release means that developers either state the errors in the README or believe that there are no known errors. It does not mean that there are no more errors in there. so please do not argument with me or anybody else, it is merely a pretty fair and neutral opinion about RELEASE meaning backed on what is stated on the page above, it seems to be the procedure, which eventually needs revision, because we humans always will fail somewhere You can do the same as I do. I run currently a 8.3 BETA. You can encourage people to do so too to make it easier for the developers to spot as many errors as possible before the release. Still, FreeBSD has always at least one more release out there which was hardened in real life. If then take into account that odd numbers are known to have a higher risk of errors plus the fact that 9.0 was the first release of the new branch, I do not see a need to change much to the advantage except of putting more load onto the people who actually make it happen. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On 24 February 2012 01:35, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote: This is NOT a troll. This is NOT a flame. Do NOT hijack this thread to troll/flame. allow them some fun too. Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( Did you read deeply into the strategy behind the releases? If I remember right, the odd numbers are a little bit more experimental compared to the even numbers. For myself, I try to stick with even numbers whenever possible. If I install FreeBSD on a serious machine, I never use x.0. It must be at least x.1. There's no such odd/even number policy with FreeBSD-- I think you're thinking of another OS ;) You're right that x.0 is slightly more experimental in general though (by its nature, it must be). Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On 26 February 2012 11:32, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, On Sunday 26 February 2012 18:16:53 Chris Rees wrote: On 24 February 2012 01:35, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote: This is NOT a troll. This is NOT a flame. Do NOT hijack this thread to troll/flame. allow them some fun too. Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( Did you read deeply into the strategy behind the releases? If I remember right, the odd numbers are a little bit more experimental compared to the even numbers. For myself, I try to stick with even numbers whenever possible. If I install FreeBSD on a serious machine, I never use x.0. It must be at least x.1. There's no such odd/even number policy with FreeBSD-- I think you're thinking of another OS ;) maybe something got stuck in my head with the move from 4 to 5. 4 to 5 was SMP-related, and when the Project decided to move to time-based rather than feature-based releases -- pure coincidence that 5 was odd. How easy was the move to 6 then? _Just_ before my time I'm afraid ;) Independent of this, it is still true that there is always the older branch available when a new one opens at .0. You're right that x.0 is slightly more experimental in general though (by its nature, it must be). And has nothing to do with FreeBSD as such. Exactly :) Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Dollansky wrote: Hi, On Sunday 26 February 2012 17:16:43 H wrote: Erich Dollansky wrote: On Sunday 26 February 2012 15:55:17 H wrote: Mark Felder wrote: I mean certainly -RELEASE __is__ the production release there is not the production release here. There are always at least two. whatever, the question is not the how many, it is the word BETA or PRE change to RELEASE and we should not turn this into some word-fiddling it is just logic. 10 is currently ALPHA, 8.3 is currently BETA, there might be soon a RC1 and the release. this is going into the wrong direction and I should hold my peace but will say my piece this is about 9.0-RELEASE only and wishfully about future releases, not beta, rc or pre- -current or - -stable ... H important is maintain the understanding for that word, because there are lot of not_developer_people out What should developer do after no errors have been reported anymore in an RC? I would suggest that they release their stuff. why do you ask? it is very easy to answer: nothing! it is release engineering who could establish a little bit more time between code-freeze and RELEASE as in practice we can see 2-3 month or so would be something reasonable what seems forgotten is what is here in the second part: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/lessons-learned.html what developers understand, mean or think does not matter, the _user_ should be able to understand and believe in this word RELEASE, what IMO is pretty clear Release means that developers either state the errors in the README or believe that there are no known errors. It does not mean that there are no more errors in there. so please do not argument with me or anybody else, it is merely a pretty fair and neutral opinion about RELEASE meaning backed on what is stated on the page above, it seems to be the procedure, which eventually needs revision, because we humans always will fail somewhere You can do the same as I do. I run currently a 8.3 BETA. You can encourage people to do so too to make it easier for the developers to spot as many errors as possible before the release. it is not about you and me it is about FreeBSD and the meaning, importance and reliability of - -RELEASE for all people the word -RELEASE is what encourage people :) Still, FreeBSD has always at least one more release out there which was hardened in real life. If then take into account that odd numbers are known to have a higher risk of errors plus the fact that 9.0 was the first release of the new branch, I do not see a need to change much to the advantage except of putting more load onto the people who actually make it happen. Erich - -- H -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9KJU4ACgkQvKVfg5xjCDzxXQCgoNRlf3pjOjQ2ZzjQBbFJtMby KEwAmwahSUftP5LT8EPei9Q7oZsc9ddE =GBIW -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
H hm at hm.net.br writes: ... it is about FreeBSD and the meaning, importance and reliability of -RELEASE for all people ... Still, FreeBSD has always at least one more release out there which was hardened in real life. ... Hi, I think you have a point. There was a very interesting discussion on FreeBSD and release engineering. http://lwn.net/Articles/478663/ There were some proposals made, but in my view this is the most important one. There are too many production releases - at present including versions 7.4, 8.2, and 9.0 . Cutting one would refocus devs and users on the remainig two, with obvious benefits to FreeBSD product. jb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi, On Sunday 26 February 2012 19:42:55 jb wrote: H hm at hm.net.br writes: ... it is about FreeBSD and the meaning, importance and reliability of -RELEASE for all people ... Still, FreeBSD has always at least one more release out there which was hardened in real life. ... Hi, I think you have a point. There was a very interesting discussion on FreeBSD and release engineering. http://lwn.net/Articles/478663/ I will read soon. There were some proposals made, but in my view this is the most important one. There are too many production releases - at present including versions 7.4, 8.2, and 9.0 . 7.4 will be gone soon. Normally when 8.3 goes out, 7.4 will go. Cutting one would refocus devs and users on the remainig two, with obvious benefits to FreeBSD product. Three is not normal. Shouldn't it have disappeared with 9.0? Two is normal. 7.4 will be maintained until February next year or so anyway. So, nothing was wasted here. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On Sun, Feb 26, 2012 at 06:32:17PM +0700, Erich Dollansky wrote: There's no such odd/even number policy with FreeBSD-- I think you're thinking of another OS ;) maybe something got stuck in my head with the move from 4 to 5. Yes, 5 was the Great Leap where true SMP was introduced. In the many-year-long development cycle, so many other things (IIRC geom and suspend/resume, among others) that the change from 4 to 5 was completely disruptive. We resolved to release more often so as to never be in that situation again. (Granted, probably no architectural change will ever be that sweeping again.) There is no meaning to odd/even release numbering in FreeBSD. How easy was the move to 6 then? An order of magnitude easier than the move to 5. Although as needs to happen with each major release, some code that had been deprecated was dropped, and some subsystems which no one stepped up to do the maintenance necessary for other re-architecting were dropped as well. Each of the subsequent moves has been much the same -- a few gotchas, but nothing like the move to 5. This has been purely intentional. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On Sun, Feb 26, 2012 at 5:08 AM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, On Sunday 26 February 2012 19:42:55 jb wrote: H hm at hm.net.br writes: ... it is about FreeBSD and the meaning, importance and reliability of -RELEASE for all people ... Still, FreeBSD has always at least one more release out there which was hardened in real life. ... Hi, I think you have a point. There was a very interesting discussion on FreeBSD and release engineering. http://lwn.net/Articles/478663/ I will read soon. There were some proposals made, but in my view this is the most important one. There are too many production releases - at present including versions 7.4, 8.2, and 9.0 . 7.4 will be gone soon. Normally when 8.3 goes out, 7.4 will go. Cutting one would refocus devs and users on the remainig two, with obvious benefits to FreeBSD product. Three is not normal. Shouldn't it have disappeared with 9.0? Two is normal. 7.4 will be maintained until February next year or so anyway. So, nothing was wasted here. OK. As someone who has been running FreeBSD for a while (though I am not an old-timer as I never ran V2), I can tell you that 5 to 6 was a very smooth upgrade from a fairly broken version (5 had a huge number of serious issues that could not be fixed without ABI changes) to a pretty good release that, because it came fairly close to 5.2 (the first production release of 5), it was still mostly fixes and not new features. .0 releases of any large project where version bumps are really significant are always something to use in production only with great care. This has been true for years and for almost all operating systems. It was true with VMS, RSX-11M, IOS (the Cisco one, not the Apple one), JunOS (Juniper's router OS), Linux distributions and, until 3.0, Linux kernels. Recently more and more products have moved from the traditional model where major version bumps meant major changes, so this is not true with Firefox, Chrome, Linux kernels, etc., but it is still true for FreeBSD. And that means that there is a real .0 that will only get significantly broad use after a release. Staying in BETA for long intervals leaves important features from getting to a large number of users, so RE has to draw a line somewhere and say, We are doing a release. It is now more or less time based, but it is still when ABIs and APIs can change which is the key to getting new features out to a broad audience. It simply as to be done. No one really likes it, but no one has come up with a better way. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: it is release engineering who could establish a little bit more time between code-freeze and RELEASE As you will see from the (very) long discussion that you are about to read, there has to be a compromise. As it was, the release process was too long, not too short. Yes, we would like to get more testers pre-release, but that seems to be more easily said than done. Ideas appreciated. You will also see in the thread that: - it is not possible to release bug-free code, and in fact - it is not possible to release code with no regressions whatsoever if you are to ever release anything at all. To summarize: yes, we do care: and yes, these are classical software engineering problems that can only be dealt with, not solved completely. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On Sun, Feb 26, 2012 at 11:43 AM, Mark Linimon lini...@lonesome.com wrote: On Sun, Feb 26, 2012 at 06:32:17PM +0700, Erich Dollansky wrote: There's no such odd/even number policy with FreeBSD-- I think you're thinking of another OS ;) maybe something got stuck in my head with the move from 4 to 5. Yes, 5 was the Great Leap where true SMP was introduced. In the many-year-long development cycle, so many other things (IIRC geom and suspend/resume, among others) that the change from 4 to 5 was completely disruptive. We resolved to release more often so as to never be in that situation again. (Granted, probably no architectural change will ever be that sweeping again.) Minor correction. Suspend/resume was around in late 3 and 4, though the Nomad code in 3 was a bit unstable. It worked well in 4, but was dependent on APM which was already being replaced by ACPI. By the time 5.2 was actually released, many systems were being shipped without APM, so could not run FreeBSD. (APM was fairly optional, but ACPI systems really need ACPI support.) ACPI was one of several things that forced 5.0 to be released even though RE and everyone running current knew it had big problems. It i also why 5.0 and 5.1 were clearly marked as development releases not for production. I really hope to never see a release as ugly as 5. 9.0 may have issues as did 7.0 and 8.0, but for most, it works quite well. I m happily running it on a couple of systems. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On Fri, Feb 24, 2012 at 7:46 AM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, On Friday 24 February 2012 04:21:12 Peter Maloney wrote: Am 23.02.2012 21:15, schrieb Mark Felder: On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot m...@my.gd wrote: Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. I suggest these concepts should be tested: I can tell you what in practical terms stops me from testing very often. The switch back to the running version. Let me suggest this. Currently, we have on the disk normally two kernels. The current one and the last one. Why not add a third one called testing? Add then an entry into the boot menu that users can switch between the current kernel and a kernel they just installed for testing. Well, as you would want to test both kernel + userland its get a bit tricky on ufs based system, as you have to setup several slices/partitions. For ZFS its easier, as the only thing required would be a snapshot of clean install, which the user then can just zfs recv, modify vfs.root.mountfrom and so on. Just my thoughts. Andreas I know that I can do this manually. But this is the point where it becomes difficult for the majority of people. As FreeBSD needs a large amount of testing on unknown hardware, this could increase the number of actual testers without much effort. Ok, the developers must then be ready to deal with reports which miss many things. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi, On Friday 24 February 2012 15:34:06 Andreas Nilsson wrote: On Fri, Feb 24, 2012 at 7:46 AM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: On Friday 24 February 2012 04:21:12 Peter Maloney wrote: Am 23.02.2012 21:15, schrieb Mark Felder: On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot m...@my.gd wrote: Let me suggest this. Currently, we have on the disk normally two kernels. The current one and the last one. Why not add a third one called testing? Add then an entry into the boot menu that users can switch between the current kernel and a kernel they just installed for testing. Well, as you would want to test both kernel + userland its get a bit tricky on ufs based system, as you have to setup several slices/partitions. For ZFS its easier, as the only thing required would be a snapshot of clean install, which the user then can just zfs recv, modify vfs.root.mountfrom and so on. /usr/local for the current system and /usr/localtest for the other system. Of course, the same for /bin, /etc ... It is not that difficult. Or a script which renames the directories for the next start. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On Thu, Feb 23, 2012 at 9:21 PM, Peter Maloney peter.malo...@brockmann-consult.de wrote: I suggest these concepts should be tested: Perhaps the testers tested beta1 and beta2, but there were so many changes after beta2, that bugs appeared in release that did not exist in beta2. Test this by reproducing things reported in release also in beta1 or 2. Perhaps the people who know the rule about running .0 releases (such as myself) never bothered to test beta1, beta2, or even release .0 (true in my case). If so, then this rule is a very bad one. Test this with a poll. At $JOB, we never install a N.0 release either, but only because the .0 release has such a brief life. The N.1 and N.3 releases have extended lifetimes, and so we tend to only use those versions. Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD9 and the sheer number of problem reports
Hello list, This is NOT a troll. This is NOT a flame. Do NOT hijack this thread to troll/flame. I'm writing this in light of the *many* problem reports I see on the lists with 9.0-RELEASE. I'm getting extremely worried here. Short introduction in order: See, we use FreeBSD at work for our firewall boxes, running: - PF + CARP + PFsync - nagios-nrpe - munin-node - bacula client and either - nginx and/or haproxy - relayd These boxes serve as frontend firewalls for all our projects/products, including a few high traffic ones. For example our most traffic intense project has 4 firewalls, 2 each on 2 different datacenters, sharing 4 CARP IPs with automagic failover. These firewalls total ~200mb/s , serving only minifi'ed javascript pages. Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( I'd love to hear feedback. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On Thu, Feb 23, 2012 at 10:25, Damien Fleuriot m...@my.gd wrote: snip Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( I'd love to hear feedback. Feedback: If you're worried, wait until you aren't. Kurt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On 2/24/2012 1:39, Kurt Buff wrote: On Thu, Feb 23, 2012 at 10:25, Damien Fleuriotm...@my.gd wrote: snip Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( I'd love to hear feedback. Feedback: If you're worried, wait until you aren't. Thorough testing ahead of time will either make you confident or give you the option to report issues which affect you directly (and help improve FreeBSD). I say that having run into one issue with 9.0 (and reported it). I am still using and deploying more 9.0 servers into production. My .02. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On 2/24/2012 1:39, Kurt Buff wrote: On Thu, Feb 23, 2012 at 10:25, Damien Fleuriotm...@my.gd wrote: snip Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( I'd love to hear feedback. Feedback: If you're worried, wait until you aren't. Thorough testing ahead of time will either make you confident or give you the option to report issues which affect you directly (and help improve FreeBSD). I say that having run into one issue with 9.0 (and reported it). I am still using and deploying more 9.0 servers into production. My .02.
Re: FreeBSD9 and the sheer number of problem reports
On Thu, 23 Feb 2012 19:25:01 +0100 Damien Fleuriot m...@my.gd wrote: In the current state of things, I have *absolutely* no wish to run it in production :( Nobody forces you to jump onto the 9.0-release bandwagon. You can choose to skip it. If you skip 9.0 - will you be better prepared and less fearful when 9.1-release comes? You decide. -- Torfinn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot m...@my.gd wrote: Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. Then stick with the 8.x train until it's no longer supported. Also, don't you know the rule about running .0 releases in production? :) 9.0 had LOTS of changes. They were very important. It's going to take a while for the community to fully absorb them and bugs to be worked out. We don't have enough testers of -CURRENT to prevent this. Everything seemed stable (ie, no release blockers) for the people running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was released. But as always, TEST TEST TEST and please have a proper staging/test environment before you throw your production into 9.x. Only YOU can prevent forest fires^W^W unplanned outages. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Am 23.02.2012 21:15, schrieb Mark Felder: On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot m...@my.gd wrote: Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. Then stick with the 8.x train until it's no longer supported. Also, don't you know the rule about running .0 releases in production? :) 9.0 had LOTS of changes. They were very important. It's going to take a while for the community to fully absorb them and bugs to be worked out. We don't have enough testers of -CURRENT to prevent this. Everything seemed stable (ie, no release blockers) for the people running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was released. This is quite a good explanation, but what can be done in the future, so either people are testing, or more report problems? I suggest these concepts should be tested: Perhaps the testers tested beta1 and beta2, but there were so many changes after beta2, that bugs appeared in release that did not exist in beta2. Test this by reproducing things reported in release also in beta1 or 2. Perhaps the people who know the rule about running .0 releases (such as myself) never bothered to test beta1, beta2, or even release .0 (true in my case). If so, then this rule is a very bad one. Test this with a poll. Perhaps people are more interested in a preview of what new features they can expect, rather than actually planning on testing and submitting PRs. Test this also with a poll. To fix this problem, you could add an automatic bug reporting system like crash handlers in many applications (Mozilla had this long ago; KDE has this, etc.).When dealing with drivers, hard disks, removable devices, etc., the devs can't test every case, but the users can, so until the FreeBSD Foundation can afford a huge test lab with every combination of hardware, strengthening user feedback is more important than internal testing. But as always, TEST TEST TEST and please have a proper staging/test environment before you throw your production into 9.x. Only YOU can prevent forest fires^W^W unplanned outages. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Short introduction in order: See, we use FreeBSD at work for our firewall boxes, running: - PF + CARP + PFsync - nagios-nrpe - munin-node - bacula client and either - nginx and/or haproxy - relayd These boxes serve as frontend firewalls for all our projects/products, including a few high traffic ones. For example our most traffic intense project has 4 firewalls, 2 each on 2 different datacenters, sharing 4 CARP IPs with automagic failover. These firewalls total ~200mb/s , serving only minifi'ed javascript pages. In the current state of things, I have *absolutely* no wish to run it in production :( I'd love to hear feedback. This is really a bad example and we shouldn't jump into the .0 releases comparison. Firewalls are supposed to be super stable. The last thing you need in a firewall is trying to troubleshoot OS related issues. Most major brands use well patched long tested OS to build their firewall software. So, no you shouldn't jump to 9 before it has been thoroughly tested. That doesn't mean of course that you should let others do the testing for you. If you plan on moving your environment to 9 at some point in the future then you have to start your own testing now. Best Regards, -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi, On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote: This is NOT a troll. This is NOT a flame. Do NOT hijack this thread to troll/flame. allow them some fun too. Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( Did you read deeply into the strategy behind the releases? If I remember right, the odd numbers are a little bit more experimental compared to the even numbers. For myself, I try to stick with even numbers whenever possible. If I install FreeBSD on a serious machine, I never use x.0. It must be at least x.1. So, I have the same wish as you and did not expect much more. Never forget, if the people behind the scene never put a release out, we never have the chance to iron out the problems. And now the fun. I even run 8.3 beta on my personal workstation. But I still would not put 9.0 on any machine I work with or give it to somebody else for this purpose. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi Damien, On Fri, Feb 24, 2012 at 5:25 AM, Damien Fleuriot m...@my.gd wrote: I'm writing this in light of the *many* problem reports I see on the lists with 9.0-RELEASE. I'm getting extremely worried here. .. See, we use FreeBSD at work for our firewall boxes, running: .. These boxes serve as frontend firewalls for all our projects/products, including a few high traffic ones. Hi Damien, I guess you wouldn't roll out a new release on all FreeBSD servers in one go. For most environments there is room to staging it, from test and developer boxes upwards to production. At the moment I am running FreeBSD 9 on some developer boxes, Nagios monitoring and others. It works without problems even if I am using VIMAGE which is still an experimental feature. Sooner or later I will install it on other more relevant production machines. Don't worry, it isn't that bad;-) If I can have one wish from the engineering team: please keep the schedule up to date. http://www.freebsd.org/releases/9.0R/schedule.html isn't showing the release yet, http://wiki.freebsd.org/Releng/9.0TODO was also quite behind. Maybe one web page is enough.. Thanks Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
Hi, On Friday 24 February 2012 04:21:12 Peter Maloney wrote: Am 23.02.2012 21:15, schrieb Mark Felder: On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot m...@my.gd wrote: Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. I suggest these concepts should be tested: I can tell you what in practical terms stops me from testing very often. The switch back to the running version. Let me suggest this. Currently, we have on the disk normally two kernels. The current one and the last one. Why not add a third one called testing? Add then an entry into the boot menu that users can switch between the current kernel and a kernel they just installed for testing. I know that I can do this manually. But this is the point where it becomes difficult for the majority of people. As FreeBSD needs a large amount of testing on unknown hardware, this could increase the number of actual testers without much effort. Ok, the developers must then be ready to deal with reports which miss many things. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
