Hi Eric, Ah - got it. I see your logic, but I don't think this list is really set up to pair people with mentors - which is really what you're looking for.
People should definitely respond who are willing to help Eric get up to speed about the putback process. Eric - if you don't get a response here, you'll want to ask around individually. Question for the people on this list: does it seem that something like a 'request-mentor' alias might be useful? Thanks a lot. Bonnie Eric Boutilier wrote On 05/25/06 15:34,: > On Wed, 24 May 2006, Bonnie Corwin wrote: > >>Hi Eric, >> >>Who is the external contributor requesting a sponsor for this fix? > > > Hi Bonnie, > > There isn't one actually. This is a situation where the person interested > in working on an RFE (me) is a Sun employee, but one who does not have > experience doing putbacks to a consolidation. > > My thinking is that although the request-sponsor process was developed > with external (non-Sun) contributors in mind, as far as I can tell it's a > logical process for internal, non-Solaris-engineer contributors as well... > > Eric > > >>Eric Boutilier wrote On 05/24/06 11:40,: >> >>>This is a sponsor request for CR 6422494 - VIM should be in WOS and >>>installed as /usr/bin/vim. >>> >>>See below for more background. >>> >>>Eric Boutilier >>> >>>-------------------------------------------------------------------------- >>> >>>From: Eric Boutilier <Eric.Boutilier at Sun.COM> >>>Date: Wed, 24 May 2006 12:37:14 -0500 (CDT) >>>To: Keith M Wesolowski <keith.wesolowski at sun.com>, tools-discuss at >>>opensolaris.org, sfwnv-discuss at opensolaris.org >>>Subject: Re: What about VIM (vi Improved?) >>> >>>On Mon, 8 May 2006, Keith M Wesolowski wrote: >>> >>> >>>>On Mon, May 08, 2006 at 02:06:54PM +0300, Cyril Plisko wrote: >>>> >>>> >>>> >>>>>On 5/8/06, Brian Nitz <Brian.Nitz at sun.com> wrote: >>>>> >>>>> >>>>>>No, it looks like I missed the obvious. Does anyone know if there is a >>>>>>reason why we can't do this? >>>>>>Cyril, do you want to reopen RFE 6422494 with this proposal or should I? >>>>> >>>>>Brian, please do so ! >>>> >>>>Thanks. BTW, although the evaluation field isn't shown ($...@#$%! >>>>b.o.o!), this is what I put there when closing the RFE: >>>> >>>>--- >>>>While adding VIM to Solaris is a fine idea, replacing /usr/bin/vi with >>>>it is not. Also, since VIM is not GNU software, it does not belong >>>>in /usr/gnu. Please do re-open this bug with a synopsis and >>>>description that more accurately reflect the true scope of the RFE: >>>>you want VIM in the WOS. This absolutely is a worthwhile goal. >>>> >>>>If the current synopsis is an accurate reflection of the RFE, >>>>there is no reasonable way this RFE can be implemented: vim is >>>>incompatible with vi, and has other characteristics (such as >>>>a huge memory footprint relative to vi) that may make it unsuitable >>>>or undesirable for many current vi users. >>>>--- >>>> >>>>I want to make it absolutely clear that putting VIM in /usr/bin sounds >>>>to me like a fine plan. But I'll be very interested to hear how you >>>>plan to deliver VIM's 'view' binary, since its name conflicts with >>>>that of the existing program. >>> >>> >>>I'm going to start drafting a proposal for this. (Bug ID 6422494) >>> >>>Cyril had a good question that nobody replied to: Is it feasible to >>>deliver only part of the vim package? >>> >>>A typical vim build installs the following in /usr/bin: >>> >>>- 3 regular files: vim, vimtutor, and xxd[1] >>> >>>- 11 files sym-linked to vim: evim, ex, gview, gvim, gvimdiff, rgview, >>> rgvim, rview, rvim, view, vimdiff. Two of these -- view and ex -- >>> collide with existing files. >>> >>>Here are some possibilities that I can think of: >>> >>>1. Include vim (and its supporting files), but omit everything else (the >>> 11 sym-links, xxd, and vimtutor). >>> >>>2. Include vim, vimtutor, and the 11 sym-links, but omit >>> ex and view. >>> >>>3. Include everything, renaming view and ex (viewm/exm? >>> vimview/vimex?) >>> >>>4. Other...? >>> >>>If we went by the usage patterns of a lot of vim users (me included), >>>option #1 seems to make a lot of sense. But my take is that #3 is best -- >>>mostly because implementations of the vim package are already in >>>widespread use on other popular platforms, and it'd be best to be as >>>compatible as possible with those. >>> >>>Eric >>> >>>[1]: xxd is a hex dumper/undumper >>>_______________________________________________ >>>request-sponsor mailing list >>>request-sponsor at opensolaris.org >> > _______________________________________________ > request-sponsor mailing list > request-sponsor at opensolaris.org