On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: > I believe core has a policy of never supporting vaporware... There is > always the chicken and egg problem with arguments like this... I'll > code this if you agree to support it and maintain it/I will agree to > support it once you code it... In FreeBSD, and many open source > projects, no code, no support, how can you support or even agree to > support something that doesn't exist? And then as soon as FreeBSD > agrees to support something that doesn't exist, either a) other people who > were interested in the project stop, even if you end up never producing > a bit of code, or b) someone else produces better code, drops the > support for the original, but then the author complains about being > told they'd support his code, and going with another code base... > > Bottom line: Once code exists, then support can be talked about.. This is the chicken and egg problem that will kill FreeBSD. I don't bother writing up patches for FreeBSD because every time I do they sit in a PR and get ignored for several years. Then someone that does have commit rights makes their own patch (which often is less useful) but they own it and the best I've ever succeeded at was convincing them to put some of the ideas from my patch into their code.
Note that none of these patches were ever rejected for any technical or political or any other reason. They just don't get paid attention to. Thus, I try to get consensus that the idea has merit. IF freebsd committers can be bothered to pay attention to the idea, I'll write code for it. But I'm too old and tired to spend another week writing up something that will get ignored for X years and then dropped for obsoletion again. AND there are a lot of opinions and politics around how to version the core that have nothing to do with code. There's no value in writing code that will be ignored because it doesn't agree with -core's view of "should be". I'm a coder, not a politician. If we can get consensus on what type of implementation would be acceptable to core, then I and many others would be happy to write code to implement this idea. But this is a considerable amount of work that will be closely tied to the operation system installation. It's not something that you can churn out 7 different implementations of just to see which one fits the current polical environment. Back to your finale: > Bottom line: Once code exists, then support can be talked about.. This is bullhockey and you know it. Once the project is done, we'll authorize a budget for it? Once the season is over we'll know who should be on the starting team? Yeah, hindsight is sweet. But this isn't a simple change. It will require very close integration with the installation and kernel modules at least (and probably more). So having some sort of consensus that (a) the project has interest and (b) what flavors would be acceptable to the existing groups - are both necessary for this project to even mumble it's first line of code. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
