Danek Duvall wrote: > On Wed, Sep 12, 2007 at 06:31:24PM -0400, Bill Sommerfeld wrote: > >> On Tue, 2007-09-11 at 21:07 -0700, Stephen Hahn wrote: >>> I suppose another way to answer this is "all aspects are debatable, as >>> long as (a) the debate is resolved by someone ultimately writing code >>> and (b) the end product still resembles what we were talking about at >>> the beginning". >> so, who gets to decide who gets to write code? > > By merit: are you writing quality code that shows an understanding of the > problem space, the code base, the direction of the project and the general > team dynamic? If so, then welcome to the team in whatever capacity you can > provide. I think that's generally the way things work when people aren't > assigned to projects by someone waving a paycheck in front of them and a > pink slip behind. :)
In my experience say zfs, trusted extensions etc, all code dev was done on nevada naturally, then backported to s10 update N and people outside of development ie gatekeeping are then forced to break this massive and all pervasive wad of code into patches that customers can install on updates N-1 and so on. This leads to all sorts or problems in my opinion, the people doing code dev are completely removed from the process of delivering it to end customers Take IP instances, developed in nevada, backported to 8/07 ( update 4 ) and patches were cut that enables pre 8/07 people to get ip instances, but no where could I get a list of patches that would give me this in 11/06! I had to do trial and error to eventually find the 4 necessary patches, and then write an info doc on this. So I imagine that while this process will deliver a new set of tools, what will solve the problem I talk of above. Currently patching is so script involved as we are essentially forcing a pseudo upgrade mechanism on top of it, ie 120011 the u4 jumbo KU is defacto upgrading you to more or less u4 ( rough guess approx 90%+ of u4 functionality ) Take the patch script i.manifest it does an SVCCFG_CHECKHASH=1 /usr/sbin/svccfg import $dst but $dst then gets it group bits etc set by pkginstll ( tho what is specified in pkgmap ), and on next reboot the hash in repo no longer matches and we then import a second time! Did anyone consider staying with SVR4 and just making the tools work properly. i.e a green field site and using SVR4 build a complete set of tools from ground up. Enda > >> I have on a couple occasions offered to contribute code to projects >> under review at PSARC to resolve issues, and (for whatever reasons) >> generally this hasn't been received well. > > Is this an expression of lament or surprise? > > Danek > _______________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/install-discuss
