Re: Upcoming release schedule - 8.4 ?
On 6/15/12 4:25 AM, Adrian Chadd wrote: Hi, 9 will mature as people use it and report bugs/regressions. It would be really great if you could try some of your workload on -9 and provide feedback and file PRs. Engaging with the community (and hiring developers :) is by far the best way to get things to mature quickly. 2c, Adrian I wholeheartedly agree, however the cheer number of problem reports I've seen on the ml when 9.0 came out really chilled me away. There are not many boxes I could try 9.0 on, because they're in production with pfsync to conserve client sessions and I'm loath to take risks with most of our firewalls. I'm thinking we might jump straight from 8.x to 10 when the time comes, I'm really looking forward to Gleb's work on CARP and PF ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
10.x will likely be more stable if 9.x gets stressed, and the bugs from there get fixed in -HEAD. I know this goes against what users expect, but as a software developer, QA is only as good as your testing and validation procedures. :) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On 2012-Jun-14 08:09:30 +0100, Chris Rees utis...@gmail.com wrote: Except STABLE is no good for production, and the problem is EoL- updates and support stop. There's nothing stopping you from from running -stable in production. Obviously, you will need to do more extensive testing than you might need to for a -release. As for EoL, all software goes EoL and support for that software stops. FreeBSD releases are typically supported for 4 years - IMO, that's excellent value for money. On 2012-Jun-14 12:48:19 +0100, Chris Rees utis...@gmail.com wrote: On Jun 14, 2012 9:30 AM, Damien Fleuriot m...@my.gd wrote: I've moved us to 8.3-STABLE recently and am quite happy with it, so far. Too strong wording perhaps; but you can't claim that an EOL stable branch will have the level of support afforded to live branches. That was supposed to be my point, as Mark has also explained. You are the only person that is claiming that 8.x is EOL. I have not seen any official announcement to that effect. The absence of an announcement of 8.4-release does not make it EOL. -- Peter Jeremy pgpxLxs9FqeLP.pgp Description: PGP signature
Re: Upcoming release schedule - 8.4 ?
On Fri, Jun 15, 2012 at 1:18 AM, Adrian Chadd adr...@freebsd.org wrote: 10.x will likely be more stable if 9.x gets stressed, and the bugs from there get fixed in -HEAD. I know this goes against what users expect, but as a software developer, QA is only as good as your testing and validation procedures. :) Being a realist (once again) most groups I've dealt with that have the resources to test their releases lag behind by CURRENT-2 major releases to avoid pushing unqualified code out on to customers. Not everyone is willing to bet on the bleeding edge of things, but this needs to change in order for things to move forward (this is something that my previous mentor at IronPort -- ambrisko@ -- encouraged for me to do and he exercised on a regular basis). The problem is time when it comes to pushing features forward to a newer OS release and testing them (IronPort used to do this, but no longer does as the individuals who used to do this left the group for other greener pastures). Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Fri, Jun 15, 2012 at 10:16:30AM +0200, Damien Fleuriot wrote: I'm thinking we might jump straight from 8.x to 10 when the time comes, I'm really looking forward to Gleb's work on CARP and PF ;) I don't know why you might think one .0 release would be more mature than another .0 release. Maybe I'm misunderstanding. There are not many boxes I could try 9.0 on, because they're in production with pfsync to conserve client sessions and I'm loath to take risks with most of our firewalls. This is where having one or more systems for development is key. Installations like yours are in a far better situation to test FreeBSD under realistic loads than are all but a few of the FreeBSD developers. I would urge testing long before the leadup to a .0 release, not afterwards. Apologies if I'm just repeating myself here, but FreeBSD does not have a dedicated QA department. We are reliant on our users to test in real- world conditions. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Jun 15, 2012 9:39 AM, Peter Jeremy pe...@rulingia.com wrote: On 2012-Jun-14 08:09:30 +0100, Chris Rees utis...@gmail.com wrote: Except STABLE is no good for production, and the problem is EoL- updates and support stop. There's nothing stopping you from from running -stable in production. Obviously, you will need to do more extensive testing than you might need to for a -release. As for EoL, all software goes EoL and support for that software stops. FreeBSD releases are typically supported for 4 years - IMO, that's excellent value for money. On 2012-Jun-14 12:48:19 +0100, Chris Rees utis...@gmail.com wrote: On Jun 14, 2012 9:30 AM, Damien Fleuriot m...@my.gd wrote: I've moved us to 8.3-STABLE recently and am quite happy with it, so far. Too strong wording perhaps; but you can't claim that an EOL stable branch will have the level of support afforded to live branches. That was supposed to be my point, as Mark has also explained. You are the only person that is claiming that 8.x is EOL. I have not seen any official announcement to that effect. The absence of an announcement of 8.4-release does not make it EOL. Of course not. The fear that this whole thread is about the possibility of EoL this year or soon; the OP wants support for longer. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On 6/15/12 10:52 AM, Mark Linimon wrote: On Fri, Jun 15, 2012 at 10:16:30AM +0200, Damien Fleuriot wrote: I'm thinking we might jump straight from 8.x to 10 when the time comes, I'm really looking forward to Gleb's work on CARP and PF ;) I don't know why you might think one .0 release would be more mature than another .0 release. Maybe I'm misunderstanding. 10.0 hasn't scared the hell out of me, yet, on the ml... :p There are not many boxes I could try 9.0 on, because they're in production with pfsync to conserve client sessions and I'm loath to take risks with most of our firewalls. This is where having one or more systems for development is key. My problem here is that the dev and preprod platforms are actively used by our devs, which means that it costs us money if we have an outage. I suppose I could try upgrading the backup box to 9.0 then swapping over to it. My main problem here is that we've got many machines to administer, on top of the network and security, and there's just me and myself that touch the firewalls. It always comes down to time being short... Installations like yours are in a far better situation to test FreeBSD under realistic loads than are all but a few of the FreeBSD developers. I would urge testing long before the leadup to a .0 release, not afterwards. I guess it couldn't hurt overmuch for me to test 9.0 on one of our projects, I could update 1 of the 4 boxes to 9.0 and make it carp master. If that goes well, 1-2 weeks later I could push 9.0 on another project which uses 4 *active* firewalls. This is a medium packet-rate [2][3] real life [1] project and could yield interesting results for you guys. @gleb Are there any counter indications against running 8-STABLE and 9-STABLE sets of firewalls with CARP and pfsync ? [1] Firewalls share 8 CARP IPs and are each master on 2 at a given time. Firewalls use VLAN tagging over a link aggregation interface. Firewalls use relayd to dynamically rdr packets to backend servers. [2] IRQs on broadcom NIC: # vmstat -i interrupt total rate irq9: acpi0 22 0 irq20: uhci3 20 0 irq21: uhci2 uhci4+ 25 0 cpu0: timer 2089687121 2000 irq256: bce033684311 32 irq257: bce1 8636578820 8266 [3] PF output: Status: Enabled for 12 days 02:10:48 Debug: Urgent Interface Stats for vlan20IPv4 IPv6 Bytes In5225964204350 Bytes Out 55365130031720 Packets In Passed 48930005750 Blocked 1449678030 Packets Out Passed 60052575430 Blocked 4783780 State Table Total Rate current entries16556 searches 2264698647621679.1/s inserts 1368370473 1309.9/s removals 1368353917 1309.9/s Counters match 1650605688 1580.1/s ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
So what , this fell on deaf ears or was it a horridly bad idea ? Anyone care to share ? On Thu, Jun 14, 2012 at 5:12 PM, Mark Saad nones...@longcount.org wrote: All I have an partial solution to this issue I was thinking about this on my morning train ride, so its a bit bumpy. Here are my solutions they are not complete but I think its a good start. 1. When official errata and security updates hit the tree . Providing updated install media could be step one . Maybe rebuild install media periodical say every 3 months, if it warrants it. 2. Change FreeBSD-update to allow you to select what updates you want, and make it work for stable. Simply put think freebsd-update fetch stable kernel or freebsd-update fetch release base 3. Change FreeBSD-update to tweak a library so the -pN level is not hardcoded into the kernel at compile time. Currently FreeBSD's patch or p level -pN is a newvers.sh function . 4. Publish a longer time line for future releases and make it easier to find. While ken smith's email about the 9.1-RELEASE time line was a good start , for 9.1,I feel that a short general time line on http://www.freebsd.org/releases/ would do a world of good for people want to know whats up next and when can I expect it. It does not need to be exact just a rough estimate. The sum total of all of this , in my eyes, is when updated drivers ( I know its a still a wish and not reality ) , bug fixes , security updates are released , new installs done around that time will start out with all of the good bits. Secondly when new updates are released users can apply base updates and kernel updates to both release and stable as needed. Lastly updates released via this new method would be easily checked via uname -a or maybe freebsd-update show version Fire away. --- Mark Saad | mark.s...@longcount.org -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 10:25 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, 9 will mature as people use it and report bugs/regressions. It would be really great if you could try some of your workload on -9 and provide feedback and file PRs. Engaging with the community (and hiring developers :) is by far the best way to get things to mature quickly. As an aside, its more projects like this that need to happen: http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068129.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
The suggestions are all good, but they require volunteers to volunteer more of their time (for free, hence volunteering) to maintain longer branches; it requires more resources from volunteer mirrors (for free, hence volunteer) to store even more ports and CD-ROM ISO snapshots. What we as a community need is more people standing up and taking these jobs on. No-one will complain if you decide to tackle, say, the ISO snapshots based on security releases. But you'd then have to do all of the QA that goes into generating the release, building the ports, doing some tests to make sure there aren't any glaring gotchas, asking users to test out your pre-.0 release image (and they don't, then complain when .0 didn't work), etc, etc. So please, if you can step up, take ownership and start attacking these issues, we'll embrace you with open arms. :) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . This is really starting to get philosophical and away from the original intent behind the original post, but given past discussions and the fact that these topics end up going around in circles/cycling through periodically (I've seen it on ports, current/stable/hackers, etc), here's my perspective after having read these discussions a few times and given what I've seen with the project over the last 5-10 years (granted, I've become a jaded realistic/pessimist in past years, so YMMV): Problem Statement (or the I want to have my cake and eat it too Issue): - Users want stability, but want latest and greatest driver code and features. These are [generally] mutually exclusive. Impedance: - There aren't enough volunteer resources to do what consumers of FreeBSD want beyond what's being done, with exception of developers and other volunteers going above and beyond in extraordinary circumstances to get the job done, or doing something his/her day job requires. The former case tends to be more of the exception than the norm. The latter happens sporadically. - There are plenty of companies out there wanting to solve this problem of release cycles, but no one group (or groups) is standing up and actively ponying up dedicated resources on a regular basis to make this a reality. What happens: Trivial tasks, like MFCing, testing, triaging, etc are being done by lead developers in a particular domain, which steals cycles from enhancement/bugfixing work in those areas [or other surrounding areas]; instead of investing time writing regression tests so others can do the work, no one other than the lead developers in a given area can do the work if it requires domain knowledge and/or specific hardware resources to complete the task. Eventually something happens, the developer becomes less active in the community (gets a family, no longer does FreeBSD work, gets a job, number of different things), and depending on the bus factor the particular area being maintained may remain unmaintained for some time. Alternatively, contact is done infrequently enough that interested parties willing to contribute code get discouraged and go off and do their own thing (be it support their own custom distro, switch to another OS, etc). In the former case, there's duplication of effort, some (or most) of which is
Re: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
Resending to list, forgot to hit reply-all. On Wed, Jun 13, 2012 at 10:06 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. [snip] Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). [my wishlist snipped] No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . Catch-22. This honestly reads as we can't stop for gas, we're already late. :-) I should have been more clear that I understand that this would require someone to step away from the firehose of work that not having such tools perpetuates. I certainly understand that it requires an effort of will to raise one's head high enough out of the lists/PRs/email swamp long enough, shake off some learned helplessness, and be inspired to tackle one of them. I struggle with that daily myself. There's a Not Invented Here comic strip that is quite applicable: http://notinventedhe.re/on/2010-3-8 [good Garrett summary of the resource problem snipped] So, rather than do things this way by posting wishlist projects that won't happen in the immediate future, why not make developers' lives easier by spreading the load, increasing the domain knowledge in one or more areas, and improving the community in the meantime? Affected companies/the Foundation should have more than enough funds to devote towards a handful of staff to make this a reality, even if the position is part-time. Remember: low hanging fruit - more likely to succeed - quicker/better RoI results. Even one item from my wish list would lower the branches so that more people could reach the fruit. :-) The objections you're raising to my wish list could have been used, in the past, to justify anything from not writing send-pr (which was somewhat low-hanging fruit) to not writing freebsd-update (decidedly less trivial). Not all of my wishlist items require Herculean effort to make progress on. They just require someone who can both code, and see the light at the end of the tunnel that such a project would reveal. It's the never-ending chronic pain and whack-a-mole game of troubleshooting that makes us frame these things as wishes. If we take as an assumption that they're within reach, they might be. It calls to mind the last lines of Say Anything (if I may indulge my John Cusack fanboyhood): Diane Court: Nobody thinks it will work, do they? Lloyd Dobler: No. You just described every great success story. Royce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, Jun 13, 2012 at 11:06:15PM -0700, Garrett Cooper wrote: On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . This is really starting to get philosophical and away from the original intent behind the original post, but given past discussions and the fact that these topics end up going around in circles/cycling through periodically (I've seen it on ports, current/stable/hackers, etc), here's my perspective after having read these discussions a few times and given what I've seen with the project over the last 5-10 years (granted, I've become a jaded realistic/pessimist in past years, so YMMV): Problem Statement (or the I want to have my cake and eat it too Issue): - Users want stability, but want latest and greatest driver code and features. These are [generally] mutually exclusive. Impedance: - There aren't enough volunteer resources to do what consumers of FreeBSD want beyond what's being done, with exception of developers and other volunteers going above and beyond in extraordinary circumstances to get the job done, or doing something his/her day job requires. The former case tends to be more of the exception than the norm. The latter happens sporadically. - There are plenty of companies out there wanting to solve this problem of release cycles, but no one group (or groups) is standing up and actively ponying up dedicated resources on a regular basis to make this a reality. What happens: Trivial tasks, like MFCing, testing, triaging, etc are being done by lead developers in a particular domain, which steals cycles from enhancement/bugfixing work in those areas [or other surrounding areas]; instead of investing time writing regression tests so others can do the work, no one other than the lead developers in a given area can do the work if it requires domain knowledge and/or specific hardware resources to complete the task. Eventually something happens, the developer becomes less active in the community (gets a family, no longer does FreeBSD work, gets a job, number of different things), and depending on the bus factor the particular area being maintained may remain unmaintained for some time. Alternatively, contact is done infrequently enough that interested parties willing to contribute code get discouraged and go off
Re: Upcoming release schedule - 8.4 ?
On Jun 14, 2012 5:52 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) Except STABLE is no good for production, and the problem is EoL- updates and support stop. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On 6/14/12 9:09 AM, Chris Rees wrote: On Jun 14, 2012 5:52 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) Except STABLE is no good for production, and the problem is EoL- updates and support stop. Chris Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). I've moved us to 8.3-STABLE recently and am quite happy with it, so far. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 06:50:34AM +0200, Wojciech Puchar wrote: does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) The difference is the freeze-and-test work that goes between random date and release time. This requires a nontrivial time committment from both developers and users. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Jun 14, 2012 9:30 AM, Damien Fleuriot m...@my.gd wrote: On 6/14/12 9:09 AM, Chris Rees wrote: On Jun 14, 2012 5:52 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) Except STABLE is no good for production, and the problem is EoL- updates and support stop. Chris Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). I've moved us to 8.3-STABLE recently and am quite happy with it, so far. Too strong wording perhaps; but you can't claim that an EOL stable branch will have the level of support afforded to live branches. That was supposed to be my point, as Mark has also explained. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Wed, 13 Jun 2012 16:49:18 -0500, Damien Fleuriot m...@my.gd wrote: I for one, as a fbsd admin on corporate servers ( read not commiter), would dearly like less releases but a more aggressive MFC approach. Less releases such as less frequent MAJOR releases (7.0, 8.0, 9.0...) or less MINOR releases as well? (8.4, 8.5, 9.1...) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Thursday, June 14, 2012 12:30:19 am Adrian Chadd wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. This is why I think we need fewer branches so that there is less merging to do. Even in the bad old 4.x days developers would merge things (especially driver updates) from HEAD back to 4.x. If we move X.0 releases farther apart then developers will still MFC things, the issue is that they don't want to MFC to 2 stable branches. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 08:20:02AM -0400, John Baldwin wrote: On Thursday, June 14, 2012 12:30:19 am Adrian Chadd wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. This is why I think we need fewer branches so that there is less merging to do. Even in the bad old 4.x days developers would merge things (especially driver updates) from HEAD back to 4.x. If we move X.0 releases farther apart then developers will still MFC things, the issue is that they don't want to MFC to 2 stable branches. I do not find it cumbersome to merge to two branches. What I find quite demotivating is the conflicts and drifted KPI/API. So my usual reaction to the attempt to merge to stable/8 which fails due to conflicts is just remove the MFC reminder. I do sometimes reconsider the choice if explicitely asked by somebody, but I really prefer to not do risky commits to old and presumably stable branches. I do not have much incentive to merge to 8 anyway, except a warm feeling of providing some relief to a peer. So having long-living stable/8 and not having stable/9 means not doing some merges at all, instead of doing just one merge. YMMV. pgp7HnmeiFCiv.pgp Description: PGP signature
Re: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 10:29:22AM +0200, Damien Fleuriot wrote: Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). In theory we try our best to keep -STABLE, well, stable in behavior and not just the API, but in practice any given snapshot of -stable may or may not have uncaught regressions in it. I reiterate, the major difference between -stable and -release is a more thorough QA process for the latter :-) mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) Except STABLE is no good for production, and the problem is EoL- updates and support stop. using RELENG_8 everywhere except my private laptop with 9. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). I've moved us to 8.3-STABLE recently and am quite happy with it, so far. as most people do who needs FreeBSD to perform crucial work. FreeBSD 9 is an improvement but still i would not classify it as stable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, 13 Jun 2012 23:06:15 -0700 Garrett Cooper yaneg...@gmail.com wrote: On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). There's a GSoC project underway for this. - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . We have the ideas list for this (http://wiki.freebsd.org/IdeasPage). While it does not attract that much people during the year, it attracts a lot of students which want to participate in the GSoC. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, 13 Jun 2012 22:32:08 -0800 Royce Williams royce.willi...@gmail.com wrote: Even one item from my wish list would lower the branches so that more people could reach the fruit. :-) Well... maybe this year for the crashdump auto-submit part. For the rest I suggest to provide some text suitable for the ideas list (see my other reply). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
All I have an partial solution to this issue I was thinking about this on my morning train ride, so its a bit bumpy. Here are my solutions they are not complete but I think its a good start. 1. When official errata and security updates hit the tree . Providing updated install media could be step one . Maybe rebuild install media periodical say every 3 months, if it warrants it. 2. Change FreeBSD-update to allow you to select what updates you want, and make it work for stable. Simply put think freebsd-update fetch stable kernel or freebsd-update fetch release base 3. Change FreeBSD-update to tweak a library so the -pN level is not hardcoded into the kernel at compile time. Currently FreeBSD's patch or p level -pN is a newvers.sh function . 4. Publish a longer time line for future releases and make it easier to find. While ken smith's email about the 9.1-RELEASE time line was a good start , for 9.1,I feel that a short general time line on http://www.freebsd.org/releases/ would do a world of good for people want to know whats up next and when can I expect it. It does not need to be exact just a rough estimate. The sum total of all of this , in my eyes, is when updated drivers ( I know its a still a wish and not reality ) , bug fixes , security updates are released , new installs done around that time will start out with all of the good bits. Secondly when new updates are released users can apply base updates and kernel updates to both release and stable as needed. Lastly updates released via this new method would be easily checked via uname -a or maybe freebsd-update show version Fire away. --- Mark Saad | mark.s...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On 14 Jun 2012, at 15:13, Mark Felder f...@feld.me wrote: On Wed, 13 Jun 2012 16:49:18 -0500, Damien Fleuriot m...@my.gd wrote: I for one, as a fbsd admin on corporate servers ( read not commiter), would dearly like less releases but a more aggressive MFC approach. Less releases such as less frequent MAJOR releases (7.0, 8.0, 9.0...) or less MINOR releases as well? (8.4, 8.5, 9.1...) Less major, I don't mind minor ones as much to be honest. I welcomed 8.3 with open arms, I'm steering clear of 9.x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On 14 Jun 2012, at 16:41, Mark Linimon lini...@lonesome.com wrote: On Thu, Jun 14, 2012 at 10:29:22AM +0200, Damien Fleuriot wrote: Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). In theory we try our best to keep -STABLE, well, stable in behavior and not just the API, but in practice any given snapshot of -stable may or may not have uncaught regressions in it. I reiterate, the major difference between -stable and -release is a more thorough QA process for the latter :-) mcl We're indeed pretty happy with 8-STABLE :) We're ready to take the risk of a regression if the update squashes a bug that's a major PITA Thanks for your work on the project guys___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
Hi, 9 will mature as people use it and report bugs/regressions. It would be really great if you could try some of your workload on -9 and provide feedback and file PRs. Engaging with the community (and hiring developers :) is by far the best way to get things to mature quickly. 2c, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Tuesday, June 12, 2012 8:01:00 pm Adrian Chadd wrote: hi, You don't need to change the FreeBSD culture. We'd love to do an 8.4 release. And an 8.5 release, and 8.6 release, etc. The problem is one of resources and time, not of culture/desire. I disagree. The pace of X.0 releases is a deliberate choice FreeBSD has made and directly impacts the number of live branches in existence. Given our developer base, we can't really support 3 branches concurrently (head + 2 stable like we have now with head, 9, and 8). Having longer lived stable branches requires either increasing resources to support exising releases longer, or slowing the pace of X.0 releases (but more aggressively merging things from HEAD back). The latter case, especially, is part of the culture and would be a choice we as a Project would have to make. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Wed, Jun 13, 2012 at 5:53 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday, June 12, 2012 8:01:00 pm Adrian Chadd wrote:
hi,
You don't need to change the FreeBSD culture. We'd love to do an 8.4
release. And an 8.5 release, and 8.6 release, etc. The problem is one
of resources and time, not of culture/desire.
I disagree. The pace of X.0 releases is a deliberate choice FreeBSD
has made and directly impacts the number of live branches in existence.
Given our developer base, we can't really support 3 branches concurrently
(head + 2 stable like we have now with head, 9, and 8). Having longer lived
stable branches requires either increasing resources to support exising
releases longer, or slowing the pace of X.0 releases (but more aggressively
merging things from HEAD back). The latter case, especially, is part of
the culture and would be a choice we as a Project would have to make.
The only way that this would really work is if there were
dedicated sustaining engineers working on actively backporting code,
testing it, committing it, etc as the current paradigm requires the
developer (or another stand-in developer in the event that the
original developer failed to MFC the code) to do the work (which is
sort of what the OP is doing in this case, and what I've seen a few
different groups do that don't run bleeding edge code). That concept
doesn't really exist today. Maybe this would be a good idea for
improving the longevity of release cycles and maybe that's what
ultimately needs to be done as it would reduce distractions on
developers actively churning away on {[CURRENT-1],}[CURRENT], and
maybe that's what should be proposed.
As good as BSDi was from what I hear, that business model alone
won't probably work as many people take the support piece (companies
that just want the software and might develop/support apps/services on
top of it) and the longevity piece (companies that develop with/on the
software as a product) separately. They're typically (but not always)
mutually exclusive from what I've seen in my limited experience.
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On 13 June 2012 05:53, John Baldwin j...@freebsd.org wrote: You don't need to change the FreeBSD culture. We'd love to do an 8.4 release. And an 8.5 release, and 8.6 release, etc. The problem is one of resources and time, not of culture/desire. I disagree. The pace of X.0 releases is a deliberate choice FreeBSD has made and directly impacts the number of live branches in existence. Given our developer base, we can't really support 3 branches concurrently (head + 2 stable like we have now with head, 9, and 8). Having longer lived stable branches requires either increasing resources to support exising releases longer, or slowing the pace of X.0 releases (but more aggressively merging things from HEAD back). The latter case, especially, is part of the culture and would be a choice we as a Project would have to make. Right, but I don't think the freebsd project would really mind or change much if more people came on board to handle legacy releases and support them. If you're a company that uses FreeBSD stable releases, please consider contributing engineering resources and/or donations to the Foundation to improve the support of said stable releases. :) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Wednesday, June 13, 2012 11:52:28 am Adrian Chadd wrote: On 13 June 2012 05:53, John Baldwin j...@freebsd.org wrote: You don't need to change the FreeBSD culture. We'd love to do an 8.4 release. And an 8.5 release, and 8.6 release, etc. The problem is one of resources and time, not of culture/desire. I disagree. The pace of X.0 releases is a deliberate choice FreeBSD has made and directly impacts the number of live branches in existence. Given our developer base, we can't really support 3 branches concurrently (head + 2 stable like we have now with head, 9, and 8). Having longer lived stable branches requires either increasing resources to support exising releases longer, or slowing the pace of X.0 releases (but more aggressively merging things from HEAD back). The latter case, especially, is part of the culture and would be a choice we as a Project would have to make. Right, but I don't think the freebsd project would really mind or change much if more people came on board to handle legacy releases and support them. If you're a company that uses FreeBSD stable releases, please consider contributing engineering resources and/or donations to the Foundation to improve the support of said stable releases. :) No, that doesn't actually work. Having additional support on a stable branch requires someone able to 1) commit changes to stable branches and 2) be able to cut newer releases from said branches (i.e. doing the work of re@). You cannot get that as an outside entity. It requires buy-in from the Project itself. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
Hey, I'm a Desktop User and I wish FreeBSD v8.3 worked for me. I can't get a Dialup Internet Connection without setting up a complicated script. And my Porn Videos crash halfway through. Yours frustratedly: Frank Mitchell On Wednesday 13 June 2012 00:08:08 Jerry McAllister wrote: Well, 8.3 is working fine for me. It is being well maintained. You sound like the people who can't decide to get something because a new version is going to come out sometime before they die. jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
I'll share my 2 cents here, as someone who maintains a decent sided FreeBSD install. 1. FreeBSD needs to make end users more comfortable with using a Dot-Ohh release; and at the time of the dot-ohh release a timeline for the next point releases should be made. * 2. Having three supported releases is showing issues , and brings up the point of why was 9.0 not released as 8.3 ? ** 3. The end users appear to want less releases, and for them to be supported longer . * A rough outline would do and it should be on the main release page http://www.freebsd.org/releases/ ** Yes I understand that 9.0 had tons of new features that were added and its not exactly a point release upgrade from 8.2 , however one can argue that if it were there would be less yelling about when version X is going to be EOL'd and when will version Y be released. -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On 13 Jun 2012, at 19:27, John Baldwin j...@freebsd.org wrote: On Wednesday, June 13, 2012 11:52:28 am Adrian Chadd wrote: On 13 June 2012 05:53, John Baldwin j...@freebsd.org wrote: You don't need to change the FreeBSD culture. We'd love to do an 8.4 release. And an 8.5 release, and 8.6 release, etc. The problem is one of resources and time, not of culture/desire. I disagree. The pace of X.0 releases is a deliberate choice FreeBSD has made and directly impacts the number of live branches in existence. Given our developer base, we can't really support 3 branches concurrently (head + 2 stable like we have now with head, 9, and 8). Having longer lived stable branches requires either increasing resources to support exising releases longer, or slowing the pace of X.0 releases (but more aggressively merging things from HEAD back). The latter case, especially, is part of the culture and would be a choice we as a Project would have to make. Right, but I don't think the freebsd project would really mind or change much if more people came on board to handle legacy releases and support them. If you're a company that uses FreeBSD stable releases, please consider contributing engineering resources and/or donations to the Foundation to improve the support of said stable releases. :) No, that doesn't actually work. Having additional support on a stable branch requires someone able to 1) commit changes to stable branches and 2) be able to cut newer releases from said branches (i.e. doing the work of re@). You cannot get that as an outside entity. It requires buy-in from the Project itself. Jumping in. I for one, as a fbsd admin on corporate servers ( read not commiter), would dearly like less releases but a more aggressive MFC approach. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
Mark Saad wrote: I'll share my 2 cents here, as someone who maintains a decent sided FreeBSD install. 1. FreeBSD needs to make end users more comfortable with using a Dot-Ohh release; and at the time of the dot-ohh release a timeline for the next point releases should be made. * 2. Having three supported releases is showing issues , and brings up the point of why was 9.0 not released as 8.3 ? ** 3. The end users appear to want less releases, and for them to be supported longer . * A rough outline would do and it should be on the main release page http://www.freebsd.org/releases/ ** Yes I understand that 9.0 had tons of new features that were added and its not exactly a point release upgrade from 8.2 , however one can argue that if it were there would be less yelling about when version X is going to be EOL'd and when will version Y be released. One thought here might be to revisit the Kernel APIs can only change on a major release rule. It seems to me that some KPIs could be frozen for longer periods than others, maybe? For example: - If device driver KPIs were frozen for a longer period of time, there wouldn't be the challenge of backporting drivers for newer hardware to the older systems. vs - The VFS/VOP interface. As far as I know, there are currently 2 out of source tree file systems (OpenAFS and FUSE) and there are FreeBSD committers involved in both of these. As such, making a VFS change within a minor release cycle might not be a big problem, so long as all the file systems in the source tree are fixed and the maintainers for the above 2 file systems were aware of the change and when they needed to release a patch/rebuild their module. - Similarily, are there any out of source tree network stacks? It seems that this rule is where the controversy of major vs minor release changes comes in? Just a thought, rick -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Upcoming release schedule - 8.4 ?
Realized my earlier related post was a bit misplaced in questions@. So I just refer to it here by link, ok then that is all. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=968504+0+current/freebsd-questions ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. Royce [1]. http://lists.freebsd.org/pipermail/freebsd-doc/2011-September/018865.html [2]. http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037310.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Mon, Jun 11, 2012 at 08:16:45PM -0500, Mark Linimon wrote: On Mon, Jun 11, 2012 at 03:38:56PM -0700, John Kozubik wrote: I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Although I am not on re@, AFAIK the only schedule that is on the table is the one for 9.1. Release 8.3 (April 2012) has it really been 6 months yet! -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Tue, 12 Jun 2012, Jason Hellenthal wrote: I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Although I am not on re@, AFAIK the only schedule that is on the table is the one for 9.1. Release 8.3 (April 2012) has it really been 6 months yet! We (rsync.net) are deploying our new ZFS based platform on FreeBSD. This is a platform that needs to be live in just a few weeks.[1] We only run release software. Further, I don't think anyone will fault us for steering clear of 9.0-RELEASE. 9.1 is probably four months away. So our choices are 8, which has no roadmap, and 9 which doesn't exist. On the one hand, we've made this choice before, when we invested hundreds of thousands of dollars into equipment, code, training, etc. for 6.4. We've successfully amortized this investment over the past 4-5 years, but not without a lot of pain. The past 24 months has been a lot of custom work, backporting drivers, etc. We don't want to repeat this. On the other hand, we're not going to debut a new platform, to customers all over the world, on 9.0. So ... how about a kickstarter, since that's all the rage ? What would a reasonable total be, donated to the FreeBSD foundation, that would ensure the maintenance of the 8.x branch for another 3 years (say, Dec 31, 2015) and out to (to pick an arbitrary number) 8.10 ? Just a thought ... [1] After years of evaluation and testing, spanning 6.x - 8.x. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Tue, Jun 12, 2012 at 11:40 AM, John Kozubik j...@kozubik.com wrote: On Tue, 12 Jun 2012, Jason Hellenthal wrote: I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Although I am not on re@, AFAIK the only schedule that is on the table is the one for 9.1. Release 8.3 (April 2012) has it really been 6 months yet! We (rsync.net) are deploying our new ZFS based platform on FreeBSD. This is a platform that needs to be live in just a few weeks.[1] We only run release software. Further, I don't think anyone will fault us for steering clear of 9.0-RELEASE. 9.1 is probably four months away. So our choices are 8, which has no roadmap, and 9 which doesn't exist. On the one hand, we've made this choice before, when we invested hundreds of thousands of dollars into equipment, code, training, etc. for 6.4. We've successfully amortized this investment over the past 4-5 years, but not without a lot of pain. The past 24 months has been a lot of custom work, backporting drivers, etc. We don't want to repeat this. On the other hand, we're not going to debut a new platform, to customers all over the world, on 9.0. So ... how about a kickstarter, since that's all the rage ? What would a reasonable total be, donated to the FreeBSD foundation, that would ensure the maintenance of the 8.x branch for another 3 years (say, Dec 31, 2015) and out to (to pick an arbitrary number) 8.10 ? Just a thought ... [1] After years of evaluation and testing, spanning 6.x - 8.x. Hey John, So, we've (iXsystems, PC-BSD) been kicking around the idea of a Long Term Supported version of PC-BSD Server, which is really FreeBSD with some PC-BSD cli tools and perhaps maintaining our own binary update server. While we were thinking of doing this with 9.1, we can consider 8.x. I'll speak with Kris Moore and the rest of the team and find out what it will take. We've hired a contract release engineer with this task in mind but you're right, most of the work will be in backporting. I like the idea of coming up with a number it would take and a plan to do it. We're not the only people with the problem, obviously. Cheers, -matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
Hi Matt, On Tue, 12 Jun 2012, Matt Olander wrote: So, we've (iXsystems, PC-BSD) been kicking around the idea of a Long Term Supported version of PC-BSD Server, which is really FreeBSD with some PC-BSD cli tools and perhaps maintaining our own binary update server. While we were thinking of doing this with 9.1, we can consider 8.x. I'll speak with Kris Moore and the rest of the team and find out what it will take. We've hired a contract release engineer with this task in mind but you're right, most of the work will be in backporting. I like the idea of coming up with a number it would take and a plan to do it. We're not the only people with the problem, obviously. As a last resort, I would be interested in this, but I'm more interested in changing the culture of FreeBSD releases and long-term support in general. I think that: a) there are a lot more people out there, that we never hear from, that have these same problems, and another 4.x style release would really help them. b) there are a lot of people out there that could be drawn into the FreeBSD ecosystem if another 4.x style release existed. I would much rather donate $10k to a $100k kickstarter and have this be official than set aside $10k privately for unofficial maintenance, or a fork. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Tue, Jun 12, 2012 at 3:52 PM, John Kozubik j...@kozubik.com wrote: Hi Matt, On Tue, 12 Jun 2012, Matt Olander wrote: So, we've (iXsystems, PC-BSD) been kicking around the idea of a Long Term Supported version of PC-BSD Server, which is really FreeBSD with some PC-BSD cli tools and perhaps maintaining our own binary update server. While we were thinking of doing this with 9.1, we can consider 8.x. I'll speak with Kris Moore and the rest of the team and find out what it will take. We've hired a contract release engineer with this task in mind but you're right, most of the work will be in backporting. I like the idea of coming up with a number it would take and a plan to do it. We're not the only people with the problem, obviously. As a last resort, I would be interested in this, but I'm more interested in changing the culture of FreeBSD releases and long-term support in general. I think that: a) there are a lot more people out there, that we never hear from, that have these same problems, and another 4.x style release would really help them. b) there are a lot of people out there that could be drawn into the FreeBSD ecosystem if another 4.x style release existed. I would much rather donate $10k to a $100k kickstarter and have this be official than set aside $10k privately for unofficial maintenance, or a fork. I understand your position, John. FYI, PC-BSD is not a fork of FreeBSD. We have someone on re@ as well as security@ and several src and ports committers. We would backport to the official branch as necessary, since that's what we use to release PC-BSD. It's really irrelevant to me who manages the money. I'm just not sure we can start with 8.x rather than 9.x. However, this is pretty much the FreeBSD way. If we want something to change, we affect the change with our efforts. -matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Tue, Jun 12, 2012 at 4:20 PM, Matt Olander m...@ixsystems.com wrote: On Tue, Jun 12, 2012 at 3:52 PM, John Kozubik j...@kozubik.com wrote: Hi Matt, On Tue, 12 Jun 2012, Matt Olander wrote: So, we've (iXsystems, PC-BSD) been kicking around the idea of a Long Term Supported version of PC-BSD Server, which is really FreeBSD with some PC-BSD cli tools and perhaps maintaining our own binary update server. While we were thinking of doing this with 9.1, we can consider 8.x. I'll speak with Kris Moore and the rest of the team and find out what it will take. We've hired a contract release engineer with this task in mind but you're right, most of the work will be in backporting. I like the idea of coming up with a number it would take and a plan to do it. We're not the only people with the problem, obviously. As a last resort, I would be interested in this, but I'm more interested in changing the culture of FreeBSD releases and long-term support in general. I think that: a) there are a lot more people out there, that we never hear from, that have these same problems, and another 4.x style release would really help them. b) there are a lot of people out there that could be drawn into the FreeBSD ecosystem if another 4.x style release existed. I would much rather donate $10k to a $100k kickstarter and have this be official than set aside $10k privately for unofficial maintenance, or a fork. I understand your position, John. FYI, PC-BSD is not a fork of FreeBSD. We have someone on re@ as well as security@ and several src and ports committers. We would backport to the official branch as necessary, since that's what we use to release PC-BSD. It's really irrelevant to me who manages the money. I'm just not sure we can start with 8.x rather than 9.x. However, this is pretty much the FreeBSD way. If we want something to change, we affect the change with our efforts. *looping in the FreeBSD Foundation Board of Directors* As John has suggested, if we come up with some requirements and vote with our wallets, perhaps the Foundation can look into bringing on a couple of people full time to assist with release engineering for a Long-Term Supported release. -matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Tue, Jun 12, 2012 at 11:40:48AM -0700, John Kozubik wrote: On Tue, 12 Jun 2012, Jason Hellenthal wrote: I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Although I am not on re@, AFAIK the only schedule that is on the table is the one for 9.1. Release 8.3 (April 2012) has it really been 6 months yet! We (rsync.net) are deploying our new ZFS based platform on FreeBSD. This is a platform that needs to be live in just a few weeks.[1] We only run release software. Further, I don't think anyone will fault us for steering clear of 9.0-RELEASE. 9.1 is probably four months away. So our choices are 8, which has no roadmap, and 9 which doesn't exist. Well, 8.3 is working fine for me. It is being well maintained. You sound like the people who can't decide to get something because a new version is going to come out sometime before they die. jerry On the one hand, we've made this choice before, when we invested hundreds of thousands of dollars into equipment, code, training, etc. for 6.4. We've successfully amortized this investment over the past 4-5 years, but not without a lot of pain. The past 24 months has been a lot of custom work, backporting drivers, etc. We don't want to repeat this. On the other hand, we're not going to debut a new platform, to customers all over the world, on 9.0. So ... how about a kickstarter, since that's all the rage ? What would a reasonable total be, donated to the FreeBSD foundation, that would ensure the maintenance of the 8.x branch for another 3 years (say, Dec 31, 2015) and out to (to pick an arbitrary number) 8.10 ? Just a thought ... [1] After years of evaluation and testing, spanning 6.x - 8.x. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
hi, You don't need to change the FreeBSD culture. We'd love to do an 8.4 release. And an 8.5 release, and 8.6 release, etc. The problem is one of resources and time, not of culture/desire. It takes a lot of (volunteer) effort and a lot of (donated) resources to do what we do with releases and release management. Are any of the release team actually working for a company that uses FreeBSD releases, and thus has a vested interest in getting them out the door and supported? That's what needs to be changed. A kickstarter style project would be great, but people can also donate directly to the foundation. It'd be great if there wre more people, time and resources available to do this. But the overlap of companies that want more/longer releases done and supported doesn't seem to overlap that great with the number of people actively doing FreeBSD release management. 2c, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Tue, Jun 12, 2012 at 07:08:08PM -0400, Jerry McAllister wrote: You sound like the people who can't decide to get something because a new version is going to come out sometime before they die. That may be how it seems to end-users, but as we have heard multiple times from people who use FreeBSD to help run their businesses, information about scheduling and support of releases is key to their decisions on when to upgrade, or even whether to use FreeBSD in the first place. To them, your characterization is going to sound quite unfair. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Upcoming release schedule - 8.4 ?
Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Mon, Jun 11, 2012 at 03:38:56PM -0700, John Kozubik wrote: I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Although I am not on re@, AFAIK the only schedule that is on the table is the one for 9.1. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
