Re: [Plplot-general] New release?

[Tom Schoonjans]

Hi Alan,


Releasing regularly new versions of the package is always good: it instills 
confidence in users that they are using a software package that is being 
actively developed and maintained.

However, I do think that the approach of having bug-fix branches is essential 
when making regular releases (3-6 months). Implementing new features (like the 
new Fortran bindings you mentioned) can take a long time, and it is difficult 
to predict when a new feature is ready to ship. After all, I am assuming none 
of the core developers are working full-time on PLplot right? This way of 
working unfortunately leads to large gaps between releases, which has led to 
the current situation where PLplot cannot be compiled with the latest version 
of CMake. Having a bug fix branch, and making releases off it, would ensure 
that PLplot can quickly address incompatible changes in its dependencies, or 
just fix important bugs, while relieving the developers from the pressure of 
having to produce a new release that will be a mixture of (hopefully properly 
working) new features and bug fixes.

Best,

Tom


> On 22 Sep 2016, at 20:01, Alan W. Irwin  wrote:
> 
> 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:

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

Re: [Plplot-general] New release?

[Alan W. Irwin]

On 2016-09-21 14:22+0100 Tom Schoonjans wrote:

> Hi all,
>
>
> I was wondering if a new release of PLplot could be made soon, as the current 
> release does not build with CMake 3.6.x? The fix for it is currently in 
> master.
>
> Many thanks in advance and best regards,

Sorry, but we are not yet in position to finalize our release date
which is at least a month away.  But as release manager I
do want to get that release out ASAP since it does include
a large number of fixes such as the one you mention above, and also a
number of new features (e.g., a complete rewrite of our Fortran binding
and examples which is a huge improvement over what we had before.)

Meanwhile, you and other PLplot users lurking here can help us a lot
to get this release out the door by using the PLplot git master branch
version  for
your daily plotting and reporting all issues that you find for that
version (after! reading the release notes in the README.release file)
either here or on the plplot-devel mailing list.

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