Welcome to iraf.net Friday, March 29 2024 @ 10:26 AM GMT


 Forum Index > Help Desk > General IRAF New Topic Post Reply
 Status of the github repository
   
olebole
 08/18/2017 08:09AM (Read 2045 times)  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Hi (especially fitz),

since a few months, the IRAF source was put into a github repository:

https://github.com/iraf/iraf

After that, I (and some others) started to look into the current problems of the IRAF code and proposed a number of patches:
  • Cleanup of the code. Get rid of temporary files, obviously outdated files etc. Some of them even prevented the make process from compilation.
  • Fix the remaining problems to compile the code on an arbitrary location and not just in /iraf/iraf/. There were still a few locations with the absolute path hardcoded, which are now removed
  • Allow the use of "modern" compilers, like gcc 4.8 and up, or clang. The original code contained dirty non-standard-C hacks that make assumptions on the C compiler which are not true anymore.
  • Finish the transition to /bin/sh from (t)csh
  • Setup a test environment on travis-ci (and do tests on even more systems, from eight-year-old systems to the just-released Debian release),
  • A couple of bug fixes found by code inspection or testing
  • and more
As asked by fitz, all patches
  • address specific issues,
  • clearly explain what is being addressed, and
  • ideally show they work on all 4 supported systems (macosx/macintel/linux/linux64)

However, aside from the initial commit (and one bugfix merge), nothing happened in the repository for more than three months now, The number of pull requests now comes close to 50, and it becomes increasingly more difficult to continue development: since it is unclear which of the patch gets accepted directly, and which may need changes, one cannot base further changes just on the sum of all patches, but also not on the unchanged code (since the original code does not work anymore).

On the other hands, there are people wanting to get IRAF packaged: on Debian, on Ubuntu, on Fedora Linux, on Astroconda, and so on. Others want to port it, for example to the ARM processor. It would be a nightmare if they would all need to individually patch the code instead of relying on a common and commonly discussed development. Look at the past: Fedora Linux started and had some patches, Mageia Linux as well (they even had a package), Debian had something, Ureka and Astroconda had their own patchesfor 2.16; all quite close (what concerns the fixes), and all were broken when 2.16.1 came out (ignoring all the work that has been done outside), and the patches didn't apply anymore. The main idea of having a central repository is to avoid this duplication of work, but this requires that the PRs are not just ignored.

So, what are the plans here? Is there a chance that the current PRs get discussed and finally merged? You (fitz) even expressed the hope
have no time to address it at the moment (or for at least several months unless the awesome power of open source provides a solution that works for all platforms).
which is exactly what happened now. To say: we presented a solution, and we tested it on all the platforms; and even on some more. We are open for the discussion. It is just there. You just need to grab it. But this is now your turn. At least, unless you give someone else you trust the power to review and merge.

But move forward. Hitting the "merge" button takes seconds, and there are bug fixes that are obvious. And the others are well-documented. If you need more information somewhere, just ask and we will provide it.

Best regards

Ole


 
Profile Email Website
 Quote
olebole
 08/28/2017 06:10AM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
I just recognized that the repository URL given above is wrong. The correct one is

https://github.com/iraf/iraf-v216

Best regards

Ole

 
Profile Email Website
 Quote
lupinix
 09/25/2017 08:36AM  
+----
Newbie

Status: offline


Registered: 09/22/2017
Posts: 2
Any news here? I'm one of the Fedora Astronomy developers and also interested in this. I analyzed the pull requests and filed bugs on github, they seem to solve many problems we distribution packagers have and would appreciate their inclusion in official iraf sources.

 
Profile Email
 Quote
fitz
 09/27/2017 04:34PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
There is nothing new to report here due to competing demands on my time that keep me from reviewing PRs. Although many PRs appear to be trivial and correct, some are appear to be done as part of multiple changes or are peculiar to specific (typically recent) versions of compilers or tools where the effect on older versions is unclear or clearly wrong (e.g. the addition of a '-m32' compiler flag that doesn't exist on older platforms). Still others (e.g. those that simply remove files) should be reviewed in the context of a more general effort to remove old/unused/intermediate code from the system (e.g.the deprecation of the VO package, vendor codes, etc). Last are PRs that would appear to not be correct at all and may simply mask an issue (e.g. this commit, or those issues that report new bugs in tasks that have been unchanged in decades (e.g. #61) that may have arisen out of PRs but can't be reviewed without adequate test code or platform/version details.

Accepting only the trivial and obvious PRs does little to advance the project, doing a proper review of the more complex PRs to ensure some level of backward compatibility takes more time than I have right now and likely won't be a priority until the existing binaries break completely (unfortunately, High Sierra works) for a significant number of users. That said, there is nothing in the interim from preventing distribution maintainers from creating their own fork with whatever PRs they feel are needed (they would not be the first or only group to do so (see Astroconda/Ureka or a number of RPMs available on the net). I cannot credibly give a date for when PRs will be reviewed or when major changes to the "official" version will happen, but it will happen.

I do not plan to participate in the continuation of this thread and will post updates as they become available.

Regards,
-Mike


 
Profile Email
 Quote
olebole
 09/27/2017 07:58PM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Hi fitz,

sorry but I think that you are wrong here:
First, it did not work well to have several forks of IRAF (one for Mageia Linux, another for Debian, and one for Ureka, for Fedora etc.). All had basically to deal with the same problems, all needed quite some effort to fix them, and when the next "official" release was out, everything had to start from scratch, because "official" IRAF development happened independently. This situation is exactly what we should avoid in the future. Which means to have a common repository, and discuss the problems and possible solutions together, instead of just doing the own stuff.

Then, it is absolutely worth to merge the "trivial" pull requests now: They may look trivial, but the way to find them is not always trivial. Anyone else who wants to use or develop IRAF should not have to go through the same time-consuming exercise again. And having them merged now reduces the risks of having merge conflicts with other PRs later: For example the PR #38 (Convert mklibs to /bin/sh) may be quite trivial, but any later fix on the scripts needs to be rebased from the csh script to the /bin/sh one. And a third point with "trivial PRs" is that this is a subjective measure; merging those you find trivial helps the submitter to see where an agreement is already reached.

You are also wrong with the "complicated" PRs, and their impact for older compilers: The tests are run regularly on a number of platforms, from five year old to the most recent variants. If required, I also do tests on even older machines, going back to Debian Squeeze (from 2011). I think this is a good test for compatibility with older compilers. However if you want to see something tested on an even older version, please tell me so that I can do it. "-m32" exists however on all tested platforms. Also all the other PRs work well on all platforms, be it the redefinition of the Mem common block, or PR #62 (which is the fix of #61),. All PRs are well documented, they also clearly describe the problem they solve and also how they do it. If you have any doubt that they don't work well, please write the arguments specific to the PR, and not just a general "will likely break everything".

For the cleanup PRs: I specifically split them into smaller parts; some of them are obious, but others may need some discussion. But each of them brings us a step forward. And I don't see why the removal of generated files (PR #25) requires a review in a larger context: They don't affect the build, and they are tested that "make src" leaves exactly the same files. What other review do you specifically want here?

Generally: If you need more tests, please tell me and I will to. But start cooperating. I beg you. I promise to spend you a beer at ADASS for the start. Isn''t that worth to think about?

 
Profile Email Website
 Quote
   
Content generated in: 0.10 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login