Re: [Oorexx-devel] post-release actions

[Harmander Singh]

Could getting more hands on deck help? Maybe specific tasks anyone thinks
can be offloaded may be announced, and volunteers can then interact with
the person to accomplish them.

I had earlier volunteered but was not offered any task (perhaps none was
suited to my skill-set which is: a lot of Rexx experience, and a little
ooRexx knowledge). Maybe documentation/testing help?

On Mon, 25 Jan 2021 at 03:58, Jeremy Nicoll 
wrote:

> On Sun, 24 Jan 2021, at 16:05, Jeremy Nicoll wrote:
>
> > I'd never heard of it until you mentioned it.  According to
> >
> >https://en.wikipedia.org/wiki/Microsoft_Store
>
> ...
>
> And also, I just stumbled across the following article, which
> makes it clear that right now there's more than one MS app
> store, but that two of them are probably about to cease to
> exist:
>
>
> https://www.zdnet.com/article/microsoft-is-planning-to-phase-out-the-windows-10-store-for-business/
>
> --
> Jeremy Nicoll - my opinions are my own.
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seven years since the last release

[P.O. Jonsson]

> Am 24.01.2021 um 21:44 schrieb Rick McGuire :
> 
> 
> 
> On Sun, Jan 24, 2021 at 3:30 PM P.O. Jonsson  > wrote:
>> Am 24.01.2021 um 18:11 schrieb Rick McGuire > >:
>> 
>> 
>> 
>> On Sun, Jan 24, 2021 at 11:11 AM P.O. Jonsson > > wrote:
>> 
>>> Am 24.01.2021 um 12:39 schrieb Rick McGuire >> >:
>>> 
>>> P.O., you have commit privileges now, so you ARE a developer.
>> 
>> I only used those privileges for documentation purposes, but if you are fine 
>> with it I will contribute what I did.
>> 
>>> If you have an install process working that is working through CMake 
>>> working, then it should be checked into the project. Having something that 
>>> is your private setup is not a working solution. You could be hit by a bus 
>>> tomorrow,
>> 
>> Regarding bus accidents: this is indeed one weak spot in the project: the 
>> whole Jenkins business (setup scripts, addresses, PWs etc) is backed-up 
>> locally and the information is spread on a few hands but there should be 
>> some mechanism to secure it on Sourceforge, which is lacking today. Moving 
>> Jenkins last time was a major effort with a lot of tweaking. I suggest to 
>> rename the „buildmachine“ item in the documentation back to „oorexxbuild“ 
>> and start documenting all aspects of the build process there. Last time this 
>> was done was in 2012 it seems. oorexxbuild, the earlier name (and internal 
>> name used as well) appears more logical than buildmachine, it is not about a 
>> machine rather all aspects of building ooRexx.
>> 
>>> so our ability to build an installer would go away. Having an installer 
>>> available means any interested person can checkout the code and follow the 
>>> instructions to build it themselves. 
>> 
>> Regarding an installer for macOS: The currently available „official“ 
>> installer, 4.1.2 (on RexxLA and Sourceforge) was introduced late 2012 and 
>> stopped working late 2015 with the introduction of SIP in macOS El Capitan. 
>> It has been broken for five years by now, I do not think that can be 
>> considered „Gold“ can it?
>> 
>> I reverse-enigeered the 4.1.2 pkg-installer and fixed the installation 
>> problem by moving the installation from /usr to /opt and created a new 
>> installer. I had to make it a command-line installer since the pkg build 
>> option did no longer work on macOS, but it is pretty straight forward. I 
>> also created uninstaller scripts for version 4, something that was missing 
>> all the time. This installer was offered to the project but never accepted. 
>> Available here 
>> 
>> 
>> I have no knowledge on how to upload anything to sourceforge other than to 
>> the build trunk, so if the installer for V4 is accepted can someone please 
>> put it in the right place?
>> 
>> No, the correct place would be to check it in to the source tree, as all 
>> other critical items are. Follow the lead of what was done for Windows. 
>> Files needed to build the installer are in trunk/platform/windows/install. 
>> There should be an equivalent directory created for the Mac. 
> 
> OK, I will put everything used for the installer in 
> trunk/platform/unix/macosx/ once I have confirmed that the 3 files residing 
> there are obsolete and not used anywhere in Cmake. Currently I refer to local 
> files but this will be easy to amend once it is agreed to go ahead. 
>> 
>> Also, I want to make clear that this is only acceptable if you have 
>> addressed the CMake integration issues. I'm not sure you really understand 
>> the requirement here. By integrated, I mean that all artifact files are 
>> defined only in the project cmake file, and then cmake makes the adjustments 
>> to pick up the build artifacts. 
> 
> OK, I admit I am not quite there yet, but I am working on it.
> 
>> 
>> So, to be clear, let's assume I add a new xyz.cls file to the project (or a 
>> new library file, sample, whatever). All I need to do as a developer is to 
>> make the appropriate additions to the cmake file, including adding an 
>> "install" definition to the cmake file. Your integration for the Mac 
>> installer should update whatever install artifacts need to generate the 
>> installer automatically.
> 
> It does.
> 
>> If a developer needs to directly alter any of the Max installer files, this 
>> is not acceptable. This was one of the primary reasons we switched to CMake 
>> in the first place, to get away from having different makefile and installer 
>> requirements for the different platforms. 
> 
> Any modification to the source code will be picked up by the installer, since 
> it is a step AFTER the "build install“ step, i.e. the installer is built from 
> an existing and working installation in the default position, currently 
> ~/Applications.
> 
> I am not referring to modifications to the source files, that is just 
> business as normal. 

