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.

Advertising

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