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.
On Thu, Feb 23, 2012 at 10:25, Damien Fleuriot <ml@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
On Thu, 23 Feb 2012 19:25:01 +0100 Damien Fleuriot <ml@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
On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot <ml@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.
> 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
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
Hi Damien, On Fri, Feb 24, 2012 at 5:25 AM, Damien Fleuriot <ml@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
-----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 <ml@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-----
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 outWhat 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 somewhereYou 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
-----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-----
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
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 RELEASEAs 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