Re: [Oorexx-devel] Seven years since the last release

[Rick McGuire]

On Sun, Jan 24, 2021 at 3:30 PM P.O. Jonsson  wrote:

> Am 24.01.2021 um 18:11 schrieb Rick McGuire :
>
>
>
> On Sun, Jan 24, 2021 at 11:11 AM P.O. Jonsson  wrote:
>
>>
>> Am 24.01.2021 um 12:39 schrieb Rick McGuire :
>>
>> P.O., you have commit privileges now, so you ARE a developer.
>>
>>
>> I only used those privileges for documentation purposes, but if you are
>> fine with it I will contribute what I did.
>>
>> If you have an install process working that is working through CMake
>> working, then it should be checked into the project. Having something that
>> is your private setup is not a working solution. You could be hit by a bus
>> tomorrow,
>>
>>
>> Regarding bus accidents: this is indeed one weak spot in the project: the
>> whole Jenkins business (setup scripts, addresses, PWs etc) is backed-up
>> locally and the information is spread on a few hands but there should be
>> some mechanism to secure it on Sourceforge, which is lacking today. Moving
>> Jenkins last time was a major effort with a lot of tweaking. I suggest to
>> rename the „buildmachine“ item in the documentation back to „oorexxbuild“
>> and start documenting all aspects of the build process there. Last time
>> this was done was in 2012 it seems. oorexxbuild, the earlier name (and
>> internal name used as well) appears more logical than buildmachine, it is
>> not about a machine rather all aspects of building ooRexx.
>>
>> so our ability to build an installer would go away. Having an installer
>> available means any interested person can checkout the code and follow the
>> instructions to build it themselves.
>>
>>
>> Regarding an installer for macOS: The currently available „official“
>> installer, 4.1.2 (on RexxLA and Sourceforge) was introduced late 2012 and
>> stopped working late 2015 with the introduction of SIP in macOS El Capitan.
>> It has been broken for five years by now, I do not think that can be
>> considered „Gold“ can it?
>>
>> I reverse-enigeered the 4.1.2 pkg-installer and fixed the installation
>> problem by moving the installation from /usr to /opt and created a new
>> installer. I had to make it a command-line installer since the pkg build
>> option did no longer work on macOS, but it is pretty straight forward. I
>> also created uninstaller scripts for version 4, something that was missing
>> all the time. This installer was offered to the project but never accepted.
>> Available here
>> 
>>
>> I have no knowledge on how to upload anything to sourceforge other than
>> to the build trunk, so if the installer for V4 is accepted can someone
>> please put it in the right place?
>>
>
> No, the correct place would be to check it in to the source tree, as all
> other critical items are. Follow the lead of what was done for Windows.
> Files needed to build the installer are in trunk/platform/windows/install.
> There should be an equivalent directory created for the Mac.
>
>
> OK, I will put everything used for the installer in
> trunk/platform/unix/macosx/ once I have confirmed that the 3 files residing
> there are obsolete and not used anywhere in Cmake. Currently I refer to
> local files but this will be easy to amend once it is agreed to go ahead.
>
>
> Also, I want to make clear that this is only acceptable if you have
> addressed the CMake integration issues. I'm not sure you really understand
> the requirement here. By integrated, I mean that all artifact files are
> defined only in the project cmake file, and then cmake makes the
> adjustments to pick up the build artifacts.
>
>
> OK, I admit I am not quite there yet, but I am working on it.
>
>
> So, to be clear, let's assume I add a new xyz.cls file to the project (or
> a new library file, sample, whatever). All I need to do as a developer is
> to make the appropriate additions to the cmake file, including adding an
> "install" definition to the cmake file. Your integration for the Mac
> installer should update whatever install artifacts need to generate the
> installer automatically.
>
>
> It does.
>
> If a developer needs to directly alter any of the Max installer files,
> this is not acceptable. This was one of the primary reasons we switched to
> CMake in the first place, to get away from having different makefile and
> installer requirements for the different platforms.
>
>
> Any modification to the source code will be picked up by the installer,
> since it is a step AFTER the "build install“ step, i.e. the installer is
> built from an existing and working installation in the default position,
> currently ~/Applications.
>

