[advocacy-discuss] Porting Community

[Jim Grisanzio]

Ron Kleinman wrote:
> Jim Grisanzio wrote:
> 
>> Ron Kleinman wrote:
>>
>>> Dennis Clarke wrote:
>>>
>>>>> Maybe we should start a porting community for all that stuff that gets
>>>>> ported or will be ported to opensolaris, iandiana, solaris or 
>>>>> however we
>>>>> call it. And with it a place to host all these projects ?
>>>>>   
>>>>
>>>>
>>> Advocacy-ites,
>>>
>>>   Actually this parallels the approved charter  of the (still closed) 
>>> migration-tools project in the former Immigrant's Community.  See:
>>>
>>>     http://www.opensolaris.org/os/project/migration-tools/
>>>
>>>   The approved charter is:
>>>
>>>     /The goal of this project is to provide a central location for a
>>>     growing source code repository of generic tools and associated
>>>     documentation, designed to ease / automate the various tasks
>>>     involved in porting applications and scripts from a variety of other
>>>     Unixes (Unixii?) to OpenSolaris.
>>>
>>>     I am seeking seconds for the proposal and an endorsement from the
>>>     leaders of the Immigrants Community, as this project seems fully in
>>>     keeping with the community  charter. Initially all we'd need is a
>>>     project space, assuming project members could share the existing 
>>> list.
>>>
>>>     One expected submittal for early collaboration is a Java based tool
>>>     (JSCORE) that uses a defined "before / after" ASCII text file
>>>     (specific to either HP-UX or AIX), to match on any "before" string
>>>     in a submitted ASCII C/C++ file and convert it to the "after"
>>>     string, thereby reducing the effort to port an alternative Unix
>>>     application to OpenSolaris.  Note in this case, the proceedure could
>>>     be made reversible by simply switching the before and after strings.
>>>
>>>     One set of additional submittals / development would likely  be
>>>     centered around providing emulation library modules for such things
>>>     as "longtostring()" functions which incoming "immigrant"
>>>     applications may require. /
>>>
>>>   I was only able to devote a small amount of effort to this due to a 
>>> Sun internal re-org, but I always felt there was more here than a 
>>> project structure could accomplish.  Something like an OpenSolaris 
>>> Porting Community, with general best practices, generic tools (ex: 
>>> JSCORE) and process tips at the top level might well be the best way 
>>> to address this topic.  Individual projects under that community 
>>> could focus specifically on a single alternative OS platform, 
>>> generating lists of porting differences / problem points in OS APIs, 
>>> scripts, install packaging), etc.
>>>   One could even have a project to ease migration of applications 
>>> from earlier versions of Solaris to OpenSolaris.  Not as strange as 
>>> it might seem.
>>>     Example:  Calling closedir() twice on the same directory pointer in
>>>     Solaris 8 doesn't cause a problem, in OpenSolaris it crashes the
>>>     program.
>>>   IMHO, it would be useful to have a collection point for that sort 
>>> of stuff, to help developers trying to port their applications to 
>>> OpenSolaris from a variety of platforms?  I'm just not certain 
>>> whether that point would be the Advocacy Community, or a separate 
>>> Porting  community totally dedicated to porting and porting projects.
>>
>>
>>
>>
>> Well, I think a porting community has been brought up from time to 
>> time and I think a distros community was also brought up recently but 
>> I'm not going there. :) Entire communities for those purposes are 
>> outside the scope of this community group. But people felt that the 
>> Immigrants Community ought to be part of the Advocacy merger, so 
>> that's why you are here. Any associated projects should also be part 
>> of that merger unless you feel that you need to be part of another 
>> effort, which would be fine, of course. I've always felt that the 
>> Advocacy CG would have both technical and non-technical projects. And 
>> I think it will.
>>
>> Jim
> 
> 
> 
> Jim,
> 
>  Fair enough.  The purpose of  "migration-tools" is pretty clear.  Right 
> now, despite being a single project, I could imagine an eventual series 
> of allied projects (one per alternative OS, one for script conversions, 
> one looking at building with gcc, etc.) with a common framework of best 
> practices and such.  But we aren't there yet.
> 
>   So given its present state of development, I'm agreeable to leaving 
> the "migration-tools" project in the Advocacy Community (assuming there 
> aren't objections from community members).  But if folks think there's a 
> better home for it (where?)  or it should be upleveled into a separate 
> community, please let me know?


Cool. Well, if there are objections we can certainly address them. 
Shouldn't be a problem, though. The bottom line is that you came along 
with an approved merger, so I'd argue that after we open the Advocacy CG 
(hopefully next week) we open your project (whenever you are ready), and 
then you just get going on your stuff. That doesn't preclude other 
Community Groups from also endorsing you, it doesn't preclude us from 
opening more projects to collaborate with yours if that makes sense, it 
doesn't preclude someone from proposing a new Community Group to address 
a series of projects into which yours would eventually fit, etc. Let's 
just start, build in stages, see where things best fit, and make 
adjustments along the way.

Jim
-- 
Jim Grisanzio http://blogs.sun.com/jimgris