[os-infrastructure] Re: [os-engineering] Model discussion boileddown

[Alex Hanshaw]

Hi Joe

 The choice of platforms will have a significant impact in terms of
tools etc. I do not think that the choice of platform affects the choice
between model a) or model b) for content of the community repository.
 Did you have a preference or an alternative model?

 Alex

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Joe Abbate
Sent: 25 June 2008 02:22
To: Andrew Ross
Cc: Open Source Engineering; Open Source Infrastructure
Subject: [os-infrastructure] Re: [os-engineering] Model discussion
boileddown

Hi Andrew,

Andrew Ross wrote:
> We have reached consensus as a team that it is impractical for us to
> move off of Piccolo (p) until some outstanding technical and workflow
> issues are sorted out. There seems to be agreement that this is the
> right direction and recognition that it's going to take time.
>  
> We also have consensus that p isn't practical for enabling community
to
> work with us. (it isn't visible to the public, wasn't designed to be,
> etc.)
>  
> Thus we expect to work with p internally and Subversion (svn) for
> external code access. This is expected to be the case for the
remainder
> of 2008. A key next step is deciding how to synchronize the two and
what
> content to make available publicly. 

I think there is a key decision that needs to be made before discusssing

synchronization and the two models.   The question is which platforms 
will be supported by the Ingres Community Edition.  If the answer to 
that question is "all currently supported commercial platforms," then 
the choice of Subversion is a much bigger problem than
if, say, "only Linux, Windows, Mac OS/X and OpenSolaris are to be 
supported."  And as you may suspect, the reason is that there is no 
Subversion client for VMS.  Trying to work in main from remote client, 
would be IMO unacceptable.  And although in the past (18 months ago or 
so) we only had one VMS engineer, we now have three (albeit perhaps not 
all full-time).

Furthermore, in the past VMS releases were done many months, if not 
years, behind the core releases, but that has changed.  We are currently

tracking the 9.2 release closely and soon I anticipate being able to do 
actual development work in main, rather than simply using it primarily 
as a way station between 2006r2 and 2006r3.  And coincidentally the work

that I was planning on doing involves another thorn on the VMS support 
arena:  Xerces.  Currently, we don't support Unicode coercion and the 
XML import/export utilities on VMS because (until recently) the only 
Xerces-C version available for VMS was 2.2 (2.7 is now available, but we

can't depend on HP making each released Xerces-C version made available 
on VMS).

If Ingres were to decide, for example, that VMS was a legacy platform 
and that no effort would be made to support "new" features such as 
Unicode, UTF-8 and the Itanium migration, and then only on the 
Enterprise Edition, then the Community Edition would be able to become 
free of VMS code (the CL, the DCL scripts).  And Subversion and Xerces 
are not the only obstacle:  although VMS is billed as POSIX compliant, 
the tools and libraries are not up to par with those available on Linux,

OS/X and Windows.  For example, GNU make is at version 3.78.1.   If we 
wanted to move to autoconf/automake instead of Jam, having to use that 
as LCD would be a drag on the other platforms.

Joe
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure