taskReproducible paper template - Tasks: task #15635, Stable branch and/or release...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #15635: Stable branch and/or release candidates/official releases

Submitted by:  Boud Roukema <boud>
Submitted on:  Tue 12 May 2020 12:40:34 AM UTC  
 
Should Start On:  Mon 11 May 2020 12:00:00 AM UTC Should be Finished on:  Mon 11 May 2020 12:00:00 AM UTC
Category:  None Priority:  5 - Normal
Status:  None Privacy:  Public
Percent Complete:  0% Assigned to:  None
Open/Closed:  Open Effort:  0.00

Fri 15 May 2020 09:14:58 PM UTC, comment #4: 

By windows-with-POSIX, I didn't mean that we have such a system, but rather that such systems apparently exist. I meant that we would need a volunteer with access to such a system and the willingness to test it.

An old system:
https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

Some interesting quotes:

> This subsystem implements only the POSIX.1 standard ...
> The NT POSIX subsystem was included with the first versions of Windows NT because of 1980s US federal government requirements  ... if Windows NT had not included this subsystem, computing systems based on it would not have been eligible for some government contracts.


Apparently more up-to-date:
https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux

https://en.wikipedia.org/wiki/Cygwin

> Cygwin (/ˈsɪɡwɪn/ SIG-win)[2] is a POSIX-compatible environment that runs natively on Microsoft Windows.


Obviously, anyone running any of these systems should assume that they are already compromised (in terms of security) at the Windows level, automatically sending telemetry data to Redmond if it's Windows 10 and hosting "unwanted inconspicuous guests" in the system (resources for Russian troll farms).

Boud Roukema <boud>
Project Member
Fri 15 May 2020 02:12:18 PM UTC, comment #3: 

This is a good suggestion, let me build upon it as a brain-storm:

We don't merge a test branch into the core maneage branch until it has been tested (where relevant). So we can define a convention for notes at the end of the commit message in the final merge.

For example saying that Maneage has been tested with this commit from scratch, on operating systems X, Y and Z. We can set some convention for this part so it can be automatically parsed for a webpage like you mentioned.

Unfortunately we don't have all the architectures of Debian to test on.

But maybe we can consider some continuous integration services, for example https://travis-ci.com. But ones that may offer free services to free software projects or something and can provide a sufficiently wide variety of architectures.

I just didn't understand your point on "windows-with-POSIX", do we have such a system?

Mohammad Akhlaghi <makhlaghi>
Project Administrator
Fri 15 May 2020 03:06:04 AM UTC, comment #2: 

Just to throw ideas around...

One idea is to have some sort of a table - plain text :) - maybe cvs for example, or yaml, with commit numbers, and values such as developer IDs and confirmation that that developer thinks that the commit works as expected, and values for particular OSes, stating that the full cycle, including creating the default paper.pdf, worked (or failed) on that OS.

We could then automatically convert that table into a compact form that is human-understandable about the quality and likelihood of working as expected; and/or into xml or html format for web pages.

Debian has a whole range of quality control pipelines, e.g.

https://tracker.debian.org/pkg/inhomog
https://tracker.debian.org/pkg/gnuastro

If we want to seriously claim all-POSIX validity, then we also need to find a windows-with-POSIX volunteer.

Boud Roukema <boud>
Project Member
Tue 12 May 2020 05:27:03 PM UTC, comment #1: 

Thanks for bringing this up Boud!

I have been thinking about this for some time, but for now (as you know), there have been more urgent things to do. As soon as the lower-level things are more complete, we'll be able to focus on things like this.

So far, this is what I have concluded with: a rolling-release style (something like ArchLinux) where the whole system is constantly evolving. Tags or versions are only arbitrary points in history.

Infact we don't even need any actual mailing list or the like: users will just fetch the main branch, have a look at the commit messages (which are not technical and tailored to the users), and decide if they want to update their project at this point in time or not.

So far, my convention has been like this (as you can see from the list of most recent commits): for any change that will affect projects or does recommend a full re-configuration, I have put an "IMPORTANT" at the start of the commit title. When a user sees this, they will know to pay more attention to this commit compared to others.

But we are in a discovery phase on this aspect of Maneage (which is arguably a whole new paradigm of software, were users aren't passive), the things above are just what I have been thinking now.

So thanks a lot for bringing it up and feel free to share anything that may occur to you. We should discuss it here and find the best way forward.

Mohammad Akhlaghi <makhlaghi>
Project Administrator
Tue 12 May 2020 12:40:34 AM UTC, original submission:  

If we don't want new users to be discouraged, then we should
sooner or later start something like the usual stable versus
development branches, or have official releases with tags (as
with gnuastro :)).

There is already quite a solid learning curve required and
having a failed default
   ./project configure -j8 && ./project make
would easily be discouraging.

We should also think about making updates between releases
smooth. Debian stable updates have improved over the years,
though users still have to read the guidelines in each case
when updating.

For example - if users are expected to do a full new configure,
then that should be in the update instructions. By "update",
I mean merging new 'maneage' commits into a particular project.

Boud Roukema <boud>
Project Member

 

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 makhlaghi (Posted a comment)
  • -email is unavailable- added by boud (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.5