> Do you already have commit access to the repository? No, and it is not clear that I should be the one with such access for ESO. This is something we have to decide here at ESO first.
> If not I can act as a sponsor for those packages, until you get it. > > My duty cycle will be more in the range of a couple of days for packages > that I don't know yet (I'd be responsible for any damage they would > cause), and approx one day or less for small updates on packages that I > know already. Thank you for volunteering. I fear that a couple of days may be a bit too long for a number of our astronomers at the moment. This will have to be discussed by us to see how to proceed. We have about 108 Portfiles in our repository and this number will grow as new instruments and their associated data processing software comes online. Unfortunately, experience has also shown that a fair amount of understanding of the ESO source code packages for the 19 different instruments is required to correctly build the software. What I mean by correct, is not just that the software compiles and runs, but that is does not introduce any nasty artefacts into the scientific results. This is actually a big motivator for us at ESO to take on the responsibility of binary packaging the ESO software for our astronomers, rather than them doing it by themselves. If you take responsibility for maintaining our Portfiles in the default MacPorts repository, how would you propose the update procedure to work? Would you only update with the patches we deliver? If you or one of the other core maintainers has to make a change independently, how would this be validated for quality assurance? However, with that all said, there certainly are one or two Portfiles that are actually 3rd party library dependencies for our software (e.g. py-photutils) or are less critical. These could be the first good candidates to consider moving over to the default repository. > For the record, all the ESO packages are being packaged by volunteers in > Debian, and I already maintain packages will small userbase, > concentrated among astronomers. I know about those packages. Unfortunately many of our users also do not regularly use those packages, since they tend to be out of date, which has a negative impact on the quality of scientific analyses. The RPM repositories also do not deliver our full data processing stack. We are actually in the process of preparing full YUM and APT repositories of our software for the ESO instruments. There again, we will have to see and negotiate with the respective communities if it makes sense to migrate any of that to the Fedora or Debian repositories. Kind regards. Artur _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
