iraf.net

Is there an unofficial github repository for IRAF. I have an unofficial repository which I've used to do my RPM conversion work on github, but I was wondering if there is something more official.

There is no official/public git or svn repository. We're about to switch the main IRAF development server to a new machine and may set one up for public access at that time.

OK sure. If you want to use git, then then easiest thing to do may be to just clone my unofficial tree on github

https://github.com/joequant/iraf

One thing that I'll be doing over the next few weeks is to try to pull in 2.16.1 into the tree.

Git for IRAF is an excellent idea - very easy to set up and trivial for updates/upgrades.

If anyone wants to fork/add to my official IRAF tree on github, they can be my guest.

My next project is to fold in the 2.16.1 source changes.

I'd like to bring this topic to front again now.
Having an official git repository for IRAF would be a really good thing. Doing this on github or similar would also help in a lot of other things, which can be categorized, like

• Bug reports,
  
• Wishlist items, and
  
• Patch requests.

And the best thing is that it does not cost you (fitz/NOAO) a cent to do that.
You don't need to setup or administrate a server for this. You can do this right now.
There are a lot of small items in IRAF that could easily fixed this way -- from the removal of forgotten binaries to the correction of links. Also, it would be sure that no reported problem is lost (what would be the case if we just report it here in the forum).

What do you think?

Best regards

Ole

I'll consider it when preparing the next release, however the logical extension of the idea is to likewise put all the external packages we maintain into repositories as well so the whole process is not as easy as creating a single repository for IRAF.



Just because a problem hasn't been dealt with yet doesn't mean it's been lost.

The idea is to do this now, so that people who want to contribute to the next release can follow the development even before the release is there, adjust their own patches, submit pull requests and so on.

Why not start with the central package? It makes things easier if the move is done step-by-step.

Having a bug report system does not only allow you to not loose reports, but it also allows us users and reporters to keep track of what happened. For example, about one year ago you told me that you were working on a better support of .x files in gdb (or so). If this would be a public bug report, I could have a look and see if this is still work in progress, if it is dropped, and (if yes) what you already did for this, and maybe continue this work.

Another example: The source tar files of IRAF contain quite a lot of annoyances since years, like wrong links, libraries or executables forgotten to removed, personal stuff like .ssh files or command line history, log files and so on.

If you would create a git repository now, you would get these and other trivial, but always forgotten things solved by the community who could provide you with pull requests for that. I could f.e. profit from a corrected ./install script (or provide one myself if you did not do this yourself) which allows the installation without the /iraf/iraf/ directories (see the other discussion thread).

BTW, when do you plan the next release?

As I said, at the next release. Despite your use of a bold font I'm not convinced cleaning up stray files in the system is worth the interruption at the moment.



There is no fixed release date, hopefully sometime in the Fall.

The problem is that without git or something like it, it is impossible for those of us that have patches that are off branch to keep them synced with development. For example, I have a lot of patches that clean up the build system for the last IRAF revision so that we can build proper RPM's for fedora and mageia. It took me several months to get these working.

As it is, there is no way I can sync my changes with the patch release, and there once the next release is put out, it's going to take me about a month (yes that long) to sync up my changes with the new release. It gets worse because I do not have any commit logs so that I have to spend about two weeks to just figure out what the changes are.

If there were a git repository, you wouldn't have to do a thing. Just check the changes into the git repository, ignore me, and as the changes go into git, I'll sync up my tree with the incoming changes.

The problem is that if IRAF doesn't have a system that is friendly to outside developers then it is just removing resources that might be available. I'd love to do development on IRAF, and getting everything to work with RPM's on fedora and mageia was an extremely non-trivial effort. Without an official github repository, I just can't continue this effort since all my time would be spend sync'ing things up.

As things exist, I have an unofficial IRAF repository on joequant. I've checked in my RPM patches there so that when development stabilizes I can do a merge.

IRAF is a worthy project, and I'm trying to do whatever I can to be productive, but I just can't make non-trivial changes without having access to git or svn or some other version control. If we can't get verison control working, then my plan is to wait until the next IRAF release, spend about a month syncing my changes with the new release, and hopefully this will be the last time that this is necessary.

The file dates in IRAF actually mean something (unlike a git checkout), it is trivial to find out which files have changed since the last release. Why those files were changed is documented in the iraf$local/notes.v216 file for the core system or the package 'Revisions' files so two weeks sounds excessive.

The trouble is that since is no way of doing a diff with the previous release, I have to go through file by file and try to figure out what the code changes were, and how those code changes interact with my changes. Also it's likely that once commit will involve coordinated changes across several files, and that the file will contain several changes. Without revision control, I have to figure out by hand the logic of each commit, so that I can do a merge with my changes. Once everything is in version control, it would take two minutes to do a trial merge, and maybe a week to resolve merge conflicts. At that point you have testing, and testing with multiple versions of IRAF is going to be impossible with the ability to do rollbacks.

I spent a lot of time getting 2.16 working with Mageia/Fedora and this involved a lot of debugging and patching and the changes are on github. I took a look at integrating those changes with 2.16.1, and it was much too big an effort and I gave up. I really don't see how I can integrate my changes with the mainline IRAF branch without importing 2.16.1 into github. I'd be willing to do that, but I don't want to have a situation in which I do this work, and then it gets wasted once the next version comes out.

I'm sorry if I sound a little grumpy, but I'm quite frustrated. I spent a huge amount of time getting RPM's working for fedora/mageia and people have been able to use those RPM's to produce deb's for ubuntu/debian. They work. You can now just do a binary install.

