Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote: 1. Incidentally, what exactly does constitute a major release? That point in time where we guarantee that we break a certain degree of backwards compatibility. (Well, that's the key component. Feature- additions ride on top of that.) 2. Is there a reason to update the numbers so quickly? Yes, so that we don't have to keep supporting backwards compatibility for as long a period (see 1) -- it's a significant burden to maintain. It's necessary to do these as we rework things like network layers for higher performance, rework wireless to work with modern devices, and other high-demand items. 3. Could a higher bar be set to reach a major release than simply temporal objectives? Yes. We did that with 5.x, and blew it big-time. The goal of rewrite the entire system to support SMP in a scalable, reliable fashion was simply too aggressive. It led to ~5 years between major releases, and by that time the system had changed very dramatically (SMP, suspend/resume, IIRC GEOM, and too many other things to list). It was a huge jump and the learning curve for upgrading was way too large. We lost userbase. Also, keeping 5 years between major releases led to very high developer frustration. Why work on something when it will take 4+ years to even see the light of day? This is why we moved to the time-based releases. 18 months was seen as a compromise between all the various demands. Even so, we are almost exactly at 24 months in practice; see the graphs I updated last month as a result of all the recent discussion: http://people.freebsd.org/~linimon/schedule/ My own view is that 5 years between major releases is not going to happen, due to how painful the 5.x experience was for all concerned. But as I'm not a src committer, I'm not one of the people who will be picking the interval for our major-branch timeline. I just try to graph it as it goes by. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
The individual maintainers of each architecture have the right to make a PRE-RELEASE of the system at any time. Come to think of it, anyone who can has that right- that is to make a pre-release. On 2/18/12, Mark Linimon lini...@lonesome.com wrote: On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote: 1. Incidentally, what exactly does constitute a major release? That point in time where we guarantee that we break a certain degree of backwards compatibility. (Well, that's the key component. Feature- additions ride on top of that.) 2. Is there a reason to update the numbers so quickly? Yes, so that we don't have to keep supporting backwards compatibility for as long a period (see 1) -- it's a significant burden to maintain. It's necessary to do these as we rework things like network layers for higher performance, rework wireless to work with modern devices, and other high-demand items. 3. Could a higher bar be set to reach a major release than simply temporal objectives? Yes. We did that with 5.x, and blew it big-time. The goal of rewrite the entire system to support SMP in a scalable, reliable fashion was simply too aggressive. It led to ~5 years between major releases, and by that time the system had changed very dramatically (SMP, suspend/resume, IIRC GEOM, and too many other things to list). It was a huge jump and the learning curve for upgrading was way too large. We lost userbase. Also, keeping 5 years between major releases led to very high developer frustration. Why work on something when it will take 4+ years to even see the light of day? This is why we moved to the time-based releases. 18 months was seen as a compromise between all the various demands. Even so, we are almost exactly at 24 months in practice; see the graphs I updated last month as a result of all the recent discussion: http://people.freebsd.org/~linimon/schedule/ My own view is that 5 years between major releases is not going to happen, due to how painful the 5.x experience was for all concerned. But as I'm not a src committer, I'm not one of the people who will be picking the interval for our major-branch timeline. I just try to graph it as it goes by. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ 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 27 Jan 2012, at 03:26, Mark Linimon wrote: On Thu, Jan 26, 2012 at 10:52:44PM +, Mark Blackman wrote: I suspect poor old RE is putting too much work into BETAs and RCs for point releases. The counter-argument is that we have a lot more leeway to make mistakes on a .0 release. We're not going to be cut any slack at all for shipping a badly regressed point release. Some minor regressions are inevitable in software, but they do indeed need to be minor. For how we're doing with regressions in general, see: http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html Now, it's true that many of the recent PRs are against 9.0, and many of the ones that aren't may be stale (certainly most of the pre-2010 ones), but these are the types of things that users really notice and become unhappy about. All good points, although I'd guess there's some diminishing returns argument for progressive RCs/BETAs, however probably only the RE team have a good feeling for the sweet spot. - 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 01/20/12 09:13, John Kozubik wrote: I normally hate to dredge up old threads, but this is like getting halfway through a story and not finding out the ending... :) What is the answer? Is there a solution to this? I have a string of questions on this: 1. Incidentally, what exactly does constitute a major release? 2. Is there a reason to update the numbers so quickly? 3. Could a higher bar be set to reach a major release than simply temporal objectives? One of the differentiating factors between linux and FreeBSD is the simple fact that linux distros tend to run so fast through the numbers- and while just a matter of perspective, it could provide some sense of stability to enterprise users. Weighed against, of course, the ability to upgrade easily. 4. If in the case of the former, could some backporting to the stable and release branches facilitate an easy upgrade to the next major release? 5. Could binaries be the answer to easier upgrades (customised for enterprise users)? I'd really like to know the OP's thoughts on this... 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
On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote: On 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: I just want to chime in here, what is the deal with killing off a potential 7.5-RELEASE ? Having a few 7.3-RELEASE and 7.4-RELEASE servers I would like to see a 7.5-RELEASE that is supported to 2015 to prevent another major upgrade cycle . There are still freebsd developers working on 7-STABLE and its been reliable and working for me and I am sure a few other people. What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. That's not actually true or really fair. There has to be some buy-in from the project to do an official release; it is not something that a single person can do off in a corner and then have the Project bless the bits as an official release. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 26 Jan 2012, at 14:37, John Baldwin wrote: On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote: On 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. That's not actually true or really fair. There has to be some buy-in from the project to do an official release; it is not something that a single person can do off in a corner and then have the Project bless the bits as an official release. And raises the interesting question for an outsider of a) who is the project in this case and b) what does it take for a release to be a release? Wasn't there a freebsd-releng (or similar) mailing list ages ago? I didn't spot an active one at http://docs.freebsd.org/mail/ - 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 Thursday, January 26, 2012 11:49:22 am Mark Blackman wrote: On 26 Jan 2012, at 14:37, John Baldwin wrote: On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote: On 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. That's not actually true or really fair. There has to be some buy-in from the project to do an official release; it is not something that a single person can do off in a corner and then have the Project bless the bits as an official release. And raises the interesting question for an outsider of a) who is the project in this case and b) what does it take for a release to be a release? I'll answer the two together. The project is the entity that owns freebsd.org and a release is not a release unless it is present on ftp.freebsd.org and has a signed announcement e-mail with hashes, etc. on the freebsd-announce@ mailing list. Without those things there is no reason for a user to believe that a particular set of bits is a legitimate FreeBSD release. Additionally, a release should be available via the appropriate tags in the CVS and SVN repositories available from freebsd.org machines. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 26 Jan 2012, at 18:22, John Baldwin wrote: On Thursday, January 26, 2012 11:49:22 am Mark Blackman wrote: a) who is the project in this case and b) what does it take for a release to be a release? I'll answer the two together. The project is the entity that owns freebsd.org and a release is not a release unless it is present on ftp.freebsd.org and has a signed announcement e-mail with hashes, etc. on the freebsd-announce@ mailing list. Without those things there is no reason for a user to believe that a particular set of bits is a legitimate FreeBSD release. Additionally, a release should be available via the appropriate tags in the CVS and SVN repositories available from freebsd.org machines. Thanks. I wonder who that entity is? Everyone with a commit bit, or perhaps just the RE team? Anyway, it's not very important in this context. I also tracked this down, but might be out of date. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. To be honest, I'm sure we all agree this sort of discussion is not useful on hackers and obviously at some point needs to turn into work rather than points of view. Mostly it just boils down, lets see if we can do -STABLE point releases a bit more frequently. - 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 26 Jan 2012, at 22:49, Mark Linimon wrote: On Thu, Jan 26, 2012 at 10:23:43PM +, Mark Blackman wrote: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. That was our intention at one point. Obviously we've not stuck to that. (IMHO doing releases quite that frequently is probably beyond what we can do with volunteer staffing, but I'm not on re@ so take it as you will.) In any case, various people within the project have now absorbed the lesson that 10 months between releases is too long, and are trying to figure out what to do about it. Indeed, I was just reviewing the last couple of years of release and the thing that struck me was the number of BETAs and RCs for each point release. I suspect poor old RE is putting too much work into BETAs and RCs for point releases. - 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 Thu, Jan 26, 2012 at 10:23:43PM +, Mark Blackman wrote: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. That was our intention at one point. Obviously we've not stuck to that. (IMHO doing releases quite that frequently is probably beyond what we can do with volunteer staffing, but I'm not on re@ so take it as you will.) In any case, various people within the project have now absorbed the lesson that 10 months between releases is too long, and are trying to figure out what to do about it. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Mark Blackman wrote: On 26 Jan 2012, at 14:37, John Baldwin wrote: On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote: On 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. That's not actually true or really fair. There has to be some buy-in from the project to do an official release; it is not something that a single person can do off in a corner and then have the Project bless the bits as an official release. And raises the interesting question for an outsider of a) who is the project in this case and b) what does it take for a release to be a release? Wasn't there a freebsd-releng (or similar) mailing list ages ago? I am going to avoid the above question, since I don't know the answer and I believe other(s) have already answered it. However, I will throw out the following comment: I can't seem to find the post, but someone suggested a release mechanism where stable/N would simply be branched when it appeared to be in good shape. Although I have no idea if this is practical for all releases, it seems that it might be a low overhead approach for releases off old stable branches like stable/7 currently is? (ie. Since there aren't a lot of commits happening to stable/7, just branch it. You could maybe give a one/two week warning email about when this will happen. I don't think it would cause a flurry of commits like happens when code slush/freeze approaches for a new .0 one.) Just a thought, rick ___ 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 Thu, Jan 26, 2012 at 10:52:44PM +, Mark Blackman wrote: I suspect poor old RE is putting too much work into BETAs and RCs for point releases. The counter-argument is that we have a lot more leeway to make mistakes on a .0 release. We're not going to be cut any slack at all for shipping a badly regressed point release. Some minor regressions are inevitable in software, but they do indeed need to be minor. For how we're doing with regressions in general, see: http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html Now, it's true that many of the recent PRs are against 9.0, and many of the ones that aren't may be stale (certainly most of the pre-2010 ones), but these are the types of things that users really notice and become unhappy about. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon lini...@lonesome.com wrote: I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happen. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. That's odd. What the src committers usually tell me, when I have my bugmeister-advocate hat on, is that they post patches and then no one comments until after they check them in, at which time they complain. This discourages them from going through this the next time. exactly my point, huge patches are impossible to review. You will also note that some of the large commits say MFp4 or MF: projectname. That means that either our Perforce repository, or SVN project/ directory, were used as staging areas. It's possible to subscribe to these email messages. (Exactly how is left as an exercise for the reader; the hour is getting late.) that is indeed a good source for having a look at early-alpha-WIP stuff. As for the research lab/company commits, I'm sure you'd complain equally if the code that these groups develop in-house and then release when it's in some kind of stable state, instead didn't get released at all. I see company contributed code as ad-hoc solution to the company's problem, not general solution for the whole FreeBSD userbase. To make a comparison with Linux, it is just as if Google got all the Android code merged in mainline as-is, without re-working anything. It did not happen that way. Much of their code had (and still has) to be re-designed, abstracted, and adapted to fit the general-purpose mainline. But, of course, I'm wasting my time trying to give you reasoned arguments about why FreeBSD does one thing or another. AFAICT you're only interested in spreading FUD about what we do, how we do it, and what we say about it before, during, and afterwards. is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/160992 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156540 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156799 ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027400.html ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030076.html ? answer to all the above: no, this is bugs, regressions, and mis-design you folks introduced, not me. Don't blame me to point it out. You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. There is tons of ad-hoc code in FreeBSD which should be properly generalized. The most silly example I can think about is `time_after()', defined in net80211/ieee80211_freebsd.h. This has _nothing_ to do specifically with IEEE802.11, it's about time manipulation. Feel free to search the tree, there is tons of potentially unsafe, open-coded version of this macros. Call it nit-picking if you want, but when I write code, I want an API to use, I'm fed up to always have to re-invent the wheel. Btw, I do not even speak about some functions in the kernel re-implementing the exact same logic +10 times in a row, one after the other, within the same function body... For the story, I've been hacking tonight in Linux... a pure pleasure, real tough to get to, but really enjoyable. Whatever patches or review you've contributed to date, to my mind, are like the last tiny little bits of onion that are left over after one peels off all the outer layers. There may be something to it, but the effort to get down to that point is so painful that it's not worth it. tl;dr: your drama outweighs your contributions. I already commented on this. I'm no longer interested in getting my stuff integrated in FreeBSD. I put it on github, eventually send patches on MLs, then you do what you want with it, I no longer particularly care. I know some patches are used around, that's enough. I did my time fighting committers to fix their not-so-bugfree code and won those battles, that's enough for me. - Arnaud ps: I have a particular appreciation for this PR, a feature praised by users, and no committer dares to care: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/161553 ... silly. ___ 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 25, 2012 at 9:58 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon lini...@lonesome.com wrote: I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happen. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. That's odd. What the src committers usually tell me, when I have my bugmeister-advocate hat on, is that they post patches and then no one comments until after they check them in, at which time they complain. This discourages them from going through this the next time. exactly my point, huge patches are impossible to review. You will also note that some of the large commits say MFp4 or MF: projectname. That means that either our Perforce repository, or SVN project/ directory, were used as staging areas. It's possible to subscribe to these email messages. (Exactly how is left as an exercise for the reader; the hour is getting late.) that is indeed a good source for having a look at early-alpha-WIP stuff. As for the research lab/company commits, I'm sure you'd complain equally if the code that these groups develop in-house and then release when it's in some kind of stable state, instead didn't get released at all. I see company contributed code as ad-hoc solution to the company's problem, not general solution for the whole FreeBSD userbase. To make a comparison with Linux, it is just as if Google got all the Android code merged in mainline as-is, without re-working anything. It did not happen that way. Much of their code had (and still has) to be re-designed, abstracted, and adapted to fit the general-purpose mainline. But, of course, I'm wasting my time trying to give you reasoned arguments about why FreeBSD does one thing or another. AFAICT you're only interested in spreading FUD about what we do, how we do it, and what we say about it before, during, and afterwards. is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/160992 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156540 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156799 ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027400.html ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030076.html ? answer to all the above: no, this is bugs, regressions, and mis-design you folks introduced, not me. Don't blame me to point it out. You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. There is tons of ad-hoc code in FreeBSD which should be properly generalized. The most silly example I can think about is `time_after()', defined in net80211/ieee80211_freebsd.h. This has _nothing_ to do specifically with IEEE802.11, it's about time manipulation. Feel free to search the tree, there is tons of potentially unsafe, open-coded version of this macros. Call it nit-picking if you want, but when I write code, I want an API to use, I'm fed up to always have to re-invent the wheel. Btw, I do not even speak about some functions in the kernel re-implementing the exact same logic +10 times in a row, one after the other, within the same function body... For the story, I've been hacking tonight in Linux... a pure pleasure, real tough to get to, but really enjoyable. Whatever patches or review you've contributed to date, to my mind, are like the last tiny little bits of onion that are left over after one peels off all the outer layers. There may be something to it, but the effort to get down to that point is so painful that it's not worth it. tl;dr: your drama outweighs your contributions. I already commented on this. I'm no longer interested in getting my stuff integrated in FreeBSD. I put it on github, eventually send patches on MLs, then you do what you want with it, I no longer particularly care. I know some patches are used around, that's enough. I did my time fighting committers to fix their not-so-bugfree code and won those battles, that's enough for me. What I'm completely missing is the reason why you're repeating this is my last word or that's enough for me or $THATSALLFOLKS_SENTENCE, but you continue adding some Gaussian noise on the MLs w/out a valid reason. If you enjoy other projects, go there. But please, don't piss off. - Arnaud ps: I have a particular appreciation for this PR, a feature praised by users, and no committer dares to care: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/161553 ... silly. ___ freebsd-hackers@freebsd.org mailing list
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happen. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. That's odd. What the src committers usually tell me, when I have my bugmeister-advocate hat on, is that they post patches and then no one comments until after they check them in, at which time they complain. This discourages them from going through this the next time. You will also note that some of the large commits say MFp4 or MF: projectname. That means that either our Perforce repository, or SVN project/ directory, were used as staging areas. It's possible to subscribe to these email messages. (Exactly how is left as an exercise for the reader; the hour is getting late.) As for the research lab/company commits, I'm sure you'd complain equally if the code that these groups develop in-house and then release when it's in some kind of stable state, instead didn't get released at all. But, of course, I'm wasting my time trying to give you reasoned arguments about why FreeBSD does one thing or another. AFAICT you're only interested in spreading FUD about what we do, how we do it, and what we say about it before, during, and afterwards. You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Whatever patches or review you've contributed to date, to my mind, are like the last tiny little bits of onion that are left over after one peels off all the outer layers. There may be something to it, but the effort to get down to that point is so painful that it's not worth it. tl;dr: your drama outweighs your contributions. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 25, 2012 at 03:58:41AM -0500, Arnaud Lacombe wrote: You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. I'm talking about the semantics of the non-technical part: the wording of things that people post in email. viz: the time-wasting nonsense about oh, it seems to be released already, has anyone noticed? from a few weeks ago. It was 100% FUD, which apparently you knew perfectly well at the time, and thus AFAICT only posted it to draw attention to yourself. That's the drama I'm talking about. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, On Wed, Jan 25, 2012 at 3:22 PM, Mark Linimon lini...@lonesome.com wrote: On Wed, Jan 25, 2012 at 03:58:41AM -0500, Arnaud Lacombe wrote: You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. I'm talking about the semantics of the non-technical part: the wording of things that people post in email. viz: the time-wasting nonsense about oh, it seems to be released already, has anyone noticed? from a few weeks ago. It was 100% FUD, which apparently you knew perfectly well at the time, and thus AFAICT only posted it to draw attention to yourself. That's the drama I'm talking about. you are misquoting and misinterpreting me, I merely asked Has 9.0 been released ?, followed by misleading clues I tried to gather in a thread where the original poster's uname shown 9-RELEASE. I see no FUD in this and none was intended. The rest of the thread indeed went ballistic. - Arnaud ___ 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
Mark Linimon lini...@lonesome.com pisze: On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote: I submit PRs and try to help test them as some developer/committer will pick up the PR, submit a patch to test, but it was MANY times that the response from developer/committer was way too long that I even DID NOT HAVE THE HARDWARE anymore ... I don't have a magic wand to solve this problem. I've spent a lot of time thinking about it and it's just a hard problem to solve in general. There are several aspects: - so many computers are very broken (specifically, horrible BIOS bugs). - most committers only have one or two computers that they work with. - most committers have their own tasklist, and support users is something they never have time to get around to. support users is, in general, something Open Source OSes do not do very well (at least without a paid support staff, as is the case in some of the Linux distros.) But what's discouraging for the people that try to clean up the stale PRs is that they get yelled at when they try to do so. Thus, they tend to get demotivated as well. Support/bug triage is hard and unrewarding work. People can tend to feel that they're being blamed for bugs that they had nothing to do with creating, and burn out. Hi, I do not have anything against You, or any other commiter/developer, maybe the answer to that PR should be 'I have checked that and that, but I do not have that hardware so no luck ...' It would be also great to have FreeBSD base system tool, that would collect all system data, dmesg, uname, hardware configuration, literally EVERYTHING, that would provide some useful input for a commiter/developer. It would also be good to have some wiki.freebsd.org page that would describe what information is needed to fill a good PR if such tool is not going to 'happen', I could write a simple SH script myself, that would collect dmesg/dmidecode/uname and more output from other commands, but I do not know what knowledge You need, so that simple program to get all that useful data can help a little, at least in theory. Here is one of the messages that I sent by then to the mailing lists: http://lists.freebsd.org/pipermail/freebsd-doc/2007-May/012507.html ... and NOTHING HAPPENED, no one told me what to do next, should I sent a SGML version or anything ... or just GTFO. I'm sorry that nothing happened, but unfortunately that's common. Submitters sometimes have to be persistent, and maybe even catch new committers when they sign up. Our documentation is certainly in need of updating. I still was (or at least felt) that was a FreeBSD newbie that time, so I did not knew if my 'handbook part' was just rubbish, or stupid, or ... whatever, no one responded, so I assumed that its not needed/useless and moved along. It would be also good to have a wiki.freebsd.org page describing what is needed and in what format a user should send the documentation changes, currently its just wasting developers' time for asking them how to do that and that, what format, where to send it ... What I have done about these 'Ports issues'? I contacted these ports maintainers and said that both RC script and AIO support for samba should be enabled by default by linking to several threads at FreeBSD Forums that the problem is known and exists ... and I did not get ANY RESPONSE till this very day, not even a GTFO (which would probably be better then nothing). When you don't get a response from a maintainer, your best bet is to file a PR against the port. If the maintainer doesn't respond, then after 2 weeks any FreeBSD ports committer is free to work on the PR and, if they agree with you, commit it via maintainer-timeout. We don't have a way to track emails that various users send to individual maintainers. With a PR open, we have a way to do that. We also track maintainer-timeouts, and these can eventually lead to a maintainer reset. I have now filled these PR's here: http://www.freebsd.org/cgi/query-pr.cgi?pr=164431 http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 It's not that people does not try to help, a lot tried (and I am still trying), but its VERY unpleasant to have awareness, that you dedicated your time, tried to help as much as possible, made some steps to achieve that ... and no one even cares about that. I think it's not don't care, I think it's that unable to cope with number of incoming PRs and other requests for changes and support. As I type this, there are 1122 ports PRs (6272 total PRs). On most days, around 40 come in. It would take a few dozen more volunteers to be able to keep up with them all. mcl So its time for another article/page on wiki.freebsd.org, how to become a commiter and help to solve PRs', how to add your mirror to FreeBSD project, etc, etc ... Regards and have a nice day, vermaden ...
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, Mark Linimon lini...@lonesome.com pisze: We don't have a way to track emails that various users send to individual maintainers. With a PR open, we have a way to do that. We also track maintainer-timeouts, and these can eventually lead to a maintainer reset. It is less a problem of having the tools than having the will to do everything publicly. From experience, committers loves to do all kind of things privately/secretly. - Arnaud ___ 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 24 January 2012 18:36, Arnaud Lacombe lacom...@gmail.com wrote: Hi, Mark Linimon lini...@lonesome.com pisze: We don't have a way to track emails that various users send to individual maintainers. With a PR open, we have a way to do that. We also track maintainer-timeouts, and these can eventually lead to a maintainer reset. It is less a problem of having the tools than having the will to do everything publicly. From experience, committers loves to do all kind of things privately/secretly. Hm, a bit of a paradox-- I now deny that anything like that happens secretly, then you ask for proof? 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 24 January 2012 18:36, Arnaud Lacombe lacom...@gmail.com wrote: It is less a problem of having the tools than having the will to do everything publicly. From experience, committers loves to do all kind of things privately/secretly. Perhaps it's human nature because of all the increasingly nit-picky, passive- agressive, whiny, sarcastic, and generally asinine postings such as yours. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, On Tue, Jan 24, 2012 at 4:10 PM, Mark Linimon lini...@lonesome.com wrote: On 24 January 2012 18:36, Arnaud Lacombe lacom...@gmail.com wrote: It is less a problem of having the tools than having the will to do everything publicly. From experience, committers loves to do all kind of things privately/secretly. Perhaps it's human nature because of all the increasingly nit-picky, passive- agressive, whiny, sarcastic, and generally asinine postings such as yours. You are indeed right. However, I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happens. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. regards. - Arnaud ___ 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 24, 2012 at 12:24:22PM +0100, vermaden wrote: It would also be good to have some wiki.freebsd.org page that would describe what information is needed to fill a good PR See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ . Your suggestion to include things like dmidecode is a good one, and we should add those. I still was (or at least felt) that was a FreeBSD newbie that time, so I did not knew if my 'handbook part' was just rubbish, or stupid, or ... whatever, no one responded, so I assumed that its not needed/useless and moved along. I'm hoping that the forums are a better place for new users to ask questions these days, than the high-volume mailing lists. In theory it should be a more appropriate venue. (Having said that, I don't participate in the forums due to lack of time, but I understand there is a community of moderators and seasoned users on it.) It would be also good to have a wiki.freebsd.org page describing what is needed and in what format a user should send the documentation changes Perhaps there should be a docs analogue to the following: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ doc folks, any takers? I have now filled these PR's here: http://www.freebsd.org/cgi/query-pr.cgi?pr=164431 http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 Thanks. This makes these issues visible. So its time for another article/page on wiki.freebsd.org, how to become a committer and help to solve PRs' See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ http://wiki.freebsd.org/BecomingACommitter how to add your mirror to FreeBSD project See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/hubs/index.html So, let me add in conclusion, I'm willing to give a hearing to constructive criticism such as this posting. There are some good, concrete, suggestions here. If I've given the impression in my earlier response that I'm not, I'm sorry. OTOH I see a lot of non-constructive criticism go by and you'll have to excuse me for being rude to those posters. After the Nth posting like that it's simply too much for my patience. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 24 Jan 2012 15:23:47 -0600 Mark Linimon lini...@lonesome.com wrote: On Tue, Jan 24, 2012 at 12:24:22PM +0100, vermaden wrote: It would be also good to have a wiki.freebsd.org page describing what is needed and in what format a user should send the documentation changes Perhaps there should be a docs analogue to the following: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ doc folks, any takers? You mean something like: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ Making it a bit easier to find would probably be a good idea. 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
It would also be good to have some wiki.freebsd.org page that would describe what information is needed to fill a good PR See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ Thanks, I will read it. I have now filled these PR's here: http://www.freebsd.org/cgi/query-pr.cgi?pr=164431 http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 Thanks. This makes these issues visible. One of them is already closed ... with ZERO changes, the reason from the person that closed it: This is intended, as vsftpd is started by inetd ... great, but not ALL FreeBSD users want to use inetd, why force them to compile it, is that one file that big or painful that it can not be added to the port? So its time for another article/page on wiki.freebsd.org, how to become a committer and help to solve PRs' See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ http://wiki.freebsd.org/BecomingACommitter Thanks I did not knew them, seems that there are a lot of useful materials/articles that are mostly known by developers/commiters and not 'casual' users, maybe a 'The Wall' page on freebsd.org with all these useful articles/pages? Kind regards, vermaden ... ___ 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, 25 Jan 2012 00:05:55 +0100 vermaden verma...@interia.pl wrote: I have now filled these PR's here: http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 Thanks. This makes these issues visible. One of them is already closed ... with ZERO changes, the reason from the person that closed it: This is intended, as vsftpd is started by inetd ... great, but not ALL FreeBSD users want to use inetd, why force them to compile it, is that one file that big or painful that it can not be added to the port? I don't know why the PR was closed this way, but given that the bug report is simply a statement of a fact, without saying why you consider this fact to be a bug, or any other justification for wanting the change, closing it as works as intended seems like a perfectly reasonable response. If you had explained *why* you wanted that changed, and provide some justification for doing so (i.e. - point out that no inetd compliant program, so the default config of the port won't run on the default config of FreeBSD), you might have gotten a different response. Of course, that kind of discussion isn't really appropriate for a PR, since it's really a feature request. As such it deserves a bit of work finding out why it's that way to begin with. All of is covered in the problem-reports document already mentioned in this thread: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ 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
Mike Meyer m...@mired.org pisze: On Wed, 25 Jan 2012 00:05:55 +0100 vermaden wrote: I have now filled these PR's here: http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 Thanks. This makes these issues visible. One of them is already closed ... with ZERO changes, the reason from the person that closed it: This is intended, as vsftpd is started by inetd ... great, but not ALL FreeBSD users want to use inetd, why force them to compile it, is that one file that big or painful that it can not be added to the port? I don't know why the PR was closed this way, but given that the bug report is simply a statement of a fact, without saying why you consider this fact to be a bug, or any other justification for wanting the change, closing it as works as intended seems like a perfectly reasonable response. If you had explained *why* you wanted that changed, and provide some justification for doing so (i.e. - point out that no inetd compliant program, so the default config of the port won't run on the default config of FreeBSD), you might have gotten a different response. Of course, that kind of discussion isn't really appropriate for a PR, since it's really a feature request. As such it deserves a bit of work finding out why it's that way to begin with. All of is covered in the problem-reports document already mentioned in this thread: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ I have sent this in reply to that cosed PR: --- ... and if someone DOES NOT WANT to run it by INETD? Why force people to (definitely needless) compile process while this little option/small fail can make like so much easier for everyone that do not use inetd? There are multiple threads at FreeBSD Forums that this script is missing from the package. Also I do not no ANY OTHER package for daemon that has RC_NG script as an option, all of them provide RC_NG script by default, so that is what a user/admin is expecting. Adding this file does not break INETD functionality and only adds a sollution to start it by RC_NG script. Its just one harmless file, why is it such a big problem? --- Regards, vermaden ... ___ 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, Atom Smasher wrote: thanks john. i've been a long-time (10+ years) freeBSD user (desktops, laptops, servers, and anywhere else i can run it) and advocate (encouraging others to at least check it out) and also a long-time satisfied johnco customer. my freeBSD days seem to be coming to an end. 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...? i really like freeBSD's robustness, especially compared to linux, among other things. i like that freeBSD is genetically a real unix... what's the real difference between BSD and linux? BSD was developed by unix hackers porting the OS to PC hardware; linux was developed by PC hackers trying to make their own version of unix. these origins are still very apparent, if one knows where to look. i like that i can set up a freeBSD bare-bones (eg secure) mail-server or web-server in an afternoon. but none of that matters if the damn thing just doesn't work. over the last two years, and it pains me to say this, i've been running linux on that T510. but it gets worse... i've been finding that i'm simply more productive on that machine, and spending more time in front of it, and more time getting useful things done. i understand that it's ultimately a matter of manpower and resources, and linux seems to have more momentum and sex appeal, but i'm finding myself in a real crisis of faith... the OS that i've been using and loving for 10+ years seems to be dying, from any real usability perspective. and for now, i'm slowly and reluctantly migrating towards linux. My experience has been pretty much the opposite. I've been using FreeBSD since 2.1 both as part of my job and also for personal use. I've been using Linux for work for about the last ten years. I'm currently running FreeBSD 8.2-STABLE for my personal computing needs. My experience is that the base system has been very solid and the only problems that I run into have been with the ports. The last major problem that I had with the base system was USB printer support in 7.x, which was incomplete and flakey and then deteriorated to the point of being unusable. This motivated me to migrate to 8 which has a rewritten USB implementation. At work, our major software vendor only supports their software on Red Hat Enterprise Linux and SUSE Linux Enterprise. Since our budget is tight, we run CentOS, which is essentially a repackaged version of RHEL. We've been running CentOS 4.x, but are switching to CentOS 5.x now that 4.x has been EOLed. My experience with CentOS is that new features and support for recent hardware lags quite a bit. A few years ago I had a motherboard that I liked a lot that ran Fedora just fine, but CentOS lacked support for. It took a very long time before CentOS supported NFS over TCP. This was especially painful because we rely heavily on NFS across a WAN to support access to the same data from diferent sites. In addition our WAN is implemented using IPSEC tunnels, which have a smaller MTU, and Linux doesn't support manually setting the MTU on a per-route basis (and I wasn't able to get PMUTD to work). What I observed was that the NFS packets would first be fragmented to the default 1500 byte MTU and then the firewall would fragment each of those packets into one large packet followed by a tiny one. This, along with the lack of TCP's congestion control, was not beneficial to NFS performance ... Bugs are also slow to get fixed. For a very long time I had problems with gam_server running away. I'd frequently start top and see gam_server pegged at 100% CPU, stealing time from my simulations. If I killed it, it would get respawed, and would then behave itself for a few days before running away again. This bug eventually got fixed, but there's a kwin bug in CentOS 4 that still hasn't been fixed. Every now an then, kwin will stop working and I can no longer move windows around my desktop. I'm pretty sure this is fixed in a newer version of KDE, but RHEL/CentOS tend to stick with one major version of their ports forever, so I probably couldn't expect to see this fixed until I upgrade to the next version of CentOS. Things might be different if I was a paying RHEL customer and was able to motivate Red Hat into back porting patches for particular bugs. Another feature that I get to enjoy on a daily basis is that the kernel in CentOS 4 does not like my KVM switch. When switching to my CentOS machine, I have about a 50% chance that any mouse movement will cause the cursor to fly all over the screen and spew random mouse clicks all over my desktop. This typically causes a bunch of windows to pop up, and it also usually causes parts of email messages to get pasted into
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 2012-Jan-21 02:07:35 +0100, Daniel Gerzo dan...@freebsd.org wrote: I have already said it in this thread - I believe we should consider issuing much more errata notices (i.e. -pX); with that I mean we should consider more bugs as major bugs. I don't really see a reason why not. The problem is that one person's major bug is completely unimportant to another person. Increasing the number of errata notices would annoy just as many people as it would please. And we should also provide some mechanism to allow for cherry-picking individual errata notices to be applied on the given release (e.g. p1, p2, p5, but not p3, p4). This is a nice idea and is something you might be able to do yourself (because the exact list of changes are in the errata notes) but I don't believe this is practical for the Project to support. Errata updates need to be lightweight from the Project's point of - it can't afford to spend months testing them. With the current model, p4 can only be applied on top of p3 so releasing p4 means: 1) verifying that applying the p4 changes to p3 corrects the bug(s) that caused p4 to be created. 2) doing regression tests to ensure that adding the p4 change to p3 doesn't break anything. With your model, someone can apply p4 on top of any combination of p0, p1, p2, p3 - 8 possibilities. This means there's now 8 times the effort involved in releasing the errata update and it increases exponentially with the number of errata. And it gets more complicated if more than one update affects the same (or related) areas of code. I don't think it makes sense to issue errata notices for driver updates as in support for new devices because we don't ship installation media with these patches applied. I'm not sure that's really an issue - except for people who can't install because the updated driver is needed to support their install media. That said, driver updates can be problematic - someone who has a new chip that isn't supported by the current driver, or who is having a serious issue with the current driver will want the update. Someone who isn't having problems won't want to touch their driver in case it introduces problems with their system. -- Peter Jeremy pgpVm8HHD84Kg.pgp Description: PGP signature
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote: I submit PRs and try to help test them as some developer/committer will pick up the PR, submit a patch to test, but it was MANY times that the response from developer/committer was way too long that I even DID NOT HAVE THE HARDWARE anymore ... I don't have a magic wand to solve this problem. I've spent a lot of time thinking about it and it's just a hard problem to solve in general. There are several aspects: - so many computers are very broken (specifically, horrible BIOS bugs). - most committers only have one or two computers that they work with. - most committers have their own tasklist, and support users is something they never have time to get around to. support users is, in general, something Open Source OSes do not do very well (at least without a paid support staff, as is the case in some of the Linux distros.) But what's discouraging for the people that try to clean up the stale PRs is that they get yelled at when they try to do so. Thus, they tend to get demotivated as well. Support/bug triage is hard and unrewarding work. People can tend to feel that they're being blamed for bugs that they had nothing to do with creating, and burn out. Here is one of the messages that I sent by then to the mailing lists: http://lists.freebsd.org/pipermail/freebsd-doc/2007-May/012507.html ... and NOTHING HAPPENED, no one told me what to do next, should I sent a SGML version or anything ... or just GTFO. I'm sorry that nothing happened, but unfortunately that's common. Submitters sometimes have to be persistent, and maybe even catch new committers when they sign up. Our documentation is certainly in need of updating. What I have done about these 'Ports issues'? I contacted these ports maintainers and said that both RC script and AIO support for samba should be enabled by default by linking to several threads at FreeBSD Forums that the problem is known and exists ... and I did not get ANY RESPONSE till this very day, not even a GTFO (which would probably be better then nothing). When you don't get a response from a maintainer, your best bet is to file a PR against the port. If the maintainer doesn't respond, then after 2 weeks any FreeBSD ports committer is free to work on the PR and, if they agree with you, commit it via maintainer-timeout. We don't have a way to track emails that various users send to individual maintainers. With a PR open, we have a way to do that. We also track maintainer-timeouts, and these can eventually lead to a maintainer reset. I got these maintainers email addresses from http://freshports.org page, are they up-to-date there? They should be, but looking on cvsweb will tell you for certain. IIRC on each freshports page there is a link to cvsweb for the port. It's not that people does not try to help, a lot tried (and I am still trying), but its VERY unpleasant to have awareness, that you dedicated your time, tried to help as much as possible, made some steps to achieve that ... and no one even cares about that. I think it's not don't care, I think it's that unable to cope with number of incoming PRs and other requests for changes and support. As I type this, there are 1122 ports PRs (6272 total PRs). On most days, around 40 come in. It would take a few dozen more volunteers to be able to keep up with them all. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 18, 2012 at 02:18:50PM +0200, Andriy Gapon wrote: So software can already send the reminders, but the real problem is to assign the PRs in the first place. Currently most assignment are self- assignments. My experience has been that assigning PRs to people who have not specifically requested that PRs related to that subject be assigned to them, almost always results in the PRs languishing. This is why I (with bugmeister hat on) discourage the bugbusters from doing so. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/22/12 15:49, Mark Linimon wrote: As I type this, there are 1122 ports PRs (6272 total PRs). On most days, around 40 come in. How do you get that number? I ran a search on pr's and only came up with around ~4k. Is there a trick I'm missing? ___ 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 22 Jan 2012 12:05, Da Rock 9phack...@herveybayaustralia.com.au wrote: On 01/22/12 15:49, Mark Linimon wrote: As I type this, there are 1122 ports PRs (6272 total PRs). On most days, around 40 come in. How do you get that number? I ran a search on pr's and only came up with around ~4k. Is there a trick I'm missing? Scroll up and count the serious and critical bugs too :) 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
Doug Barton writes: That would suggest that the end users don't really lose on features by delaying the new releases, since those features typically aren't ready anyway. I think typically is stretching it a bit here. As humans we tend to focus our attention on the things that cause us problems, rather than acknowledging (or even being aware of) the things that are working well in the background. Also: how many (non-ports) developers out there remember bugs (including performance issues) that weren't triggered until the code went live? One can argue it shouldn't happen ... but it does. Robert Huff ___ 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/22/12 22:44, Chris Rees wrote: On 22 Jan 2012 12:05, Da Rock9phack...@herveybayaustralia.com.au wrote: On 01/22/12 15:49, Mark Linimon wrote: As I type this, there are 1122 ports PRs (6272 total PRs). On most days, around 40 come in. How do you get that number? I ran a search on pr's and only came up with around ~4k. Is there a trick I'm missing? Scroll up and count the serious and critical bugs too :) Oh shit! That's embarrassing... I was only looking at the number at the bottom- I didn't realise it broke the numbers into the sections. Sorry for the cruft ___ 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 Sun, Jan 22, 2012 at 11:15:09PM +1000, Da Rock wrote: Scroll up and count the serious and critical bugs too :) I didn't realise it broke the numbers into the sections. Yeah. The problem is that, over time, the values in those fields has become meaningless. Some of us try to triage what should and should not be 'critical', but other than that, the whole concept has become useless. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, It's not an easy task to get noticed. Well, no i lie - that's easy, start submitting patches. Then you need to find someone who you can nag to get it done. I've offered to a few people to include stuff - just keep nagging me. Linux projects have the same problem, don't doubt it - but they have a larger group of active people, generally looking after a very specific corner of the world. If you want to join the fray and get a commit bit, just be persistent and be willing to look after one specific corner of the tree. Then you'll be responsible for dealing with others nagging you. :) Getting to that point can take a bit of effort though. In terms of wifi, I jumped in with both feet and asked a whole bunch of questions (and nagged a whole lot of people) until I wrapped my head around things. This may or may not be the way you work. :-) The trouble is it's just (mostly) me. It's a little overwhelming, especially since I don't subscribe to the copy everyone elses' work and hope it works fine method of working.. 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, Jan 17, 2012 at 02:43:21AM +, Igor Mozolevsky wrote: To be realistic, I think any serious developer should expect to spend 70% of their development time on maintenance s/developer/paid developer/ and you've got a correct model of how commercial software companies work. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 06:45:17PM -0500, Daniel Eischen wrote: The problem I have with ports is that there is not a -stable branch that tracks with -stable core. We've been working for 18 months to try to get the hardware infrastructure in place to be able to consider such approaches. It doesn't even have to be every port, just the commonly used ports. That's easy in theory, but extremely difficult in practice. The infra- sturcture is far more heavyweight (because of demand for features) than most people give it credit for. There's no concept of subset of ports tree. Go examine the hierarchy and it will become apparent why. Even a server-only concept doesn't get you as far as you might think. Again, the general problem is hard. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, I think some tools could help here. If users are able to submit patches to branches they are interested in and some automatic compile/style/whatever testing for them, it would already help. See http://www.leidinger.net/blog/ for a more detailed explanation of this. Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. Adrian Chadd adr...@freebsd.org hat geschrieben:.. and people _do_ realise that this is all mostly driven by volunteers, right? The companies/individuals that _could_ run this kind of thing do it internally. So you're left with volunteers doing the public releases instead of the vendors who are asking for it. Honestly, I think the re@ and ports building teams would _love_ some help. If you'd like to see this happen, step up and offer your assistance. That's the most likely way to achieve your goal. 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 ___ 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
Damien, On Tue, Jan 17, 2012 at 10:09:55AM +0100, Damien Fleuriot wrote: D I'm having an increasingly difficult time defending FreeBSD in our D company against the advances of debian kfree which is much easier to D maintain. D Can we get back to the 4.x release style and, hopefully, see some 9.7, D 9.8... ? D D Check this PR I opened some months ago: D http://www.freebsd.org/cgi/query-pr.cgi?pr=161123cat=kern D D It was planned for 9.0-RELEASE, there is no mention of 8.x D That's just the kind of problem John raises here. D D I can't keep on defending FreeBSD when the minor fix to a major bug D isn't backported, and only makes it to the next major version, 4 or 5 D months from now. Hey, what's the problem here? Fix for kern/161123 has been committed to stable/8! You reminded me, and I promptly did merge, w/o any argument, albeit I have no ability to test it properly on stable/8. I trust you, that you have tested in on stable/8, but if anything breaks, guess who would be blamed: me or you? -- Totus tuus, Glebius. ___ 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/20/12 2:38 PM, Gleb Smirnoff wrote: Damien, On Tue, Jan 17, 2012 at 10:09:55AM +0100, Damien Fleuriot wrote: D I'm having an increasingly difficult time defending FreeBSD in our D company against the advances of debian kfree which is much easier to D maintain. D Can we get back to the 4.x release style and, hopefully, see some 9.7, D 9.8... ? D D Check this PR I opened some months ago: D http://www.freebsd.org/cgi/query-pr.cgi?pr=161123cat=kern D D It was planned for 9.0-RELEASE, there is no mention of 8.x D That's just the kind of problem John raises here. D D I can't keep on defending FreeBSD when the minor fix to a major bug D isn't backported, and only makes it to the next major version, 4 or 5 D months from now. Hey, what's the problem here? Fix for kern/161123 has been committed to stable/8! You reminded me, and I promptly did merge, w/o any argument, albeit I have no ability to test it properly on stable/8. I trust you, that you have tested in on stable/8, but if anything breaks, guess who would be blamed: me or you? Don't be mistaken, I greatly appreciate the work you put into this and the time you devoted to fixing this issue which was *a real annoyance* in our case. I'm not saying you didn't merge it Gleb, I'm saying for a lng time I had to manually patch the 8.2-RELEASE boxes, because for some reason that I don't know/understand, the patch couldn't (and still hasn't been, I guess) be merged with 8.2-RELEASE. Actually, on topic, what prevents patches from being merged with -RELEASE, as opposed to waiting for a new -RELEASE bump ? Regarding the patch, we've been running it since I submitted it on over 20 firewalls and they're all humming happily. ___ 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 Fri, Jan 20, 2012 at 02:43:55PM +0100, Damien Fleuriot wrote: D Don't be mistaken, I greatly appreciate the work you put into this and D the time you devoted to fixing this issue which was *a real annoyance* D in our case. D D I'm not saying you didn't merge it Gleb, I'm saying for a lng D time I had to manually patch the 8.2-RELEASE boxes, because for some D reason that I don't know/understand, the patch couldn't (and still D hasn't been, I guess) be merged with 8.2-RELEASE. D D Actually, on topic, what prevents patches from being merged with D -RELEASE, as opposed to waiting for a new -RELEASE bump ? It cannot be merged into RELEASE! RELEASE is a point on a branch, as soon as RELEASE had been released, you can't push anything into it, unless you have a time machine. So, the fix has been merged to the branch you reported problem on, this means that it'll be available in the next release from this branch - in 8.3-RELEASE. -- Totus tuus, Glebius. ___ 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/20/12 2:59 PM, Gleb Smirnoff wrote: On Fri, Jan 20, 2012 at 02:43:55PM +0100, Damien Fleuriot wrote: D Don't be mistaken, I greatly appreciate the work you put into this and D the time you devoted to fixing this issue which was *a real annoyance* D in our case. D D I'm not saying you didn't merge it Gleb, I'm saying for a lng D time I had to manually patch the 8.2-RELEASE boxes, because for some D reason that I don't know/understand, the patch couldn't (and still D hasn't been, I guess) be merged with 8.2-RELEASE. D D Actually, on topic, what prevents patches from being merged with D -RELEASE, as opposed to waiting for a new -RELEASE bump ? It cannot be merged into RELEASE! RELEASE is a point on a branch, as soon as RELEASE had been released, you can't push anything into it, unless you have a time machine. So, the fix has been merged to the branch you reported problem on, this means that it'll be available in the next release from this branch - in 8.3-RELEASE. Ok good to know (and too bad for us running -RELEASE). I guess at some point I'll have to study the possibility of us running -STABLE, perhaps that would be acceptable. Thanks for ensuring it'll be in 8.3 anyway :) ___ 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
2012/1/20 Gleb Smirnoff gleb...@freebsd.org: On Fri, Jan 20, 2012 at 02:43:55PM +0100, Damien Fleuriot wrote: D Don't be mistaken, I greatly appreciate the work you put into this and D the time you devoted to fixing this issue which was *a real annoyance* D in our case. D D I'm not saying you didn't merge it Gleb, I'm saying for a lng D time I had to manually patch the 8.2-RELEASE boxes, because for some D reason that I don't know/understand, the patch couldn't (and still D hasn't been, I guess) be merged with 8.2-RELEASE. D D Actually, on topic, what prevents patches from being merged with D -RELEASE, as opposed to waiting for a new -RELEASE bump ? It cannot be merged into RELEASE! RELEASE is a point on a branch, as soon as RELEASE had been released, you can't push anything into it, unless you have a time machine. I think he's asking what's the criteria to push a patch to RELENG_8_2, the security/fixes branch of -RELEASE? IOW, how does one increase the patch level (8.2-RELEASE-p5 - 8.2-RELEASE-p6, etc) of a release? I believe, and RE/security team can correct me on this, that the criteria is along the lines of security issues and major bug fixes only. Perhaps that policy should be looked at and loosened slightly to also include driver updates? Or something along those lines? Perhaps look at releasing point releases (8.2.1) like DoubB suggested? -- 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 18 January 2012 17:13, Daniel Eischen deisc...@freebsd.org wrote: On Wed, 18 Jan 2012, Andriy Gapon wrote: on 18/01/2012 12:44 Robert Watson said the following: My view is therefore that we have a social -- which is to say structural -- problem. Regardless of .0 releases, we should be forcing out minor releases, which are morally similar to service packs in the vocabulary of other vendors: device driver improvements, new CPU support, steady of conservative feature development, etc, required to keep older major releases viable on contemporary hardware and with contemporary applications. One known problem is using a single head release engineer in steering all releases. I think this is a mistake, as it makes the whole project's release schedule subject to individual unavailability, burnout, etc, as well as increasing the risks associated with low bus factor. I'd like to see us move to a model where new release engineers are mentored in from the developer community for point releases, ensuring that we increase our expertise, share knowledge about release engineering in the broader community, and get new eyes on the process which can lead more readily to process improvements. The role of the head release engineer shouldn't be hands-on prodution of every release, but rather, steering of the overall team. I'd like to see this begin with 8.3, drawing a per-release lead from the developer community, and continue with a fixed schedule release of 8.4. Yes, more staffing is needed, but first, what is needed is an improvement in model. Robert, I think that in addition to what you suggest above it would also be useful to have some sort of branch meisters. The current model when every developer decides whether and when and where to do an MFC does not seem to be the proper one. Developers often forget to do an MFC. Or decide against an MFC when there is no reason to do so. Or sometimes do an MFC where the stable branch users would rather prefer that it is not done. There needs to be someone who owns a branch and who want to make it perfect. Someone who could request an MFC (or even do it himself) and someone who could reject an MFC. someone who owns a branch... - If you cut release N.0, do not move -current to N+1. Keep -current at N for a while, prohibiting ABI changes, and any other risky changes. If a developer wants to do possibly disruptive work, they can do it from their own repo. At this point, the branch meister(s) own the branch, and HEAD is only moved to N+1 when they decide that the branch is stable enough for production. Maybe then, N.1 (or N.2) is rolled out. I think most developers track HEAD because: you have to commit and test in HEAD before MFC'ing anyway; because of that, it easier to track and test one branch; and ports built for HEAD may not work on -stable. -- 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 Interesting conversation, what you just siggested I suggested years back ;) My view is a branch cant be marked stable at .0 because it hasnt had enough use. In addition I feel PRs need more attention and I would accept less frequent release in trade for more fixed bugs. I am about to post some PRs myself, one been a nasty lockf issue which has forced me to shift about 20 production http servers over to debian because of processes going into lockf (at low/moderate loads). 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 20.1.2012 18:58, Freddie Cash wrote: It cannot be merged into RELEASE! RELEASE is a point on a branch, as soon as RELEASE had been released, you can't push anything into it, unless you have a time machine. I think he's asking what's the criteria to push a patch to RELENG_8_2, the security/fixes branch of -RELEASE? IOW, how does one increase the patch level (8.2-RELEASE-p5 - 8.2-RELEASE-p6, etc) of a release? I believe, and RE/security team can correct me on this, that the criteria is along the lines of security issues and major bug fixes only. Perhaps that policy should be looked at and loosened slightly to also include driver updates? Or something along those lines? Perhaps look at releasing point releases (8.2.1) like DoubB suggested? I have already said it in this thread - I believe we should consider issuing much more errata notices (i.e. -pX); with that I mean we should consider more bugs as major bugs. I don't really see a reason why not. And we should also provide some mechanism to allow for cherry-picking individual errata notices to be applied on the given release (e.g. p1, p2, p5, but not p3, p4). I don't think it makes sense to issue errata notices for driver updates as in support for new devices because we don't ship installation media with these patches applied. In those cases we would need to make those point releases. On the other hand, simply releasing minor releases more often would solve that problem too. -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer ___ 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, yesterday I wrote some words in my how we could put the power how long a branch lives a little bit more into he hands of the users. It's available at http://www.leidinger.net/blog/ and also has some sentences how we could improve our knowledge about what bugs our users the most. Maybe it gives some ideas to some people. Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. Matthew D. Fuller fulle...@over-yonder.net hat geschrieben:On Wed, Jan 18, 2012 at 02:20:56PM -0600 I heard the voice of Mark Felder, and lo! it spake thus: On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik j...@kozubik.com wrote: This is nice because no upheaval needs to happen with 7 and 8, and interested developers do not get kneecapped vis a vis 9 - they can just keep going where they were going with it, and the only real change is that 10 is pushed out a long ways, and people[1] get to really sink their teeth into 9. What are the policies for changes though? Are we stuck with 9.0's feature set for 5 years? Will we have to wait 5 years to get a stable release of FreeBSD with KMS/GEM? That work is unfinished and didn't make 9.0; it's also a huge changeset. How will things like this be dealt with? Five years is a long time for the next stable release if we have a policy to not import major changes from -CURRENT. It would be devastating to so many users. This is where the problem comes in. As I read it, John's problem in a sentence is I just got onto 8.x, and it's already shutting down! If the problem is stable trains don't live long enough, why, the solution's simple; make stable trains live longer! The problem is, there are unpleasant tradeoffs every direction we try to go with that. We can: 1) Just make each one live longer. Of course, that means that pretty soon we're maintaining 3 and 4 -STABLE branches all the time. Yeah... maintaining is sure to be an overstatement in that case. Even if we had massively more manpower, the project management complexity would still eat us alive. This is just a non-starter. 2) Wait longer between making new ones. This is what John is suggesting above, but it has two related huge drawbacks. The a) As Mark said, is that it means any significant new features or architectures come out a couple years after they're already obsolete. To pick one example, from 8-9 we have the new eventtimers stuff, which drastically reduces the number of clock interrupts. As we get 4 and 8 and 16 and higher core counts becoming common, that gets very important, as servicing 32k interrupts/second while completely idle is really bad for system efficiency. If we pushed 9 out to 2 years or so from now, we're telling people sure, just eat the overhead until then. Whoops. b) The other big drawback is as I've said in other mails; it turns every major release into a giant watershed of everything changing, which makes upgrading systems across it a *HUGE* amount of work, and *VERY* risky. Again, this had an impact in the 4/5 days; upgrading to 5 was so risky and so different, that lots of people stayed on 4 long after it was out. I sure don't want to deal with that sort of divide again. The more frequent major release steps are, the smaller and easier they are. Now, you could say Well, 2(a) just won't be a problem because we'll merge more stuff back. But now all you're doing is making that -STABLE branch _less_ stable, compromising the reason people are using it in the first place. Now, sure, 'stable' isn't a binary condition, and we can always re-evaluate just where we want to stick the needle. Maybe we could be a bit more aggressive about the size of changes we merge back. But I don't believe that we could get _near_ enough backporting to alleviate the time between the big/dangerous new feature landings, without seriously compromising the stability of -STABLE. Or there's another option, a variant of (1), where we extend the lifetime of some major release trains, but not all. Every second, or every third. Then we can have a longer life, without ballooning out the number of trains being supported. But that has big drawbacks too; the problems of backporting aren't just the number of branches to port too, but how far back they are. Backporting from -CURRENT to 9 right now is almost trivial. Going to 8 isn't too bad for most things. To 7, it's getting to be a much bigger deal. If 7 were an extended support train, with 2 years of active support left on it, not only would backporting things get inordinately expensive from accumulated differences, but they'd get very _risky_ too. They slip from backport into rewrite for, and now we've seriously compromised the stability of the branch, undermining our own goals. Now, I don't suggest the current state is perfect. There are certainly relatively minor tweaks like more common minor
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, 18 Jan 2012 22:54:44 -0800, Tim Kientzle wrote: On Jan 18, 2012, at 2:44 AM, Robert Watson wrote: ... perhaps what is really called for is breaking out our .0 release engineering entirely from .x engineering, with freebsd-update being in the latter. This is a great idea! In particular, it would allow more people to be involved. I like this idea too. In a summary to this thread, I'd say that people would love to see: - more regular minor releases, e.g. 8.3, 8.4 say every 4 months (3x per year) - have max. 2 -STABLE branches under support at any given time (once a new -STABLE is created, EOL the oldest supported branch; in a result we would release major version a bit less often. However 5 years between mayor releases is too much and that would only stagnate the development and make switching between mayor releases much more difficult) - make X.Y.Z releases more common or issue Errata notices for existing minor releases more often. I can easily imagine us fixing much more bugs by Errata notices than we do now. How much work is behind issuing an errata notice? - an idea from this thread that I liked is to allow people to cherry-pick the patch level (-pX) which would be great if we managed to release more errata notices. -- Kind regards Daniel ___ 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
Igor Mozolevsky writes: Wouldn't this discourage even more people from helping? Would this not separate people who have a genuine interest in contributing from tinker-monkeys? Did I miss a previous definition of tinker-monkey? Robert Huff ___ 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 just want to chime in here, what is the deal with killing off a potential 7.5-RELEASE ? Having a few 7.3-RELEASE and 7.4-RELEASE servers I would like to see a 7.5-RELEASE that is supported to 2015 to prevent another major upgrade cycle . There are still freebsd developers working on 7-STABLE and its been reliable and working for me and I am sure a few other people. What could I do to help make 7.5-RELEASE a reality ? -- 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
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Robert Huff Sent: Thursday, January 19, 2012 8:35 AM To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Igor Mozolevsky writes: Wouldn't this discourage even more people from helping? Would this not separate people who have a genuine interest in contributing from tinker-monkeys? Did I miss a previous definition of tinker-monkey? And is it anything like a tinker-tailor? -- 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 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: I just want to chime in here, what is the deal with killing off a potential 7.5-RELEASE ? Having a few 7.3-RELEASE and 7.4-RELEASE servers I would like to see a 7.5-RELEASE that is supported to 2015 to prevent another major upgrade cycle . There are still freebsd developers working on 7-STABLE and its been reliable and working for me and I am sure a few other people. What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. 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 19 January 2012 16:35, Robert Huff roberth...@rcn.com wrote: Igor Mozolevsky writes: Wouldn't this discourage even more people from helping? Would this not separate people who have a genuine interest in contributing from tinker-monkeys? Did I miss a previous definition of tinker-monkey? Coders who attempt to repair or improve something in a way that lacks a plan, purpose, or enthusiasm, often to no useful effect. First coined by me in this thread :-) Cheers, -- 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
Hi Doug, On Wed, 18 Jan 2012, Doug Barton wrote: On 01/18/2012 11:46, John Kozubik wrote: - mark 9 as the _only_ production release While I understand your motivation, I am not sure this is a workable goal when combined with the goal that others have expressed of longer timelines for the support of a given branch. Speaking from personal experience, once a service is released on a given platform the costs of migration can be significant. And if what I have is working well and only needs the occasional bug/security fix my motivations for migration are near zero. So the tradeoffs then become more frequent major releases to get new features, vs. longer support for a given release branch. Agreed. What I am saying is that that dial is currently set incorrectly. I think we should sacrifice new features for longer lived releases. My own experience has been that all of the new features I have benefited from did not start being useful until several releases past their introduction. For instance, one or more new releases has been, at least partly, justified by ZFS ... and yet it is only now with 8.3 that I'm even beginning to think of deploying. The same is true with the excellent SMP code we all now enjoy - it took until 6 to be usable. That would suggest that the end users don't really lose on features by delaying the new releases, since those features typically aren't ready anyway. Let's take 5 years as a reasonable time period for supporting a branch. Waiting that long between major releases would significantly stifle the ability to add new features that require breaks to the [AK][BP]I. It would also inhibit our ability to do revolutionary architectural changes such as moving to clang as the primary supported compiler. I agree. Those are costs I am willing to pay, and I think the response to this thread shows that a lot of other folks would prefer that cost/benefit setting to the current one. What I've proposed instead is a new major release every 2 1/2 years, where the new release coincides with the EOL of the oldest production release. That way we have a 5-year cycle of support for each major branch, and no more than 2 production branches extant at one time. I think that at first glance, 2.5 or 3 years sounds completely reasonable. That's a long time, right ? The problem is, nobody uses x.0 (maybe that's rational and maybe not, but it's a fact) so subtract 6 months there, and then if the project is even readying the next major, they're going to detach focus about 6 months prior, so subtract 6 months there ... the next thing you know I'm back where I am right now: getting *maybe* 1.5 total years of *real* lifecycle out of a major release. And since that's my major complaint, I have to disagree. And that is why I am advocating a 5 year lifespan, with at least 4 of those years being totally focused - no other production releases. History tells us that 2 production branches is a goal we can achieve, with the focus shifting more heavily towards only bug/security fixes in the oldest branch after the new production release branch is cut. If we combine that with the ideas that are being put forward about teams that own a production branch, and a more frequent stripped-down release process, I think this is a very workable model. Well, the top of my priority list is occupied with longer lived releases, so if we get that, and we're still maintaining two production releases, it's still a big win for me. But in the bigger picture I think having two production releases simultaneously, while possible, is a bad idea. You have to optimize for something, and in practice I think both lose out. This isn't a FreeBSD issue, it's a classical resources issue. There's a reason that part of this thread got hijacked with complaints about the PR process, and that has to do with PRs getting submitted and devs deciding which production release to plug them into, etc. That's just one of many symptoms of that lack of focus. ___ 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 Thu, 19 Jan 2012, John Kozubik wrote: Hi Doug, On Wed, 18 Jan 2012, Doug Barton wrote: On 01/18/2012 11:46, John Kozubik wrote: - mark 9 as the _only_ production release While I understand your motivation, I am not sure this is a workable goal when combined with the goal that others have expressed of longer timelines for the support of a given branch. Speaking from personal experience, once a service is released on a given platform the costs of migration can be significant. And if what I have is working well and only needs the occasional bug/security fix my motivations for migration are near zero. So the tradeoffs then become more frequent major releases to get new features, vs. longer support for a given release branch. Agreed. What I am saying is that that dial is currently set incorrectly. I think we should sacrifice new features for longer lived releases. There are at least 2 problems with that. First, often the new features are either really useful, or actually necessary. Second, getting new features into a production release is one of the motivating factors for FreeBSD developers. Yes, I agree with others in this thread that the pendulum has swung too far in allowing people free reign with little/no responsibility for followup. But we still have to acknowledge that reality. My own experience has been that all of the new features I have benefited from did not start being useful until several releases past their introduction. I both understand this, and have experienced it myself. The answer to that is to raise the bar higher for what goes into HEAD, such that more developers (and especially users) can be using it on a more frequent basis. In that way fewer bugs exist in the first place, and the ones that exist (because of hardware differences, etc.) are found and fixed prior to the .0 release. That would suggest that the end users don't really lose on features by delaying the new releases, since those features typically aren't ready anyway. I think typically is stretching it a bit here. As humans we tend to focus our attention on the things that cause us problems, rather than acknowledging (or even being aware of) the things that are working well in the background. Let's take 5 years as a reasonable time period for supporting a branch. Waiting that long between major releases would significantly stifle the ability to add new features that require breaks to the [AK][BP]I. It would also inhibit our ability to do revolutionary architectural changes such as moving to clang as the primary supported compiler. I agree. Those are costs I am willing to pay, and I think the response to this thread shows that a lot of other folks would prefer that cost/benefit setting to the current one. Personally, that message has been clearly understood. So the challenge at this point is to come up with a plan that can accomplish as much as possible of what the users need while still being sufficiently attractive to our volunteer developers to actually get things done. What I've proposed instead is a new major release every 2 1/2 years, where the new release coincides with the EOL of the oldest production release. That way we have a 5-year cycle of support for each major branch, and no more than 2 production branches extant at one time. I think that at first glance, 2.5 or 3 years sounds completely reasonable. You're not following the math. :) I'm proposing a 5 year support cycle for each production branch. But in the bigger picture I think having two production releases simultaneously, while possible, is a bad idea. You have to optimize for something, and in practice I think both lose out. This isn't a FreeBSD issue, it's a classical resources issue. I freely concede that 2 production releases is stretching us to the limit of our abilities. I think that this will be improved by the idea of having teams of developers who are responsible for shepherding each production branch. But now speaking as a consumer of FreeBSD, 2 production branches is something that *I* definitely want. If for no other reason than because it gives me options in case the newest one doesn't work out for me for some reason. It also helps with the .0 problem that you're concerned about, although I am still hopeful that we can fix that problem by actually fixing that problem. 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi Doug, On Thu, 19 Jan 2012, Doug Barton wrote: What I've proposed instead is a new major release every 2 1/2 years, where the new release coincides with the EOL of the oldest production release. That way we have a 5-year cycle of support for each major branch, and no more than 2 production branches extant at one time. I think that at first glance, 2.5 or 3 years sounds completely reasonable. You're not following the math. :) I'm proposing a 5 year support cycle for each production branch. Yes, you're right - I missed that. 5 year support, and overlapping 2.5 year majors ... provided that minors got increased to 3 per year ... would be fantastic. ___ 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
.. and people _do_ realise that this is all mostly driven by volunteers, right? The companies/individuals that _could_ run this kind of thing do it internally. So you're left with volunteers doing the public releases instead of the vendors who are asking for it. Honestly, I think the re@ and ports building teams would _love_ some help. If you'd like to see this happen, step up and offer your assistance. That's the most likely way to achieve your goal. 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 Wed, 18 Jan 2012, Dieter BSD wrote: John writes: - EOL 7 - mark 8 as legacy - mark 9 as the _only_ production release - release 10.0 in January 2017 Until a few days ago 8 was the latest, shinest release. So you want to suddenly demote it all the way down to legacy? I thought the goal was to have releases that can be used for a long time? No, that's not quite what I meant. I was speaking at the same time about the problem of having two concurrent production releases. Since 9.0 is already released, you can't stop having two production releases with 8, since 9 is already here. So i was saying *after* you continue the normal 8.x lifecycle (perhaps another 1 or 1.5 years, getting it to 8.5 *then* you make the drastic changes, which I showed in the list above. So 8 would become legacy on the same schedule that it always had. No changes there. The change comes with 9 being the only production release, and 10.0-RELEASE being delayed. ___ 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 Thu, 19 Jan 2012 08:07:43 +0100 vermaden verma...@interia.pl wrote: I got these maintainers email addresses from http://freshports.org page, are they up-to-date there? Maybe that is the problem and that my mails jest went to /dev/null ... Just checking for sure. I dunno. If you want the maintainer as of your update of the ports tree, go to the port and do make -V MAINTAINER. I've generally had good luck with ports. I ran for years with LOCALBASE set to /usr/opt (what can I say, I was a masochist). I'd regularly find ports that failed to build under those conditions. I'd try and patch the port to fix it, or sometimes just kludge it to work, then mail the maintainer with the patch. Most of them fixed things pretty quickly. Ditto after the conversion to rc.d - I'd find ports that needed such scripts, write them, and send them to the maintainer. There, my patches weren't accepted as is quite so often, but I generally saw an appropriate script (even if inferior to mine :-) fairly quickly. And as a port maintainer, I tried to respond quickly to such requests. Getting patches accepted was a spottier story. It generally worked better if I approached the maintainer with I'd like to fix this/add this feature, are you interested than just submitting patches to gnats. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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 01/20/12 09:13, John Kozubik wrote: On Wed, 18 Jan 2012, Dieter BSD wrote: John writes: - EOL 7 - mark 8 as legacy - mark 9 as the _only_ production release - release 10.0 in January 2017 Until a few days ago 8 was the latest, shinest release. So you want to suddenly demote it all the way down to legacy? I thought the goal was to have releases that can be used for a long time? No, that's not quite what I meant. I was speaking at the same time about the problem of having two concurrent production releases. Since 9.0 is already released, you can't stop having two production releases with 8, since 9 is already here. So i was saying *after* you continue the normal 8.x lifecycle (perhaps another 1 or 1.5 years, getting it to 8.5 *then* you make the drastic changes, which I showed in the list above. So 8 would become legacy on the same schedule that it always had. No changes there. The change comes with 9 being the only production release, and 10.0-RELEASE being delayed. I'll weigh in :) I can sympathise with the need for longer support; but then on the other hand that means for things like fixes for drivers you have to wait 2 years or more- I've already done that, and I've been happier when things finally just work rather than having to root around and try to get things to work in any way I can. Case in point: I had a laptop with an iwn driver, there was no support for it, and it was going to wait for 8.0 (7.0 at the time). There was no option to backport as the driver wasn't working in current, so I tried to get involved and help but that quickly stagnated. So I was stuck to a cable (age had to be backported) and finally in 8 it worked, and wpa_supplicant was finally fixed as well. And when everything worked my laptop died and I bought another! :( Now I have ath. ath didn't work in 8. I tried a backport from current, and it worked for a bit and broke in 8.2. I was then forced to work with 9.0-RCx. Waiting longer would not have been an option- I was looking for a release date or some idea on where 9.0-RELEASE was at but the information was outdated and scarce. I was also hoping to get 802.11n support. Now apparently that is not really an option until 10. So what do I do? Some support is backported, but not all can be due to unresolvable API differences, same as what happened back with iwn. So based on this I face a continually moving target: my hardware lifetimes and the ability to keep up with new hardware produced by the dev team. I'd like to get involved, but drivers are still very much an enigma as yet. I also keep getting told to use current to help with testing, but given my userbase I can't do this without screams of agony, and vm's are useless here for hardware testing. I'm also advised to follow stable, but again- same deal. So I'm always asking myself why is it so hard to run release? I've read this entire thread now, but I still can't see a specific answer that resolves the issues presented. IF releases are supported longer, then backports are a must as near as I can see, but if the APIs are too different then how? If hardware or other feature support takes too long then users go elsewhere as well. I can't help being stubborn as mule, working with something no matter how hard it is, but I'm sure most users/sysadmins aren't. If a split was made between server and desktop edition that would be a disaster I believe. The only reason all this works so well is because there is no difference. The features required to make desktop more user friendly need to be added (probably by ports) as required, but that wouldn't kill server support. That only adds more labor to an already stressed environment. I will put my hand up to help with RE, or whatever will help in this situation; maybe even customised releases for rollouts for different organisations interested? I have cpu cycles to burn, and my missus is even egging me on :) I have enough systems to warrant this even for my own needs, and I'm sure I could pull it off with some help. My needs are more desktop than server though, and that should be helpful for the majority as support doesn't just stop at just what will provide for the sysadmins. I'll help in any way I can, if I get some support as well that would be handy. One thing that stands out to me I think is that svn (or similar) is a definite must and the cvs is too archaic for the needs here. The code freeze seems to be a real hindrance to a healthy release. Also, as to bugs, cannot some of the processes be automated (scripted?) somehow? Say if a patch is commited, can't this be detected and tested and a report sent to the stakeholders/interested parties? Depending on skill level required my missus could help on the poking side of things... On another point, Adrian: you mention that one can get involved, but that does seem to be an overwhelming task. I've tried to put up my hand a few times, but got
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
on 18/01/2012 02:16 Igor Mozolevsky said the following: 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). Let me pretend that I don't get it. It is as much your code as it is mine if you are a user of FreeBSD. I just happen to have a commit bit at this point in time. No other project requires a non-committer to be so ridiculously persistent in order to get a patch through. There are about 5000 open PRs for FreeBSD base system, maybe more. There are only a few dozens of active FreeBSD developers. Maybe less for any given particular point in time (as opposed to a period of time). And dealing with PRs is not always exciting. Need I continue? P.S. Using GNATS for the PR database doesn't help either, in some technical ways. -- 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:09 Devin Teske said the following: 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. But how can you say that without knowing what will (can) come in 10. Maybe it will have something that would be a complete re-write, but something that you would super-want. IMO, it's the whole purpose of our present stable branches policy to let users try/test/use new/advanced features sooner, all while having a choice. -- 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, Julian Elischer wrote: On 1/16/12 3:32 PM, William Bentley 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. [...] 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? It pretty much boils down to one thing.. man power.. I disagree. Resourcing is an issue, but it is not *the* issue. The real issue here is a failure by the release engineering team (which includes me) to concurrently perform major and minor releases. Given that minor releases run like clockwork in most cases, this is disappointing. In the past, there have been a lot of good technical and structural obstacles to trying to do clockwork releases for both major and minor releases: - Tight synchronisation of the ports and base release schedule means that the base release schedule limits ports productivity. - Long freezes forced on us by poor revision control support for branching. None of these really apply any longer -- and in as much as they do, they should be addressed. In particular, I think there's a growing feeling that ports should be conducting its own releases out of lockstep with the base tree, producing package sets as a primary product at regular intervals regardless of the base release schedule. Likewise, long freezes enforced by expensive branching operation in CVS no longer apply due to use of Subversion -- it's not perfect, but it's workable. There's no way to satisfy everyone with any particular maintenance schedule and release cycle. However, it seems clear that the current model with minor releases spaced at a year is satisfying no one. It's easy to point at a developer-user divide, but I think that misses the point: most developers are users. A big gap between development branch and shipped features hurts the commercial users of FreeBSD that pay for so much of its development, since it forces them to support diverging local development and shipping products -- ISPs, etc. There is no incentive for year-long gaps in minor releases. My view is therefore that we have a social -- which is to say structural -- problem. Regardless of .0 releases, we should be forcing out minor releases, which are morally similar to service packs in the vocabulary of other vendors: device driver improvements, new CPU support, steady of conservative feature development, etc, required to keep older major releases viable on contemporary hardware and with contemporary applications. One known problem is using a single head release engineer in steering all releases. I think this is a mistake, as it makes the whole project's release schedule subject to individual unavailability, burnout, etc, as well as increasing the risks associated with low bus factor. I'd like to see us move to a model where new release engineers are mentored in from the developer community for point releases, ensuring that we increase our expertise, share knowledge about release engineering in the broader community, and get new eyes on the process which can lead more readily to process improvements. The role of the head release engineer shouldn't be hands-on prodution of every release, but rather, steering of the overall team. I'd like to see this begin with 8.3, drawing a per-release lead from the developer community, and continue with a fixed schedule release of 8.4. Yes, more staffing is needed, but first, what is needed is an improvement in model. On a related note, the security team owns the freebsd-update mechanism, largely for historical reasons (Colin wrote it), but this is actually a bit backwards from how you would expect things to run, as we now use freebsd-update for upgrades, which are almost never engineered by the security team. Not sure what the fix is there, but it seems related -- perhaps what is really called for is breaking out our .0 release engineering entirely from .x engineering, with freebsd-update being in the latter. Robert ___ 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 09:25, Andriy Gapon a...@freebsd.org wrote: on 18/01/2012 02:16 Igor Mozolevsky said the following: 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). Let me pretend that I don't get it. It is as much your code as it is mine if you are a user of FreeBSD. I just happen to have a commit bit at this point in time. Actually that is not true at all, it is in no way my code because there is absolutely nothing I can do to change it (evidently, even if I do submit patches ;-) )---I'm, at best, an involved bystander!.. No other project requires a non-committer to be so ridiculously persistent in order to get a patch through. There are about 5000 open PRs for FreeBSD base system, maybe more. There are only a few dozens of active FreeBSD developers. Maybe less for any given particular point in time (as opposed to a period of time). And dealing with PRs is not always exciting. Need I continue? Is that because there are so many bugs that need fixing or is it because PRs get ignored/become staled? From the preceding discussion it appears to be more of the latter than the former. While I appreciate the excitement in churning out new edge code, pretending that old bugs do not exist will not simply make them go away... In fact, given the large number of PRs (and thus presumably ones containing patches) what are the chances that some devs are trying to reinvent the wheel and write a fix that is already contained within the PR system? Equally, there's probably a large number of PRs that are simply not relevant any more... Throwing toys out of the pram because there's just too much stuff to do is really not the answer I'm afraid... -- 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 18/01/2012 12:44 Robert Watson said the following: My view is therefore that we have a social -- which is to say structural -- problem. Regardless of .0 releases, we should be forcing out minor releases, which are morally similar to service packs in the vocabulary of other vendors: device driver improvements, new CPU support, steady of conservative feature development, etc, required to keep older major releases viable on contemporary hardware and with contemporary applications. One known problem is using a single head release engineer in steering all releases. I think this is a mistake, as it makes the whole project's release schedule subject to individual unavailability, burnout, etc, as well as increasing the risks associated with low bus factor. I'd like to see us move to a model where new release engineers are mentored in from the developer community for point releases, ensuring that we increase our expertise, share knowledge about release engineering in the broader community, and get new eyes on the process which can lead more readily to process improvements. The role of the head release engineer shouldn't be hands-on prodution of every release, but rather, steering of the overall team. I'd like to see this begin with 8.3, drawing a per-release lead from the developer community, and continue with a fixed schedule release of 8.4. Yes, more staffing is needed, but first, what is needed is an improvement in model. Robert, I think that in addition to what you suggest above it would also be useful to have some sort of branch meisters. The current model when every developer decides whether and when and where to do an MFC does not seem to be the proper one. Developers often forget to do an MFC. Or decide against an MFC when there is no reason to do so. Or sometimes do an MFC where the stable branch users would rather prefer that it is not done. There needs to be someone who owns a branch and who want to make it perfect. Someone who could request an MFC (or even do it himself) and someone who could reject an MFC. Likely this could be the same person who then cuts a release from the branch. IMO. -- 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 12:54 Igor Mozolevsky said the following: On 18 January 2012 09:25, Andriy Gapon a...@freebsd.org wrote: on 18/01/2012 02:16 Igor Mozolevsky said the following: 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). Let me pretend that I don't get it. It is as much your code as it is mine if you are a user of FreeBSD. I just happen to have a commit bit at this point in time. Actually that is not true at all, it is in no way my code because there is absolutely nothing I can do to change it (evidently, even if I do submit patches ;-) )---I'm, at best, an involved bystander!.. In a philosophical sense you are what you chose to be. If you really want to change the code you can make it happen. Fork being an ultimate option, but there are many less dramatic ways. No other project requires a non-committer to be so ridiculously persistent in order to get a patch through. There are about 5000 open PRs for FreeBSD base system, maybe more. There are only a few dozens of active FreeBSD developers. Maybe less for any given particular point in time (as opposed to a period of time). And dealing with PRs is not always exciting. Need I continue? Is that because there are so many bugs that need fixing or is it because PRs get ignored/become staled? Sorry for saying the obvious, but it is because the PRs are fixed at slower rate than they are opened. From the preceding discussion it appears to be more of the latter than the former. Impressions can be deceiving. Honestly, do you believe that all committers are willfully ignoring the PRs just to cause pain to the users? Or do you consider a possibility that there is an objective reason why the things are the way they are? While I appreciate the excitement in churning out new edge code, pretending that old bugs do not exist will not simply make them go away... Nobody pretends that. In fact, given the large number of PRs (and thus presumably ones containing patches) what are the chances that some devs are trying to reinvent the wheel and write a fix that is already contained within the PR system? That does happen from time to time. Equally, there's probably a large number of PRs that are simply not relevant any more... Definitely. Throwing toys out of the pram because there's just too much stuff to do is really not the answer I'm afraid... So what's your suggestion? But, please, nothing involving other people spontaneously starting to do what you believe to be the right thing. BTW, there is also a gnats only commit bit. And you can post followups to the PRs even without a commit bit. Any work would be appreciated. -- 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 Wed, 18 Jan 2012, Andriy Gapon wrote:
on 18/01/2012 02:16 Igor Mozolevsky said the following:
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).
Let me pretend that I don't get it. It is as much your code as it is mine
if you are a user of FreeBSD. I just happen to have a commit bit at this
point in time.
No other project requires a non-committer to be so ridiculously persistent
in order to get a patch through.
There are about 5000 open PRs for FreeBSD base system, maybe more. There are
only a few dozens of active FreeBSD developers. Maybe less for any given
particular point in time (as opposed to a period of time). And dealing with
PRs is not always exciting. Need I continue?
P.S. Using GNATS for the PR database doesn't help either, in some technical
ways.
The structural problem around the PR system for the base system is that there
isn't a whole lot of incentive for most developers to use it. I think we can
reasonably categorise developers into three classes -- some move between or
span them, of course:
(1) Volunteers. Due to childhood trauma, they have a desperate urge to write
operating systems. Not much incentive to do PRs here, as most refer to
versions of FreeBSD before their time, aren't great characterisations,
rarely come with patches, and when they do, the patches are out of date,
don't apply, have the wrong style, solve the wrong problem, etc. A
sweeping generalisation, but you see what I mean. The only exceptions
here are our dedicated team of bugmeisters, who get enourmous respect from
me, but they are a tiny minority.
(2) Employees. They work at a company using FreeBSD as a product, and
effectively deliver their own CompanyBSD as a further product to their own
internal customers -- to be put on a web service frontline, to ship as the
foundation of an appliance, etc. The key phrase here is internal
customers -- they have their own bug report database, which they respond
to in a timely way due to the incentives of the workplace, but also
because they are relevant bug reports for their product goals.
(3) Authors of upstream code. They don't even work on FreeBSD, but their code
ends up in FreeBSD, so they also have their own bug report databases, fix
bugs, and eventually the fixes trickle into FreeBSD.
With the above, the incentives to handle PRs are very weak -- and it's
compounded by gnats being terrible for both submitters and handlers of bug
reports. Contrast this with ports, where the PR database is a key part of the
workflow.
However, and I am being entirely honest when I say this: FreeBSD works anyway.
So somehow, we end up with a pretty good OS despite largely ignoring our bug
report database. Why? Well, for (1) it's because volunteers have a strong
sense of ownership of the code they've written and care about, (2) there's a
significant internal QA and bug management effort at downstream companies from
FreeBSD, whose improvements are frequently upstreamed by committers on staff,
and (3) occurs independently of bugs in our bug report database.
Don't get me wrong: it's a problem that the PR database goes so unloved. But
it's a symptom of the construction of *extremely large* volunteer projects in
which the incentives are not aligned for dealing with PRs most of the time.
If you want to see something similarly sad, try counting dropped patches on
the linux-kernel list. Someone once ported the entire FreeBSD kernel audit
framework and OpenBSM to Linux, posted on the list saying here are my
patches, never heard anything back, and went away. You can moralise in
various ways and for various parties in that relationship, but at heart,
that's pretty similar to a lot of the patches in the PR database; you'll find
similar stuff in every open source project of scale. I submitted patches to
fix several bugs in KDE a decade or so ago .. after five years, the reports
were closed as out of date. Yet large open source products *do* work, and
become the foundations for amazing things.
I think shifting away from Gnats would help as it would make it easier for
developers to find bugs they care about, users to submit higher-quality
reports, and so on. Gnats makes it really hard to manage reports in a useful
way.
Another possibility is to get some combination of {The FreeBSD Foundation, iX
Systems, ...} to trawl the bug report database in a more official capacity.
The problem there is that this will be a high burn-out job. I'll bring it up
at the next Foundation board meeting, especially after a bumper year of
fund-raising, and see what we can do.
Robert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, Andriy Gapon wrote: 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. Suppose for a moment we get the .x release process fixed: we start cutting regular point releases from -STABLE on a 6-month cycle (just a strawman). freebsd-update's update and upgrade features actually make tracking -STABLE at release engineered time slices plausible. One reason that's true is that between 5.x and 6.x, the FreeBSD Project underwent a substantive change in our approach to binary interfaces. In 4.x and before, the letters ABI rarely hit the mailing lists. In 6.x and later, it's a key topic discussed whenever merges to -STABLE come up. We now really care about keeping applications running as the OS moves under them. We also build packages to better-defined ABIs -- not perfectly, but OK. I think John gets a lot of what he wants if we just fix our release cycle. Robert ___ 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, Doug Barton wrote: 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. Agreed entirely. There's been an over-swing caused by the diagnosis it's like herding cats into cats can't be herded, so why try?. Projects like FreeBSD don't agree if there's no consensus on interesting problems to solve, directions to run in, etc. The history of FreeBSD is also full of examples of successful collaborative development in which developers decide, together, on a direction and run that way. Sure, it's not the same as we are paying you to do X, but I think many FreeBSD developers like the idea that they are working on something larger than just their own micro-project, and would subscribe (and contribute) to a sensible plan. In fact, I think we'd find that if we were a bit more forthcoming about our plans, we'd have an easier time soliciting contributions from people less involved in the project, as it would be more obvious how they could get involved. It strikes me that the first basic plan would be a release schedule, however. :-) Robert ___ 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
Robert Watson wrote: On Mon, 16 Jan 2012, Julian Elischer wrote: On 1/16/12 3:32 PM, William Bentley 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. [...] 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? It pretty much boils down to one thing.. man power.. I disagree. Resourcing is an issue, but it is not *the* issue. The real issue here is a failure by the release engineering team (which includes me) to concurrently perform major and minor releases. Given that minor releases run like clockwork in most cases, this is disappointing. In the past, there have been a lot of good technical and structural obstacles to trying to do clockwork releases for both major and minor releases: - Tight synchronisation of the ports and base release schedule means that the base release schedule limits ports productivity. - Long freezes forced on us by poor revision control support for branching. None of these really apply any longer -- and in as much as they do, they should be addressed. In particular, I think there's a growing feeling that ports should be conducting its own releases out of lockstep with the base tree, producing package sets as a primary product at regular intervals regardless of the base release schedule. Likewise, long freezes enforced by expensive branching operation in CVS no longer apply due to use of Subversion -- it's not perfect, but it's workable. There's no way to satisfy everyone with any particular maintenance schedule and release cycle. However, it seems clear that the current model with minor releases spaced at a year is satisfying no one. It's easy to point at a developer-user divide, but I think that misses the point: most developers are users. A big gap between development branch and shipped features hurts the commercial users of FreeBSD that pay for so much of its development, since it forces them to support diverging local development and shipping products -- ISPs, etc. There is no incentive for year-long gaps in minor releases. My view is therefore that we have a social -- which is to say structural -- problem. Regardless of .0 releases, we should be forcing out minor releases, which are morally similar to service packs in the vocabulary of other vendors: device driver improvements, new CPU support, steady of conservative feature development, etc, required to keep older major releases viable on contemporary hardware and with contemporary applications. One known problem is using a single head release engineer in steering all releases. I think this is a mistake, as it makes the whole project's release schedule subject to individual unavailability, burnout, etc, as well as increasing the risks associated with low bus factor. I'd like to see us move to a model where new release engineers are mentored in from the developer community for point releases, ensuring that we increase our expertise, share knowledge about release engineering in the broader community, and get new eyes on the process which can lead more readily to process improvements. The role of the head release engineer shouldn't be hands-on prodution of every release, but rather, steering of the overall team. I'd like to see this begin with 8.3, drawing a per-release lead from the developer community, and continue with a fixed schedule release of 8.4. Yes, more staffing is needed, but first, what is needed is an improvement in model. It looks like Intel's development model. They have two teams. One works on new processor, while the second do upgrade of the previous one. On next turn the last one start the new processor and the first one does. I think it is great model. [...] ___ 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 11:08, Andriy Gapon a...@freebsd.org wrote: on 18/01/2012 12:54 Igor Mozolevsky said the following: [snip] There are about 5000 open PRs for FreeBSD base system, maybe more. There are only a few dozens of active FreeBSD developers. Maybe less for any given particular point in time (as opposed to a period of time). And dealing with PRs is not always exciting. Need I continue? Is that because there are so many bugs that need fixing or is it because PRs get ignored/become staled? Sorry for saying the obvious, but it is because the PRs are fixed at slower rate than they are opened. That may be the case, but we are not talking about PRs as a whole, but PRs that already contain fixes... From the preceding discussion it appears to be more of the latter than the former. Impressions can be deceiving. Honestly, do you believe that all committers are willfully ignoring the PRs just to cause pain to the users? Or do you consider a possibility that there is an objective reason why the things are the way they are? I was not suggesting malice on behalf of the developers at all, what I was saying is that there is an *appearance* that developers prefer to write new and funky code in lieu of dealing with PRs. This is evidenced by people saying that one has to persistently nag to get the patch looked at/incorporated. Why should that be the case, when it isn't the case on other F/OSS projects? This might be another social problem is that the PR and the bug busting team do not have enough stick over devs... Throwing toys out of the pram because there's just too much stuff to do is really not the answer I'm afraid... So what's your suggestion? But, please, nothing involving other people spontaneously starting to do what you believe to be the right thing. For starters, what would be much more appreciated is for devs to be much more involved from the start once someone does submit the patch. I appreciate that people a fallible and from time to time are bound to forget that they have a PR with a patch assigned to them, but there's no reason why the PR handling system can't email reminders... The best way of dealing with too much on my plate, from personal experience, is to start tackling things one at a time... :-) -- 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 18/01/2012 13:54 Igor Mozolevsky said the following: On 18 January 2012 11:08, Andriy Gapon a...@freebsd.org wrote: on 18/01/2012 12:54 Igor Mozolevsky said the following: [snip] There are about 5000 open PRs for FreeBSD base system, maybe more. There are only a few dozens of active FreeBSD developers. Maybe less for any given particular point in time (as opposed to a period of time). And dealing with PRs is not always exciting. Need I continue? Is that because there are so many bugs that need fixing or is it because PRs get ignored/become staled? Sorry for saying the obvious, but it is because the PRs are fixed at slower rate than they are opened. That may be the case, but we are not talking about PRs as a whole, but PRs that already contain fixes... They get lost in the noise quite easily. And probably not many people start their days with browsing through the PRs looking for a gem. From the preceding discussion it appears to be more of the latter than the former. Impressions can be deceiving. Honestly, do you believe that all committers are willfully ignoring the PRs just to cause pain to the users? Or do you consider a possibility that there is an objective reason why the things are the way they are? I was not suggesting malice on behalf of the developers at all, what I was saying is that there is an *appearance* that developers prefer to write new and funky code in lieu of dealing with PRs. This is evidenced by people saying that one has to persistently nag to get the patch looked at/incorporated. Why should that be the case, when it isn't the case on other F/OSS projects? Let's not repeat this other projects thing ad infinitum. I also have experience with other projects and they are not all that perfect. Especially the large projects. This might be another social problem is that the PR and the bug busting team do not have enough stick over devs... In a volunteer community nobody has a real stick over other people. We can try to talk each other into doing things, but nobody can force someone else, only himself. Throwing toys out of the pram because there's just too much stuff to do is really not the answer I'm afraid... So what's your suggestion? But, please, nothing involving other people spontaneously starting to do what you believe to be the right thing. For starters, what would be much more appreciated is for devs to be much more involved from the start once someone does submit the patch. Indeed, it would be appreciated. That doesn't answer the question about how to make it happen. I appreciate that people a fallible and from time to time are bound to forget that they have a PR with a patch assigned to them, but there's no reason why the PR handling system can't email reminders... So software can already send the reminders, but the real problem is to assign the PRs in the first place. Currently most assignment are self-assignments. As such most of the open PRs are not assigned to anybody. The best way of dealing with too much on my plate, from personal experience, is to start tackling things one at a time... :-) And from my personal experience I already have a several dozen items on my plate that I am really interested in. And by the time I remove one item from the plate I get a few more added. And so I just don't happen to have a day where I have to think which random PR to fix today. -- 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, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: 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. Often times people don't do this part and submit a drive by patch. Nothing is wrong with that, but it does make it harder to verify that a fix is correct (especially for hardware support PRs). 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. I guess I didn't follow through on all the above. My point was that who wants to spend 3, 4, 7, 10 hours fixing a bug report when they can be working on a shiny new feature (or play games, or anything else but work!)? 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. As I said above, the time it takes to follow through on a PR discourages people from even looking. But, as I said above, it's getting to *this* stage that is the lengthy and a disheartening process... I agree that this is a real problem. Unfortunately I can't think of any good solutions. The bugbusting team maintains a list of easy and quality PRs which we try to get committers to look at. I also maintain a personal bugging list (pun intended) of PRs which I bug other people about. This has helped somewhat (the PRs I bug people about tend to get closed) but it isn't sufficient. 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. Solving this and other problems is so hard a back has been written on the topic: http://producingoss.com/ 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!)? Wouldn't this discourage even more people from helping? -- 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
On 18 January 2012 13:11, Eitan Adler li...@eitanadler.com wrote: On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: 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!)? Wouldn't this discourage even more people from helping? Would this not separate people who have a genuine interest in contributing from tinker-monkeys? -- 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 Tuesday, January 17, 2012 6:41:48 am Ivan Voras wrote: (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. This is not strictly true. At work we are using 8.2-ish, and so right now much of development happens on 8 and has to be forward ported to HEAD. I do think we are cutting stable branches a bit too often and that we could merge features back to older branches more aggressively. SVN had made that much easier (e.g. merging superpages from 8 back to 7). However, it is more work for a developer to merge a change back to 2 or 3 branches (e.g. from HEAD to 9 to 8 to 7). Developers are more willing to merge things back to one or two branches. Right now we have made a design decision to release new X.0 releases (and cut new branches) at a certain frequency (and we aren't even keeping up). We could choose to alter that design and I think we would end up with longer-lived stable branches as a result. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
[snip] For starters, what would be much more appreciated is for devs to be much more involved from the start once someone does submit the patch. I appreciate that people a fallible and from time to time are bound to forget that they have a PR with a patch assigned to them, but there's no reason why the PR handling system can't email reminders... GNATS already emails periodic reminders to bug owners (be the owners individual devs or mailing lists, eg freebsd-rc, etc). -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: FreeBSD has serious problems with focus, longevity, and lifecycle
Am 17.01.2012 um 20:54 schrieb Steven Hartland: - 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? freebsd-update its the keyword. Many of our customers could use (and do - most of them are paying peanuts for their IT staff) trained monkeys for system upgrades if they stay on -RELEASE steps. Alternatively: Use properly versioned binaries and get freebsd-update working on arbitrary versions. Achim ___ 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 [snip] 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. Got new stats. In 2011 we ran $1.61T USD through FreeBSD. Separately, we ran another $0.05T USD through Linux in the same year. Kinda says something about, doesn't it? -- 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 18 January 2012 17:06, Devin Teske devin.te...@fisglobal.com wrote: -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 [snip] 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. Got new stats. In 2011 we ran $1.61T USD through FreeBSD. Separately, we ran another $0.05T USD through Linux in the same year. Kinda says something about, doesn't it? Sorry to burst your bubble but this is utterly meaningless statistic. You show nothing but correlation and in no way a causation. Back in the days when the UK banks ran ATMs, c on Windows NT (I have no idea what they are running now) they went through a lot more value than that---means absolutely nothing... -- 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 Wed, 18 Jan 2012, Andriy Gapon wrote: on 18/01/2012 12:44 Robert Watson said the following: My view is therefore that we have a social -- which is to say structural -- problem. Regardless of .0 releases, we should be forcing out minor releases, which are morally similar to service packs in the vocabulary of other vendors: device driver improvements, new CPU support, steady of conservative feature development, etc, required to keep older major releases viable on contemporary hardware and with contemporary applications. One known problem is using a single head release engineer in steering all releases. I think this is a mistake, as it makes the whole project's release schedule subject to individual unavailability, burnout, etc, as well as increasing the risks associated with low bus factor. I'd like to see us move to a model where new release engineers are mentored in from the developer community for point releases, ensuring that we increase our expertise, share knowledge about release engineering in the broader community, and get new eyes on the process which can lead more readily to process improvements. The role of the head release engineer shouldn't be hands-on prodution of every release, but rather, steering of the overall team. I'd like to see this begin with 8.3, drawing a per-release lead from the developer community, and continue with a fixed schedule release of 8.4. Yes, more staffing is needed, but first, what is needed is an improvement in model. Robert, I think that in addition to what you suggest above it would also be useful to have some sort of branch meisters. The current model when every developer decides whether and when and where to do an MFC does not seem to be the proper one. Developers often forget to do an MFC. Or decide against an MFC when there is no reason to do so. Or sometimes do an MFC where the stable branch users would rather prefer that it is not done. There needs to be someone who owns a branch and who want to make it perfect. Someone who could request an MFC (or even do it himself) and someone who could reject an MFC. someone who owns a branch... - If you cut release N.0, do not move -current to N+1. Keep -current at N for a while, prohibiting ABI changes, and any other risky changes. If a developer wants to do possibly disruptive work, they can do it from their own repo. At this point, the branch meister(s) own the branch, and HEAD is only moved to N+1 when they decide that the branch is stable enough for production. Maybe then, N.1 (or N.2) is rolled out. I think most developers track HEAD because: you have to commit and test in HEAD before MFC'ing anyway; because of that, it easier to track and test one branch; and ports built for HEAD may not work on -stable. -- 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 Jan 2012 17:12, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: On 18 January 2012 17:06, Devin Teske devin.te...@fisglobal.com wrote: -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 [snip] 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. Got new stats. In 2011 we ran $1.61T USD through FreeBSD. Separately, we ran another $0.05T USD through Linux in the same year. Kinda says something about, doesn't it? Sorry to burst your bubble but this is utterly meaningless statistic. You show nothing but correlation and in no way a causation. Back in the days when the UK banks ran ATMs, c on Windows NT (I have no idea what they are running now) they went through a lot more value than that---means absolutely nothing... Well I've not seen any BSOD'd cashpoints around for a while, so I'd like to suggest they may have switched. 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 18 January 2012 17:30, Chris Rees utis...@gmail.com wrote: On 18 Jan 2012 17:12, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: Back in the days when the UK banks ran ATMs, c on Windows NT (I have no idea what they are running now) Well I've not seen any BSOD'd cashpoints around for a while, so I'd like to suggest they may have switched. That, or they found reboot after crash tick box... ;-) -- 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 1/18/12 3:32 AM, Robert Watson wrote:
Another possibility is to get some combination of {The FreeBSD
Foundation, iX Systems, ...} to trawl the bug report database in a
more official capacity. The problem there is that this will be a
high burn-out job. I'll bring it up at the next Foundation board
meeting, especially after a bumper year of fund-raising, and see
what we can do.
we really need a bud-submitting-user advocate..
Someone (need not have a commit bit) who doesn't take charge of the
patch, but, rather,
acts as a project manager in hte process of getting it in.
i.e. finding, and then pinging the approriate developer, and
occasionally nagging them or
finding an alternate dev if the first choice is unresponsive.
diplomatic skill would be important.. maybe a woman might be best in
this job as the developers tend to not want to be rude to women :-) .
Robert
___
___
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 19:13 Daniel Eischen said the following: someone who owns a branch... - If you cut release N.0, do not move -current to N+1. Keep -current at N for a while, prohibiting ABI changes, and any other risky changes. If a developer wants to do possibly disruptive work, they can do it from their own repo. I am totally against this. -- 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
-Original Message- From: mozolev...@gmail.com [mailto:mozolev...@gmail.com] On Behalf Of Igor Mozolevsky Sent: Wednesday, January 18, 2012 9:12 AM To: Devin Teske Cc: Julian Elischer; Mark Felder; freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle On 18 January 2012 17:06, Devin Teske devin.te...@fisglobal.com wrote: -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 [snip] 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. Got new stats. In 2011 we ran $1.61T USD through FreeBSD. Separately, we ran another $0.05T USD through Linux in the same year. Kinda says something about, doesn't it? Sorry to burst your bubble but this is utterly meaningless statistic. You show nothing but correlation and in no way a causation. Back in the days when the UK banks ran ATMs, c on Windows NT (I have no idea what they are running now) they went through a lot more value than that---means absolutely nothing... No worries... you're not bursting anyone's bubble here. We are limited as to what metrics we can publish in this open forum. If there's some information that would better put this into perspective, feel free to ask, but we are always at liberty to decline if the published information would violate any federal laws. -- 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 Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer jul...@freebsd.orgwrote: we really need a bud-submitting-user advocate.. Someone (need not have a commit bit) who doesn't take charge of the patch, but, rather, acts as a project manager in hte process of getting it in. i.e. finding, and then pinging the approriate developer, and occasionally nagging them or finding an alternate dev if the first choice is unresponsive. diplomatic skill would be important.. maybe a woman might be best in this job as the developers tend to not want to be rude to women :-) . I've suggested this before without much response, but since this thread seems to be encouraging repetition I'll give it another go. ;) I think a bounty system would be very effective(e.g. micro-donations of recent political campaigns) in getting many of these problems resolved. The main problem with a bounty system is getting people to pay since certain needs/desires lose their urgency over time. To address this, the system needs to be an escrow type setup where money is pooled until project is complete, then payment in full is given. There are large barriers to entry in setting up such a system though such as legal and financial hurdles. I don't believe the technical hurdles are over-whelming and I would be willing develop a web front end for such a system. Because of the barriers I believe such a system should be setup and spun off by the FreeBSD Foundation and I don't want to do any dev unless there is some momentum. -- Adam Vande More ___ 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 10:27 AM, Adam Vande More amvandem...@gmail.com wrote: I've suggested this before without much response, but since this thread seems to be encouraging repetition I'll give it another go. ;) I think a bounty system would be very effective(e.g. micro-donations of recent political campaigns) in getting many of these problems resolved. The main problem with a bounty system is getting people to pay since certain needs/desires lose their urgency over time. To address this, the system needs to be an escrow type setup where money is pooled until project is complete, then payment in full is given. There are large barriers to entry in setting up such a system though such as legal and financial hurdles. I don't believe the technical hurdles are over-whelming and I would be willing develop a web front end for such a system. Because of the barriers I believe such a system should be setup and spun off by the FreeBSD Foundation and I don't want to do any dev unless there is some momentum. Hi Adam, I went down this road sometime ago and went so far as to create a portal so that iXsystems could manage the transactions (collect the funds and make sure everyone got paid). We put a bit of work into it and we would be happy to hand the keys over to the Foundation if it's useful at all. http://sponsorbsd.org/ Let me know off-list if you'd like access to look at the code. It's a simple CakePHP app and needs a little bit of love but worked originally before we migrated the server. 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 Wed, Jan 18, 2012 at 10:27 AM, Adam Vande More amvandem...@gmail.com wrote: On Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer jul...@freebsd.orgwrote: we really need a bud-submitting-user advocate.. Someone (need not have a commit bit) who doesn't take charge of the patch, but, rather, acts as a project manager in hte process of getting it in. i.e. finding, and then pinging the approriate developer, and occasionally nagging them or finding an alternate dev if the first choice is unresponsive. diplomatic skill would be important.. maybe a woman might be best in this job as the developers tend to not want to be rude to women :-) . I've suggested this before without much response, but since this thread seems to be encouraging repetition I'll give it another go. ;) I think a bounty system would be very effective(e.g. micro-donations of recent political campaigns) in getting many of these problems resolved. The main problem with a bounty system is getting people to pay since certain needs/desires lose their urgency over time. To address this, the system needs to be an escrow type setup where money is pooled until project is complete, then payment in full is given. There are large barriers to entry in setting up such a system though such as legal and financial hurdles. I don't believe the technical hurdles are over-whelming and I would be willing develop a web front end for such a system. Because of the barriers I believe such a system should be setup and spun off by the FreeBSD Foundation and I don't want to do any dev unless there is some momentum. Bounty systems have not come into existence because of the potential legal ramifications w.r.t. distribution of funds, responsibility of completion of work, and a number of other points I've not listed here. iXsystems does help funnel money to contractors [with a small amount of administrative overhead] if you need something done and you have the funds to do it with. In which case, it's advised to have a proper plan, requirements document, and deliverables setup before going and proposing a course of action. That's where some opensource projects tend to fail: the requirements are too openended and thus the end-result cannot be achieved in a meaningful timeframe or in sufficiently manageable quanta (deliverables in this case). The deliverables and the scope of the work should be negotiated between all three parties: the 'customer', the 'contracting group', and the 'contractor'. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 18:27, Adam Vande More amvandem...@gmail.com wrote: I've suggested this before without much response, but since this thread seems to be encouraging repetition I'll give it another go. ;) I think a bounty system would be very effective(e.g. micro-donations of recent political campaigns) in getting many of these problems resolved. The main problem with a bounty system is getting people to pay since certain needs/desires lose their urgency over time. To address this, the system needs to be an escrow type setup where money is pooled until project is complete, then payment in full is given. This has a lot of problems in itself: people would just turn around and say that bugs will not get fixed unless they get hard cash for the fix, or FreeBSD might end up in the situation where devs get paid to fix the bugs they introduced, deliberately or innocently, essentially getting paid to fix their own sloppy code, which is not that great either. -- 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 18 January 2012 17:56, Andriy Gapon a...@freebsd.org wrote: on 18/01/2012 19:13 Daniel Eischen said the following: someone who owns a branch... - If you cut release N.0, do not move -current to N+1. Keep -current at N for a while, prohibiting ABI changes, and any other risky changes. If a developer wants to do possibly disruptive work, they can do it from their own repo. I am totally against this. I was thinking about this and I'm with Andriy on this: such solution has no long term potential and will only serve to stagnate the innovation. This has been repeated over and over in this thread, but it's worth another mention, currently, there are effectively four tracks: 7.4, 8.2, 9.0 and -HEAD, which understandably poses a lot of difficulty for in terms of maintenance. Whatever historical reason for that is, I think a lot of people would agree that this needs changing in the near future to have a single -RELEASE branch and a single -HEAD branch, but with the understanding by the devs that just because -RELEASE has been cut, it doesn't mean that everyone, en mass, drops development on that and hops on the -HEAD bandwagon... -- 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 Wed, 18 Jan 2012, Robert Watson wrote: I think John gets a lot of what he wants if we just fix our release cycle. Agreed. I still think that having two production releases running simultaneously really hurts focus and the end product, but that's not going to keep us from using FreeBSD. Not getting a decent five years out of a major release and not getting a minor release every 4-6 months *will* keep us from using FreeBSD. ___ 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, 18 Jan 2012, Igor Mozolevsky wrote: I was thinking about this and I'm with Andriy on this: such solution has no long term potential and will only serve to stagnate the innovation. This has been repeated over and over in this thread, but it's worth another mention, currently, there are effectively four tracks: 7.4, 8.2, 9.0 and -HEAD, which understandably poses a lot of difficulty for in terms of maintenance. Whatever historical reason for that is, I think a lot of people would agree that this needs changing in the near future to have a single -RELEASE branch and a single -HEAD branch, but with the understanding by the devs that just because -RELEASE has been cut, it doesn't mean that everyone, en mass, drops development on that and hops on the -HEAD bandwagon... And as long as we're repeating ... :) Since 9.0 is already out of the bag, I think a decent approach would be to fizzle out 8.x on the current timeline/trajectory (maybe 8.4 in 6-8 months, and maybe 8.5 in a year or so), then: - EOL 7 - mark 8 as legacy - mark 9 as the _only_ production release - release 10.0 in January 2017 And in the meantime, begin the every 4-6 month minor releases that we all agree can occur with 9. By Jan 2017, you get to 9.12 or 9.14 or so. This is nice because no upheaval needs to happen with 7 and 8, and interested developers do not get kneecapped vis a vis 9 - they can just keep going where they were going with it, and the only real change is that 10 is pushed out a long ways, and people[1] get to really sink their teeth into 9. [1] *both* developers and end users ___ 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, 18 Jan 2012 13:46:45 -0600, John Kozubik j...@kozubik.com wrote: And as long as we're repeating ... :) Since 9.0 is already out of the bag, I think a decent approach would be to fizzle out 8.x on the current timeline/trajectory (maybe 8.4 in 6-8 months, and maybe 8.5 in a year or so), then: - EOL 7 - mark 8 as legacy - mark 9 as the _only_ production release - release 10.0 in January 2017 And in the meantime, begin the every 4-6 month minor releases that we all agree can occur with 9. By Jan 2017, you get to 9.12 or 9.14 or so. This is nice because no upheaval needs to happen with 7 and 8, and interested developers do not get kneecapped vis a vis 9 - they can just keep going where they were going with it, and the only real change is that 10 is pushed out a long ways, and people[1] get to really sink their teeth into 9. What are the policies for changes though? Are we stuck with 9.0's feature set for 5 years? Will we have to wait 5 years to get a stable release of FreeBSD with KMS/GEM? That work is unfinished and didn't make 9.0; it's also a huge changeset. How will things like this be dealt with? Five years is a long time for the next stable release if we have a policy to not import major changes from -CURRENT. It would be devastating to so many users. ___ 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/18/2012 11:46, John Kozubik wrote: - mark 9 as the _only_ production release While I understand your motivation, I am not sure this is a workable goal when combined with the goal that others have expressed of longer timelines for the support of a given branch. Speaking from personal experience, once a service is released on a given platform the costs of migration can be significant. And if what I have is working well and only needs the occasional bug/security fix my motivations for migration are near zero. So the tradeoffs then become more frequent major releases to get new features, vs. longer support for a given release branch. Let's take 5 years as a reasonable time period for supporting a branch. Waiting that long between major releases would significantly stifle the ability to add new features that require breaks to the [AK][BP]I. It would also inhibit our ability to do revolutionary architectural changes such as moving to clang as the primary supported compiler. What I've proposed instead is a new major release every 2 1/2 years, where the new release coincides with the EOL of the oldest production release. That way we have a 5-year cycle of support for each major branch, and no more than 2 production branches extant at one time. History tells us that 2 production branches is a goal we can achieve, with the focus shifting more heavily towards only bug/security fixes in the oldest branch after the new production release branch is cut. If we combine that with the ideas that are being put forward about teams that own a production branch, and a more frequent stripped-down release process, I think this is a very workable model. 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 Jan 2012, at 11:47, Robert Watson wrote: It strikes me that the first basic plan would be a release schedule, however. :-) 7.4 - no further development 8.3 - Mar 2012 9.1 - May 2012 8.4 - July 2012 9.2 - Sep 2012 8.5 - Nov 2012 9.3 - Jan 2013 8.6 - Mar 2013 9.4 - May 2013 8.7 - July 2013 - Final release 9.5 - Sep 2013 10.0 - Nov 2013 9.6 - Jan 2014 10.1 - Mar 2014 Although, I'm not sure a release every two months would be practical. - 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 18 January 2012 22:31, Mark Blackman m...@exonetric.com wrote: 10.0 - Nov 2013 I think 10.0 should be released based on feature-readiness and not on some arbitrary date... -- 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 18 Jan 2012, at 22:50, Igor Mozolevsky wrote: On 18 January 2012 22:31, Mark Blackman m...@exonetric.com wrote: 10.0 - Nov 2013 I think 10.0 should be released based on feature-readiness and not on some arbitrary date… You can always redefine the feature-set to meet the date. :) - 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 18 January 2012 22:53, Mark Blackman m...@exonetric.com wrote: On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote: On 18 January 2012 22:31, Mark Blackman m...@exonetric.com wrote: 10.0 - Nov 2013 I think 10.0 should be released based on feature-readiness and not on some arbitrary date… You can always redefine the feature-set to meet the date. :) Yes, but there's a difference between releasing because it's the right thing to do now vs releasing because it's about time... -- 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 18 Jan 2012, at 22:59, Igor Mozolevsky wrote: On 18 January 2012 22:53, Mark Blackman m...@exonetric.com wrote: On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote: On 18 January 2012 22:31, Mark Blackman m...@exonetric.com wrote: 10.0 - Nov 2013 I think 10.0 should be released based on feature-readiness and not on some arbitrary date… You can always redefine the feature-set to meet the date. :) Yes, but there's a difference between releasing because it's the right thing to do now vs releasing because it's about time… The terse-ness of the e-mail should have told you it wasn't particularly serious. :) However, it was based around 3 minor releases per year, fitting whatever features make sense, FSVO sense, into each one, giving HEAD a bit over two years to gestate into something you might one day bet the farm on, which isn't a million miles from what happens anyway. - 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
