If there is anything else we should do, please let me know.

Otherwise, please let the +1 year old task finish.

> I tried to come up with a criterion on what mistakes "slipped through fingers" are acceptable

In software terminology, these things are known as bugs. Things the author did not intend to happen in the final product, but were missed due to the complexity of the whole/larger project and limited time.

As soon as someone finds/reports a bug, the author will fix it.

This is the case here and has been demonstrated in previous messages on this thread.

If I had not implemented your bug-reports, you had reason to complain. But demanding that any project be bug-free from day one is absurd.

> The point of your package is bit-to-bit reproducing, isn't it?

Not for the software (like GNU Guix), but for mostly the output data of the analysis. When built on different OSs or Kernel versions for example, the software will necessarily be different from the bit-wise perspective. But this does not necessarily mean that the output data are different (the software authors may/will have accounted for the difference in low-level architecture).

The reason I put "mostly" is that for some scenarios in statistical analysis with high performance computing (parallel execution on many clusters), it is also impossible to have bit-wise identical data outputs. In such cases, users can implement statistical verification

In fact, we recently published a paper on this project in IEEE's Computing in Science and Engineering, where we also discuss this point: https://doi.org/10.1109/MCSE.2021.3072860 (open-access), or you can see the version on arXiv: https://arxiv.org/abs/2006.03018

All the remaining issues have been implemented in Commit 0043ba8d9.

> Why did you miss them?

Please compare the number of missed with all the cases that have been implemented! The few cases that have slipped through my fingers are just momentary mistakes.

> Did you think the policies only applies to the materials the maintainers make themselves from the scratch?

Of course not ;-)! Like before, we have corrected them in so many cases, these few are just momentary mistakes that as you see above, I fix as soon as I find them: for me, this is a bug, and all software have unintentional bugs.

> I agree that it would be hard to eliminate it in this case.

As you may notice from the commit message, I found out that for almost all the other journals we were referring to it through its abbreviation, this one and three others were just out-liers. So I fixed this by simply using the journal abbreviation for all citations.

> What about README-hacking.md?

That has also been corrected, it passed my previous check because it was 'open-source' (with a '-' in between!).

> Have you read the FAQ entry I referred to in comment #1?

As you may see from the commit above, this has also been corrected in reference to all GNU/Linux distribution names, thanks for reminding me.

Thank you, I done a search for "Copyright (C)" and corrected the files that didn't have any notice or license, I also set all of them to have the GPL-suggested format in Commit c0a512e0631.

I also searched for "open source" with the command below and noticed that it only occurs in two BibTeX entries (which we just imported from journals and didn't write ourselves). In one it is in the "abstract", so since this BibTeX entry isn't used in our context I removed it in Commit 4ff12fa2. However, I couldn't remove the other one because its in the name of the journal that published the paper: "The Journal of Open Source Software".

grep -ir "open source" ./*

I done a similar search for "Linux." and only one entry came which was actually ArchLinux (the name of a GNU/Linux distribution, and a special name). I also removed the ".", and couldn't find a single place where we referred to "Linux" instead of GNU/Linux. There was just a few more "ArchLinux"s in code and one instance of "Linux from Scratch" (which is also a special name for an operating system. comments (because that is where we got the idea of applying that step and need to be able to remember!).

If you noticed any other usage of "open source" or "Linux", please let me know and I will correct it, it must have been a typo!

By the way, I should have given this link for the source of the project (the "maneage" branch, not the "master" branch), can you please look here for any further checks: http://git.savannah.gnu.org/cgit/reproduce.git/tree/?h=maneage

Generally, in Maneage, the standard "master" branch belongs to the users (projects derived from Maneage). So the branch we should protect here to avoid mistakenly deleting or changing is "maneage". So, when making the project's Git repository, can you please set it to protect the "maneage" branch?

A new project has been registered at Savannah
This project account will remain inactive until a site admin approves
or discards the registration.

Registration Administration

While this item will be useful to track the registration process,
approving or discarding the registration must be done using the specific Group Administration page, accessible only to site administrators,
effectively logged as site administrators (superuser):

• Group Administration

Registration Details

• Name: Maneage
• System Name:  maneage
• Type: non-GNU software and documentation
• License: GNU General Public License v3 or later

---

Description:

Maneage (Manage+Lineage) is a fully working template for doing reproducible research (writing a paper). It is designed to be customized for separate projects: you specify which software you need and how to run them to achieve your result. The pipeline will then download (if necessary) the software source code and build them in a closed environment (highly independent of your operating system) during the configuration step. You can then organize your research steps through Makefiles, which will finish in a fully reproducible 'paper.pdf'.

Other Software Required:

A minimal POSIX environment

Other Comments:

This is just a copy of the "Reproducible Paper Template" project that is already on Savannah: https://savannah.nongnu.org/projects/reproduce

Tarball URL:

http://git.savannah.nongnu.org/cgit/reproduce.git/tree/