--- [EMAIL PROTECTED] wrote: > > >I feel maybe we're getting closer to the issue. I think a lot of > >people are put off by the perceived complexity of submitting code > to > >OpenSolaris. I also think that not compromising on quality is a > good > >goal, but that you have to understand that the community only > >produces Very Good Code only through an iterative process. I think > it > >has to start with "barely works", proceed to "works in most > cases", > >on to "works all the time on all platforms", followed by "we made > it > >relatively fast" to finally "it's screaming fast". I think that > >expecting one person to follow through from start to finish by > >himself is too harsh, and only a few very motivated people will do > >it. I think you need to look at something like Debian, maybe > having a > >unstable release, where everybody and their brother can go check > in > >code that may break stuff, and then the community members can come > in > >and find bugs, talk about them, fix them, and encourage/support > each > >other. That would, I think, really chafe the Sun Engineering Way, > but > >I am fairly confident it would get more people involved, > regardless > >of license. > > At Sun we have no tolerance for "works some of the time" or even > "works in most cases" code. At least not in the main branch.
What I mean was --Works in x86 32bit but not in 64bit, and not in Sparc --Works with Bash but not ksh --Works with single core but not dual or even 8 cores --Works with cli but crashes X Window etc. > This is why we have "projects" which are by and large experimental > branches. Can a "project" be long-lived enough to allow for long-term development by a largish team (like doing an 12 month project for a team of 15 without getting hopelessly away from the main branch? > In the main branch, I can't see any reason for code which does not > work. Could you see dog-slow code (but working correctly) code in the main branch? For example, a utility written in Python rather than C/C++? > When we created the development process, we very much went for a > "cut to size" approach; the bigger the project the bigger the > overhead; > consider it a flat rate tax. ksh93 is huge as a project and so it > pays a large tax; changes limited to a few lines pay a much smaller > tax (though there's a minimum fee, I would gather) I see. > >As far as the patent/NDA encumbered libs, can could OpenSolaris > >Unstable even run without them, or with empty/minimal > functionality > >wrappers? I'm asking because someone will want to compile code > >locally and see if it even runs before sending in diffs. > > You will need and can have the binary. Could you humor me and tell me, in your opinion, what a team composed entirely of non-Sun people would have to do to reverse-engineer the binary-only code? Pull a samba? > >Also, I would look at allowing people to check in either x86 or > sparc > >code, letting the community work on the other. As someone else > >mentioned, I imagine very few people will have both types of > >machines. > > I think there's supposed to be a test pool in future. I see. Thanks for the comments. Chris Mahan 818.943.1850 cell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.christophermahan.com/ ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
