taskSavannah Administration - Tasks: task #15653, Submission of Maneage

 
 

task #15653: Submission of Maneage

Submitter:  Mohammad Akhlaghi <makhlaghi>
Submitted:  Wed 20 May 2020 12:43:58 AM UTC
   
 
Should Start On:  Tue 19 May 2020 11:00:00 PM UTC Should be Finished on:  Fri 29 May 2020 11:00:00 PM UTC
Category:  Project Approval Priority:  * 5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  ineiev Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 02 Jul 2021 07:18:46 PM UTC, comment #8: 

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

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

Mohammad Akhlaghi <makhlaghi>
Fri 02 Jul 2021 08:33:50 AM UTC, comment #7: 

comment #6:

> If I had not implemented your bug-reports, you had reason to complain.


This goes without saying; however, we discuss criteria for a different thing: when one has no reason to complain (that is, sufficient vs. necessary).

> But demanding that any project be bug-free from day one is absurd.


We do demand that groups are "bug-free" (in the sense that all files that look copyrightable have copyright and license notices that look valid) at least when evaluating them.  I might agree if bug-reports were about notices that turned out wrong (e.g. someone wrote a wrong copyright year or a wrong copyright holder in some notice), but the form of the notices is much easier to check, so it doesn't look like the analogy holds in this case.

Ineiev <ineiev>
Site Administrator
Thu 24 Jun 2021 11:02:07 AM UTC, comment #6: 


> 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


Mohammad Akhlaghi <makhlaghi>
Thu 24 Jun 2021 08:14:53 AM UTC, comment #5: 

I tried to come up with a criterion on what mistakes "slipped through fingers" are acceptable, but I failed.  Can you suggest it?  The point of your package is bit-to-bit reproducing, isn't it?

Ineiev <ineiev>
Site Administrator
Mon 25 May 2020 08:22:03 PM UTC, comment #4: 

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.

Mohammad Akhlaghi <makhlaghi>
Mon 25 May 2020 05:25:08 PM UTC, comment #3: 

comment #2:

> 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.


Why did you miss them?

> 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).


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

> 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".


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

What about README-hacking.md?

> 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.


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

Ineiev <ineiev>
Site Administrator
Fri 22 May 2020 11:04:49 PM UTC, comment #2: 

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?

Mohammad Akhlaghi <makhlaghi>
Thu 21 May 2020 04:38:11 PM UTC, comment #1: 

Files like reproduce/software/make/README.md lack copyright and license notices; also, you should have made sure that your package always speaks about free software rather than open source and calls the operating system GNU/Linux rather than "Linux."

You are a GNU maintainer and should be familiar with these matters.  Why did you miss that?

While at it, the license notices differ from the text suggested in the GPL.  I believe this should be fixed, too.

Ineiev <ineiev>
Site Administrator
Wed 20 May 2020 12:43:58 AM UTC, original submission:  

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):



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/


Mohammad Akhlaghi <makhlaghi>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _289157 (Voted in favor of this item)
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by makhlaghi (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-05 _289157 Carbon-Copy- Added fontdevelopment
    2020-05-21 ineiev StatusNone In Progress
        Assigned toNone ineiev

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code