This involved a huge amount of debuging and getting into the weird esoteric world of fortran memory management. All of that work is on the my unofficial github repository, but I'm feeling as if it is wasted effort since there is no obvious way of merging those changes in with 2.16.1, and no obvious way of maintaining a parallel branch that tracks mainline changes.

There are a lot of people that would like to donate time and effort into IRAF, but I just don't see how this is possible without a proper version control system.

Has anyone set up an official github repository for the 2.16.1 version of the IRAF software?

---

Rob Steele (Robert.D.Steele@jpl.nasa.gov)

Not an "official" one, it's still on the ToDo list but the contents would be the same as what's available for download anyway. Various "unofficial" repos exist as do RPMs and things like AstroConda, typically either out of date or with custom changes however.

So the changes that were proposed a few years ago (f.e. zvsjmp.s for several architectures) are still not there?
I must say that I am a bit frustrated that I (and others, like joequant) has put quite some efforts to improve IRAF, but all this is finally ignored (and maybe even forgotten) over the years.

It seems that the way forward is to use 2.16.1 (if this is indeed the latest version) as the starting point for all future work. The administrator could name himself (or a small group) as the github administrators and then they could establish a github account with a name like 'official iraf development'. Then a repository for the latest software established and tagged as 2.16.1. Folks could clone/fork from this point and all future development would be done from this starting point and updates to the official repository controlled by the administrators. When thing progress so a new release is ready that could be tagged as 2.16,2 or 2.17 as appropriate.

What do folks think?

There is of course https://github.com/olebole/iraf which already has the 2.16.1 software committed.

Rob

---

Rob Steele (Robert.D.Steele@jpl.nasa.gov)

Yes. I'm also extremely frustrated. The trouble is that without version control it turns out to be *IMPOSSIBLE* to do any sort of development at my end. I put in major patches to get the system to build and run on linux against 2.16.0 before 2.16.1, and without version control it turns out to be *IMPOSSIBLE* to merge the two branches.

I've given up on doing any development work on IRAF because any changes that I make will go absolutely nowhere. If anyone is willing to maintain a git repository with IRAF, I can spend the two or three weeks in order to merge my changes with those of 2.16.1

I should point out that one of the changes that I had to make was that the build system was a total nightmare which I had to clean up. Because nothing is version controlled, there is no distinction between the original pure source files, and files that are generated as a result of a compilation. Simply creating a repository of IRAF in which all of the generated files are removed would be a very useful thing to do.

There are some projects that IRAF desperately needs. Most of the memory allocation system is now legacy because fortran 95 allows for dynamic memory so very large parts of IRAF could be removed. Also there is one and only one barrier that keeps IRAF from being used with newer compilers and that's an "equivalence" trick that doesn't work in fortran 95.

Also some of the utilities in IRAF are duplicates of things that are standard and some of the things aren't.

I'm willing to put a lot of my time to get IRAF to become a modern, cutting edge package, and so are a lot of other people, but this is simply *IMPOSSIBLE* without some sort of version control system.

One other thing is that the changes that I made include fixes to allow IRAF to work on 64-bit systems.

Do you have a git repository of 2.16.1 as well as olebole. I had trouble installing with the olebole 2.16.1 repository. If I can't install from olebole's I'll just commit a version of the tar ball from the iraff repository. Either way I still need a set of regression tests to very any changes I do make. Does anyone have any regression tests that they would be willing to share?

---

Rob Steele (Robert.D.Steele@jpl.nasa.gov)

I was unable to get the repository from https://github.com/olebole/iraf to install correctly. So I grabbed the latest tar ball version of 2.16.1 and created my own. Anyone is welcome to fork off from mine and make any changes from there. My is at: https://github.com/steelewool/iraf

---

Rob Steele (Robert.D.Steele@jpl.nasa.gov)

The problem here is that everyone starts from scratch here, tries to change the same things and hits the same pitfalls.

Mike, you promised this already three years ago: will there be a public git repository, with a public bug database, pull requests and such (in short: something github or gitlab alike) before your retirement in 2030?

Things that could be changed that way are:

* clean up all that messie stuff that is left in the 2.16.1 source (like old .a, .e, .o, .bak, .orig etc. files)
* replace csh by sh or bash (google for "csh considered harmful")
* fix the installation path all over the code
* add new architectures
* fix the makefiles to not hardcode /usr/bin/gcc, propagate build flags (CFLAGS, CPPFLAGS etc.) through the build tree
* fix compiler errors
* improve the Fortran interface
* update internal libraries and allow to use external libraries instead
etc.

There are a lot of changes that would be useful on the code, and there are obviously volunteers to prepare them. Every few years that topic pops up, people appear that want to help here, but then nothing happens. Instead of the needed cleanup of the code, you still dream of CL enhancements, spectroscopy tools and such -- see the "IRAF roadmap" poll in the forum.

Why don't you move IRAF to a true collaborational package f.e. on github? Why don't you take advantage of people like joequant of robsteele (or myself) who are or were motivated to fix the problems? Why are you ignoring this request for years now?

The first version an offical github repository doesn't need to have any of the items fixed. Just something that compiles correctly would be a great starting point. All of the items listed in the last post could go as issues and be fixed one at a time. But, getting that version that has to exist somewhere that compiles correctly would be a positive first step.

---

Rob Steele (Robert.D.Steele@jpl.nasa.gov)