Re: FreeBSD has serious problems with focus, longevity, and lifecycle
John's trying to manage risk. Switching from RELEASE to CURRENT adds a lot of risk and churn, when most folks in this class of use case just need a few very specific drivers and bugfixes (what some OSes call hotfixes.) John sounds willing to trade a little bit of local risk (and testing time) in exchange for a way to self-serve a hotfix without abandoning RELEASE. How can we enable that? There are simple cases -- the ones that just need a few files and a kernel module -- that seem within easy reach. For example, the eRacks guys generated these handy binaries for mps(4) for 7.4, 8.0, 8.1 and 8.2: http://blog.eracks.com/2011/08/lsi-logic-6gbps-mps-driver-for-freebsd-8-2-release/ For me, this was perfect: I got to have my cake (tracking 8.1-RELEASE, and using freebsd-update) and eat it too (support for specific newer hardware). If security updates break my mps(4), I'm on my own -- but it's still a much better balance of risk for me than switching to CURRENT. I know that some fixes are harder than just adding a kernel module. I know that the standards for releasing errata are high, and they should be. But I wish there was a way to optionally lower that threshold and say: Yes, I know this might eat my data. Let me judge and test that for myself without otherwise abandoning RELEASE. If there was a way to mark hotfixes as worked for me (to let the better ones bubble up to the top), we non-coders could even help manage the list. I can't do it myself, but I would happily help brainstorm, test -- and commit $100 or more, Kickstarter-style, to fund someone else's work. 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/16/12 11:28 PM, John Kozubik wrote: Friends, I was disappointed to see that 8.3-RELEASE is now slated to come out in March of 2012. This will be ~13 months since 8.2-RELEASE and is typical of a trend towards longer gaps between minor releases. I also see that undercutting the current release before wide deployment and maturity is continuing. 7.0 came (barely) after 6.3, which was bad enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2. Finally, the culture of that's fixed in CURRENT or we built those changes into (insert next major release) continues to get worse. It's difficult to escape the notion that FreeBSD is becoming an operating system by, and for, FreeBSD developers. Wholeheartedly agree. I'm having an increasingly difficult time defending FreeBSD in our company against the advances of debian kfree which is much easier to maintain. Can we get back to the 4.x release style and, hopefully, see some 9.7, 9.8... ? Check this PR I opened some months ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=161123cat=kern It was planned for 9.0-RELEASE, there is no mention of 8.x That's just the kind of problem John raises here. I can't keep on defending FreeBSD when the minor fix to a major bug isn't backported, and only makes it to the next major version, 4 or 5 months from now. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
on 17/01/2012 00:28 John Kozubik said the following: we going to run RELEASE software ONLY My opinion: you've put yourself in a box that is not very compatible with the current FreeBSD release strategy. With your scale and restrictions you probably should just use the FreeBSD source and roll your own releases from a stable branch of interest (including testing, etc). Or have your own branch where you could cherry-pick interesting changes from any FreeBSD branches. Tools like e.g. git and mercurial make it easy. Of course, this strategy is not as easy as trying to persuade the rest of FreeBSD community/project/thing to change its ways, but perhaps a little bit more realistic. You can bond with similarly minded organizations to share costs/work/etc. It's a community-driven project after all. -- Andriy Gapon ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Mon, 16 Jan 2012, Yuri wrote: On 01/16/2012 17:03, Atom Smasher wrote: i bought myself a LENOVO T510 when it first came out, around early 2010. it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i STILL can't run xorg properly with it. linux has run fine with it since i opened the box. last i checked, freeBSD will be support this GPU in R9... or maybe R10...? The usual explanation for this is that FreeBSD is the server OS and doesn't need to worry about desktop-only hardware. (Not that I agree with such position.) I noticed that FreeBSD overall isn't too good for laptops (correct me if I am wrong). Even if Arrandale GPU worked, there is no working network manager in kde or gnome, able to find and setup WiFi networks without user typing anything. Also FreeBSD isn't able to enter (and come back from) the sleep mode. Also it can't stop the hard drives when the system is idle (last time I tried I got system crash). These make it very difficult to use FreeBSD on the laptops. Major usability issues. == so i guess that means that i'm tougher than a typical laptop user... and instead of making things easier, freeBSD is getting harder. thing is, when people don't play with freeBSD on laptops and desktops, then they grow up, get real jobs, and don't know much about it. if this keeps up, i'll cross a line where i just get more comfortable with linux and migrate my freeBSD servers to it. this is one of the areas where linux is doing well... people are playing with it, but in the process they're getting used to it and comfortable with it. from that background, they can install a linux based server without breaking a sweat. linux's ease of use and hardware support are seeding the next generation of FLOSS and *nix users... and most of them have never installed/used freeBSD. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - Don't suspect your friends - turn them in! -- Brazil ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
(answering out of order) On 16/01/2012 23:28, John Kozubik wrote: 2) Having two simultaneous production releases draws focus away from both of them, and keeps any release from ever truly maturing. This isn't how things work. The -CURRENT always has (and probably always had and always will have) the focus of developers. The releases are for many people simply a periodical annoyance due to freezes. In no way will reducing the number of production releases change this. As a volunteer effort, backports to stable branches only happen when 1) it's in the interest of the developer, e.g. I've found a bug on my systems, want to get it fixed in -STABLE and 2) when the developer is budged by outside forces (users complaining, other developers requesting it) and 3) they think it's worth doing and have time to do it spontaneously. These are in order of likelihood to happen. You could say the question is: why is it so, but I think you know the answer to that: small project, not enough manpower and volunteer-hours. However, the situation is actually quite good because the developers are usually very responsive to MFC requests... going to run RELEASE software ONLY 4) New code and fixes that people NEED TODAY just sits on the shelf for 8 or 10 or (nowadays) 13 months while end users wait for new minor releases. ... except if you expect regular releases :) I've concluded very early that because of what I've said above, the only way to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff usually try hard not to break things so -STABLE has become a sort of running RELEASE branch. Since -STABLE is so ... stable ..., there is less and less incentive to make proper releases (though I think nobody would mind it happening). The next question is: what do releases from a -STABLE branch bring in that simply tracking the original -STABLE tree doesn't? Lately, not very much. Since there is a huge number of users and developers tracking -STABLE, the testing done specifically for a X.Y, Y0 RELEASE is not very extensive, so you just as well could have tracked -STABLE. I'm sure you know how easy it is to upgrade a STABLE-running system, and there are simple ways in which that can be made to scale to thousands of machines. Breakage is of course a risk, but not significantly greater than for any other upgrading. of 2012, we should be on 6.12 (or so) and just breaking ground on 7.0. Instead, each release gets perhaps two years of focused development before every new fix is applied only to the upcoming release, and any kind of support or enthusiasm from the community just disappears. If you're saying that -STABLE branches don't get fixes fast enough, I'd disagree. A few years ago we were dying for new em(4) and twa(4) drivers in FreeBSD 6, but they were applied only to 7 and beyond, since that was the new production release (as opposed to the old production release). It's the same bad choice again: make major investments in testing and people and processes every two years, or just limp along with old, buggy drivers and no support. Have you tried contacting the developers of those drivers? The most likely causes the drivers weren't MFC-ed are either that they were experimental enough that it was feared for their stability or that they didn't think anyone needs drivers MFC-ed. The situation you describe is certainly not FreeBSD-specific: Debian is notoriously slow in adopting new features, but so is Red Hat Enterprise Linux, which had the ancient (2006 vintage) 2.6.18 kernel throughout its 5.x cycle (still active in 2011) - though updated with new drivers. Compared to these, FreeBSD is in many ways a pleasure to work with. Seriously, just think of -STABLE as a rolling release, just like the ports tree. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17/01/2012 07:20, John Kozubik wrote: as wonderful as ZFS on FreeBSD is (and we are deploying it this year) it is only now (well, in March) with 8.3 that I feel it is finally safe and stable enough to bet the farm on. I'm not the only one that feels this way. I must remember to ask you about your experiences with ZFS in about a year from now :) ___ 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: Processes' FIBs
Kostik Belousov kostik...@gmail.com wrote:
The patch misses compat32 bits and breaks compat32 ps/top.
Right, thank you for pointing it out! I missed it because
I only have i386 for testing.
I've created new patch sets for releng8 and current. These
include compat32 support and an entry for the manual page.
Would someone with amd64 please test the compat32 part?
I've been using this code on i386 for a few days without
any problems.
I've attached the patch for current below. Both patch sets
are also available from this URL:
http://www.secnetix.de/olli/tmp/ki_fibnum/
Testing is easy: Apply the patch, rebuild bin/ps and kernel.
Make sure that your kernel config has options ROUTETABLES=16
so multiple FIBs are supported. Reboot. Open a shell with
setfib, e.g. setfib 3 /bin/sh (no root required), type
ps -ax -o user,pid,fib,command or something similar, and
verify that the shell process and its children are listed
with the correct FIB. When testing on amd64, use both the
native ps and an i386 binary.
Thank you very much!
Best regards
Oliver
--- sys/sys/user.h.orig 2011-11-07 22:13:19.0 +0100
+++ sys/sys/user.h 2012-01-17 11:33:59.0 +0100
@@ -83,7 +83,7 @@
* it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and
* function kvm_proclist in lib/libkvm/kvm_proc.c .
*/
-#defineKI_NSPARE_INT 9
+#defineKI_NSPARE_INT 8
#defineKI_NSPARE_LONG 12
#defineKI_NSPARE_PTR 6
@@ -186,6 +186,7 @@
*/
charki_sparestrings[50];/* spare string space */
int ki_spareints[KI_NSPARE_INT];/* spare room for growth */
+ int ki_fibnum; /* Default FIB number */
u_int ki_cr_flags;/* Credential flags */
int ki_jid; /* Process jail ID */
int ki_numthreads; /* XXXKSE number of threads in total */
--- sys/kern/kern_proc.c.orig 2012-01-15 19:47:24.0 +0100
+++ sys/kern/kern_proc.c2012-01-17 12:52:36.0 +0100
@@ -836,6 +836,7 @@
kp-ki_swtime = (ticks - p-p_swtick) / hz;
kp-ki_pid = p-p_pid;
kp-ki_nice = p-p_nice;
+ kp-ki_fibnum = p-p_fibnum;
kp-ki_start = p-p_stats-p_start;
timevaladd(kp-ki_start, boottime);
PROC_SLOCK(p);
@@ -1121,6 +1122,7 @@
bcopy(ki-ki_comm, ki32-ki_comm, COMMLEN + 1);
bcopy(ki-ki_emul, ki32-ki_emul, KI_EMULNAMELEN + 1);
bcopy(ki-ki_loginclass, ki32-ki_loginclass, LOGINCLASSLEN + 1);
+ CP(*ki, *ki32, ki_fibnum);
CP(*ki, *ki32, ki_cr_flags);
CP(*ki, *ki32, ki_jid);
CP(*ki, *ki32, ki_numthreads);
--- sys/compat/freebsd32/freebsd32.h.orig 2011-11-11 08:17:00.0
+0100
+++ sys/compat/freebsd32/freebsd32.h2012-01-17 11:34:00.0 +0100
@@ -319,6 +319,7 @@
charki_loginclass[LOGINCLASSLEN+1];
charki_sparestrings[50];
int ki_spareints[KI_NSPARE_INT];
+ int ki_fibnum;
u_int ki_cr_flags;
int ki_jid;
int ki_numthreads;
--- bin/ps/keyword.c.orig 2011-09-29 08:31:42.0 +0200
+++ bin/ps/keyword.c2012-01-17 12:54:49.0 +0100
@@ -85,6 +85,7 @@
{etimes, ELAPSED, NULL, USER, elapseds, 0, CHAR, NULL, 0},
{euid, , uid, 0, NULL, 0, CHAR, NULL, 0},
{f, F, NULL, 0, kvar, KOFF(ki_flag), INT, x, 0},
+ {fib, FIB, NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, d, 0},
{flags, , f, 0, NULL, 0, CHAR, NULL, 0},
{gid, GID, NULL, 0, kvar, KOFF(ki_groups), UINT, UIDFMT, 0},
{group, GROUP, NULL, LJUST, egroupname, 0, CHAR, NULL, 0},
--- bin/ps/ps.1.orig2011-11-22 22:53:06.0 +0100
+++ bin/ps/ps.1 2012-01-17 12:56:17.0 +0100
@@ -29,7 +29,7 @@
.\ @(#)ps.1 8.3 (Berkeley) 4/18/94
.\ $FreeBSD: src/bin/ps/ps.1,v 1.112 2011/11/22 21:53:06 trociny Exp $
.\
-.Dd November 22, 2011
+.Dd January 17, 2012
.Dt PS 1
.Os
.Sh NAME
@@ -506,6 +506,9 @@
minutes:seconds.
.It Cm etimes
elapsed running time, in decimal integer seconds
+.It Cm fib
+default FIB number, see
+.Xr setfib 1
.It Cm flags
the process flags, in hexadecimal (alias
.Cm f )
___
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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 11:41 AM, Ivan Voras ivo...@freebsd.org wrote: I've concluded very early that because of what I've said above, the only way to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff usually try hard not to break things so -STABLE has become a sort of running RELEASE branch. Since -STABLE is so ... stable ..., there is less and less incentive to make proper releases (though I think nobody would mind it happening). The next question is: what do releases from a -STABLE branch bring in that simply tracking the original -STABLE tree doesn't? Lately, not very much. Sorry to just pick out bits of your email Ivan… Ability to use freebsd-update. It would be better to have more frequent releases. As a prime example, ZFS became much more stable about 3 months after 8.2 was released. If you were waiting for an 8.x release that supported that improved version of ZFS, you are still waiting. You say that snapshots of STABLE are stable and effectively a running release branch, so why can't more releases be made? Is the release process too complex for minor revisions, could that be improved to make it easier to have more releases, eg by not bundling ports packages? Can it really be that the best advice for users is to run their own build infrastructure and make their own releases? I really don't want to come across as someone throwing their toys out and saying that unless everything changes I'm off to Linux-land, however there is mutterings at $JOB that too much time is spent massaging FreeBSD and that using Linux would be significantly easier to manage. Cheers Tom ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 13:02, Tom Evans tevans...@googlemail.com wrote: On Tue, Jan 17, 2012 at 11:41 AM, Ivan Voras ivo...@freebsd.org wrote: I've concluded very early that because of what I've said above, the only way to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff usually try hard not to break things so -STABLE has become a sort of running RELEASE branch. Since -STABLE is so ... stable ..., there is less and less incentive to make proper releases (though I think nobody would mind it happening). The next question is: what do releases from a -STABLE branch bring in that simply tracking the original -STABLE tree doesn't? Lately, not very much. Sorry to just pick out bits of your email Ivan… Ability to use freebsd-update. It would be better to have more frequent releases. As a prime example, ZFS became much more stable about 3 months after 8.2 was released. If you were waiting for an 8.x release that supported that improved version of ZFS, you are still waiting. You know, that's an excellent point! And maybe an excellent idea: to provide occasional, time-based STABLE snapshots for freebsd-update. You say that snapshots of STABLE are stable and effectively a running release branch, so why can't more releases be made? Nobody volunteered :( Is the release process too complex for minor revisions, could that be improved to make it easier to have more releases, eg by not bundling ports packages? Almost certainly yes. The current release process involves src, ports and docs teams. Would you and other RELEASE users be happy with simple periodic snapshots off the STABLE branches, not much different from tracking STABLE? The only benefit I see would be a light-weight opportunity for testing which would probably end up being implemented by moving to date-based tags (e.g. if a critical bug is found and the fix MFC-ed, the current tag would be advanced to $today)? Can it really be that the best advice for users is to run their own build infrastructure and make their own releases? Maybe. I'm trying to suggest that it looks like (I may be wrong, of course) that the effort required to upgrade from one RELEASE to the other is comparable to the effort of just having a -STABLE build machine somewhere and doing make installkernel, make installworld, mergemaster -FU over NFS on a 1000 machines. If you are serious about testing, you would need to test the RELEASEs also. I really don't want to come across as someone throwing their toys out and saying that unless everything changes I'm off to Linux-land, however there is mutterings at $JOB that too much time is spent massaging FreeBSD and that using Linux would be significantly easier to manage. Personally, I actually like apt-get and the way it handles installs, updates, dependencies, suggesteions, etc. I dislike almost everything else, thoughj. But now I'm curious: how do you (and others) update from one RELEASE to the other? Just by using freebsd-update? What do you think prevents you from using -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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, richo wrote: This would be a different argument if all the devs were paid a salary. == what percentage of linux devs are on salary to develop linux? -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - Patriotism is the willingness to kill and be killed for trivial reasons. -- Bertrand Russell ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17/01/2012 07:32, Atom Smasher wrote: On Tue, 17 Jan 2012, richo wrote: This would be a different argument if all the devs were paid a salary. == what percentage of linux devs are on salary to develop linux? Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 13:44, Ivan Voras ivo...@freebsd.org wrote: On 17/01/2012 07:32, Atom Smasher wrote: On Tue, 17 Jan 2012, richo wrote: This would be a different argument if all the devs were paid a salary. == what percentage of linux devs are on salary to develop linux? Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm Actually, you're misrepresenting the facts: according to the headline, 75% of the code came from paid developers, *not* 75% of developers are paid... See the difference?.. -- Igor M. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 14:49, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: On 17 January 2012 13:44, Ivan Voras ivo...@freebsd.org wrote: On 17/01/2012 07:32, Atom Smasher wrote: On Tue, 17 Jan 2012, richo wrote: This would be a different argument if all the devs were paid a salary. == what percentage of linux devs are on salary to develop linux? Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm Actually, you're misrepresenting the facts: according to the headline, 75% of the code came from paid developers, *not* 75% of developers are paid... See the difference?.. Yes, you're correct. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 14:20, Ivan Voras ivo...@freebsd.org wrote: On 17 January 2012 14:49, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: On 17 January 2012 13:44, Ivan Voras ivo...@freebsd.org wrote: On 17/01/2012 07:32, Atom Smasher wrote: what percentage of linux devs are on salary to develop linux? Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm Actually, you're misrepresenting the facts: according to the headline, 75% of the code came from paid developers, *not* 75% of developers are paid... See the difference?.. Yes, you're correct. Actually, I don't think it's cash that's the problem. I think it is more to do with the lack of common goal: the way that releases are perceived, at least by me, are that a bunch of people play in current then at some point someone decides to take a cut of the current branch and call it a release then work toward making that release passable as stable. To illustrate that, I cannot find anywhere on the .org website what core@ see the desirable features of 10.0 to be, or what the committers are working toward. It seems that the bazaar model of development is at its worst here: everyone is doing their own thing and at some point someone decides to call it a day and make a release, nobody cares for what they have already done, but only what they want to do in the future, non-committer patches go ignored (no, I don't have a reference) which discourages end-user contribution... I'm very happy to be shown wrong here, btw!.. -- Igor M. :-) ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 Jan 2012 13:38, Atom Smasher a...@smasher.org wrote: On Tue, 17 Jan 2012, richo wrote: This would be a different argument if all the devs were paid a salary. == what percentage of linux devs are on salary to develop linux? You're not comparing like with like. Linux is not an OS; FreeBSD is. Are you talking about Linux? Debian? Red Hat? 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 7:32 AM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: Actually, I don't think it's cash that's the problem. I think it is more to do with the lack of common goal: the way that releases are perceived, at least by me, are that a bunch of people play in current then at some point someone decides to take a cut of the current branch and call it a release then work toward making that release passable as stable. To illustrate that, I cannot find anywhere on the .org website what core@ see the desirable features of 10.0 to be, or what the committers are working toward. That would be because, with the multi-year debacle that 5.0-RELEASE became while they worked on the features list for 5.0 (primarily SMPng), the FreeBSD Project has moved away from features-based releases and to time-based releases (although the exact timelines are not carved in stone). You won't find a list of features for the next release of FreeBSD. You'll just find a list of things that people are working on that may or may not be ready in time for the next release. The development is much closer to Ubuntu (release whatever is ready every 6 months) than to Debian (release everything when it's ready, even if it takes 2, 3, 4+ years to make it ready, while the current release grows stale). -- Freddie Cash fjwc...@gmail.com ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 16:48, Freddie Cash fjwc...@gmail.com wrote: On Tue, Jan 17, 2012 at 7:32 AM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: Actually, I don't think it's cash that's the problem. I think it is more to do with the lack of common goal: the way that releases are perceived, at least by me, are that a bunch of people play in current then at some point someone decides to take a cut of the current branch and call it a release then work toward making that release passable as stable. To illustrate that, I cannot find anywhere on the .org website what core@ see the desirable features of 10.0 to be, or what the committers are working toward. That would be because, with the multi-year debacle that 5.0-RELEASE became while they worked on the features list for 5.0 (primarily SMPng), the FreeBSD Project has moved away from features-based releases and to time-based releases (although the exact timelines are not carved in stone). You won't find a list of features for the next release of FreeBSD. You'll just find a list of things that people are working on that may or may not be ready in time for the next release. The development is much closer to Ubuntu (release whatever is ready every 6 months) than to Debian (release everything when it's ready, even if it takes 2, 3, 4+ years to make it ready, while the current release grows stale). And this is the ridiculous bazaar situation that I was criticising. In contrast to Ubuntu, or other distribution on top of Linux, FreeBSD is a whole system. Even Ubuntu and such, take a collection of projects that have been developed with certain measurable goals. Yes, Ubuntu appears to be date-oriented distribution, but the software that Ubuntu incorporate into their releases is feature- and goal- oriented. FreeBSD, it seems, as I have pointed out, have no measurable goals within the project itself other than whatever looks like it has a potential to work on date X is going to be in our release. How can this be even considered to be serious?.. No serious manufacturer/producer says throw things in a mix and we'll stick to whatever passes as passable by date X... -- Igor M. :-) ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Mon, Jan 16, 2012 at 02:28:09PM -0800, John Kozubik wrote: Friends, I was disappointed to see that 8.3-RELEASE is now slated to come out in March of 2012. This will be ~13 months since 8.2-RELEASE and is typical of a trend towards longer gaps between minor releases. I also see that undercutting the current release before wide deployment and maturity is continuing. 7.0 came (barely) after 6.3, which was bad enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2. Finally, the culture of that's fixed in CURRENT or we built those changes into (insert next major release) continues to get worse. It's difficult to escape the notion that FreeBSD is becoming an operating system by, and for, FreeBSD developers. Hello John, With my sysadmin hat on i can echo your feelings, but i guess that your proposals are more focused on a company environment than a collaborative environment. First i would like to remember the last stage of FreeBSD 4.x for those people (not you) who are arguing in the thread about long stable releases. Those of us who used FreeBSD 4.x on the late release cycle will remember a few of this problems: - New hardware didn't work because no ACPI support was in 4.x until 4.11 or 4.12 (can't remember). Even then, it was considered a bad idea to backport it because it was a huge change for a -STABLE branch. - Because SMPng project involved a lot of changes, it was not easy to backport drivers. - SMP performance was horrible. As libc_r was the only option on 4.x you got various performance and stability problems with apps designed for a better threading model. A good example is MySQL performance. At that time started the whole mysql performance issues of FreeBSD vs linux that last until today. - Porting some new apps was troublesome because a lot of libraries had missing bits pending the big SMPng changes on 5.x. Mostly related to thread libs. - 5.x was a huge change relating to POLA. Eg: init scripts changed to new rc.d framework (iirc imported or based on NetBSD work). At that time you had two options: - Use rock solid FreeBSD 4.x and be unable to run more or less recent apps and hardware without huge problems. - Use FreeBSD 5.x which was unstable and slow compared to 4.x Because of this problems some people migrated to Linux, a fork of FreeBSD with the idea of an easier SMP model was created, etc. FreeBSD project learnt a good lesson: If you wait too much for great features to came to a reality instead of releasing often, you will not have features or stability. Ie: The stable release is unusable because backporting drivers and libs is harder and you end with unsupported new hardware as time passes, apps are harder to port because missing APIs, etc. And the new current release is unusable because there are too many things in testing and breaks in a lot of places. At that time (maybe 6.x? can't remember for sure, maybe someone else will remember better) the FreeBSD project announced a new way of doing releases. Release Timely instead of release based on features. If you don't have a feature ready when it's time for releases, just skip until next one instead of waiting. Now a few years later as sysadmins we find that there are too many releases that don't last too much. We waste a lot of time testing upgrades and once they're in production releases don't last often enough for the effort to be worthwile. Hence, John mail. I agree with John on the problems, but i disagree on solutions and the causes. No solution is going to work if you expect volunteers to do anything for a long time that's boring. You lost interest and stop working on that. What i really think it's the problem: If you try to maintain a few servers without much resources you end replicating half FreeBSD's project release infraestructure: - You find a bug, report, get a patch and apply. After that, you lost forever the option of using freebsd-update. You need to reinstall the system to get freebsd-update again - You want binary updates with custom kernel or patches? - Your only option is cutting your own releases or forget about freebsd-update. - You want to track packages on various machines? - create your tinderbox because binary package upgrades is a no-op with standard packages distributed by the project. - You want to apply a security update to a custom kernel? - no binary option - Do you want to apply just one security update but no other to a standard kernel? - no option freebsd-update will just allow you all patches or none. - Performance problems? Usually involves recompiling with different compiler or kernel/userland options. Again: no easy binary upgrade path. As you can see, if
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 4:39 PM, Mark Felder wrote: Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. Running FBSD in a *production* environment means you want something stable and tested. -STABLE does not fulfill the requirements I'm afraid. We've had to downgrade some boxes from 8.2-STABLE to -RELEASE here. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 15:39, Mark Felder f...@feld.me wrote: FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. I would guess that for folks like VMWare, the choice of their focus is essentially determined by their customers and not by them themselves. So if VMWare choose to focus more on Linux over FreeBSD it is simply indicative that VMWare's customers demand Linux support more that the FreeBSD one... Now, why is there more end-user demand for Linux than FreeBSD? I am guessing that is exactly what John K's original post was trying to address... -- Igor M. :-) ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Ivan, On Tue, 17 Jan 2012, Ivan Voras wrote: 2) Having two simultaneous production releases draws focus away from both of them, and keeps any release from ever truly maturing. This isn't how things work. The -CURRENT always has (and probably always had and always will have) the focus of developers. The releases are for many people simply a periodical annoyance due to freezes. In no way will reducing the number of production releases change this. As a volunteer effort, backports to stable branches only happen when 1) it's in the interest of the developer, e.g. I've found a bug on my systems, want to get it fixed in -STABLE and 2) when the developer is budged by outside forces (users complaining, other developers requesting it) and 3) they think it's worth doing and have time to do it spontaneously. These are in order of likelihood to happen. I could not have illustrated my point better, RE: FreeBSD becoming an OS by, and for, FreeBSD developers. I wish I could find the quote - it was from one of the FreeBSD core team many years ago, and it was something along the lines of we are holding a piece in one of the highest stakes games in the modern world. Now juxtapose that with The releases are for many people simply a periodical annoyance. going to run RELEASE software ONLY 4) New code and fixes that people NEED TODAY just sits on the shelf for 8 or 10 or (nowadays) 13 months while end users wait for new minor releases. ... except if you expect regular releases :) I've concluded very early that because of what I've said above, the only way to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff usually try hard not to break things so -STABLE has become a sort of running RELEASE branch. Since -STABLE is so ... stable ..., there is less and less incentive to make proper releases (though I think nobody would mind it happening). Impossible. I'm not a FreeBSD guy, I'm a business owner. Like most businesses, we are running official, delivered, release software only. Controller firmware ? Release only. Motherboard BIOS ? Release only. Drivers ? Release only. Just because I *happen* to also have some techincal expertise with FreeBSD, and some geeky tendencies does not mean we're making any exceptions. The next question is: what do releases from a -STABLE branch bring in that simply tracking the original -STABLE tree doesn't? Lately, not very much. Since there is a huge number of users and developers tracking -STABLE, the testing done specifically for a X.Y, Y0 RELEASE is not very extensive, so you just as well could have tracked -STABLE. I'm sure you know how easy it is to upgrade a STABLE-running system, and there are simple ways in which that can be made to scale to thousands of machines. Breakage is of course a risk, but not significantly greater than for any other upgrading. If we lose an rsync.net storage array, we'll get sued in 50 countries. My family and I will be *fucked*, not to mention the thousands and thousands of people, possibly ruined, around the globe. Now let's explain to one of those folks (or a judge and jury) (or my wife and kids) how the STABLE track works. Presumably they will refer us directly to the FreeBSD projects home page, where they had found: This is still a development branch, however, and this means that at any given time, the sources for FreeBSD-STABLE may or may not be suitable for any particular purpose. It is simply another engineering development track, NOT A RESOURCE FOR END-USERS. of 2012, we should be on 6.12 (or so) and just breaking ground on 7.0. Instead, each release gets perhaps two years of focused development before every new fix is applied only to the upcoming release, and any kind of support or enthusiasm from the community just disappears. If you're saying that -STABLE branches don't get fixes fast enough, I'd disagree. I'm not saying that. I'm not a FreeBSD developer and I have little use for either CURRENT or STABLE. I'm saying that I need a major release to have an *effective* lifetime longer than two years. Nobody runs the x.0, and these days the next major release comes in concurrent with x.2 ... so that's x.1 and x.2 you get to use in a real world, enterprise setting, before you have to either: a) scrap that investment and start a new round of investment in the new release (not trivial for a global firm) b) begin limping along as a second class citizen, watching everything - not just new features, but necessary bug fixes, go into the next major. --john ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, Tom Evans wrote: On Tue, Jan 17, 2012 at 11:41 AM, Ivan Voras ivo...@freebsd.org wrote: I've concluded very early that because of what I've said above, the only way to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff usually try hard not to break things so -STABLE has become a sort of running RELEASE branch. Since -STABLE is so ... stable ..., there is less and less incentive to make proper releases (though I think nobody would mind it happening). The next question is: what do releases from a -STABLE branch bring in that simply tracking the original -STABLE tree doesn't? Lately, not very much. Sorry to just pick out bits of your email Ivan? Ability to use freebsd-update. It would be better to have more frequent releases. As a prime example, ZFS became much more stable about 3 months after 8.2 was released. If you were waiting for an 8.x release that supported that improved version of ZFS, you are still waiting. Ding! It's amazing how many people are in the exact same boats - waiting for 8.3, getting locked out of new motherboards because em(4) can't be backported to even the production release... You say that snapshots of STABLE are stable and effectively a running release branch, so why can't more releases be made? Is the release process too complex for minor revisions, could that be improved to make it easier to have more releases, eg by not bundling ports packages? Thanks, Tom. I'm calling for some changes that, culturally, might be impossible, but a lot of pain would be avoided if more regular minor releases (3 per year) were made. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi Ivan, Thanks for the insights below ... see my comments inline: On Tue, 17 Jan 2012, Ivan Voras wrote: Ability to use freebsd-update. It would be better to have more frequent releases. As a prime example, ZFS became much more stable about 3 months after 8.2 was released. If you were waiting for an 8.x release that supported that improved version of ZFS, you are still waiting. You know, that's an excellent point! And maybe an excellent idea: to provide occasional, time-based STABLE snapshots for freebsd-update. You say that snapshots of STABLE are stable and effectively a running release branch, so why can't more releases be made? Nobody volunteered :( Fair enough. Is it the case that if funds or manpower were made available, more releases would be workable ? Or are there some deeper cultural leanings toward having fewer minor releases ? Is the release process too complex for minor revisions, could that be improved to make it easier to have more releases, eg by not bundling ports packages? Almost certainly yes. The current release process involves src, ports and docs teams. Would you and other RELEASE users be happy with simple periodic snapshots off the STABLE branches, not much different from tracking STABLE? The only benefit I see would be a light-weight opportunity for testing which would probably end up being implemented by moving to date-based tags (e.g. if a critical bug is found and the fix MFC-ed, the current tag would be advanced to $today)? Well, as I tried to explain just previously in the thread, these need to be real, bona fide releases. The notion of putting a few extra ones out without updating the ports tree and docs is tempting, but I think it's the wrong answer. Things should be kept simple and straightforward, and all of the minor releases should be *real* releases. Is three per year an insane schedule ? Remember, I am simultaneously advocating that FreeBSD stop publishing two production releases simultaneously, which is almost oxymoronic, so presumably there are resources that get freed up there. Can it really be that the best advice for users is to run their own build infrastructure and make their own releases? Maybe. I'm trying to suggest that it looks like (I may be wrong, of course) that the effort required to upgrade from one RELEASE to the other is comparable to the effort of just having a -STABLE build machine somewhere and doing make installkernel, make installworld, mergemaster -FU over NFS on a 1000 machines. If you are serious about testing, you would need to test the RELEASEs also. All very interesting - and honestly, things I will personally consider for my home filers, pfsense boxes, etc. But no, none of my firms are going into the OS business - even for ourselves. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, Mark Felder wrote: Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases. This will help people. The fact that vmware only works with release software is consistent with my own assertions. They (we) don't care what fancy toolchain and build environments you have - we need things that we can defend to customers, stockholders, judges, juries, etc. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/16/12 10:20 PM, John Kozubik wrote: On Tue, 17 Jan 2012, Steven Hartland wrote: I was disappointed to see that 8.3-RELEASE is now slated to come out in March of 2012. This will be ~13 months since 8.2-RELEASE and is typical of a trend towards longer gaps between minor releases. ... I must say as a small company that runs ~200 machines on FreeBSD I do see where John is coming from, as it is very time consuming to keep things up to date and new is not always better e.g. we still have boxes stuck on 6.x as issues introduced in the Linux compat after that caused problems. That said I'm in two minds as the features that have been brought in by the more rapid dev cycle like ZFS have been great. The features are great - nobody doesn't want the features! Like I said in the original post, as wonderful as ZFS on FreeBSD is (and we are deploying it this year) it is only now (well, in March) with 8.3 that I feel it is finally safe and stable enough to bet the farm on. I'm not the only one that feels this way. If that's the case, then, ZFS could have been developed just as it has, in a development branch, and not been used as justification for (mutiple) major releases and all of their disruption. but it would not have gotten the testing it did. As I said in the original post - we should be on 6.12 right now, and bringing out 7.0, with ZFS v28. that was my feeling when we went to this bring out a new major release every 3 weeks scheme. We must however look at why Major and Minor releases are different. A major release means that kernel ABIs (inside the system) have changed. We needed to change the ABIs between 4 and 5 for sure (threaded kernel) and between 6 and 7 for sure, (second round of threading work). 7 and 8 also really required a change. I'm not sure about 5-6 and 8-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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/16/12 10:29 PM, Atom Smasher wrote: so i guess that means that i'm tougher than a typical laptop user... and instead of making things easier, freeBSD is getting harder. thing is, when people don't play with freeBSD on laptops and desktops, then they grow up, get real jobs, and don't know much about it. if this keeps up, i'll cross a line where i just get more comfortable with linux and migrate my freeBSD servers to it. this is one of the areas where linux is doing well... people are playing with it, but in the process they're getting used to it and comfortable with it. from that background, they can install a linux based server without breaking a sweat. linux's ease of use and hardware support are seeding the next generation of FLOSS and *nix users... and most of them have never installed/used freeBSD. have a play with PCBSD some time ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 10:08 AM, John Kozubik wrote: Hi Ivan, [...] Fair enough. Is it the case that if funds or manpower were made available, more releases would be workable ? Or are there some deeper cultural leanings toward having fewer minor releases ? sure if you or someone is willing to cut releases, you can do so and I'm sure re@, given the resources (not just promised them) could do things differently. re would probably love to have people employed by someone to do the job :-) ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 7:39 AM, Mark Felder wrote: Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. I'm going to go both ways on this one. Where I used to work (Devin Teske is now there) we used to use the 'stable' branch and rolll our own releases. the criticality of those systems was hard to over-emphasize. In 2005 we worked out we processed 1.5 trillion dollars of transactions on those systems. The other side of the coin is that we had the resources to have someone (me) tracking the branch. I only spun a release when I thought it was a good time to do so, but I always had a year or so advance warning of when a new release was likely to be needed so I could select a good moment from over a wide range. Also ran a layer on the top of the sources where I could add cherry-picked back-ports and changes as part of our release. If it came to that maybe all the people who are currently saying they need better support of the 8.x branch could get together and together, support someone to do that job for them..would 1/5th of a person be too expensive for them? if not, what is a reasonable cost? Is it worth 1/20 th of a person? Julian ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/17/12 12:42, Ivan Voras wrote: On 17 January 2012 13:02, Tom Evanstevans...@googlemail.com wrote: Almost certainly yes. The current release process involves src, ports and docs teams. Would you and other RELEASE users be happy with simple periodic snapshots off the STABLE branches, not much different from tracking STABLE? The only benefit I see would be a light-weight opportunity for testing which would probably end up being implemented by moving to date-based tags (e.g. if a critical bug is found and the fix MFC-ed, the current tag would be advanced to $today)? If (a cluster of) new features have made it to stable in the mean time and have been tested and generally recognized as being in working condition, my opinion is that a release should be up for consideration: For starters, it's so much easier from a server management point of view.. easier to memorize and compare 8.5-RELEASE vs 8.6-RELEASE (now with blah-ZFS features and cpuset added to rc.d, bind updated to blah, openssh updated to version bleh, insert other usual suspects here) than it is to track stable. I don't remember what was added to -STABLE 3 months ago. It doesn't appear to be as much of a good starting point (good snapshot), compared to a release either. I like to know where I'm standing when setting up a new system, and a release is a convenient starting point. Also, one can always check what was added to a release on freebsd.org, while for -stable some digging has to be performed. For production servers, I'd rather run most servers with known good release branches. Sure, there were times when I needed something from the stable branch and decided to use it, but when the next release comes out then it's time to revert back to the release branch. Come to think about it, those days are pretty much gone since 4.x (incidentally, many of us who've stuck with FreeBSD for this long think of 4.x as an epic series). Running different -stable snapshots from different times results in systems running different versions of the operating system, in my opinion this is bound to bring problems (more stuff can go wrong). It's so much easier to have a look at ganglia or cacti or clusterit or anything similar and contrast the OS version and architecture. Running -stable, not so much. Is it stable from 2 days ago or a year? And what has changed since then? Furthermore, releases get way more attention in freebsd's own webpage, not to mention the cascading effect that has. You don't see a lot of articles about new blah features on 9-stable snapshot dated Jan 17 2012, but there are many about 9.0-RELEASE being out in the street. This also brings more visibility to the project. Maybe I'm horribly mistaken about the releasographics of production FreeBSD users, but I think most of us tend to run -release for the reasons mentioned above, and perhaps some more that I'm neglecting right now. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 9:36 AM, Damien Fleuriot wrote: On 1/17/12 4:39 PM, Mark Felder wrote: Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. Running FBSD in a *production* environment means you want something stable and tested. -STABLE does not fulfill the requirements I'm afraid. We've had to downgrade some boxes from 8.2-STABLE to -RELEASE here. then you went the wrong way and your process is flawed. having run -stable on production systems, the way to do it is: * follow -stable.. * pick a time that IN RETROSPECT (from 1 month later) looks as though it was good. * take a snapshot from that time and test it. * if it has problems MOVE FORWARD (not back) to the next candidate snapshot time. * repeat until you have one that works for you ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
- Original Message - From: John Kozubik j...@kozubik.com It's amazing how many people are in the exact same boats - waiting for 8.3, getting locked out of new motherboards because em(4) can't be backported to even the production release... This is not true, only last week did we take the version of e1000 from HEAD into our 8.2-RELEASE tree as a patch. It wasnt totally trivial but it also wasnt difficult either. But it would still be preferable for many not to have to do this I assume? This import brings the number of number release patches we manually apply to our machines above 8.2-RELEASE to 18 which includes:- updated areca driver, boot time fixes (disable memtest), devfs startup fix ixgbe e100 drivers, libz assembly crash fix, mps driver import, rc.subr fix for scripts, increased max swap size, tcp reassembly fix, udp6 fix for java, cam timeout fixes, zfs overflow fix, zfs slice boot delay, camcontrol security options for ssds and jail uref panic fix. I'm sure there are more that others would include but these changes are important enough to our environment to prompt their inclusion in what is effectively our own stream of 8.2-RELEASE. Now I know the factastic work commiters do in bring us FreeBSD so I can't bring myself to critisise in anyway the work they do. But its defintiely interesting to see others are in the same boat as us looking for something thats a bit more predicable than the current large change releases. I wonder if there is something that could be created to make maintaining micro branches easier. I know mfsbsd has made our lives so much simpler since we discovered it allowing us to take a standard source build on one machine and roll an install cd customised to our requirements in minutes. What other undiscovered gems are our out there? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Build Option Survey results
On Thu, 2012-01-12 at 07:45:34 +, Bjoern A. Zeeb wrote: Hey, after two years I had the opportunity to run the build option survey, initially done by phk, again. The number of options seems to have grown quite a bit it felt. I have not even looked at the results yet but here they are fresh off the machine: http://people.freebsd.org/~bz/build_option_survey_20120106/ Special thanks go to np, sbruno and bhaga for bringing worm back to life. Cool. Is the idea to kill options that have zero effect on anything? What about options that are broken? Is it worth carrying around tons of conditionals if they don't even work? Aren't we supposed to have an army of embedded people that use all of that stuff? Or is nanobsd circumventing the WITHOUT_FOO logic? Cheers, Uli ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tuesday 17 January 2012 20:54:51 Steven Hartland wrote: boot time fixes (disable memtest), Hi, Another noticeable part is that ufsread.c in boot2 uses very small block sizes to read the file system data. If that could be fixed boot times would drop too ! --HPS ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, Chris Rees wrote: what percentage of linux devs are on salary to develop linux? You're not comparing like with like. Linux is not an OS; FreeBSD is. Are you talking about Linux? Debian? Red Hat? linux is, in fact, an operating system. debian, red hat, ubuntu, gentoo, etc are distributions of that OS. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - Facts change from time to time. -- Donald Rumsfeld ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 14:30:20 -0600, Atom Smasher a...@smasher.org wrote: linux is, in fact, an operating system. debian, red hat, ubuntu, gentoo, etc are distributions of that OS. It's not really worth getting into this argument, but I'll reiterate that no, it's not an OS -- it's a kernel. Without the userland utilities the distros provide it's not very usable. Linus and co don't maintain the shell or the rc subsystem or anything like that. They only work on the kernel and in-tree drivers. We need to be comparing FreeBSD to a full blown distro. Cheers ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Here are My 2 Cents , 1. Support each release longer, or develop a better way to MFS ( Merge from Stable ) bug fixes, and driver updates to RELEASE. It always seams that there are a number of things in X-STABLE I would love to have in X.3-RELEASE and X.4-RELEASE, and I do not want all of X-STABLE just some new drivers and fixes . 2. Spell out the entire RELEASE road map at the beginning of the release. So for 9.0-RELEASE set tentative dates for 9.1, 9.2, 9.x etc . -- 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 12:59:44 -0600, Julian Elischer jul...@freebsd.org wrote: On 1/17/12 9:36 AM, Damien Fleuriot wrote: having run -stable on production systems, the way to do it is: * follow -stable.. * pick a time that IN RETROSPECT (from 1 month later) looks as though it was good. * take a snapshot from that time and test it. * if it has problems MOVE FORWARD (not back) to the next candidate snapshot time. * repeat until you have one that works for you This is also the way I've had it explained to me. Note, I'm currently not running anything -STABLE in production right now simply because I don't have that need. I did for a while last year, but not now. I'm deploying two ZFS SANs based on 9 early February. It might be on -RELEASE with manual backports of the gmultipath rewrite (required) and also I am considering the fixes for CDROM access (CAM stuff). I've seen several other things hit -STABLE right after the freeze ended early January which surprise me that they weren't included in -RELEASE and we didn't have another RC. I definitely see the frustration being expressed here, but I personally am comfortable running -STABLE. Many people are not and it is unfortunate that they will be left waiting until 9.1-RELEASE (probably late summer?). I hope a compromise will be found. I'm clearly in the minority that is OK with the current situation. To be fair, it could be worse -- OpenBSD secretly wants you to run snapshots and CURRENT as the RELEASEs are mostly unmaintained outside of the most extreme security concerns. Even the packages are kept at the exact version of the time of release. Well to be honest, Theo doesn't want me running OpenBSD at all. :-) -Previously Flamed User ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 20:30, Atom Smasher a...@smasher.org wrote: On Tue, 17 Jan 2012, Chris Rees wrote: what percentage of linux devs are on salary to develop linux? You're not comparing like with like. Linux is not an OS; FreeBSD is. Are you talking about Linux? Debian? Red Hat? linux is, in fact, an operating system. debian, red hat, ubuntu, gentoo, etc are distributions of that OS. No. Linux is, in fact, not an operating system. It is a kernel. You can't compare a *project* with a kernel. You could compare a *distribution* with a project, hence my email. 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Jan 17, 2012, at 11:12 AM, John Kozubik wrote: Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases. This will help people. I tend to agree with you. Our release engineering process isn't serving the needs of users as much as it once did. When Walnut Creek was running release engineering, we had releases often because they wanted to make money from their subscriptions. This produced reasonably spaced minor releases and except for 4-5, decently spaced major releases. Even after the torch passed from walnut creek to others, there was still either residual pressures to make the releases happen, or inherited mindset that keep on the same pace. Today we have lost our way. We have no major vendor pushing the process along to make it happen faster. We have no reason to get things done faster or differently than the volunteers are doing it. So we're languishing. 9.0 took forever to get out, and we didn't do stop-gap 8.x releases. Our port collection has also gotten bigger since those by-gone days so doing a release of the whole ports tree is taking longer to QA, so pressure to do it more often meets up with resource constraints. Our binary update tools lag considerably compared to Linux, and there's a big reluctance to whole-heartedly embrace PBI as a possible solution. Maybe pkgng will help there. Maybe the various attempts to get ABI stability to allow for easier decoupling of FreeBSD base and FreeBSD ports releases. But we have a real problem here. One I don't have easy answers for how to solve. One that likely has many other root-causes than the few I've cherry picked for this reply. The underlying balances that allowed the early project to succeed have shifted, but we've not shifted with them. Warner ___ 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: Build Option Survey results
Thanks Bjoern! -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Bjoern A. Zeeb Sent: Wednesday, January 11, 2012 11:46 PM To: FreeBSD current mailing list Cc: freebsd-hackers@freebsd.org Subject: Build Option Survey results Hey, after two years I had the opportunity to run the build option survey, initially done by phk, again. The number of options seems to have grown quite a bit it felt. I have not even looked at the results yet but here they are fresh off the machine: http://people.freebsd.org/~bz/build_option_survey_20120106/ With respect to the results of the build-survey linked-to above... I submitted 4x PR's to restore the failed WITHOUT_OPENSSL build option: misc/164206: [PATCH] buildworld WITHOUT_OPENSSL stops at lib/libarchive http://www.FreeBSD.org/cgi/query-pr.cgi?pr=164206 misc/164208: [PATCH] buildworld WITHOUT_OPENSSL stops at lib/libbsnmp/libbsnmp http://www.FreeBSD.org/cgi/query-pr.cgi?pr=164208 misc/164209: [PATCH] buildworld WITHOUT_OPENSSL stops at usr.sbin/wpa/hostapd http://www.FreeBSD.org/cgi/query-pr.cgi?pr=164209 misc/164210: [PATCH] buildworld WITHOUT_OPENSSL stops at usr.sbin/wpa/wpa_supplicant http://www.FreeBSD.org/cgi/query-pr.cgi?pr=164210 -- Devin Special thanks go to np, sbruno and bhaga for bringing worm back to life. /bz PS: the last run from 2010 can still be found here: http://people.freebsd.org/~bz/build_option_survey_20100104/ -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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 _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 2012-01-17 at 10:56 -0800, Julian Elischer wrote: If it came to that maybe all the people who are currently saying they need better support of the 8.x branch could get together and together, support someone to do that job for them..would 1/5th of a person be too expensive for them? if not, what is a reasonable cost? Is it worth 1/20 th of a person? Julian I've got to say, this strikes me as the most interesting idea floated so far in this conversation. I've heard of many instances of sponsored projects; they almost always involve major new features or support for new hardware or technologies; paying someone for a specific small focused fix is also common. A sponsored branch is... well... just an interesting concept to me. Unlike most developers, I have little interest in creating new code from scratch to implement the fad of the week. (There's that whole other opensource OS if fad of the week technology is your thing.) I live to find and fix bugs. Sometimes that means days of frustration to generate a one-line patch. Sometimes you find the problem in minutes but the fix means a painful redesign that touches 342 files and has the potential to ruin everyone's day when you get it wrong. But, for me at least, it's much more challenging and thus more rewarding when you get it right. Despite being a developer myself, I understand completely where John is coming from in opening this conversation, and I'm firmly in the me too camp because I'm also an end user of FreeBSD. I work at a company that creates embedded systems products with FreeBSD as our OS. In July we started the process of converting our products from 6.2 to 8.2. Out of sheer emergency necessity we shipped a product using 8.2 in October -- 6.2 was panicking and the customer was screaming, we had no choice; we've had to do several fix releases since then. It's only within the past couple weeks that I think we're finally ready to deploy 8.2 for all new products. More testing is needed before updating existing products in the field. It takes a long time for a business to vet a major release of an OS and deploy it. It costs a lot. Now, before we're even really completely up and running on 8.2 at work, 9.0 hits the street, and developers have moved on to working in the 10.0 world. What are the chances that any of the patches I've submitted for bugs we fixed in 8.x are ever going to get commited now that 8 is well on its way to becoming ancient history in developers' minds? So back to where I started this rambling... that concept of a sponsored branch, or maybe something along the lines of a long-lived stable branch supported by a co-op of interested users. Some co-op members may be able to provide developers or other engineering-related resources, some may just pay cash to help acquire those resources for various short-term or targeted needs along the way. I think it could work, and I think businesses that need such stability might find it easier to contribute something to a co-op than the current situation that requires a company such as ours to become, in effect, our own little FreeBSD Project Lite (if you think FreeBSD lacks manpower to do release engineering, imagine how hard it is for a small or medium sized business). -- Ian ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 Jan 2012, at 21:09, Warner Losh wrote: On Jan 17, 2012, at 11:12 AM, John Kozubik wrote: Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases. This will help people. I tend to agree with you. Our release engineering process isn't serving the needs of users as much as it once did. When Walnut Creek was running release engineering, we had releases often because they wanted to make money from their subscriptions. This produced reasonably spaced minor releases and except for 4-5, decently spaced major releases. Even after the torch passed from walnut creek to others, there was still either residual pressures to make the releases happen, or inherited mindset that keep on the same pace. Today we have lost our way. We have no major vendor pushing the process along to make it happen faster. What exactly did the major vendor to push things along? Keep nagging? I'd have thought PC-BSD and iXsystems are the natural people to to take over that role in any case. The FreeBSD foundation seems less interested in the for end-users angle as well. - Mark___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 1:27 PM, Mark Blackman m...@exonetric.com wrote: On 17 Jan 2012, at 21:09, Warner Losh wrote: On Jan 17, 2012, at 11:12 AM, John Kozubik wrote: Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases. This will help people. I tend to agree with you. Our release engineering process isn't serving the needs of users as much as it once did. When Walnut Creek was running release engineering, we had releases often because they wanted to make money from their subscriptions. This produced reasonably spaced minor releases and except for 4-5, decently spaced major releases. Even after the torch passed from walnut creek to others, there was still either residual pressures to make the releases happen, or inherited mindset that keep on the same pace. Today we have lost our way. We have no major vendor pushing the process along to make it happen faster. What exactly did the major vendor to push things along? Keep nagging? I'd have thought PC-BSD and iXsystems are the natural people to to take over that role in any case. The FreeBSD foundation seems less interested in the for end-users angle as well. We'd be happy to sponsor a full-time employee at the Mall to handle rolling -STABLE into release a few more times per year. We might need a bit of help maintaining a long term release but we think it's a pretty good idea all the way around. 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 02:50:08PM -0600 I heard the voice of Mark Felder, and lo! it spake thus: I've seen several other things hit -STABLE right after the freeze ended early January which surprise me that they weren't included in -RELEASE and we didn't have another RC. You mean the 9.0-RELEASE that's scheduled to be done (after having already slipped a month) at the beginning of Sept 2011? At some point (well before those add'l patches you're talking about, IMO) you have to STOP and release the damn thing already. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 12:02:29PM + I heard the voice of Tom Evans, and lo! it spake thus: You say that snapshots of STABLE are stable and effectively a running release branch, so why can't more releases be made? Is the release process too complex for minor revisions, could that be improved to make it easier to have more releases, eg by not bundling ports packages? That's at LEAST a double edged sword. The moment you do that, you'll have a giant groundswell of complaining about how the quality of releases has gone down. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 06:57:19PM + I heard the voice of Hugo Silva, and lo! it spake thus: Come to think about it, those days are pretty much gone since 4.x (incidentally, many of us who've stuck with FreeBSD for this long think of 4.x as an epic series). Having been a FreeBSD user for a very long time, I don't think of 4.x as epic. I think of 5.x as a clusterf...un. 4.x didn't last such a long time because everyone thought it was awesome, it was because the next version was still so broken it was the only thing we had to release. And the reason it developed whatever excess stability it may have had is _because_ it was moribund. It's trivial to avoid introducing new bugs to software; all you have to do is never change it. The next best thing is to make very small targetted changes with enormous care to make them local. But that means you DON'T get things like new drivers and infrastructure and so on, because those are just the sort of big changes that are likely to create new problems even as they solve existing ones. At some point aroudn X.4 or X.5 it stops being -STABLE and starts just being -STALE. For me, the smaller jumps between major releases are a *GOOD* thing, because it makes it parsecs easier to move between them. Moving a system from 4 to 5 was a giant nightmare of everything breaking. The only thing I can remember worse was moving from 2.2 to 3 (and actually, most of my 2.2 systems either stayed that way until they died, or got moved via *HEROIC* efforts straight to 4). In contrast, moving from 6-7-8 was only a slightly larger bump than moving from 6.X to 6.Y. I have a specific system that I'm holding back moving from 8 to 9 now because of a specific change, and I'm sorta hoping I can retire that system before I have to try it. If we went back to the days of mega-major's, that would happen *EVERY* time. Now, there are some environments where upgrades are rare major events and every single upgrade (possibly excluding those that can be honestly described as single targetted patch) requires a giant pile of from-scratch requalification. And in those cases, it's almost the same amount of work whether you're going from 4.6-4.7 as if you were doing 4.10-9.1. From that perspective, sure, giant lengthenings may sound like an excellent idea. But from the position of considering upgrades as common and minor things, giant leaps are a nightmare I want to avoid at all costs. Maybe I'm horribly mistaken about the releasographics of production FreeBSD users, but I think most of us tend to run -release [...] I doubt it would be easy to get stats. But you could probably draw a reasonable correlation between people using releases and binary packages, vs. source and port builds. That would probably be easier to get numbers on. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 16 January 2012 18:21, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: On 17 January 2012 01:02, richo ri...@psych0tik.net wrote: This would be a different argument if all the devs were paid a salary. Isn't this a bit of a cyclical argument: developers don't work because they are not paid a salary, the end-user base shrinks, BigCo doesn't want to pay for someone to put extra work in getting fBSD to do something that it can get elsewhere (eg Linux), fewer still developers work on fBSD, end-user base shrinks, BigCo is even more reluctant, even fewer Right, so some people need to stand up and actually push their agenda forward by agreeing to take on (and then completing) contributions towards the project that furthers their goals. OP - if you'd like to see FreeBSD's stable release schedule pushed forward a bit quicker then please, step up and offer to assist. No-one is going to say no. Everyone will appreciate the extra help. 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 16 January 2012 22:32, Atom Smasher a...@smasher.org wrote:
On Tue, 17 Jan 2012, richo wrote:
This would be a different argument if all the devs were paid a salary.
==
what percentage of linux devs are on salary to develop linux?
That's the wrong question.
The question is what is a good minimum threshold for the number of
paid developers on ${PROJECT} (which is project-specific!) to create a
sustainable project, given the requirements of developers and users.
Then you see whether the number of developers meets this threshold.
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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 21:27:24 + Mark Blackman m...@exonetric.com wrote: I'd have thought PC-BSD and iXsystems are the natural people to to take over that role in any case. The FreeBSD foundation seems less interested in the for end-users angle as well. If that's the case, is there any reason for cutting FreeBSD releases? No, I'm serious. If FreeBSD is being run by developers for developers (first rule of organizations: they're run for the benefit of the people who run them), how do they benefit from a release? If users move to some other organizations releases, and the developers don't get any benefit from them, why do them? On a less radical note, how about taking in the resources suggested for the sponsored branch, and using those to reorganize and expand the role of release engineering? Maybe get help from PC-BSD and iXsystems as well? Make STABLE the sponsored branch owned by the expanded RE group. To justify this, change it to an always production ready approach. Set up a CI system to test it regularly, and back out changes that break the build or tests. This does *not* include testing ports or anything else outside the base system. RELEASES become a snapshot of the new always production ready STABLE that has ports (and anything else included that's outside the base system) built for it and tested on it. The goal is that doing the work to keep STABLE production ready will significantly decrease the amount of work required to do a release. mike ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
.. I'm replying to the OP because honestly, this thread has gotten a bit derailed. If you'd like to see: ... more frequent releases? then please step up and help with all the infrastructure needed to roll out test releases, including building _all_ the ports. A lot of people keep forgetting that a release is build all the ports for all the supported platforms. ... longer lifecycle? Then please step up and contribute patches for features for your favourite branch. As a developer doing this in my spare time I'm only really working on new features on -HEAD and maybe backporting fixes to 9.x. What _I_ would like is someone to take on the task of testing and backporting net80211/ath fixes to 8.x and 7.x. ... longer branch lifecycle? Same as above. None of the developers are going to reject bugfixes and backported drivers to a legacy, stable branch. We may be a bit against the idea of porting entire new subsystems to legacy, stable branches - but if there's a good enough reason _and_ it's been tested _and_ there's a need for it - _I_ wouldn't say no. If you care this much to comment on it, please consider caring enough to step up and assist. Or, pay a company like ixSystems for FreeBSD support and get them to do this for you. Otherwise you're just re-iterating the same stuff I'm sure all the developers know but are just out of manpower/time/money/resources to do anything about. Adrian (who _did_ step up and take over a subsystem, so I'm speaking from recent experience.) ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Garrett Cooper Sent: Monday, January 16, 2012 4:07 PM To: wbent...@futurecis.com Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle On Mon, Jan 16, 2012 at 3:32 PM, William Bentley will...@futurecis.com wrote: I also echo John's sentiments here. Very excellent points made here. Thank you for voicing your opinion. I was beginning to think I was the only one who felt this way. I also have several FreeBSD installations spread across different development/production systems and it is not feasible to always upgrade to the latest and greatest. Part of why FreeBSD is difficult to adopt into more of the commercial/government sectors is because of this fast paced release cycle and most of the important patches/fixes are not backported far enough. This is why most of my customers decide to use Solaris or RedHat and not FreeBSD. (Not looking to start a flame war about the OS choice/etc just pointing out the Release cycle model). I would love to push FreeBSD harder but it is becoming increasingly difficult as of late. We seem to have lost our way around the release of FreeBSD 7. I am all in favor of new features but not at the risk of stability and proper life cycle management. Are me and John the only people that feel this way or are we among the minority? You aren't. There are other people like Devin Teske's group that feel the same (they're upgrading from 4.x to 8.2! Brave man.. and godspeed to him), Thanks! Actually, we're jumping from 4.11 to 8.1 (not 8.2 -- reason as follows). A lot of the problems we're having in 8.1 still exist in 8.2 (but will go-away in 8.3, according to what we're seeing already-committed to RELENG_8 tag beyond the RELENG_8_2_0_RELEASE tag -- that is, if 8.3 ever gets produced!). Therefore, we've seen no need to push 8.2 (in-fact, we've internally black-listed it because it doesn't fix anything we care about). So far, we've made over 10 patches to FreeBSD-8.1, and not a one of them would have been needed for 8.3, but all of them would still be needed for 8.2. I might add that we're doing an in-place binary migration from 4.11 to 8.1 using a very sophisticated sh(1) script named host_rebuild which we'll be releasing later this year. It allows binary migration both forwards, backwards, and even stationary (re-installing the same OS, to either migrate architecture or simply rebuild the OS). along with some development organizations that depend on long release cycles (IronPort, Isilon, etc). I brought this up in last weekend's BAFUG meeting... We're _very_ interested in replicating the long-lifecycle of the 4-series with a newer series. But which one? Right now, we're jumping to the 8-series, but after seeing that one of the major focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j enable), I'm ready to say that the 9-series should instead be the chosen outlier when it comes to picking one single release to have an ultra-wide lifecycle. The 9-series represents the first release to integrate a journaled filesystem by-default into the system (aka boot) filesystem(s). We were pleasantly surprised to see that the default installer enabled SU+J by-default when choosing guided and auto for disk partitioning. NOTE: We hated gjournal -- too clunky as a bolt-on solution. SU+J is a breath of fresh-air as it's truly integrated into the filesystem and recognized at the base FreeBSD level. -- Devin That being said. More people, more likelihood to succeed with what you need, like julian@ suggests. I like long release cycles too for stuff that I find critical and in production, like my router. My fileserver is a slightly different story, but I just got off the CURRENT bandwagon off on to the 9-STABLE bandwagon :). Cheers, -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 _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 23:01, Adrian Chadd adr...@freebsd.org wrote: If you'd like to see: ... more frequent releases? then please step up and help with all the infrastructure needed to roll out test releases, including building _all_ the ports. A lot of people keep forgetting that a release is build all the ports for all the supported platforms. I don't know this so I'm asking: does fixing a port to work on a pending release involve substantial changes (as in functionality cf. cosmetic) to the core or just patching the port to work with the core? If latter, maybe it's worthwhile uncoupling the two (core OS and ports)? -- Igor M. :-) ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
on 17/01/2012 23:46 Ian Lepore said the following: Now, before we're even really completely up and running on 8.2 at work, 9.0 hits the street, and developers have moved on to working in the 10.0 world. What are the chances that any of the patches I've submitted for bugs we fixed in 8.x are ever going to get commited now that 8 is well on its way to becoming ancient history in developers' minds? My opinion is that this will have more to do with your approach to pushing the patches (and your persistence) rather than with anything else. As long as stable/8 is still a supported branch or the bugs are reproducible in any of the supported branches. -- Andriy Gapon ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
on 18/01/2012 01:01 Adrian Chadd said the following: .. I'm replying to the OP because honestly, this thread has gotten a bit derailed. If you'd like to see: ... more frequent releases? then please step up and help with all the infrastructure needed to roll out test releases, including building _all_ the ports. A lot of people keep forgetting that a release is build all the ports for all the supported platforms. ... longer lifecycle? Then please step up and contribute patches for features for your favourite branch. As a developer doing this in my spare time I'm only really working on new features on -HEAD and maybe backporting fixes to 9.x. What _I_ would like is someone to take on the task of testing and backporting net80211/ath fixes to 8.x and 7.x. ... longer branch lifecycle? Same as above. None of the developers are going to reject bugfixes and backported drivers to a legacy, stable branch. We may be a bit against the idea of porting entire new subsystems to legacy, stable branches - but if there's a good enough reason _and_ it's been tested _and_ there's a need for it - _I_ wouldn't say no. And another 2 cents from me: we also have this KPI/KBI stability policy for the stable branches. So if anyone would like to have a stable branch but with some super wanted/needed/requested change added, then that would be a bit harder to arrange. I personally would call that a custom branch. And that of course can also be done, even as an official custom branch, but interested people would need either to take the job upon themselves or find (motivate, interest) those who would the job for them. If you care this much to comment on it, please consider caring enough to step up and assist. Or, pay a company like ixSystems for FreeBSD support and get them to do this for you. Otherwise you're just re-iterating the same stuff I'm sure all the developers know but are just out of manpower/time/money/resources to do anything about. Adrian (who _did_ step up and take over a subsystem, so I'm speaking from recent experience.) -- Andriy Gapon ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Atom writes: i bought myself a LENOVO T510 when it first came out, around early 2010. it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i STILL can't run xorg properly with it. I have a machine from 2005-08 that FreeBSD still doesn't support properly in 2012. After much research I figured out that SATA NCQ was an essential feature, and choose a mainboard with nforce4 to get it. FreeBSD still doesn't support NCQ on nforce after all these years. Linux has had NCQ on nforce4 since Oct 2006. FreeBSD also doesn't properly support the onboard VIA firewire chip, which is still found on new mainboards today. I don't necessarily expect support for every exotic chip out there the first day they hit the street, but these are both popular chips, and it is 6.5 years later. I'm not sure how an OS is supposed to have The power to serve when it can't even talk to disks properly. And all the device drivers that think it is ok to lollygag around for absurd lengths of time with interrupts turned off, thus causing data to be lost. Damien writes: Check this PR I opened some months ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=161123cat=kern It was planned for 9.0-RELEASE, there is no mention of 8.x That's just the kind of problem John raises here. Hey, at least you have a fix, and it is even in a release (I'm assuming it made it into 9.0). The bigger problem is all the bugs that don't have fixes at all. Igor writes: patches go ignored (no, I don't have a reference) Here is a PR that contains a patch, yet is still open after several years. Also fixes an even older PR from Dec 2006. Dinky little patch, works great. Should be easy enough to code inspect, test, and check in. http://www.FreeBSD.org/cgi/query-pr.cgi?pr=127717cat= Mark writes: Why is everyone so afraid of running -STABLE? Experience. John writes: Is three per year an insane schedule ? Remember, I am simultaneously advocating that FreeBSD stop publishing two production releases simultaneously, which is almost oxymoronic Why is publishing two production releases almost oxymoronic? Seems like a very good policy to me. Say you are running 8.1. It is good to have the choice of going to a low risk 8.2 with bugfixes or going to 9.0 with some major new feature at the expense of more work and higher risk. If you want the option of sticking with a major release series (say 8.x) for a long time, then there needs to be at least two production releases supported. As fast as major releases are coming out, probably 3 or 4. Why are major releases coming out so often? Gotta compete in the large number war. NetBSD was at 1.x for years and years, then suddenly someone decided to change the numbering scheme and they're off to the races. Firefox has caught the same insanity. I see complaints from medium-to-large sites, yet FreeBSD's budget is so small. Surely it must be possible for these medium-to-large sites to pay into a fund to improve things. FreeBSD clearly needs more developers to fix problems, to code review, test, and check in patches, and to improve the documentation. Judging from this email thread there is a demand for more/better release engineering and backporting as well. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote: on 17/01/2012 23:46 Ian Lepore said the following: Now, before we're even really completely up and running on 8.2 at work, 9.0 hits the street, and developers have moved on to working in the 10.0 world. What are the chances that any of the patches I've submitted for bugs we fixed in 8.x are ever going to get commited now that 8 is well on its way to becoming ancient history in developers' minds? My opinion is that this will have more to do with your approach to pushing the patches (and your persistence) rather than with anything else. As long as stable/8 is still a supported branch or the bugs are reproducible in any of the supported branches. Well I submitted a sort of random sample of the patches we're maintaining at work, 11 of them as formal PRs and 2 posted to the lists here recently. So far two have been committed (the most important one and the most trivial one, oddly enough). I'm not sure just how pushy one is supposed to be, I don't want to be a jerk. Not to mention that I wouldn't know who to push. That's actually why I'm now being active on the mailing lists, I figured maybe patches will be more accepted from someone the commiters know rather than just as code out of the blue attached to a PR. I think it would be great if there were some developers (a team, maybe something not quite that formal) who concentrated on maintenance of older code for the user base who needs it. I'd be happy to contribute to that effort, both on my own time, and I have a commitment from management at work to allow me a certain amount of billable work hours to interface with the FreeBSD community, especially in terms of getting our work contributed back to the project (both to help the project, and to help us upgrade more easily in the future). I have no idea if there are enough developers who'd be interested in such a concept to make it work, co-op or otherwise. But I like the fact that users and developers are talking about their various needs and concerns without any degeneration into flame wars. It's cool that most of the focus here is centered on how to make things better for everyone. -- Ian ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, Mark Felder wrote: linux is, in fact, an operating system. debian, red hat, ubuntu, gentoo, etc are distributions of that OS. It's not really worth getting into this argument, but I'll reiterate that no, it's not an OS -- it's a kernel. Without the userland utilities the distros provide it's not very usable. Linus and co don't maintain the shell or the rc subsystem or anything like that. They only work on the kernel and in-tree drivers. We need to be comparing FreeBSD to a full blown distro. if it makes you feel better, then pick a distribution of linux, and compare it's successes and/or failings to freeBSD. whether or not linux is an OS or just a kernel is irrelevant here, but at the same time an interesting distinction (and let's not debate it here, just acknowledge that it's been pointed out) since freeBSD is both a kernel and a collection of core utilities. in some ways freeBSD is like the linux kernel, in other ways it's more like a distribution of linux. would freeBSD benefit from breaking up those things into explicitly different projects? like linux GNU? -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - No matter how cynical you get, it is impossible to keep up. -- Lily Tomlin ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
First, let's do away with the whole, If you step up to help, your help will be accepted with open arms myth. That's only true if the project leadership agrees with your goals. We also need to take a step back and ask if throwing more person-hours at the problem is the right solution, or if redesigning the system to better meet the needs of the users *as a first step* is the right answer? On 01/17/2012 15:01, Adrian Chadd wrote: .. I'm replying to the OP because honestly, this thread has gotten a bit derailed. If you'd like to see: ... more frequent releases? then please step up and help with all the infrastructure needed to roll out test releases, including building _all_ the ports. A lot of people keep forgetting that a release is build all the ports for all the supported platforms. Does it need to be? I've been pushing a long time now to have a branched ports tree. If we have a stable version of the ports where only known-good changes are promoted then that frees us up quite a bit to redefine what a release is. ... longer lifecycle? Then please step up and contribute patches for features for your favourite branch. As a developer doing this in my spare time I'm only really working on new features on -HEAD and maybe backporting fixes to 9.x. What _I_ would like is someone to take on the task of testing and backporting net80211/ath fixes to 8.x and 7.x. So you want to do all the fun stuff, and have someone else do your scut work? Good luck with that. :) Maybe what we need to do is redefine what it means to be a FreeBSD committer. From now on, your commit bit comes with XYZ privileges, but also ABC responsibilities. Sure, we'd lose some people, but what would we gain? Also, your premise is flawed. We (speaking generally) suck at supporting more than one -stable branch. We *really* suck at supporting three. Six months ago when the machinery was just beginning to spin up for 9.0-RELEASE I tried to get the PTB to reconsider. I was told that my concerns were invalid because it was basically ready to go as is. The plan I laid out at the time was to have no more than 2 stable branches extant at any given time. Lengthen the periods where each stable branch is supported, and terminate the oldest one when the newest one is released. ... longer branch lifecycle? Same as above. None of the developers are going to reject bugfixes and backported drivers to a legacy, stable branch. We may be a bit against the idea of porting entire new subsystems to legacy, stable branches - but if there's a good enough reason _and_ it's been tested _and_ there's a need for it - _I_ wouldn't say no. But committers already fail to MFC *existing* bug fixes to stable branches (even ones they generated). This is especially true for the older branches. So how is the idea of users generating more new bug fixes going to help? What I'd like to see us do is to rethink what a release is. In particular, I'd like to see us start to do more point releases (e.g., 8.2.1) which involve only updates to the base, and don't involve the whole ports and doc machinery. This would combine the current patch releases done for security purposes. Ideally of course we'd have a branch were known-good stuff was merged from the -stable branch, so an 8.2.1 wouldn't (necessarily) be what's in stable/8 at the time. However I'm not sure we have the personnel for that, so even doing stable/8 - 8.2.N would be an improvement over what we have. One area where user involvement *would* be really welcome here is in the area of regression testing. It would be much easier to cut a point release if we had a series of regression tests, submitted by users so as to reflect real world conditions, that we could run against the new version. That way we could at least be sure that we didn't break anything that current users of that branch are relying on. Several people have mentioned 3x/year as a good release schedule, I don't see any reason why we couldn't do point releases in that timescale. The other thing I think has been missing (as several have pointed out in this thread already) is any sort of planning for what should be in the next release. The current time-based release schedule is (in large part) a reaction to the problems we had in getting 5.0 out the door. However I think the pendulum has swung *way* too far in the wrong direction, such that we are now afraid to put *any* kind of plan in place for fear that it will cause the release schedule to slip. Aside from the obvious folly in that (lack of) plan, it fails to take into account the fact that the release schedules already slip, often comically far out into the future, and that the results are often worse than they would have been otherwise. Meta-note, there is going to be a strong knee-jerk reaction to that last paragraph to the effect that I'm attacking individuals who are involved in the release process. I'm not. The *system* is deeply flawed, so the heroic efforts of those doing their
RE: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi Devin, On Tue, 17 Jan 2012, Devin Teske wrote: I brought this up in last weekend's BAFUG meeting... We're _very_ interested in replicating the long-lifecycle of the 4-series with a newer series. But which one? Right now, we're jumping to the 8-series, but after seeing that one of the major focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j enable), I'm ready to say that the 9-series should instead be the chosen outlier when it comes to picking one single release to have an ultra-wide lifecycle. The 9-series represents the first release to integrate a journaled filesystem by-default into the system (aka boot) filesystem(s). We were pleasantly surprised to see that the default installer enabled SU+J by-default when choosing guided and auto for disk partitioning. There's two parallel suggestions being put forth here, both of which are interesting: - Allow a related party to adopt a release (as I understand it) and provide a sub-community taht donates resources to tending and updating that release. - Picking a chosen release to really dive into, officially, and polish and extend it, like 4. If I had to pick, I'd say the second one, but I'm not sure either one is the right direction. I think a more sustainable, balanced approach that can be extended for every release into the future would be best. I don't really want to see some semi-official fork, or extended release - it would duplicate a lot of existing effort as well as raise questions about how official it was. Would vmware support it as a real release ? Large organizations might disqualify it the same way they would STABLE. As for picking 8 or 9 to be the chosen exception - that would help me a lot in the short term, but if things are being done wrong, they should be fixed in the long run. I think the real choice that has to be made is when will we halt proclaiming two simultaneous releases as production ? and since 9 is already here, it can't be 8/9, it has to be 9/10. You could progress 8.x along its current trajectory, possibly building 8.4 a year or so from now and then be done with it, and then that would be the last short/unfocused release. Then you postpone 10.0-RELEASE until January 2017. Instead of having a legacy branch and two production branches, you would have legacy (8) production (9) and ... nothing. Or if you need to have it out there, 10 is the development branch. Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at the end of the cycle. On Tue, 17 Jan 2012, Adrian Chadd wrote: OP - if you'd like to see FreeBSD's stable release schedule pushed forward a bit quicker then please, step up and offer to assist. No-one is going to say no. Everyone will appreciate the extra help. I don't really know how much upheaval is implied in pushing 10.0 to 2017, developing only one production release, and running 9.x up to 9.15 (or whatever) but I can contribute USD $10k per year that this course was followed, or $50k over five years. We can contribute some hardware, hosting and bandwidth as well. Are there any others here who can chip in, or whose firms can ? ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 16:25:12 -0600, Matthew D. Fuller fulle...@over-yonder.net wrote: On Tue, Jan 17, 2012 at 02:50:08PM -0600 I heard the voice of Mark Felder, and lo! it spake thus: I've seen several other things hit -STABLE right after the freeze ended early January which surprise me that they weren't included in -RELEASE and we didn't have another RC. You mean the 9.0-RELEASE that's scheduled to be done (after having already slipped a month) at the beginning of Sept 2011? At some point (well before those add'l patches you're talking about, IMO) you have to STOP and release the damn thing already. Yeah, but how much sense does it make to do a -RELEASE with critical bugs? For example, gmultipath guarantees a panic on various hardware just by breaking a path. This was fixed in a full rewrite discussed this summer and publicized in November. Now anyone with shiny 9.0 (or even 8.2) running gmultipath risks a panic. The fix IS the rewrite. But it's s total rewrite and so patching that onto 9.0 as errata doesn't really make sense (rewrite adds features too), so now the choices for a stable gmultipath is -STABLE or patiently waiting for 9.1. So yeah, 9.0 slipped hard. Perhaps it should have slipped a bit further until blockers like gmultipath and the cdrom/CAM stuff were fully addressed. But it's impossible to release 100% bug free software where exactly *do* you draw the line? :-/ I certainly would not be better than anyone else at managing any portion of this project. I'm just glad I have the ability to find and apply fixes myself when necessary. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi Doug, Thanks a lot for these comments and insight - response below... On Tue, 17 Jan 2012, Doug Barton wrote: I tried to make the point back in June that there was no reason to cut 9.0-RELEASE yet because we don't have solid support for clang in either the base, or ports (amongst several other reasons) and that the delay for getting that working would be a great excuse for slipping the support schedule for 8 so that we could release 9.0 not-too-long before 7 was about to go EOL, and make the 8/9/10 release schedules fit the new, (hopefully) more rational model. Perhaps we can reconsider that idea for 10.0. Just previously in this thread, I suggested the following: quote You could progress 8.x along its current trajectory, possibly building 8.4 a year or so from now and then be done with it, and then that would be the last short/unfocused release. Then you postpone 10.0-RELEASE until January 2017. Instead of having a legacy branch and two production branches, you would have legacy (8) production (9) and ... nothing. Or if you need to have it out there, 10 is the development branch. Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at the end of the cycle. /quote I wonder if this is too aggressive in that direction, or if this would be a decent balance ? ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
on 18/01/2012 01:36 Ian Lepore said the following: On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote: on 17/01/2012 23:46 Ian Lepore said the following: Now, before we're even really completely up and running on 8.2 at work, 9.0 hits the street, and developers have moved on to working in the 10.0 world. What are the chances that any of the patches I've submitted for bugs we fixed in 8.x are ever going to get commited now that 8 is well on its way to becoming ancient history in developers' minds? My opinion is that this will have more to do with your approach to pushing the patches (and your persistence) rather than with anything else. As long as stable/8 is still a supported branch or the bugs are reproducible in any of the supported branches. Well I submitted a sort of random sample of the patches we're maintaining at work, 11 of them as formal PRs and 2 posted to the lists here recently. Just a note: the next best thing you can to _not_ have a patch committed is to just open a PR and stop at that. The best thing being not sharing the patch at all :-) So far two have been committed (the most important one and the most trivial one, oddly enough). I'm not sure just how pushy one is supposed to be, I don't want to be a jerk. Some things that help: - send a problem description and a patch (or a short description and a link to a PR) to a relevant mailing list - maintain a discussion of the patch if it arises - try to be interesting and keep the interested folks hooked - find some folks who recently committed stuff in the area of the patch and contact them directly - don't just wait for too long, remind about yourself and the patch, try different mailing lists/people - never give up - stay technical, never get bitter or overly emotional - don't refuse when offered a commit bit :-) Not to mention that I wouldn't know who to push. That's actually why I'm now being active on the mailing lists, I figured maybe patches will be more accepted from someone the commiters know rather than just as code out of the blue attached to a PR. That helps. And, as I've said above, being pro-active about the patches helps too. I think it would be great if there were some developers (a team, maybe something not quite that formal) who concentrated on maintenance of older code for the user base who needs it. Yes, it would be great if some current developers found themselves interested/motivated to do that kind of work. Or if some new developers joined the ranks to do the job. I'd be happy to contribute to that effort, both on my own time, and I have a commitment from management at work to allow me a certain amount of billable work hours to interface with the FreeBSD community, especially in terms of getting our work contributed back to the project (both to help the project, and to help us upgrade more easily in the future). That sounds great! I am sure that this approach will be productive. I have no idea if there are enough developers who'd be interested in such a concept to make it work, co-op or otherwise. But I like the fact that users and developers are talking about their various needs and concerns without any degeneration into flame wars. It's cool that most of the focus here is centered on how to make things better for everyone. -- Andriy Gapon ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, Igor Mozolevsky wrote: On 17 January 2012 23:01, Adrian Chadd adr...@freebsd.org wrote: If you'd like to see: ... more frequent releases? then please step up and help with all the infrastructure needed to roll out test releases, including building _all_ the ports. A lot of people keep forgetting that a release is build all the ports for all the supported platforms. I don't know this so I'm asking: does fixing a port to work on a pending release involve substantial changes (as in functionality cf. cosmetic) to the core or just patching the port to work with the core? If latter, maybe it's worthwhile uncoupling the two (core OS and ports)? IMHO, the two are already uncoupled too much. The problem I have with ports is that there is not a -stable branch that tracks with -stable core. I don't need the latest and greatest ports, just security and bug fixes. It doesn't even have to be every port, just the commonly used ports. There's not enough man power for this, unfortunately, but I'm still happy that at least we _do_ have _a_ ports system :-) -- DE ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 00:00, Andriy Gapon a...@freebsd.org wrote: Just a note: the next best thing you can to _not_ have a patch committed is to just open a PR and stop at that. The best thing being not sharing the patch at all :-) [snip] Some things that help: - send a problem description and a patch (or a short description and a link to a PR) to a relevant mailing list - maintain a discussion of the patch if it arises - try to be interesting and keep the interested folks hooked - find some folks who recently committed stuff in the area of the patch and contact them directly - don't just wait for too long, remind about yourself and the patch, try different mailing lists/people - never give up - stay technical, never get bitter or overly emotional - don't refuse when offered a commit bit :-) Seriously, WTF is the point of having a PR system that allows patches to be submitted??! When I submit a patch I fix *your* code (not yours personally, but you get my gist). No other project requires a non-committer to be so ridiculously persistent in order to get a patch through. Such system is plainly wrong---it simply discourages people from sending this works for me(TM) fixes. The committers have to realise three things: they can and do write broken code now and then, most people who write patches to help the fBSD along don't have the time to become full time committers (otherwise they'd already be, right?), and there's only so many times one is willing to bang their head against a wall with no results---as Einstein pointed out Insanity: doing the same thing over and over again and expecting different results... I'm not saying that responding to reasonable requests from people who are in the process of testing and committing the patch, but expecting the end-users to chase committers to have a fix included is plainly wrong!.. -- Igor M. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Julian Elischer Sent: Tuesday, January 17, 2012 10:56 AM To: Mark Felder Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle On 1/17/12 7:39 AM, Mark Felder wrote: Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. I'm going to go both ways on this one. Where I used to work (Devin Teske is now there) we used to use the 'stable' branch and rolll our own releases. We still do this today, but have only further enhanced the procedure. Within FreeBSD announcing a new release, we can be ready to ship said-release within 3-6 weeks. However, that's not to say that our customers can take said-new-release every 3-6 weeks. Our largest customer is not-surprisingly the fastest at turn-around but at-best could only do maybe 2 releases at-most in a single year. Our smaller customers are taking OS upgrades much slower (every-other year if we're lucky; more like once every 3 years). For both our large and small customers, we actively back-port device support in-accordance with hardware manufacturing windows. This is to explain that our hardware suppliers notify us ahead-of time when a particular piece of hardware is about to become unavailable. At that time we are usually given a choice of hardware to evaluate as replacements for the existing EOM production-line. We're usually given at least 3-9 months prior-notice before our current production-line goes EOL. For each candidate replacement we try each FreeBSD release that we're currently using in production. If it doesn't work, we try another candidate hardware. If we can't seem to find a winning combo that works with our existing -RELEASE, we then start trying newer releases until we find drivers working for each/every required piece of hardware (network cards, RAID cards, serial ports/cards, Adaptec SCSI cards, Fibre HBAs, etc.). When we find a release that contains the necessary drivers, we back-port. At this time, it's worth noting that we use ONLY monolithic kernels and we deliver them via packages. When we back-port new device support, we just roll a new kernel, ship it via package, pkg_add, reboot. Similarly, if the patch is in userland, we package up the replaced binaries (produced by using the release engineering procedures documented in build(7) and [more importantly] release(7)). The net effect is that we run a -RELEASE with patches from either the same -STABLE, a higher -RELEASE, higher -STABLE, or (as a last-resort) -CURRENT or HEAD. We've been known to roll FreeBSD-4.11 kernels with bits back-ported from RELENG_8. So, I guess what I’m trying to say is that if you're going to take your production environment extremely seriously (as though 1.5-Trillion globally-economic-dollars depended on it) you-too would take a serious look at release(7) and the Release Engineer's handbook. It really is worth maintaining your own release, taking required fixes from -STABLE (preferred) or higher (as necessary) to satisfy your customers (which are nearly almost always going to have a different release schedule than that-of any OS, be-it FreeBSD, Linux, or other distribution). the criticality of those systems was hard to over-emphasize. In 2005 we worked out we processed 1.5 trillion dollars of transactions on those systems. I'm going to have to sit down with DaveR, JPL, and others to get an updated metric for 2011. I'd be willing to bet that we've increased transactional load over the years (with respect to FreeBSD, we brought on one new sizable customer since then and expanded the scope of existing FreeBSD customers to new overseas installations as well as several new sites in the States). The other side of the coin is that we had the resources to have someone (me) tracking the branch. That person is now (me) plus I have Dave Robison (DaveR) to lean on occasionally (and you're always a great help, DaveR). I'd argue that it's not the man-power... it's whether management sees the importance in allowing one (or two) persons to spin his/her wheels, developing a laudable solution to the problem at-hand (precisely what we've done; mitigating extra/busy work). However, sometimes you just have to take initiative. The company
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
- Original Message - From: Hans Petter Selasky hsela...@c2i.net On Tuesday 17 January 2012 20:54:51 Steven Hartland wrote: boot time fixes (disable memtest), Hi, Another noticeable part is that ufsread.c in boot2 uses very small block sizes to read the file system data. If that could be fixed boot times would drop too ! It might but not the same order of magnitude I suspect as this was like 30-60+ delay depending on memory size ;-) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 7:16 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: Seriously, WTF is the point of having a PR system that allows patches to be submitted??! When I submit a patch I fix *your* code (not yours personally, but you get my gist). No other project requires a non-committer to be so ridiculously persistent in order to get a patch through. It takes time to review and test patches. There are a lot of people that think it only takes 30 seconds to download the patch, apply, and commit. This is just not true. When I take PRs committers 1) Download the PR 2) Read the surrounding code sufficiently to understand what it does 3) Read the patched code to find the bug 4) Read the patch to see if it fixes the bug 5) Ensure that it is the most appropriate way to fix the bug 6) Apply the patch and test the affected issue. 7) Find the person who wrote the original code (or at least one other person) and have them review it - this person usually goes through steps 1-6 too. 8) Apply the patch to head and commit 9) Verify the changes are correct didn't cause any regressions 10) MFC to stable[789] And this assumes the patch was perfect, there really was a bug, and everyone thinks things through properly. The process take anywhere from half an hour for obvious fixes to multiple days in addition to the committer's work, school, and family obligations.. Being persistent sometimes gives the committer the motivation to go through all those steps. As a part of the bugbusting team I've taken quite a few bugs and been the annoying persistent person for other people. As a result I've closed quite a few bugs. Such system is plainly wrong---it simply discourages people from sending this works for me(TM) fixes. Yes and no. The system is bad, it shouldn't take 5 years to commit a correct patch, but at the same time this works for me patches still need to go through all of the above. The committers have to realise three things: they can and do write broken code now and then, most people who write patches to help the fBSD along don't have the time to become full time committers (otherwise they'd already be, right?), and there's only so many times one is willing to bang their head against a wall with no results---as Einstein pointed out Insanity: doing the same thing over and over again and expecting different results... And we need to work to find ways to fix issues while still ensuring that the above steps are followed. I'm not saying that responding to reasonable requests from people who are in the process of testing and committing the patch, but expecting the end-users to chase committers to have a fix included is plainly wrong!.. I agree, and we need to work to find systematic solutions to correct patches waiting for someone to take a look without compromising the quality checks committers (should) do. If you have ideas to make this process easier or more efficient we are all eager to hear them. I am especially interested to know what *I* could do to help speed things along in areas I don't know well enough to commit to. -- Eitan Adler ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi John, -Original Message- From: John Kozubik [mailto:j...@kozubik.com] Sent: Tuesday, January 17, 2012 3:52 PM To: Devin Teske Cc: 'Garrett Cooper'; wbent...@futurecis.com; freebsd-hackers@freebsd.org Subject: RE: FreeBSD has serious problems with focus, longevity, and lifecycle Hi Devin, On Tue, 17 Jan 2012, Devin Teske wrote: I brought this up in last weekend's BAFUG meeting... We're _very_ interested in replicating the long-lifecycle of the 4-series with a newer series. But which one? Right now, we're jumping to the 8-series, but after seeing that one of the major focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j enable), I'm ready to say that the 9-series should instead be the chosen outlier when it comes to picking one single release to have an ultra-wide lifecycle. The 9-series represents the first release to integrate a journaled filesystem by-default into the system (aka boot) filesystem(s). We were pleasantly surprised to see that the default installer enabled SU+J by-default when choosing guided and auto for disk partitioning. There's two parallel suggestions being put forth here, both of which are interesting: - Allow a related party to adopt a release (as I understand it) and provide a sub- community taht donates resources to tending and updating that release. - Picking a chosen release to really dive into, officially, and polish and extend it, like 4. If I had to pick, I'd say the second one, but I'm not sure either one is the right direction. I too am not sure. The latter (pick a chosen release) option seems a good route, but like you say, maybe a re-envisioning of the release procedure is what's needed for long-term. I think a more sustainable, balanced approach that can be extended for every release into the future would be best. I don't really want to see some semi-official fork, or extended release - it would duplicate a lot of existing effort as well as raise questions about how official it was. Would vmware support it as a real release ? Large organizations might disqualify it the same way they would STABLE. As for picking 8 or 9 to be the chosen exception - that would help me a lot in the short term, but if things are being done wrong, they should be fixed in the long run. I think the real choice that has to be made is when will we halt proclaiming two simultaneous releases as production ? and since 9 is already here, it can't be 8/9, it has to be 9/10. You could progress 8.x along its current trajectory, possibly building 8.4 a year or so from now and then be done with it, and then that would be the last short/unfocused release. I often have to deal with FUD at work, especially when the developers learn that FreeBSD has, for example, released FreeBSD 9.0 somewhat indicating that oh, no -- we're obsolete?! In which I've always had to then explain how FreeBSD has three versions running simultaneously at all times -- a legacy release, a stable release, and a future release, and they are happy with such an explanation. I usually then go on to explain back in the day it was 4/5/6, and now it's 8/9/10. Naturally, this is an over-simplified view of the situation, but it sure would be a nice view if it were absolutely true. There ought to be a charter that explicitly defines the types of things you can expect from each release (regardless of which release): For example, the legacy release (which might as well be 8.x now) should: a. Receive all security patches until deprecated b. Receive critical bug fixes until deprecated c. Benefit from trivial hardware device additions (e.g., developer adds 0x10de device identifier to if_bgereg.h to add new hardware support to bge(4)) Meanwhile, the stable release (which might as well be 9.x now) should: a. Receive all security patches b. Receive critical bug fixes c. Benefit from ALL hardware device changes except experimental ones and those that completely redesign the driver Last, the current release (which might as well be 10.x now) should: a. Be the landing zone for all new code, experimental or otherwise. Finally, the charter ought to also define when a current can become stable ... not define some arbitrary timeline which results in situations like that which was previously mentioned in this thread (9.0 shipped as stable release with completely broken gmultipath). Then you postpone 10.0-RELEASE until January 2017. Instead of having a legacy branch and two production branches, you would have legacy (8) production (9) and ... nothing. Or if you need to have it out there, 10 is the development branch. +1 Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at the end of the cycle. Ought we to have one timeline for stable (aka production) and a different timeline for legacy? Say, cut a new release in legacy 1-2 times a year and cut a new release in production 2-3 times a
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 01:11, Eitan Adler li...@eitanadler.com wrote: It takes time to review and test patches. There are a lot of people that think it only takes 30 seconds to download the patch, apply, and commit. This is just not true. I fully understand that and it is not what I was saying, what I was saying was about the patches that were being plainly ignored/allowed to go stale. What you said below is perfectly reasonable once a committer is actively involved in dealing with a patch, then I, and anyone else for that matter, would be very reasonably expected to be involved in the process and understands that someone else is working on the issue you've address. The problem, however, lies in the time between a patch is submitted and is picked up, if the latter ever occurs!.. That is where the discouragement occurs. [snip] And this assumes the patch was perfect, there really was a bug, and everyone thinks things through properly. The process take anywhere from half an hour for obvious fixes to multiple days in addition to the committer's work, school, and family obligations.. I hope I've address what you say here just above :-) and wholeheartedly agree with everything else you've said, but you are addressing the problem from a different angle: nobody is ever going to disagree that _once_ someone has picked up a patch it will take them time to get it through whatever steps necessary. But, as I said above, it's getting to *this* stage that is the lengthy and a disheartening process... [snip] If you have ideas to make this process easier or more efficient we are all eager to hear them. I am especially interested to know what *I* could do to help speed things along in areas I don't know well enough to commit to. The problem, which I suspect is very difficult to overcome in what I call the bazaar environment, is the enforcement. One way to encourage people to fix their code would be to prevent them from committing to -CURRENT once they pass a certain threshold of unattended patches. Of course then, committers will be whinging that they'd be resigning if they can't commit to -CURRENT, but quite frankly, why should anyone have the commit privilege if they can't be bothered to address the bugs, are those people just using the FreeBSD project to boost their CV (with great powers comes great responsibility!)? -- Igor M. :-) ___ 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
tzsetup(8) patches
Can someone please take a look at 3 patches I've filed against tzsetup(8)? bin/164039: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/164039 [PATCH] tzsetup(8): Don't write /var/db/zoneinfo either when -n is passed or when install_zoneinfo_file returns failure bin/164041: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/164041 [PATCH] tzsetup(8): Remove unnecessary code duplication and clean-up reinstall option bin/164042: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/164042 [PATCH] tzsetup(8): Fix VERBOSE to work with new UTC menu option I have other patches that are waiting on these. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
14 month old regression (how?)
Looking at bin/164192... I'm left wondering to myself... How on Earth did a regression-by-typo introduced in SVN r214735 go 14 months without being noticed? Effected branches include: RELENG_9_0_RELEASE RELENG_9_0 affected for 2 months and 1 week RELENG_9 RELENG_9_0_BP affected for 3 months and 3 weeks MAIN RELENG_9_BP HEAD affected for 14 months and 2 weeks -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 12:11 PM, Mark Saad wrote: Here are My 2 Cents , 1. Support each release longer, or develop a better way to MFS ( Merge from Stable ) bug fixes, and driver updates to RELEASE. It always seams that there are a number of things in X-STABLE I would love to have in X.3-RELEASE and X.4-RELEASE, and I do not want all of X-STABLE just some new drivers and fixes . 2. Spell out the entire RELEASE road map at the beginning of the release. So for 9.0-RELEASE set tentative dates for 9.1, 9.2, 9.x etc . I think by the .2 release of a line we should have some idea as to whether a particular lineage is going to provide a good basis for extended life. if for example we were to declare that 8 is really quite good, we might decide to declare it as having a longer life and allow 9 to die earlier as we go forward. I do understand the requirement for a stable basis for work but I can not say how many of the changes for newer hardware will get ported back. or by who. ___ 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: 14 month old regression (how?)
On Tue, Jan 17, 2012 at 6:21 PM, Devin Teske devin.te...@fisglobal.com wrote: Looking at bin/164192... I'm left wondering to myself... How on Earth did a regression-by-typo introduced in SVN r214735 go 14 months without being noticed? Very carefully. I've seen it happen before on paid products (in fact I've fixed 15 year old bugs thanks to my colorized editor, and I'm sure someone's going to find bugs I've made 1, 5, 10, or 20 years in the future..).. people make mistakes -- it's a fact of life. -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: 14 month old regression (how?)
-Original Message-
From: Garrett Cooper [mailto:yaneg...@gmail.com]
Sent: Tuesday, January 17, 2012 6:29 PM
To: Devin Teske
Cc: freebsd-hackers@freebsd.org
Subject: Re: 14 month old regression (how?)
On Tue, Jan 17, 2012 at 6:21 PM, Devin Teske devin.te...@fisglobal.com
wrote:
Looking at bin/164192...
I'm left wondering to myself...
How on Earth did a regression-by-typo introduced in SVN r214735 go 14
months without being noticed?
Very carefully. I've seen it happen before on paid products (in fact I've
fixed 15
year old bugs thanks to my colorized editor, and I'm sure someone's going to
find
bugs I've made 1, 5, 10, or 20 years in the future..).. people make mistakes
-- it's a
fact of life.
-Garrett
I found the reason why this typo wasn't noticed.
Appears that ${WPA_DISTDIR}/src/crypto is already being declared one-level-up
in the following file:
src/usr.sbin/wpa/Makefile.inc
Otherwise, buildworld would have failed in src/usr.sbin/wpa/wpa_supplicant
complaining about undefined references while linking wpa_supplicant.
The patch in bin/164192 still stands, but I'm going to amend the PR to explain
why this typo went unnoticed for 14 months.
--
Devin
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 3:36 PM, Ian Lepore wrote: On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote: on 17/01/2012 23:46 Ian Lepore said the following: Now, before we're even really completely up and running on 8.2 at work, 9.0 hits the street, and developers have moved on to working in the 10.0 world. What are the chances that any of the patches I've submitted for bugs we fixed in 8.x are ever going to get commited now that 8 is well on its way to becoming ancient history in developers' minds? My opinion is that this will have more to do with your approach to pushing the patches (and your persistence) rather than with anything else. As long as stable/8 is still a supported branch or the bugs are reproducible in any of the supported branches. Well I submitted a sort of random sample of the patches we're maintaining at work, 11 of them as formal PRs and 2 posted to the lists here recently. So far two have been committed (the most important one and the most trivial one, oddly enough). I'm not sure just how pushy one is supposed to be, I don't want to be a jerk. Not to mention that I wouldn't know who to push. That's actually why I'm now being active on the mailing lists, I figured maybe patches will be more accepted from someone the commiters know rather than just as code out of the blue attached to a PR. you are supposed to be as pushy as you need to be.. If you really want your patches in I'd suggest teh following method: 1/ post a summary email explaining all teh bugs and patches 2/ see if anyone takes them up 3/ for the remaining problems, find the names of developers who have committed to that code and contact them asking for their assistance. 4/ report back here ;-) I think it would be great if there were some developers (a team, maybe something not quite that formal) who concentrated on maintenance of older code for the user base who needs it. I'd be happy to contribute to that effort, both on my own time, and I have a commitment from management at work to allow me a certain amount of billable work hours to interface with the FreeBSD community, especially in terms of getting our work contributed back to the project (both to help the project, and to help us upgrade more easily in the future). I have no idea if there are enough developers who'd be interested in such a concept to make it work, co-op or otherwise. But I like the fact that users and developers are talking about their various needs and concerns without any degeneration into flame wars. It's cool that most of the focus here is centered on how to make things better for everyone. -- Ian ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 2:41 PM, Matthew D. Fuller wrote: On Tue, Jan 17, 2012 at 06:57:19PM + I heard the voice of Hugo Silva, and lo! it spake thus: Come to think about it, those days are pretty much gone since 4.x (incidentally, many of us who've stuck with FreeBSD for this long think of 4.x as an epic series). Having been a FreeBSD user for a very long time, I don't think of 4.x as epic. I think of 5.x as a clusterf...un. 4.x didn't last such a long time because everyone thought it was awesome, it was because the next version was still so broken it was the only thing we had to release. 5 was not out on a limb for so long because it was a clusterfun, it was out there because it was a rework of how almost everything in the kernel worked. Everything written since 1978 had to be rewritten to some extent. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 18, 2012 at 01:41:53AM + I heard the voice of Igor Mozolevsky, and lo! it spake thus: The problem, however, lies in the time between a patch is submitted and is picked up, if the latter ever occurs!.. That is where the discouragement occurs. Quite. For instance, we're now well past the 3 year mark since I submitted docs/127908, which fixes 1 sentence in a manpage. So far, I can't see that anybody but me has ever looked at it. That doesn't serve to encourage me to nibble at anything substantial. (In fairness, I should note that I also maintain several ports, and so submit a steady trickle of PR's there. Almost none of them take more than a week from submission to application and closing, and it's fairly common for it to be less than 24 hours. I know the ports team carries a huge load with such things, but they're carrying it well.) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 3:50 PM, Doug Barton wrote: First, let's do away with the whole, If you step up to help, your help will be accepted with open arms myth. That's only true if the project leadership agrees with your goals. leadership doesn't really control development here. action does. We also need to take a step back and ask if throwing more person-hours at the problem is the right solution, or if redesigning the system to better meet the needs of the users *as a first step* is the right answer? careful, you are starting to sound reasonable there.. On 01/17/2012 15:01, Adrian Chadd wrote: .. I'm replying to the OP because honestly, this thread has gotten a bit derailed. If you'd like to see: ... more frequent releases? then please step up and help with all the infrastructure needed to roll out test releases, including building _all_ the ports. A lot of people keep forgetting that a release is build all the ports for all the supported platforms. Does it need to be? I've been pushing a long time now to have a branched ports tree. If we have a stable version of the ports where only known-good changes are promoted then that frees us up quite a bit to redefine what a release is. that's another 'man hours' problem (branched ports) ... longer lifecycle? Then please step up and contribute patches for features for your favourite branch. As a developer doing this in my spare time I'm only really working on new features on -HEAD and maybe backporting fixes to 9.x. What _I_ would like is someone to take on the task of testing and backporting net80211/ath fixes to 8.x and 7.x. So you want to do all the fun stuff, and have someone else do your scut work? Good luck with that. :) Maybe what we need to do is redefine what it means to be a FreeBSD committer. From now on, your commit bit comes with XYZ privileges, but also ABC responsibilities. Sure, we'd lose some people, but what would we gain? Also, your premise is flawed. We (speaking generally) suck at supporting more than one -stable branch. We *really* suck at supporting three. Six months ago when the machinery was just beginning to spin up for 9.0-RELEASE I tried to get the PTB to reconsider. I was told that my concerns were invalid because it was basically ready to go as is. The plan I laid out at the time was to have no more than 2 stable branches extant at any given time. Lengthen the periods where each stable branch is supported, and terminate the oldest one when the newest one is released. I certainly think 9.0 was premature.. 8.x just started.. this should have been 8.3. ... longer branch lifecycle? Same as above. None of the developers are going to reject bugfixes and backported drivers to a legacy, stable branch. We may be a bit against the idea of porting entire new subsystems to legacy, stable branches - but if there's a good enough reason _and_ it's been tested _and_ there's a need for it - _I_ wouldn't say no. But committers already fail to MFC *existing* bug fixes to stable branches (even ones they generated). This is especially true for the older branches. So how is the idea of users generating more new bug fixes going to help? usually it's because they just forgot.. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of Julian Elischer, and lo! it spake thus: 5 was not out on a limb for so long because it was a clusterfun, it was out there because it was a rework of how almost everything in the kernel worked. I'm not saying it was a cluster because it was a huge amount of very deep work; it's because that huge amount of very deep work completely gated our next release. Now, sure, changing external circumstances caught us with our pants down, and the tools we were using (like CVS) made it hard to do anything else. But that just means there were good reasons why it happened; doesn't make it less clusterfull :) The two circumstances (giant rework, and long period between major releases) are duals of each other. If we chop off giant piles of stuff to do for FreeBSD-next, it's going to take a very long time. And if we instead just set very long times (Jan 2017 for 10?! Insanity!) for -next, we're going to end up with giant reworks and huge differences. And _both_ faces are very bad. The one means we wait forever for any new work, and the other means that it takes enormous amounts of work as a user to transistion across the barrier. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Jan 17, 2012, at 7:05 PM, Matthew D. Fuller fulle...@over-yonder.net wrote: On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of Julian Elischer, and lo! it spake thus: 5 was not out on a limb for so long because it was a clusterfun, it was out there because it was a rework of how almost everything in the kernel worked. I'm not saying it was a cluster because it was a huge amount of very deep work; it's because that huge amount of very deep work completely gated our next release. Now, sure, changing external circumstances caught us with our pants down, and the tools we were using (like CVS) made it hard to do anything else. But that just means there were good reasons why it happened; doesn't make it less clusterfull :) The two circumstances (giant rework, and long period between major releases) are duals of each other. If we chop off giant piles of stuff to do for FreeBSD-next, it's going to take a very long time. And if we instead just set very long times (Jan 2017 for 10?! Insanity!) for -next, we're going to end up with giant reworks and huge differences. And _both_ faces are very bad. The one means we wait forever for any new work, and the other means that it takes enormous amounts of work as a user to transistion across the barrier. We could adopt a cycle similar to the Linux Kernel... Odd numbered releases are experimental while even numbered releases are stable (ducks for flying fruit) _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: * Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 7:12 PM, Devin Teske wrote: On Jan 17, 2012, at 7:05 PM, Matthew D. Fullerfulle...@over-yonder.net wrote: On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of Julian Elischer, and lo! it spake thus: 5 was not out on a limb for so long because it was a clusterfun, it was out there because it was a rework of how almost everything in the kernel worked. I'm not saying it was a cluster because it was a huge amount of very deep work; it's because that huge amount of very deep work completely gated our next release. Now, sure, changing external circumstances caught us with our pants down, and the tools we were using (like CVS) made it hard to do anything else. But that just means there were good reasons why it happened; doesn't make it less clusterfull :) The two circumstances (giant rework, and long period between major releases) are duals of each other. If we chop off giant piles of stuff to do for FreeBSD-next, it's going to take a very long time. And if we instead just set very long times (Jan 2017 for 10?! Insanity!) for -next, we're going to end up with giant reworks and huge differences. And _both_ faces are very bad. The one means we wait forever for any new work, and the other means that it takes enormous amounts of work as a user to transistion across the barrier. the trouble with 5 was that it had to be all-or-nothing. there is no such thing as a partly SMP system. (well, not one that you'd want to run). the size of the giant pile of stuff was not of our choosing. We could adopt a cycle similar to the Linux Kernel... Odd numbered releases are experimental while even numbered releases are stable (ducks for flying fruit) _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, Mark Felder wrote: To be fair, it could be worse -- OpenBSD secretly wants you to run snapshots and CURRENT as the RELEASEs are mostly unmaintained outside of the most extreme security concerns. Even the packages are kept at the exact version of the time of release. = and how many corps are running openBSD? talk about an OS that seems to exist only as a playground for its developers... -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - All censorships exist to prevent anyone from challenging current conceptions and existing institutions. All progress is initiated by challenging current conceptions, and executed by supplanting existing institutions. Consequently, the first condition of progress is the removal of censorships. -- George Bernard Shaw ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18/01/12 10:07 +1300, Atom Smasher wrote: On Tue, 17 Jan 2012, Mark Felder wrote: To be fair, it could be worse -- OpenBSD secretly wants you to run snapshots and CURRENT as the RELEASEs are mostly unmaintained outside of the most extreme security concerns. Even the packages are kept at the exact version of the time of release. = and how many corps are running openBSD? talk about an OS that seems to exist only as a playground for its developers... This is more or less like Debian in regards to their packaging. Admittedly, OpenBSD is way up there on the paranoia scale, but I know of plenty of big companies running OpenBSD on large scale routing infrastructure. -- richo || Today's excuse: Your Pentium has a heating problem - try cooling it with ice cold water.(Do not turn off your computer, you do not want to cool down the Pentium Chip while he isn't working, do you?) http://blog.psych0tik.net signature.asc Description: Digital signature
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 15:07:56 -0600, Atom Smasher a...@smasher.org wrote: and how many corps are running openBSD? Works amazingly well as an edge router. You get pf, openbgpd, openspfd much higher performance that 50K cisco gear. The bugs we've hit have been fixed promptly as well. Pretty decent little setup for a budget. But yeah, not many do what we do. ___ 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: * Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 07:20:15PM -0800 I heard the voice of Julian Elischer, and lo! it spake thus: the trouble with 5 was that it had to be all-or-nothing. [...] the size of the giant pile of stuff was not of our choosing. As may be, it's beside my point. Whether due to malice, incompetence, or the unalterable ways of the universe, 5 spent something approaching forever not ready to release, and depending on who you ask, kept that status until it became known as 6.0. And that, not 4 is awesome, is the principal reason 4 kept chugging so long. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: * Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/17/2012 19:20, Julian Elischer wrote: the trouble with 5 was that it had to be all-or-nothing. there is no such thing as a partly SMP system. (well, not one that you'd want to run). the size of the giant pile of stuff was not of our choosing. ... again, with all due respect to those who worked so hard to get 5.0 out the door ... That's not quite true. The original goal for 5.0 was to completely remove the Giant lock (and do other cool SMP-related stuff). Eventually it was realized that this was too big a goal to fully accomplish in 5.0 (albeit too late in the process) and the goal was changed to do the basic framework for the new SMP model; and lay the groundwork for some things run under Giant for now, and we'll remove it from them ASAP. That actually turned out to last through 6, making 7 the realization of what 5.0 was supposed to be. So what we need to do is to learn from the mistakes that were made, and figure out how we can make *reasonable* plans for both new features, and the framework for the future development that we want; without making the all or nothing mistake again. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: * Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Devin Teske wrote: [...] We could adopt a cycle similar to the Linux Kernel... Odd numbered releases are experimental while even numbered releases are stable I do not know the current state things in Linux kernel, but as far as I know 2.6 branch was not stable. It was branch with a lot of experimental code and with a lot of API change. rik (ducks for flying fruit) _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