I am not referring to modifications to the source files, that is just
business as normal. I am referring to what happens when new components are
added to the build, such as new .cls files, new libraries, new doc files,
etc. The install statements in the CMake file determine what items need to
be picked up to generate the installation package on all platforms 

Re: [Oorexx-devel] Seven years since the last release

[P.O. Jonsson]

> Am 24.01.2021 um 18:11 schrieb Rick McGuire :
> 
> 
> 
> On Sun, Jan 24, 2021 at 11:11 AM P.O. Jonsson  > wrote:
> 
>> Am 24.01.2021 um 12:39 schrieb Rick McGuire > >:
>> 
>> P.O., you have commit privileges now, so you ARE a developer.
> 
> I only used those privileges for documentation purposes, but if you are fine 
> with it I will contribute what I did.
> 
>> If you have an install process working that is working through CMake 
>> working, then it should be checked into the project. Having something that 
>> is your private setup is not a working solution. You could be hit by a bus 
>> tomorrow,
> 
> Regarding bus accidents: this is indeed one weak spot in the project: the 
> whole Jenkins business (setup scripts, addresses, PWs etc) is backed-up 
> locally and the information is spread on a few hands but there should be some 
> mechanism to secure it on Sourceforge, which is lacking today. Moving Jenkins 
> last time was a major effort with a lot of tweaking. I suggest to rename the 
> „buildmachine“ item in the documentation back to „oorexxbuild“ and start 
> documenting all aspects of the build process there. Last time this was done 
> was in 2012 it seems. oorexxbuild, the earlier name (and internal name used 
> as well) appears more logical than buildmachine, it is not about a machine 
> rather all aspects of building ooRexx.
> 
>> so our ability to build an installer would go away. Having an installer 
>> available means any interested person can checkout the code and follow the 
>> instructions to build it themselves. 
> 
> Regarding an installer for macOS: The currently available „official“ 
> installer, 4.1.2 (on RexxLA and Sourceforge) was introduced late 2012 and 
> stopped working late 2015 with the introduction of SIP in macOS El Capitan. 
> It has been broken for five years by now, I do not think that can be 
> considered „Gold“ can it?
> 
> I reverse-enigeered the 4.1.2 pkg-installer and fixed the installation 
> problem by moving the installation from /usr to /opt and created a new 
> installer. I had to make it a command-line installer since the pkg build 
> option did no longer work on macOS, but it is pretty straight forward. I also 
> created uninstaller scripts for version 4, something that was missing all the 
> time. This installer was offered to the project but never accepted. Available 
> here 
> 
> 
> I have no knowledge on how to upload anything to sourceforge other than to 
> the build trunk, so if the installer for V4 is accepted can someone please 
> put it in the right place?
> 
> No, the correct place would be to check it in to the source tree, as all 
> other critical items are. Follow the lead of what was done for Windows. Files 
> needed to build the installer are in trunk/platform/windows/install. There 
> should be an equivalent directory created for the Mac. 

OK, I will put everything used for the installer in trunk/platform/unix/macosx/ 
once I have confirmed that the 3 files residing there are obsolete and not used 
anywhere in Cmake. Currently I refer to local files but this will be easy to 
amend once it is agreed to go ahead. 
> 
> Also, I want to make clear that this is only acceptable if you have addressed 
> the CMake integration issues. I'm not sure you really understand the 
> requirement here. By integrated, I mean that all artifact files are defined 
> only in the project cmake file, and then cmake makes the adjustments to pick 
> up the build artifacts. 

OK, I admit I am not quite there yet, but I am working on it.

> 
> So, to be clear, let's assume I add a new xyz.cls file to the project (or a 
> new library file, sample, whatever). All I need to do as a developer is to 
> make the appropriate additions to the cmake file, including adding an 
> "install" definition to the cmake file. Your integration for the Mac 
> installer should update whatever install artifacts need to generate the 
> installer automatically.

It does.

> If a developer needs to directly alter any of the Max installer files, this 
> is not acceptable. This was one of the primary reasons we switched to CMake 
> in the first place, to get away from having different makefile and installer 
> requirements for the different platforms. 

Any modification to the source code will be picked up by the installer, since 
it is a step AFTER the "build install“ step, i.e. the installer is built from 
an existing and working installation in the default position, currently 
~/Applications.

The only problem I see here is that the post-build installer creation presumes 
the installation to be in ~/Applications, so a Cmake change to where the 
installation resides might break the build of the installer.

I have modified the build process on Jenkins to build the installer now, be 
aware that this is a draft version, I do not know where to put the installer 

Re: [Oorexx-devel] Seven years since the last release

[Rick McGuire]

On Sun, Jan 24, 2021 at 11:11 AM P.O. Jonsson  wrote:

>
> Am 24.01.2021 um 12:39 schrieb Rick McGuire :
>
> P.O., you have commit privileges now, so you ARE a developer.
>
>
> I only used those privileges for documentation purposes, but if you are
> fine with it I will contribute what I did.
>
> If you have an install process working that is working through CMake
> working, then it should be checked into the project. Having something that
> is your private setup is not a working solution. You could be hit by a bus
> tomorrow,
>
>
> Regarding bus accidents: this is indeed one weak spot in the project: the
> whole Jenkins business (setup scripts, addresses, PWs etc) is backed-up
> locally and the information is spread on a few hands but there should be
> some mechanism to secure it on Sourceforge, which is lacking today. Moving
> Jenkins last time was a major effort with a lot of tweaking. I suggest to
> rename the „buildmachine“ item in the documentation back to „oorexxbuild“
> and start documenting all aspects of the build process there. Last time
> this was done was in 2012 it seems. oorexxbuild, the earlier name (and
> internal name used as well) appears more logical than buildmachine, it is
> not about a machine rather all aspects of building ooRexx.
>
> so our ability to build an installer would go away. Having an installer
> available means any interested person can checkout the code and follow the
> instructions to build it themselves.
>
>
> Regarding an installer for macOS: The currently available „official“
> installer, 4.1.2 (on RexxLA and Sourceforge) was introduced late 2012 and
> stopped working late 2015 with the introduction of SIP in macOS El Capitan.
> It has been broken for five years by now, I do not think that can be
> considered „Gold“ can it?
>
> I reverse-enigeered the 4.1.2 pkg-installer and fixed the installation
> problem by moving the installation from /usr to /opt and created a new
> installer. I had to make it a command-line installer since the pkg build
> option did no longer work on macOS, but it is pretty straight forward. I
> also created uninstaller scripts for version 4, something that was missing
> all the time. This installer was offered to the project but never accepted.
> Available here
> 
>
> I have no knowledge on how to upload anything to sourceforge other than to
> the build trunk, so if the installer for V4 is accepted can someone please
> put it in the right place?
>

No, the correct place would be to check it in to the source tree, as all
other critical items are. Follow the lead of what was done for Windows.
Files needed to build the installer are in trunk/platform/windows/install.
There should be an equivalent directory created for the mac.

Also, I want to make clear that this is only acceptable if you have
addressed the CMake integration issues. I'm not sure you really understand
the requirement here. By integrated, I mean that all artifact files are
defined only in the project cmake file, and then cmake makes the
adjustments to pick up the build artifacts.

