Re: [Plplot-devel] git workflow plans for the proposed bug-fix plplot-5.14.1 release

2018-12-17 Thread Phil Rosenberg 
Sounds like a generally good plan to me. The only issues might be picking what 
is a bug fix commit vs a non bug fix commit - I'm sure we are all guilty of 
finding a bug while changing code and not submitting it as a separate commit. 
But providing we all try to be good in that sense, I think a bug fixes release 
is a good idea.

Phil

Get Outlook for Android


From: Alan W. Irwin 
Sent: Monday, December 17, 2018 5:31:31 AM
To: PLplot development list
Subject: [Plplot-devel] git workflow plans for the proposed bug-fix 
plplot-5.14.1 release

Can some git guru here review my proposed git workflow for the planned
5.14.1 release below?

The reason I ask for that review is because I currently have no
practical experience with some of the special git commands that will
be needed.  In fact, because of that lack of experience I previously
did not create a bug-fix release in an earlier release cycle for
PLplot (at least in its git era) when I likely should have!  So this
bug-fix release will be a long-overdue learning experience for me.

That said, I am pretty sure from reading on-line material and a hint
from one of our users what git steps I would have to take.  Also note
these proposed steps do not violate our (enforced) workflow rule that
no merge commits other than fast-forwarded ones are allowed.

Those git steps are as follows:

* Create a local branch called 5.14.0-bugfix from the existing plplot-5.14.0 
tag.

* Cherry pick bug-fix commits such as plplot-5.14.0-8-gdb9d90d0b onto that 
branch.

* Go through the usual release procedure while staying strictly on
   that branch which will add other commits to that branch such as the
   new (short) release notes and ChangeLog for that 5.14.1 release
   without ever merging those commits back to master.  Which means none
   of this bugfix release work impacts on the ordinary development of
   the master branch.  One of the last steps in that procedure would be
   to push the local tag that points to the tip of 5.14.0-bugfix
   (called plplot-5.14.1 in this case) to our SF git repository (again
   without changing the master branch).

* From remarks in
   

   it appears that pushing a tag pushes the associated commit and also
   pushes all ancestors of that commit that have not been pushed
   before.

   If that is correct, then all commits on my local branch called
   "5.14.0-bugfix" will end up accessible at SF but not organized as a
   formal branch there.  That result is fine with me since it doesn't
   clutter the SF version with extra branch names, and the result is
   enough to allow anybody (after they use the "git refresh" command)
   to access the commit corresponding to the plplot-5.14.1 tag or any
   of that commit's ancestors.  For example, if later on during the
   release cycle I decided to release another bug-fix release called
   5.14.2, I could start that process by branching from the
   plplot-5.14.1 tag.

   Furthmore after pushing the plplot-5.14.1 tag I would likely delete
   the 5.14.0-bugfix local branch to be consistent with the SF repository;
   I would have no further use for that branch; and
   that branch deletion does not get rid of the plplot-5.14.1 tag,
   the associated commit or any ancestors of that commit;

   Of course, with this model of workflow for bug-fix releases, no
   attempt would ever be made to merge bug-fix branches back to master
   since that makes no sense in any case and would violate our
   (enforced) rebase work flow rule that there can be no merge commits
   that cannot be fast-forwarded.

Again, comments on this plan from the git gurus here will be most welcome.

Alan
__
Alan W. Irwin

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-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] git workflow plans for the proposed bug-fix plplot-5.14.1 release

2018-12-17 Thread Alan W. Irwin 

Hi Phil:

On 2018-12-18 00:33- Phil Rosenberg wrote:


Sounds like a generally good plan to me.


Good.


The only issues might be picking what is a bug fix commit vs a non

  bug fix commit - I'm sure we are all guilty of finding a bug while
  changing code and not submitting it as a separate commit. But
  providing we all try to be good in that sense, I think a bug fixes
  release is a good idea.

The other important issue is whether the bug is a regression or not.
Regressions mean by definition that users of prior versions of PLplot
are going to get a nasty surprise by the new version of PLplot.  So
avoidance of regressions is my motivation for asking for comprehensive
testing on all platforms prior to each release, and anytime such
a regression is turned up by such testing, I view it as release critical,
i.e., the release should be held until a proper fix for the regression
has been implemented.  However, if a regression actually gets into a
release despite our testing efforts, then that would be a large
motivation to immediately issue a bug-fix release containing the
fix for that regression.

But I would rather not learn about the git steps needed for a bug-fix
release under such time pressure, and the present bug fix has a wide
impact for all our present or future qt device users.  So I am going
to use the present impactful bug fix as a good excuse to get educated
on the git steps needed to create a bug-fix release.  However, I will
likely not be willing to do this again unless the bug fix is actually
a fix for a regression.  Instead, I would like to spend most of my
PLplot effort on development and making sure that our regular releases
(which normally include both bug fixes and new development) occur
every 6 months or less.  Due to a variety of excuses I haven't managed
to do that recently, but I am planning on having a much better
ordinary release outcome in the latter part of the first half of 2019.

Alan
__
Alan W. Irwin

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-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel