[Plplot-general] Nightly testing?

[Alan W. Irwin]

Hi Tom:

On 2016-09-22 13:54+0100 Tom Schoonjans wrote:

>
[Hazen said]
>> I am not familiar with Travis-CI or AppVeyor but they sound interesting.
>
> Nowadays Continuous Integration is a standard tool for automated testing and 
> building nightly releases. With Travis-CI and AppVeyor you can easily 
> configure that each commit sets of a number of builds on Linux, Mac OS X and 
> Windows using any combination of options and compilers you want. Plus it’s 
> completely free for open-source projects!
>
> It is also possible to require PRs to successfully build and survive testing 
> on Travis-CI and AppVeyor as a precondition for being merged in.
>
> For an example of Travis-CI and AppVeyor, have a look at for example 
> https://github.com/tschoonj/easyRNG , 
> scroll to the end of the page and click on the green badges.

Even if we move to github I would advise whoever is in charge of such
a move to not rely on semi-proprietary or proprietary products this
way since "free of cost" can change to "costly" with one corporate
decision at github.

I do agree that nightly testing of PLplot would be worthwhile.  In
fact, we are already almost completely set up to do that with ctest,
and very little more is required for anybody interested to publish
their nightly PLplot ctest results in cdash client mode. So all that
is essentially required is a cdash (see ) server to
collect and display those results in convenient form on a website.
KitWare already provides such a free service (see
), but I recall there are some limitations
(e.g., only a limited number of clients are allowed for a given
project such as PLplot). But note that cdash is a completely
open-source product so it should be straightforward to download that
source and build a cdash server. So ultimately if the my.cdash.org
limitations became an issue we would need to find a volunteer
(presumably someone who is already running their own website) who is
willing to build and host a cdash server for PLplot.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] New release?

[Alan W. Irwin]

Hi Tom:

On 2016-09-22 13:54+0100 Tom Schoonjans wrote:

> In the scenario I am suggesting, you would just end up with a new
branch that starts at a tag and will contain bug fixes only. It will
never need to be merged into master as it will consist of commits that
were cherrypicked from master.

> This kind of workflow is used for example by all GNOME projects such
as glib and gtk+: development occurs on master, when a new major
release is ready, a tag is created (e.g. 3.22.0), as well as a new
branch with the name of that major release (gtk-3-22), which will then
receive bug fixes that were cherrypicked from master, but not its new
features! Every now and then maintenance releases will be created off
this branch like 3.22.1, 3.22.2 etc.

This is certainly a possible approach, but in my view an even better
(and simpler) approach would be to get out our releases (whether
maintenance releases or otherwise) in a timely manner, i.e., every 3-6
months.  I have obviously fallen short of that goal for this release,
but I also hope to do a lot better moving forward!

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] New release?

[Alan W. Irwin]

Hi Tom:

At the end of this I have a question concerning using our preferred
workflow at github (assuming someone wants to take responsibility for
such a move).

But first, you need some background.  PLplot used CVS for a long time,
then SVN for a long time, and then fairly recently made the transition
to git, but with an enforced rebase workflow since that was so similar
to the CVS and SVN workflow we had been using previously.  And we
still have core developers getting up to speed with git even though we
have made it easy for them to transition from svn with the rebase
workflow. We also have some developers with quite a bit more
experience with git who are urging that we might want to move to a
more sophisticated workflow that makes collaboration more convenient
then it is with git format-patch/am, but we have proved with some git
format-patch/am collaborations that that method works well, and the
tradeoff for moving to a merge-based workflow appears to be either (a)
a completely messed up git history that is impossible for a human to
understand or (b) a complex but enforced merge-style workflow that
maintains clean --first-parent history (see, e.g.,
). In both the
CMake and Itk cases, that clean --first-parent history is enforced by
server side hooks, but both those related projects have a human git
integration manager (Brad King in the CMake case) to help git users
navigate the complex merge workflow rules (and particularly help them
get the mess sorted out when they inevitably run afoul of the workflow
enforcement rules).

Given our own CVS/SVN background, Brad's advice when we first moved to
git was to follow the enforced rebase workflow that we currently have,
but he did also say after several years of that we might want to move
to a git workflow similar to that used by CMake.  I would not stand in
the way of such a move if someone else wanted to take full
responsibility for it including being the guy to interpret for the
rest of our developers what has gone wrong when the server side hooks
reject their pushes.  Note, I am assuming here that whatever workflow
we adopt will be enforced by server side hooks (just like now) because 
otherwise you
just end up with a mess.

@Tom: I assume github would allow us to set any server side hooks we
wanted to use to enforce our adopted workflow (just like SF does), but
could you confirm that please?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] New release?

[Alan W. Irwin]

Hi Tom:

You have opened up a lot of interesting topics for discussion here
which I am going to answer in separate e-mails with separate subject
lines.

In those separate replys I will also quote some key questions that
Hazen has already asked.

More later...

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] New release?

[Tom Schoonjans]

Hello again,

> We have been trying to maintain a linear history with git following the 
> process explained in the README.developers file. I think that the fork and 
> pull-request system would break this?

Not necessarily, you can ask people submitting a PR that they rebase against 
master. You can even enforce as a required check before merging that new 
branches are up to date with the latest changes in master.

In the scenario I am suggesting, you would just end up with a new branch that 
starts at a tag and will contain bug fixes only. It will never need to be 
merged into master as it will consist of commits that were cherrypicked from 
master.
This kind of workflow is used for example by all GNOME projects such as glib 
and gtk+: development occurs on master, when a new major release is ready, a 
tag is created (e.g. 3.22.0), as well as a new branch with the name of that 
major release (gtk-3-22), which will then receive bug fixes that were 
cherrypicked from master, but not its new features! Every now and then 
maintenance releases will be created off this branch like 3.22.1, 3.22.2 etc.

> I am not familiar with Travis-CI or AppVeyor but they sound interesting.

Nowadays Continuous Integration is a standard tool for automated testing and 
building nightly releases. With Travis-CI and AppVeyor you can easily configure 
that each commit sets of a number of builds on Linux, Mac OS X and Windows 
using any combination of options and compilers you want. Plus it’s completely 
free for open-source projects!

It is also possible to require PRs to successfully build and survive testing on 
Travis-CI and AppVeyor as a precondition for being merged in.

For an example of Travis-CI and AppVeyor, have a look at for example 
https://github.com/tschoonj/easyRNG , 
scroll to the end of the page and click on the green badges.


Best,

Tom

> On 22 Sep 2016, at 13:29, Hazen Babcock  wrote:
> 
> On 09/22/2016 04:58 AM, Tom Schoonjans wrote:
>> 
>> Thanks for the fast reply.
>> 
>> I appreciate that you want to make sure that all newly implemented features 
>> have been properly tested before making the next release. Surely we can all 
>> benefit from that.
>> 
>> However, since a new release is at least a month from now, I still would 
>> like to urge you to release a maintenance release (5.11.2) in the meantime, 
>> which branches off the commit tagged as ‘plplot-5.11.1’ and cherrypicks the 
>> two commits (and possibly other bugfixes) from master to ensure it builds 
>> properly with CMake 3.6.
>> 
>> On a side note, I am also wondering if it would be possible to set up a 
>> mirror of the repository on GitHub? The fork and pull-request system is 
>> extremely good for collaboration. Also, it would be trivial to implement 
>> continuous integration support with e.g. Travis-CI and AppVeyor, which 
>> should really make testing a lot easier. I would gladly help out with that.
>> 
>> Best regards,
>> 
>> Tom
> 
> We have been trying to maintain a linear history with git following the 
> process explained in the README.developers file. I think that the fork and 
> pull-request system would break this?
> 
> Also, I have been maintaining an unofficial mirror here:
> https://github.com/HazenBabcock/PLplot
> 
> And we do have a PLplot organization on github, though we've not done much 
> with it:
> https://github.com/PLplot
> 
> I am not familiar with Travis-CI or AppVeyor but they sound interesting.
> 
> best,
> -Hazen
> 

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general