So, to be clear, let's assume I add a new xyz.cls file to the project (or a
new library file, sample, whatever). All I need to do as a developer is to
make the appropriate additions to the cmake file, including adding an
"install" definition to the cmake file. Your integration for the Mac
installer should update whatever install artifacts need to generate the
installer automatically. If a developer needs to directly alter any of the
Max installer files, this is not acceptable. This was one of the primary
reasons we switched to CMake in the first place, to get away from having
different makefile and installer requirements for the different platforms.


>
> Same for version 5 of the installer, I can arrange for it to be built on
> Jenkins automatically but for uploading it to the right place
> (/projects/oorexx/files/oorexx/5.0.0beta/?) I think you or Erich need to
> amend the upload script on Jenkins.
>
>
> That would be a big step, but the docs really need a thorough review. A
> lot of new features in 5.0 (e.g., variable references) make portions of
> both the reference and programming guide a bit dated.
>
> There are currently 83 open bug reports. A few of these I would consider
> show stoppers, such as Walter's linein performance problems and the issues
> with Windows file name case. A number of others are not in complete state,
> missing needed tests and documentation. There are similar incomplete items
> in the feature requests. This is not a release that is ready to go gold
> yet.
>
>
> I for one would be happy if we could get „Silver“ on the road and provide
> „Gold" in 5.1. Please document the showstoppers for all others to see and
> judge. Help may arrive from unexpected places and showstoppers for some may
> not be showstoppers for others :-) Since the GC was rewritten ooRexx 5
> improved greatly and is IMO already 

Re: [Oorexx-devel] post-release actions

[Jeremy Nicoll]

On Sun, 24 Jan 2021, at 16:05, Jeremy Nicoll wrote:

> I'd never heard of it until you mentioned it.  According to 
> 
>https://en.wikipedia.org/wiki/Microsoft_Store

...

And also, I just stumbled across the following article, which 
makes it clear that right now there's more than one MS app
store, but that two of them are probably about to cease to 
exist:

https://www.zdnet.com/article/microsoft-is-planning-to-phase-out-the-windows-10-store-for-business/

-- 
Jeremy Nicoll - my opinions are my own.


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] post-release actions

[Jeremy Nicoll]

On Sun, 24 Jan 2021, at 14:21, René Jansen wrote:

[snip]

> For Windows, we should get into that Microsoft app store. 

I'd never heard of it until you mentioned it.  According to 

   https://en.wikipedia.org/wiki/Microsoft_Store

it's quite complicated in terms of what sorts of apps it offers
and the (potentially many) platforms that they may have to be 
available for.

I have never in my life installed any software from such a store.
Instead, I find a product's website (or pages on eg Sourceforge)
download an installer and run it.  

I would be surprised if many of the current users of ooREXX are
used to the 'store'-based approach.

Maybe it's a good idea if we want to attract younger(?) users 
who are used to the 'store'?  But I wonder if offering ooREXX
that way might result in a lot of extra work?

I'm not clear whether, to find and install something from the MS
store, one needs a Microsoft Account.  I've never had one - always
giving that option a body-swerve when installing Windows.  I know
I'm not - by a long way - the only person who does not want to 
have to have such an account. 

Even if we did have ooREXX available that way, I would want it to 
be available in a traditional manner too.


-- 
Jeremy Nicoll - my opinions are my own.


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seven years since the last release

[P.O. Jonsson]

> Am 24.01.2021 um 12:39 schrieb Rick McGuire :
> 
> P.O., you have commit privileges now, so you ARE a developer.

I only used those privileges for documentation purposes, but if you are fine 
with it I will contribute what I did.

> If you have an install process working that is working through CMake working, 
> then it should be checked into the project. Having something that is your 
> private setup is not a working solution. You could be hit by a bus tomorrow,

Regarding bus accidents: this is indeed one weak spot in the project: the whole 
Jenkins business (setup scripts, addresses, PWs etc) is backed-up locally and 
the information is spread on a few hands but there should be some mechanism to 
secure it on Sourceforge, which is lacking today. Moving Jenkins last time was 
a major effort with a lot of tweaking. I suggest to rename the „buildmachine“ 
item in the documentation back to „oorexxbuild“ and start documenting all 
aspects of the build process there. Last time this was done was in 2012 it 
seems. oorexxbuild, the earlier name (and internal name used as well) appears 
more logical than buildmachine, it is not about a machine rather all aspects of 
building ooRexx.

> so our ability to build an installer would go away. Having an installer 
> available means any interested person can checkout the code and follow the 
> instructions to build it themselves. 

Regarding an installer for macOS: The currently available „official“ installer, 
4.1.2 (on RexxLA and Sourceforge) was introduced late 2012 and stopped working 
late 2015 with the introduction of SIP in macOS El Capitan. It has been broken 
for five years by now, I do not think that can be considered „Gold“ can it?

I reverse-enigeered the 4.1.2 pkg-installer and fixed the installation problem 
by moving the installation from /usr to /opt and created a new installer. I had 
to make it a command-line installer since the pkg build option did no longer 
work on macOS, but it is pretty straight forward. I also created uninstaller 
scripts for version 4, something that was missing all the time. This installer 
was offered to the project but never accepted. Available here 


I have no knowledge on how to upload anything to sourceforge other than to the 
build trunk, so if the installer for V4 is accepted can someone please put it 
in the right place?

Same for version 5 of the installer, I can arrange for it to be built on 
Jenkins automatically but for uploading it to the right place 
(/projects/oorexx/files/oorexx/5.0.0beta/?) I think you or Erich need to amend 
the upload script on Jenkins.

> 
> That would be a big step, but the docs really need a thorough review. A lot 
> of new features in 5.0 (e.g., variable references) make portions of both the 
> reference and programming guide a bit dated. 
> 
> There are currently 83 open bug reports. A few of these I would consider show 
> stoppers, such as Walter's linein performance problems and the issues with 
> Windows file name case. A number of others are not in complete state, missing 
> needed tests and documentation. There are similar incomplete items in the 
> feature requests. This is not a release that is ready to go gold yet. 

I for one would be happy if we could get „Silver“ on the road and provide 
„Gold" in 5.1. Please document the showstoppers for all others to see and 
judge. Help may arrive from unexpected places and showstoppers for some may not 
be showstoppers for others :-) Since the GC was rewritten ooRexx 5 improved 
greatly and is IMO already „Gold“. I have scripts running for weeks now that do 
not bloat, they just go on and on and on. If we document the items that are 
still (for some) showstoppers, that would be sufficient for me. Example: I do 
not suffer from Walters performance problems, I could work around it using 
arrayIn instead, fast like a wind.

> 
> Rick
> 
> On Sun, Jan 24, 2021 at 5:54 AM P.O. Jonsson  > wrote:
> I agree with Rony that version 5 of ooRexx should be formally released, I 
> just did not raise my voice since this is a discussion amongst the developers.
> 
> Due to the delay we may already have lost a major „client, my former 
> employer, the European Patent Office, with more than 4000 ooRexx 4 
> installations. They are now going all-in for Python instead, they will never 
> be able to upgrade to 5.0.0 unless there is an official release.
> 
> Can Rick and/or Erich provide a list of „showstoppers“ so they can be worked 
> off? Are there REALLY any problems that are so severe that they would 
> prohibit a release? I doubt it.
> 
> I can offer to set up the macOS Installer on the Jenkins machine. It is Cmake 
> driven and uses standard Unix commands in the post-processing. It also 
> includes the latest documentation, license, HowTo etc. Example can be found 
> in „MacBuilds“ here 
> 

[Oorexx-devel] post-release actions

[René Jansen]

… that we can start now.

It seems imperative that we get ooRexx added to the different distributions. 
Most people install like that; some run installers; even less build from source.

I know ooRexx is in the SLES build tree and is just waiting for the GA signal. 
We should be able to address RedHat via our IBM contacts. For other 
distributions - I hope people have their own favorites and will try to get them 
into those. It might entail setting up a repository and make sure apt and yum 
can handle that.

For macOS we have Homebrew and Macports to consider. And maybe even the App 
Store (shudder).

For Windows, we should get into that Microsoft app store. I think before that 
we should have solved the false positive problem for some virus businesses, and 
have crypto certificates.
I will go after those. Last time Les and Chip were rebuffed because some 
telephone number was not connected, if I remember correctly.

If someone knows other Windows distribution mechanisms, I would love to hear 
about those. Because I avoid it, I would not know, and I only see corporate 
distribution tools. This might be the only platform where the traditional 
installer exe still matters.

René.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seven years since the last release

[René Jansen]

I agree with Rick here.

But: the problem here is that the notions of GA, ‘golden’ are from the last 
century and might not be applicable in this day and age. I see a lot of 
software projects having two lines of release, one stable and one rolling. It 
is a fact, though, that there are companies still adhering to those older 
notions, some of them are ex-Open Object Rexx clients from IBM, and RexxLA has 
obligations towards those clients for maintaining and improving the product, on 
condition of which it was delivered the source code. The moment that the 4.X 
releases (our ‘stable release’) don’t work properly anymore, we are defaulting 
on that agreement. I might all be academic because those companies seem to be 
moving to other languages; that may or may not be our fault.

But whatever the state of the code, being in beta for 7 years is not a good 
sign for viability of any project. The problem here was declaring a beta, when 
in fact it was still pre-release code. For the future, we should refrain from 
calling a release a beta when we do not have a plan for a release.

In my opinion, we need a plan to address this problem. It should be a plan to 
release on a specific date, on the condition that work has been done on a few 
issues.

1) What: Classify the open issues in ‘showstoppers' and ‘other’ categories. 
Flag them as such. Who: Rick and Erich, René. When: March 31, 2021
2) What: Commit all installers, tests and other improvements we have. Who: 
P.O., Rony and others. When: February 15, 2021
3) What: Identify documentation issues. Who: Rick and Rony, Erich, others. 
When: Februari 28, 2021
4) What: Improve documentation along identified issues. Who: Gil, Jon, René, 
Rony, Walter, others. When: April 15, 2021
5) What: fix, freeze, prepare and test GA release. Who: P.O., Erich, Rick, 
others. When: May 1st, 2021.

I know I cannot decide on other people’s time, so I just hope we can agree to 
this, on a best effort base. I hope we all see the predicament we are in. When 
we have this in the past, we can decide on release approaches that are a better 
fit. 

Please react on, and improve on this planning, so we can have something we can 
commit to soon.

best regards,

René.
 

> On 24 Jan 2021, at 12:39, Rick McGuire  wrote:
> 
> P.O., you have commit privileges now, so you ARE a developer. If you have an 
> install process working that is working through CMake working, then it should 
> be checked into the project. Having something that is your private setup is 
> not a working solution. You could be hit by a bus tomorrow, so our ability to 
> build an installer would go away. Having an installer available means any 
> interested person can checkout the code and follow the instructions to build 
> it themselves. 
> 
> That would be a big step, but the docs really need a thorough review. A lot 
> of new features in 5.0 (e.g., variable references) make portions of both the 
> reference and programming guide a bit dated. 
> 
> There are currently 83 open bug reports. A few of these I would consider show 
> stoppers, such as Walter's linein performance problems and the issues with 
> Windows file name case. A number of others are not in complete state, missing 
> needed tests and documentation. There are similar incomplete items in the 
> feature requests. This is not a release that is ready to go gold yet. 
> 
> Rick
> 
> On Sun, Jan 24, 2021 at 5:54 AM P.O. Jonsson  > wrote:
> I agree with Rony that version 5 of ooRexx should be formally released, I 
> just did not raise my voice since this is a discussion amongst the developers.
> 
> Due to the delay we may already have lost a major „client, my former 
> employer, the European Patent Office, with more than 4000 ooRexx 4 
> installations. They are now going all-in for Python instead, they will never 
> be able to upgrade to 5.0.0 unless there is an official release.
> 
> Can Rick and/or Erich provide a list of „showstoppers“ so they can be worked 
> off? Are there REALLY any problems that are so severe that they would 
> prohibit a release? I doubt it.
> 
> I can offer to set up the macOS Installer on the Jenkins machine. It is Cmake 
> driven and uses standard Unix commands in the post-processing. It also 
> includes the latest documentation, license, HowTo etc. Example can be found 
> in „MacBuilds“ here 
> 
> 
> I have also written test cases for all sample files, they can be uploaded but 
> require a little fix in the testing framework (that I can provide as well).
> 
> I have set up the documentation (PDF and HTML) to be built on Jenkins every 
> new revision (this is where I get it for the macOS installer) what is missing 
> is an upload to Sourceforge, this needs to be done with someone with R/W 
> access there.
> 
> So what is really missing that prohibits a release? Is it not about time now 
> to kill our baby and go ahead and release 5.0 and 

