Bonnie, That makes sense. In fact, thinking more about this particular
case, a mentor in the traditional sense might not even be required. Reason
being, I have access to resources internally, and because there's no hurry
(it's an RFE as opposed to a bug fix, and not a high priority one at that)
in theory I can read/practice/learn/do the preliminary (pre-putback)
stages of the project mostly unassisted.

Eric

On Fri, 26 May 2006, Bonnie Corwin wrote:
> 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
>

Reply via email to