Coordinating the Vms porting efforts

[labadie_1]

Hello

I see regularly various freeware ported to Vms a second time by another person.
I think this is a pity, as there is a real need to have some software ported urgently.
Some years ago, Mysql was the important piece missing on Vms.
It is now available.

In your opinion, what is the most urgent freeware to port ?
I think some SAP-light may be useful (Baan, Bpcs...), when I see more and more companies leaving Vms because they go for SAP or any other ERP.
While there are many interesting languages to port, having a good language is not enough: you need to be able to read a Vms indexed file, to access an Oracle or Rdb database, use all the Vms system services...
We need more than printing Hello World :-)
So Haskell, Erlang, Ocaml, LUA, Lisaac may wait a little.

Several Wiki and CMS (content management system) are available, so this is not at the top at the list IMHO.

What do you put at the top of the list ?

[David Jones_21]

When I re-port things, it is usually because the existing port is several versions out date and/or sub-optimal choices were made in how to accommodate OS incompatibilities in the freeware version.

[labadie_1]

I was more thinking at some recents ports, like bzip2 ported, when it was already available.

I think there are few people porting free software to Vms, so such thing should be avoided.

[Hoff]

I was party to a recent email discussion on a nearby topic; a discussion basically related to coordinating and maintaining an open source depot and open source ports.

No future Freeware distro is known to me.

Contact me off-line and I'll send along the information on who was thinking about this project. I'd rather not post the names here.

I know of only a few folks actively porting open source wares over to OpenVMS.

There are certainly larger porting efforts available for consideration, whether you look at a business practices environment (SAP, et al) or at PostgreSQL or the Ingres community release databases.

That written, it is often easier to use the existing tool ports -- or existing and supported packages -- on the particular platforms that have ports or packages. Or for folks with specific requirements and/or particularly for larger-scale packages, to simply pay for a port.

What package(s) are appropriate or are needed can and does vary widely, and whether or not incorporating support for native OpenVMS features and APIs such as indexed files is considered appropriate also varies. Widely.

And empirical evidence shows duplication of effort is an inherent feature of open source and open source porting -- the definition of "best" is always highly localized.

Contact me offline and I'll get you in touch with the folks that were here ruminating most recently.

Stephen Hoffman
HoffmanLabs.com

[Steven Schweda]

> I was more thinking at some recents ports,
> like bzip2 ported, when it was already
> available.

> the definition of "best" is always highly
> localized.

Exactly. I like my bzip2 better, naturally.
On the bright side, the more people who do a
job, the better the chance that one of them
will get it right.

[Jansen_8]

To Take bzip2 as example:
Probably I was the first to port the stuff. But when I got aware of Steven's port, I recognized his work was better and changed the links on my web-page.
Recently I cam across Alexey Chupahin's port He added some good idea's but was nor aware of Steven's port. So I urged him to look at it and merge the two versions to get a better one. (I'm not sure what the status is).

IMHO : the more people work on VMS-porting the better. But avoid inventing the wheel many times. So merge good ports into one version.

[Jansen_8]

Oh, and I forgot to mention that I'm normally in favor of including the VMS-port into the "original" distribution. This has the advantage that if the package evolves some of the VMS stuff is automatically updated and there is only one version.

However, in the case of bzip2 the author of bzip2 was not very cooperative (some 10 years ago).

[Steven Schweda]

> However, in the case of bzip2 the author of
> bzip2 was not very cooperative (some 10
> years ago).

That was my experience in 2006-2006, too, but
he did fix a problem I reported in the UNIX
installation procedure.

The new wget maintainer has expressed at
least a weak interest in adding some
VMS-related changes. I've been trying for
years to figure out which release is that
"next" release, where all the good stuff will
happen.

[Craig A Berry]

In my view the best way to keep a package up to snuff on VMS is to get involved in the community or project that maintains it. Learn to speak their language and learn their submission policies and procedures, their coding standards, their tools, and their workflow. If it's a single-author packge (like bzip2) and that author is not open to it, there's not much you can do, but in my experience that's rare.

Some of the typical dos and don'ts when participating in open source projects would be:

Don't view porting as a one-way, one-time effort: get your changes into the authoritative repository and use whatever tact, diplomacy, and technical prowess you have at your disposal to make that happen and keep them up-to-date.

Do submit changes against the latest development snapshot, not the last stable release.

Don't make changes that will work only on VMS unless it's really necessary (such as providing VMS-only functionality).

Do make your VMS-specific changes in a way that minimizes the cost of maintaining a separate port. For example, take advantage of existing build infrastructure if possible.

Don't make the mainline code a jungle of "#ifdef __VMS" statements. Use OO-type overrides, macros, LIB$INITIALIZ sections, and/or separate modules and procedures to abstract out platform differences where possible.

Do make changes that upgrade the code to comply with some published standard, such as ANSI C, the Open Group Single Unix Spec, or some relevant RFC. There are times when standards compliance makes the portability problem go away.

Don't make changes that break functionality on other platforms -- test everywhere (or at least on one non-VMS platform) before submitting.

Do submit changes as GNU uniified diffs, not as VMS DIFFERENCES output (though this varies by project).

Don't override missing CRTL functions in a way that will break if a new CRTL begins to provide them. Either do your own prefixing or do a configure-time test for the presence of the functions and define macros accordingly.

Do port, support, and run any test suite available with the package when at all possible.

Well, this could go on for pages, but it's a start.

[Ian Miller.]

I think openvms.org could be involved in this in a publicity role or hosting a poll or perhaps hosting a forum (with limited members). I don't think there is enough disk space to hold the projects.