Re: [Oorexx-devel] Seven years since the last release

[Rick McGuire]

P.O., you have commit privileges now, so you ARE a developer. If you have
an install process working that is working through CMake working, then it
should be checked into the project. Having something that is your private
setup is not a working solution. You could be hit by a bus tomorrow, so our
ability to build an installer would go away. Having an installer available
means any interested person can checkout the code and follow the
instructions to build it themselves.

That would be a big step, but the docs really need a thorough review. A lot
of new features in 5.0 (e.g., variable references) make portions of both
the reference and programming guide a bit dated.

There are currently 83 open bug reports. A few of these I would consider
show stoppers, such as Walter's linein performance problems and the issues
with Windows file name case. A number of others are not in complete state,
missing needed tests and documentation. There are similar incomplete items
in the feature requests. This is not a release that is ready to go gold
yet.

Rick

On Sun, Jan 24, 2021 at 5:54 AM P.O. Jonsson  wrote:

> I agree with Rony that version 5 of ooRexx should be formally released, I
> just did not raise my voice since this is a discussion amongst the
> developers.
>
> Due to the delay we may already have lost a major „client, my former
> employer, the European Patent Office, with more than 4000 ooRexx 4
> installations. They are now going all-in for Python instead, they will
> never be able to upgrade to 5.0.0 unless there is an official release.
>
> Can Rick and/or Erich provide a list of „showstoppers“ so they can be
> worked off? Are there REALLY any problems that are so severe that they
> would prohibit a release? I doubt it.
>
> I can offer to set up the macOS Installer on the Jenkins machine. It is
> Cmake driven and uses standard Unix commands in the post-processing. It
> also includes the latest documentation, license, HowTo etc. Example can be
> found in „MacBuilds“ here
> 
>
> I have also written test cases for all sample files, they can be uploaded
> but require a little fix in the testing framework (that I can provide as
> well).
>
> I have set up the documentation (PDF and HTML) to be built on Jenkins
> every new revision (this is where I get it for the macOS installer) what is
> missing is an upload to Sourceforge, this needs to be done with someone
> with R/W access there.
>
> So what is really missing that prohibits a release? Is it not about time
> now to *kill our baby* and go ahead and release 5.0 and start working on
> 5.1?
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seven years since the last release

[P.O. Jonsson]

I agree with Rony that version 5 of ooRexx should be formally released, I just 
did not raise my voice since this is a discussion amongst the developers.

Due to the delay we may already have lost a major „client, my former employer, 
the European Patent Office, with more than 4000 ooRexx 4 installations. They 
are now going all-in for Python instead, they will never be able to upgrade to 
5.0.0 unless there is an official release.

Can Rick and/or Erich provide a list of „showstoppers“ so they can be worked 
off? Are there REALLY any problems that are so severe that they would prohibit 
a release? I doubt it.

I can offer to set up the macOS Installer on the Jenkins machine. It is Cmake 
driven and uses standard Unix commands in the post-processing. It also includes 
the latest documentation, license, HowTo etc. Example can be found in 
„MacBuilds“ here 


I have also written test cases for all sample files, they can be uploaded but 
require a little fix in the testing framework (that I can provide as well).

I have set up the documentation (PDF and HTML) to be built on Jenkins every new 
revision (this is where I get it for the macOS installer) what is missing is an 
upload to Sourceforge, this needs to be done with someone with R/W access there.

So what is really missing that prohibits a release? Is it not about time now to 
kill our baby and go ahead and release 5.0 and start working on 5.1?

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se

> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seven years since the last release

[WalterPachl via Oorexx-devel]

Having read Rick's remarks about open doc/test items that need attention, how 
about lending your
hand to tackle them, Walter?

>>gimme an item an I shall try 
>>ALL Of ooRexx exceeds my mental capabilities :-(

If you volunteer what (knowledge) would you need to become able to help? What 
would you want to tackle?

>> If it's doc, where could I make changes instead of asking for them being made

>>All the best
Walter


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel