Hello! For what's worth since at the moment I'm a spectator and sometimes comments maker, I agree.
Once when trying to build a kernel that was closer to the term unique rather then the generic one that normally traveled with one of my systems, I came across references to certain items that had Google's fingerprints on it. I asked about it here, and sure enough the response was that it was invented for the Google servers, and was sent as contribution to the Linux Kernel community. I wasn't able to make my unique kernel work, but it was an interesting job. And I'm still interested in figuring out further how I can contribute to this particular example of software running hardware properly. ----- Gregg C Levine [email protected] "This signature fought the Time Wars, time and again." On Sat, Feb 8, 2014 at 4:03 PM, ron minnich <[email protected]> wrote: > On Sat, Feb 8, 2014 at 8:30 AM, Peter Stuge <[email protected]> wrote: >> ron minnich wrote: > >> I disagree. I do think it means that the project isn't fitting its >> contributors so well. Note that I am explicitly not saying and not >> thinking that it is a failure of any contributor. > > If you have some idea, then propose it. Best to propose something then > just say "this is wrong". > >> >> If the project could change to work somehow differently and that >> would help contributors then I think that's something we should >> consider identifying and doing. > > who is the "we" here? Who identifies, and what do they do? And how do > you manage the fact that companies may do development that for a > number of reasons can not be released immediately? > >> >> >>> It's a natural consequence of the fact that companies can't always >>> immediately push all their work upstream. >> >> What's the difference from Linux kernel development again? > > Nothing. Most companies I know of that use Linux, and contribute to > upstream, deal with the issue of upstream vs. what is done in the > company and the time delay involved. They have the same time delta > issue with their internal patches vs. upstream. So we're not > different. > > ron > > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
