gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Update on the branch surgery

[sfeam <sf...@us...>]

On Thursday, 26 October 2017 00:06:43 Eric S. Raymond wrote:
> The alternatives remain as follows:
> 
> If it were my call, I'd cut our losses - just drop the 3.7.x and 4.0
> branches entirely.  That would leave the repo in a very clean state where
> we have confidence that what is there matches its actual development
> history quite closely.

OK by me.

> The second option would be to leave the mess as it is.  I dislike this plan
> for one major reason: We know the 3.7.x branch is corrupt - its 3.7.1 state
> does not match the archived tarball.  

At least we _have_ tarballs for 3.7.1 3.7.2 3.7.3
They can be accessed as-is.
I can't find tarballs for anything between 4.0.0 and 4.2.0 anywhere on the web.

	Ethan


> The third option is the heroic, possibly overinvested one. I could insert
> a synthetic commit between the master-branch root of 4.0 and the rest
> replicating the X change to gnuplot.rot, with a change comment explaining
> the mess.  Then we could try to rectify the 3.7.x branch.
> 

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

sfeam <sf...@us...>:
> > Hm. That's not what I see.
> > 
> > reposurgeon% [demo/gnuplot.rot] list
> >   1009 1998-04-15T19:16:47Z  :1008 *** empty log message ***
> >   1370 1998-04-22T13:40:59Z  :1369 Import of beta 344.
> >  18500 2005-01-07T23:21:02Z :18499 Revise gif animation code to comply with
> 
> [shrug]  In CVS view on SourceForge that revision "Revise gif animation code ..."
> has timestamp 
>     Sat Jan 7 23:21:02 2006 UTC (11 years, 9 months ago) by sfeam 
> 
>  http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/demo/gnuplot.rot?revision=1.2&view=markup  
> 
> Nothing before that all the way to 1998.

That's weird.  gitk says 2005, too.  I'll look into this further. 

It doesn't make any difference to the present mess, though; both dates are
too late at the 2005/2006 commit is on the wrong branch.

The alternatives remain as follows:

If it were my call, I'd cut our losses - just drop the 3.7.x and 4.0
branches entirely.  That would leave the repo in a very clean state where
we have confidence that what is there matches its actual development
history quite closely.

The second option would be to leave the mess as it is.  I dislike this plan
for one major reason: We know the 3.7.x branch is corrupt - its 3.7.1 state
does not match the archived tarball.  

The third option is the heroic, possibly overinvested one. I could insert
a synthetic commit between the master-branch root of 4.0 and the rest
replicating the X change to gnuplot.rot, with a change comment explaining
the mess.  Then we could try to rectify the 3.7.x branch.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Update on the branch surgery

[sfeam <sf...@us...>]

On Wednesday, 25 October 2017 23:16:15 Eric S. Raymond wrote:
> Ethan A Merritt <sf...@us...>:
> > On Wednesday, October 25, 2017 3:18:37 PM PDT Eric S. Raymond wrote:
> > > I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
> > > it on /#include gp_time.h/ yields this diff at the tip:
> > > 
> > > --- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
> > > +++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
> > > @@ -1,12 +1,5 @@
> > > -# HBB: revised open-ended animation routine. Used to just turn
> > > -# round and round by somewhat large steps. Now, it tumbles
> > > -# back and forth smoothly.
> > > -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
> > > -# many iterations (iteration_count=0 has to be set before this -#
> > > script is called)
> > >  zrot=(zrot+10)%360
> > >  xrot=(xrot+17)%180
> > > -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
> > > +set view xrot,zrot
> > >  replot
> > > -iteration_count=iteration_count+1
> > > -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
> > > +reread
> > 
> > That file has only been touched twice, once in 1998 and once in 2006.
> > The diff you list above was the 1998 change.
> 
> Hm. That's not what I see.
> 
> reposurgeon% [demo/gnuplot.rot] list
>   1009 1998-04-15T19:16:47Z  :1008 *** empty log message ***
>   1370 1998-04-22T13:40:59Z  :1369 Import of beta 344.
>  18500 2005-01-07T23:21:02Z :18499 Revise gif animation code to comply with

[shrug]  In CVS view on SourceForge that revision "Revise gif animation code ..."
has timestamp 
    Sat Jan 7 23:21:02 2006 UTC (11 years, 9 months ago) by sfeam 

 http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/demo/gnuplot.rot?revision=1.2&view=markup  

Nothing before that all the way to 1998.

	Ethan

> 
> That first one looks like the initial import.  Two following changes, all
> right, first in 1998, but the second early in 2005 rather than in 2006.
> 
> reposurgeon% :1008
> Event 1009 ==============================================================
> commit refs/tags/4.0.2
> mark :1008
> author Lars Hecking <lhe...@nm...> 892667807 +0100
> committer Lars Hecking <lhe...@nm...> 892667807 +0100
> data 26
> *** empty log message ***
> from :765
> M 100644 :766 00test
> M 100644 :767 0BUGS
>           :
> M 100644 :836 demo/fit.dem
> M 100644 :600 demo/gnuplot.rot
> M 100644 :837 demo/hidden.dem
> M 100644 :838 demo/mgr.dem
>            :
>   (bulk of file manifest omitted)
> reposurgeon% inspect :600
> Event 601 ===============================================================
> blob
> mark :600
> data 71
> zrot=(zrot+10)%360
> xrot=(xrot+17)%180
> set view xrot,zrot
> replot
> reread
> 
> The initial import brought in the short form. The longer form is in the
> 1998 change, which was actually a re-import of some different version of
> ancestral GNUPLOT.
> 
> reposurgeon% :1369 inspect
> Event 1370 ==============================================================
> commit refs/tags/3.7.1
> mark :1369
> author Lars Hecking <lhe...@nm...> 893252459 +0100
> committer Lars Hecking <lhe...@nm...> 893252459 +0100
> data 20
> Import of beta 344.
> from :1207
> M 100644 :1208 0PORTING
>         :
> M 100644 :1222 demo/animate.dem
> M 100644 :1223 demo/gnuplot.rot
> M 100644 :1224 demo/multimsh.dem
>         :
>    (most of the filelist omitted)
> reposurgeon% :1223 inspect
> Event 1224 ==============================================================
> blob
> mark :1223
> data 518
> # HBB: revised open-ended animation routine. Used to just turn
> # round and round by somewhat large steps. Now, it tumbles
> # back and forth smoothly.
> # If 'limit_iterations' is set to a nonzero value, it'll stop after that
> # many iterations (iteration_count=0 has to be set before this
> # script is called)
> zrot=(zrot+10)%360
> xrot=(xrot+17)%180
> set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
> replot
> iteration_count=iteration_count+1
> if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
> 
> Here's the 2005 change:
> 
> reposurgeon% :18499 inspect
> Event 18500 =============================================================
> commit refs/tags/4.2.1
> mark :18499
> author Daniel Sebald <dan...@ie...> 1105140062 -0800
> committer Ethan A Merritt <merritt@u.washington.edu> 1136676062 -0800
> data 57
> Revise gif animation code to comply with Gif89a standard
> from :18493
> M 100644 :18494 ChangeLog
> M 100644 :18495 demo/animate.dem
> M 100644 :18496 demo/animate2.dem
> M 100644 :18497 demo/gnuplot.rot
> M 100644 :18498 term/gd.trm
> 
> reposurgeon% inspect :18497
> Event 18498 =============================================================
> blob
> mark :18497
> data 1294
> # A generic rotation routine for the gnuplot view.  In the commands
> # that load this file, the following should be defined:
> #
> # iteration_count:  set iteration_count=0
> #
> # limit_iterations:  if set to a nonzero value, it'll stop after that
> #     many iterations; if zero value, continues indefinitely
> #
> # xrot:  the initial x rotation of the view
> #
> # xrot_delta:  the amount to increment the x rotation for each new plot
> #
> # xview:  function for generating x view value; for example
> #     xview(xrot)=(50.+30.*sin((xrot%180)/180.*pi))
> #
> # zrot:  the initial z rotation of the view
> #
> # zrot_delta:  the amount to increment the z rotation for each new plot
> #
> # zview:  function for generating z view value; for example
> #     zview(zrot)=(60.+45.*sin(zrot/180.*pi))
> #
> # History:
> #   - 1. 1. 2006 Dan Sebald:  Made more generic so other demos could use
> #   - ?. ?. ?    Hans-Bernhard Broeker:  Used to just turn round and round
> #                by somewhat large steps. Now, it tumbles back and forth
> #                smoothly.
> #   - ?. ?. ?    ?:  Initial recursive script
> 
> iteration_count=iteration_count+1
> if ((!limit_iterations) || (iteration_count<=limit_iterations)) \
>   set view xview(xrot),zview(zrot); \
>   replot; \
>   zrot=(zrot+zrot_delta)%360; \
>   xrot=(xrot+xrot_delta)%360; \
>   reread
> 
> > At a guess, the 07-Jan-2006 change is right at the time of the 4.2 branch
> > and got caught on the wrong side of it.
> 
> Alas, it's nastier than that. The import of 344 is a commit that was only
> on the bizarro-branch leading to 3.7.1.  The 4-0-stable branch was rooted
> in *that import*, not the trunk leading 4 4 and everything later.
> 
> Here is what the repo structure looks like now, with the 5.0/4.6/4.4/4.2
> grafts done:
> 
> ------+--------+---------+-------+----------+---------+-------- master
>       |        |         |       |          |         |
>       |        |         |       |          |         +----- 5-2-stable
>       |        |         |       |          |         
>       |        |         |       |          +------------ 5-0 stable
>       |        |         |       |                   
>       |        |         |       +-------------------- 4-6-stable
>       |        |         |          
>       |        |         +------------------------- 4-4-stable
>       |        |
>       |        +-------------------------------- 4.2-stable
>       |
>       +--------X---------- 3.7.1
>                |
> 	       +------------------ 4.0-stable
> 
> X marks the spot where the shortened version of the demo visible at the
> 4-0-stable tip (before surgery) was introduced.  When 4.0 is rerooted
> to the logical spot on the master branch, the longer 1998 version is exposed.
> 
> This is not a conversion problem.  It's not even like the 4.2/4.4/4.6
> branches, where an incomplete root-tag set threw the join point
> backwards in time. This is somebody's finger error that's been lurking
> in the repo metadata since the 4.0 branch was forked from the wrong
> place.
> 
> As such, our options for fixing it are limited and unpleasant.
> 
> If it were my call, I'd cut our losses - just drop the 3.7.x and 4.0
> branches entirely.  That would leave the repo in a very clean state where
> we have confidence that what is there matches its actual development
> history quite closely.
> 
> The second option would be to leave the mess as it is.  I dislike this plan
> for one major reason: We know the 3.7.x branch is corrupt - its 3.7.1 state
> does not match the archived tarball.  
> 
> The third option is the heroic, possibly overinvested one. I could insert
> a synthetic commit between the master-branch root of 4.0 and the rest
> replicating the X change to gnuplot.rot, with a change comment explaining
> the mess.  Then we could try to rectify the 3.7.x branch.
> 
> You guys are the customer, you get to decide.
> 

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

Ethan A Merritt <sf...@us...>:
> On Wednesday, October 25, 2017 3:18:37 PM PDT Eric S. Raymond wrote:
> > I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
> > it on /#include gp_time.h/ yields this diff at the tip:
> > 
> > --- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
> > +++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
> > @@ -1,12 +1,5 @@
> > -# HBB: revised open-ended animation routine. Used to just turn
> > -# round and round by somewhat large steps. Now, it tumbles
> > -# back and forth smoothly.
> > -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
> > -# many iterations (iteration_count=0 has to be set before this -#
> > script is called)
> >  zrot=(zrot+10)%360
> >  xrot=(xrot+17)%180
> > -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
> > +set view xrot,zrot
> >  replot
> > -iteration_count=iteration_count+1
> > -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
> > +reread
> 
> That file has only been touched twice, once in 1998 and once in 2006.
> The diff you list above was the 1998 change.

Hm. That's not what I see.

reposurgeon% [demo/gnuplot.rot] list
  1009 1998-04-15T19:16:47Z  :1008 *** empty log message ***
  1370 1998-04-22T13:40:59Z  :1369 Import of beta 344.
 18500 2005-01-07T23:21:02Z :18499 Revise gif animation code to comply with

That first one looks like the initial import.  Two following changes, all
right, first in 1998, but the second early in 2005 rather than in 2006.

reposurgeon% :1008
Event 1009 ==============================================================
commit refs/tags/4.0.2
mark :1008
author Lars Hecking <lhe...@nm...> 892667807 +0100
committer Lars Hecking <lhe...@nm...> 892667807 +0100
data 26
*** empty log message ***
from :765
M 100644 :766 00test
M 100644 :767 0BUGS
          :
M 100644 :836 demo/fit.dem
M 100644 :600 demo/gnuplot.rot
M 100644 :837 demo/hidden.dem
M 100644 :838 demo/mgr.dem
           :
  (bulk of file manifest omitted)
reposurgeon% inspect :600
Event 601 ===============================================================
blob
mark :600
data 71
zrot=(zrot+10)%360
xrot=(xrot+17)%180
set view xrot,zrot
replot
reread

The initial import brought in the short form. The longer form is in the
1998 change, which was actually a re-import of some different version of
ancestral GNUPLOT.

reposurgeon% :1369 inspect
Event 1370 ==============================================================
commit refs/tags/3.7.1
mark :1369
author Lars Hecking <lhe...@nm...> 893252459 +0100
committer Lars Hecking <lhe...@nm...> 893252459 +0100
data 20
Import of beta 344.
from :1207
M 100644 :1208 0PORTING
        :
M 100644 :1222 demo/animate.dem
M 100644 :1223 demo/gnuplot.rot
M 100644 :1224 demo/multimsh.dem
        :
   (most of the filelist omitted)
reposurgeon% :1223 inspect
Event 1224 ==============================================================
blob
mark :1223
data 518
# HBB: revised open-ended animation routine. Used to just turn
# round and round by somewhat large steps. Now, it tumbles
# back and forth smoothly.
# If 'limit_iterations' is set to a nonzero value, it'll stop after that
# many iterations (iteration_count=0 has to be set before this
# script is called)
zrot=(zrot+10)%360
xrot=(xrot+17)%180
set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
replot
iteration_count=iteration_count+1
if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread

Here's the 2005 change:

reposurgeon% :18499 inspect
Event 18500 =============================================================
commit refs/tags/4.2.1
mark :18499
author Daniel Sebald <dan...@ie...> 1105140062 -0800
committer Ethan A Merritt <merritt@u.washington.edu> 1136676062 -0800
data 57
Revise gif animation code to comply with Gif89a standard
from :18493
M 100644 :18494 ChangeLog
M 100644 :18495 demo/animate.dem
M 100644 :18496 demo/animate2.dem
M 100644 :18497 demo/gnuplot.rot
M 100644 :18498 term/gd.trm

reposurgeon% inspect :18497
Event 18498 =============================================================
blob
mark :18497
data 1294
# A generic rotation routine for the gnuplot view.  In the commands
# that load this file, the following should be defined:
#
# iteration_count:  set iteration_count=0
#
# limit_iterations:  if set to a nonzero value, it'll stop after that
#     many iterations; if zero value, continues indefinitely
#
# xrot:  the initial x rotation of the view
#
# xrot_delta:  the amount to increment the x rotation for each new plot
#
# xview:  function for generating x view value; for example
#     xview(xrot)=(50.+30.*sin((xrot%180)/180.*pi))
#
# zrot:  the initial z rotation of the view
#
# zrot_delta:  the amount to increment the z rotation for each new plot
#
# zview:  function for generating z view value; for example
#     zview(zrot)=(60.+45.*sin(zrot/180.*pi))
#
# History:
#   - 1. 1. 2006 Dan Sebald:  Made more generic so other demos could use
#   - ?. ?. ?    Hans-Bernhard Broeker:  Used to just turn round and round
#                by somewhat large steps. Now, it tumbles back and forth
#                smoothly.
#   - ?. ?. ?    ?:  Initial recursive script

iteration_count=iteration_count+1
if ((!limit_iterations) || (iteration_count<=limit_iterations)) \
  set view xview(xrot),zview(zrot); \
  replot; \
  zrot=(zrot+zrot_delta)%360; \
  xrot=(xrot+xrot_delta)%360; \
  reread

> At a guess, the 07-Jan-2006 change is right at the time of the 4.2 branch
> and got caught on the wrong side of it.

Alas, it's nastier than that. The import of 344 is a commit that was only
on the bizarro-branch leading to 3.7.1.  The 4-0-stable branch was rooted
in *that import*, not the trunk leading 4 4 and everything later.

Here is what the repo structure looks like now, with the 5.0/4.6/4.4/4.2
grafts done:

------+--------+---------+-------+----------+---------+-------- master
      |        |         |       |          |         |
      |        |         |       |          |         +----- 5-2-stable
      |        |         |       |          |         
      |        |         |       |          +------------ 5-0 stable
      |        |         |       |                   
      |        |         |       +-------------------- 4-6-stable
      |        |         |          
      |        |         +------------------------- 4-4-stable
      |        |
      |        +-------------------------------- 4.2-stable
      |
      +--------X---------- 3.7.1
               |
	       +------------------ 4.0-stable

X marks the spot where the shortened version of the demo visible at the
4-0-stable tip (before surgery) was introduced.  When 4.0 is rerooted
to the logical spot on the master branch, the longer 1998 version is exposed.

This is not a conversion problem.  It's not even like the 4.2/4.4/4.6
branches, where an incomplete root-tag set threw the join point
backwards in time. This is somebody's finger error that's been lurking
in the repo metadata since the 4.0 branch was forked from the wrong
place.

As such, our options for fixing it are limited and unpleasant.

If it were my call, I'd cut our losses - just drop the 3.7.x and 4.0
branches entirely.  That would leave the repo in a very clean state where
we have confidence that what is there matches its actual development
history quite closely.

The second option would be to leave the mess as it is.  I dislike this plan
for one major reason: We know the 3.7.x branch is corrupt - its 3.7.1 state
does not match the archived tarball.  

The third option is the heroic, possibly overinvested one. I could insert
a synthetic commit between the master-branch root of 4.0 and the rest
replicating the X change to gnuplot.rot, with a change comment explaining
the mess.  Then we could try to rectify the 3.7.x branch.

You guys are the customer, you get to decide.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

The first repository branch, "Windows linestyle fix."

[Daniel J S. <dan...@ie...>]

On 10/25/2017 02:48 PM, Daniel J Sebald wrote:
> On 10/25/2017 12:16 PM, Eric S. Raymond wrote:
[snip]
>> I'm going to to do some more analysis on the 3.7 branch, but the odds
>> that we'll have to write it off look pretty high.
> 
> I'll look at this a bit more.  For those with historical knowledge, I'm 
> going to write some checkin comments here that come from searching, but 
> only those that seem like they could give a clue about when the first 
> branch was done.  (I'm using qgit, which has some nice searching and 
> file features.)  Let me know if they ring a bell:
> 
> "branch"
> New function gp_strdup, from cvs MAIN branch.
> Updated from cvs MAIN branch
> New files from my branched-off 'monster patch'
> Merged the pm3d branch back to MAIN
> Merge axis-branch into MAIN. Lots of changes all over the places
> a few changes after merging the axis branch
> make the branched version compile under OS/2
> Updated from aquaterm cvs bugfix branch.
> 
> "merge"
> Final fixes for merger.
> Update from current automake (lost in merge).
> Some cleanups/fixes after the merge.

Here's a bit of a clue about the branch point for that first branch.  I 
noted that the two files that had changed with the "Windows linestyle 
fix." checkin are:

=============================================================================
RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgnuplib.h,v
Working file: win/wgnuplib.h
head: 1.6
branch:
----------------------------
revision 1.4.2.1
date: 1999/08/19 14:13:09;  author: lhecking;  state: Exp;  lines: +4 -1
Windows linestyle fix.
=============================================================================

=============================================================================
RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgraph.c,v
Working file: win/wgraph.c
head: 1.7
branch:
----------------------------
revision 1.5.2.1
date: 1999/08/19 14:13:09;  author: lhecking;  state: Exp;  lines: +12 -1
Windows linestyle fix.
=============================================================================

However, compare the date with the following major modification which 
moved those files from the win/ directory to the win/src directory (and 
remember in CVS the "move" is actually as though these are completely 
different files, with new instantiation):

=============================================================================
RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgnuplib.h,v
Working file: win/wgnuplib.h
head: 1.6
branch:
----------------------------
revision 1.6
date: 1999/03/26 22:09:29;  author: lhecking;  state: dead;  lines: +1 -1
Moved to src/win/.
----------------------------
=============================================================================

So, that modification "Windows linestyle fix" is dated five months 
*after* the file was moved, effectively terminated.  There is no way the 
branch point could be near 1999/08/19 where I was searching.  So, no 
surprise that search failed.

I've searched back much earlier.  I'm not familiar with CVS versioning, 
does the "revision 1.4.2.1 date: 1999/08/19 14:13:09;" mean that this 
particular revision was derived from "revision 1.4"?  I.e., the user 
checked out "revision 1.4" as a start for creating the branch?  In this 
case revision 1.4 was of

----------------------------
revision 1.4
date: 1998/12/10 18:30:13;  author: lhecking;  state: Exp;  lines: +0 -2
branches:  1.4.2;
Remove two defines.
----------------------------

So, maybe that is where I should look, around 1998/12/10.  (I should 
probably just write a script to compare against all versions.) ...
Nope.  If I'm understanding correctly, based upon the "branches" number 
of 1.4.2.1, "Windows linestyle fix" could have happened any time between 
revision 1.5 (1999/02/14 18:13:55) and revision 1.4 (1998/12/10 
18:30:13).  The logical branch points in that range would be

date: 1999/01/12 14:03:53;  author: lhecking;  state: Exp;  lines: +4 -5
Version 3.7, patchlevel 0, update date string.

and

date: 1999/01/12 13:58:02;  author: lhecking;  state: Exp;  lines: +3 -3
Updated to 3.7.

but again, those don't seem to match well.

Well, here's one encouraging result:  I've done the directory comparison 
between CVS versions.  If I pick CVS directory to be

cvs update -rGNUPLOT_RELEASE_3_7_0

and compare against the git "Windows linestyle fix." directory it 
creates pretty good agreement but it looks like all the RCSid are rather 
different.  Just to illustrate, here a diff of one of the files that 
supposedly changes both within CVS and across CVS and git:

sebald@ ~/gnuplot/git_translation/branch_point_search/gnuplot $ cvs diff 
-u -r1.4 -r1.4.2.1 win/wgnuplib.h
Index: win/wgnuplib.h
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgnuplib.h,v
retrieving revision 1.4
retrieving revision 1.4.2.1
diff -u -r1.4 -r1.4.2.1
--- win/wgnuplib.h	10 Dec 1998 18:30:13 -0000	1.4
+++ win/wgnuplib.h	19 Aug 1999 14:13:09 -0000	1.4.2.1
@@ -1,5 +1,5 @@
  /*
- * $Id: wgnuplib.h,v 1.4 1998/12/10 18:30:13 lhecking Exp $
+ * $Id: wgnuplib.h,v 1.4.2.1 1999/08/19 14:13:09 lhecking Exp $
   */

  /* GNUPLOT - win/wgnuplib.h */
@@ -320,6 +320,9 @@
  	HPEN	hbpen;					/* border pen */
  	HPEN	hapen;					/* axis pen */
  	HPEN	hpen[WGNUMPENS];		/* pens */
+#if 1 /* HBB 980118: new try ... */
+        HPEN    hsolidpen[WGNUMPENS];           /* solid pens (for 
point symbols) */
+#endif
  	LOGPEN	colorpen[WGNUMPENS+2];	/* logical color pens */
  	LOGPEN	monopen[WGNUMPENS+2];	/* logical mono pens */
  	COLORREF background;			/* background color */

sebald@ ~/gnuplot/git_translation/branch_point_search $ diff -ur 
--exclude=".git" gnuplot/win/wgnuplib.h branch_reference/win/wgnuplib.h
--- gnuplot/win/wgnuplib.h	1998-12-10 12:30:13.000000000 -0600
+++ branch_reference/win/wgnuplib.h	2017-10-25 16:05:19.318473813 -0500
@@ -320,6 +320,9 @@
  	HPEN	hbpen;					/* border pen */
  	HPEN	hapen;					/* axis pen */
  	HPEN	hpen[WGNUMPENS];		/* pens */
+#if 1 /* HBB 980118: new try ... */
+        HPEN    hsolidpen[WGNUMPENS];           /* solid pens (for 
point symbols) */
+#endif
  	LOGPEN	colorpen[WGNUMPENS+2];	/* logical color pens */
  	LOGPEN	monopen[WGNUMPENS+2];	/* logical mono pens */
  	COLORREF background;			/* background color */

The discouraging part, though, is that when I compare CVS 
GNUPLOT_RELEASE_3_7_0 against git master commit "Updated to 3.7.", it's 
not a good match at all.  Shouldn't it be a good match?

I think the key here is to first figure out and reconstruct what would 
be tag 3.7.0 in the git repository, so that it coincides with 
GNUPLOT_RELEASE_3_7_0.  It might be the something is corrupted in the 
master branch in that first few years of checkins.  My guess would be 
that release 3.7.0 was on the trunk, then "Windows linestyle fix" was a 
branch, which produced 3.7.1, 3.7.2, etc.  I can see why this is so 
difficult to reconstruct now.  Tags are the only sort of reliable CVS 
construct, so I suppose we should get those important ones working first.

Dan

Re: Update on the branch surgery

[Hans-Bernhard B. <HBB...@t-...>]

Am 26.10.2017 um 00:18 schrieb Eric S. Raymond:
> I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
> it on /#include gp_time.h/ yields this diff at the tip:
> 
> --- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
> +++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
> @@ -1,12 +1,5 @@
> -# HBB: revised open-ended animation routine. Used to just turn
> -# round and round by somewhat large steps. Now, it tumbles
> -# back and forth smoothly.
> -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
> -# many iterations (iteration_count=0 has to be set before this
> -# script is called)
>   zrot=(zrot+10)%360
>   xrot=(xrot+17)%180
> -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
> +set view xrot,zrot
>   replot
> -iteration_count=iteration_count+1
> -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
> +reread

The actual CVS version of this file, from almost the beginning of the 
public repository, to the 4.0 branch point and beyond, all the way to 
almost the 4.2 branch point, was 1.1.1.2.  All branches before the 4.2 
one originate at revision 1.1.1.2, getting branch-point numbers like 
1.1.1.2.0.{n}.

As the numbering indicates ('*.1.n', instead of '*.2.n' of ordinary 
branches), this revision is from one of those pesky CVS "vendor" 
pseudo-branches which the conversion tools apparently shy away from as a 
vampire from garlic.  Apparently Lars Hecking used "cvs import" to track 
early development from his own machine(s) into the new public repository 
at SF.net.  That vendor branch itself is called "GNUPLOT_BETA", and all 
the BETA_34* tags are on this branch.

About 2 dozen files in our project (primarily demo/*.dat) are apparently 
_still_ on that branch, because they were ne7ver changed since the 
initial check-in.

Re: Update on the branch surgery

[Ethan A M. <sf...@us...>]

On Wednesday, October 25, 2017 3:18:37 PM PDT Eric S. Raymond wrote:
> I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
> it on /#include gp_time.h/ yields this diff at the tip:
> 
> --- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
> +++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
> @@ -1,12 +1,5 @@
> -# HBB: revised open-ended animation routine. Used to just turn
> -# round and round by somewhat large steps. Now, it tumbles
> -# back and forth smoothly.
> -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
> -# many iterations (iteration_count=0 has to be set before this -#
> script is called)
>  zrot=(zrot+10)%360
>  xrot=(xrot+17)%180
> -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
> +set view xrot,zrot
>  replot
> -iteration_count=iteration_count+1
> -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
> +reread

That file has only been touched twice, once in 1998 and once in 2006.
The diff you list above was the 1998 change.

At a guess, the 07-Jan-2006 change is right at the time of the 4.2 branch
and got caught on the wrong side of it.

	Ethan

Update on the branch surgery

[<es...@th...>]

I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
it on /#include gp_time.h/ yields this diff at the tip:

--- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
+++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
@@ -1,12 +1,5 @@
-# HBB: revised open-ended animation routine. Used to just turn
-# round and round by somewhat large steps. Now, it tumbles
-# back and forth smoothly.
-# If 'limit_iterations' is set to a nonzero value, it'll stop after that
-# many iterations (iteration_count=0 has to be set before this
-# script is called)
 zrot=(zrot+10)%360
 xrot=(xrot+17)%180
-set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
+set view xrot,zrot
 replot
-iteration_count=iteration_count+1
-if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
+reread
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Rightful liberty is unobstructed action, according to our will, within limits
drawn around us by the equal rights of others."
	-- Thomas Jefferson

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> 4.2: Yes, I think I'm wrong there, having a second look.
> 4.6: I think I could go along with your choice on this one as well.

OK.  I'm working on 4.0. I've run into a minor bug in reposurgeon that
I need to fix.

> >I'm going to to do some more analysis on the 3.7 branch, but the odds
> >that we'll have to write it off look pretty high.
> 
> I'll look at this a bit more.  For those with historical knowledge, I'm
> going to write some checkin comments here that come from searching,

I'll want those to patch in, of course.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: 5.2-stable regression for log axes still not fixed completely

[Ethan A M. <sf...@us...>]

On Wednesday, October 25, 2017 12:47:37 PM PDT Achim Gratz wrote:
> Achim Gratz writes:
> > I don't really know what I'm doing, but this patch seems to fix this
> > issue.  I don't know if it causes a regression somewhere else.
> 
> I#ve got a PM from Ethan about my patch, but my answer did not seem to
> have reached him.

I was deferring action because of the freeze on cvs/git commits,
but I was planning to include a fix for this in 5.2.1 tarball even it 
doesn't hit the source repository until the cvs->git conversion completes.
 
> One concern was about my patch ignoring the axis range.  If I'm reading
> the code correctly, that was taken care of a few lines earlier in the
> code when start was getting set to just below the min of the axis.

The code is confusing, but it is easy enough to test what happens.
What I see is that with your patch "as is" the first x-axis tic mark does
not change as I gradually extend the lower end range on x.
I added a while loop to push the start point for tic generation back
past the lower limit. Note that the tic placement code will simply 
ignore tics that are out of range, so placing the start point a bit
lower than strictly necessary does not hurt. 

> THe other question was about what this is trying to achieve: This is
> about specifying a log series with undefined start and end, working on
> an axis which has later been set up to have a defined range whose ends
> do not coincide with the major tics.  Since the axis can start before
> the first major tic inside its range, you must define the start to be
> the first correct position just outside the axis min or the minor tics
> that still lie inside the range are not visible.

Right. 
I'll send you a copy of the patch and/or a preliminary tarball offline
if you like.

	Ethan


> Regards,
> Achim.

Re: Update on the branch surgery

[Daniel J S. <dan...@ie...>]

On 10/25/2017 12:16 PM, Eric S. Raymond wrote:
[snip]
> To sum up: everyone agrees on the root points for 5.2, 5.0, 4.0, and 4.4.
> 
> I think Dan made an error locating the 4.2 root point, but I could be
> wrong. We also have differing ideas about the 4.6 root.

4.2: Yes, I think I'm wrong there, having a second look.  I agree that 
the first two commits on trunk and branch having the same version number 
change is slightly odd (root uses the word "Changed" where branch uses 
the word "Bumped"), but different people do things differently. 
However, there are two checkins of the same message: "Jump to version 
4.2, 1st release candidate."  One wouldn't branch off of a point and use 
the same message for the first change.  So the branch point is

Author: Hans-Bernhard Broeker <xxxxxx@xxxxxx>
Date:   Sun Oct 1 14:11:58 2006 +0200
     Reorganize top-level configuration of automake and autoconf...
     ...to allow version-testing automake.

4.6: I think I could go along with your choice on this one as well.  It 
looks to me that Ethan first prepped for the branch by updating dates in 
the checkin "*** empty log message ***", but didn't change the actual 
version number at that time.  Bifurcating at this point would have the 
updated version number on the 4.6 branch as the first change, whereas 
the trunk's first change is continued development and nothing to do with 
version number.  I was looking for a common pattern of branching I 
guess, but as noted different people do things differently.  So, yeah, 
the branch point is

*** empty log message ***
Ethan A Merritt<xxxxxx@xxxxxx>
11/21/11 11:08 PM

but note that this author date (not commit date) is 11/21 where the 
previous change is 11/22.  The commit date (11/23 or 11/24 depending on 
time zone) seems to be in order though.


> I'm going to to do some more analysis on the 3.7 branch, but the odds
> that we'll have to write it off look pretty high.

I'll look at this a bit more.  For those with historical knowledge, I'm 
going to write some checkin comments here that come from searching, but 
only those that seem like they could give a clue about when the first 
branch was done.  (I'm using qgit, which has some nice searching and 
file features.)  Let me know if they ring a bell:

"branch"
New function gp_strdup, from cvs MAIN branch.
Updated from cvs MAIN branch
New files from my branched-off 'monster patch'
Merged the pm3d branch back to MAIN
Merge axis-branch into MAIN. Lots of changes all over the places
a few changes after merging the axis branch
make the branched version compile under OS/2
Updated from aquaterm cvs bugfix branch.

"merge"
Final fixes for merger.
Update from current automake (lost in merge).
Some cleanups/fixes after the merge.

Dan

Re: 5.2-stable regression for log axes still not fixed completely

[Achim G. <Str...@ne...>]

Achim Gratz writes:
> I don't really know what I'm doing, but this patch seems to fix this
> issue.  I don't know if it causes a regression somewhere else.

I#ve got a PM from Ethan about my patch, but my answer did not seem to
have reached him.

One concern was about my patch ignoring the axis range.  If I'm reading
the code correctly, that was taken care of a few lines earlier in the
code when start was getting set to just below the min of the axis.

THe other question was about what this is trying to achieve: This is
about specifying a log series with undefined start and end, working on
an axis which has later been set up to have a defined range whose ends
do not coincide with the major tics.  Since the axis can start before
the first major tic inside its range, you must define the start to be
the first correct position just outside the axis min or the minor tics
that still lie inside the range are not visible.



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

Ethan A Merritt <sf...@us...>:
> The logical branch point for branch-4-2-stable would have been immediately 
> before the 2006-10-01 "jump to version 4.2" commit.
> e18d4e5da418c2ad5a98a2aff3237088aeee01c8
> 
> I don't know whether the "branch point" terminology used by git
> refers to the last common ancester or the first commit after divergence.
> Looks like "jump to version 4.2" is the latter (first commit after split), 
> while "re-organize top level configuration" is the former (last common 
> ancestor).

Yes, that is how I have rearranged the tree.

Usually, "branch point" refers to the common ancestor.  But it is wise to be
careful about this, as noyt all usage is consistent.

I'm working on 4.0 now.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Update on the branch surgery

[Ethan A M. <sf...@us...>]

On Wednesday, October 25, 2017 10:16:29 AM PDT Eric S. Raymond wrote:
> 4.2:
> 
>     HBB:
> >	branch-4-2-stable:1.2224.0.2
> >
> >revision 1.2224
> >date: 2006/10/01 12:11:58;  author: broeker;  state: Exp;  lines: +15 -7
> >branches:  1.2224.2;
> >Reorganize top-level configuration of automake and autoconf to allow
> >version-testing automake.
> 
>     Dan:
> >[10/1/06 10:17 AM] Child: Jump to version 4.2, 1st release candidate.
> >git -C branch_reference checkout
> >e14ada2e7b0ae4f80d8abeffb5a27d8587a3bbed ---
> >MY BEST GUESS AT THE BRANCH POINT IS:
> >commit e18d4e5da418c2ad5a98a2aff3237088aeee01c8
> >Author: Hans-Bernhard Broeker <xxxxxx@xxxxxx>
> >Date:   Sun Oct 1 17:11:57 2006 +0200
> >
> > Jump to version 4.2, 1st release candidate.
> >
> >git -C root_reference checkout e18d4e5da418c2ad5a98a2aff3237088aeee01c8
> >diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"|
> >grep -v "^---" | wc -l
> >diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"|
> >grep -v "^+++" | wc -l
> >2 + 2
> >---
> >In this case HBB specifically made a note about branching.
> 
>     I think Dan got this one wrong; /Jump to version 4.2/ looks to me
>     like branch first commit, not the root point (see the digram).
> 
>     Matters are slightly complicated by the fact that that content
>     matches to two different commits.
> 
>     2006-10-01T15:17:17Z  :3688 Jump to version 4.2, 1st release
> candidate. 2006-10-01T15:11:57Z :22184 Jump to version 4.2, 1st release
> candidate.
> 
>     The later one looks like a manual merge onto the mainline, so I
>     have rooted the earlier one to /Reorganize top-level configuration/.

The logical branch point for branch-4-2-stable would have been immediately 
before the 2006-10-01 "jump to version 4.2" commit.
e18d4e5da418c2ad5a98a2aff3237088aeee01c8

I don't know whether the "branch point" terminology used by git
refers to the last common ancester or the first commit after divergence.
Looks like "jump to version 4.2" is the latter (first commit after split), 
while "re-organize top level configuration" is the former (last common 
ancestor).

	Ethan

Update on the branch surgery

[<es...@th...>]

I have successfully transplanted the 5.0, 4.6. and 4.4 stable
branches.

Daniel Sebald says:
>First, that oldest branch I couldn't make sense of and I think it actually may
>be bogus.  Rather, it might be that those 3.x series commits should actually
>be mixed in with the master branch.  We'll come back to this one.

I agree, the 3.7 branch may be unsalvageable.  HBB tells me:

>3.7.1 has one check-in to ChangeLog that's tagged but not tarred, and an extra
>pair of quotes around a line in configure.in that tarred but not tagged:

But that's the last thing we need to tackle - rerooting the 4.2 and
4.0 branches comes first.

Here's what HBB and Dan think about the root points:

5.2:

    HBB:
    >	branch-5-2-stable:1.6034.0.2
    >revision 1.6034
    >date: 2017/05/22 05:05:26;  author: sfeam;  state: Exp;  lines: +5 -4170
    >branches:  1.6034.2;
    >Tag branchpoint for 5.2;  Split off entries prior to 2016-02-07 into
    >ChangeLog.5

    Dan didn't weigh in on this one.  It doesn't need to be rerooted;
    the tag set was, apparently, complete and the join was not
    displaced.

5.0:

    HBB:
    >	branch-5-0-stable:1.5023.0.2
    >revision 1.5023
    >date: 2014/08/20 04:42:44;  author: sfeam;  state: Exp;  lines: +6 -0
    >branches:  1.5023.2;
    >Empirical adjustments to dashlength calculated as a function of linewidth

    Dan:
    >[8/20/14 1:37 PM] Child: Start of separate branch for version 5 stable
    >releases
    >git -C branch_reference checkout 66a787634452661f02d7997a2a780165a89cedf0
    >---
    >MY BEST GUESS AT THE BRANCH POINT IS:
    >commit 9c68a0d5f752801b536c03694cceb8e66b1122cc
    >Author: Ethan A Merritt <merritt@u.washington.edu>
    >Date:   Tue Aug 19 21:42:44 2014 -0700
    >   Empirical adjustments to dashlength calculated as a function of linewidth

    Ethan has confirmed that this is the correct branch point for
    5-0-stable. So everybody agrees.

4.6:

    HBB:
    >branch-4-6-stable:1.3943.0.2
    >revision 1.3943
    >date: 2011/11/22 22:35:30;  author: sfeam;  state: Exp;  lines: +3 -0
    >branches:  1.3943.2;
    >Try to allow for coordinate offset caused by scrolling (Firefox, Opera,
    >chrome?)

    Dan:
    >[11/21/11 11:26 PM] Child: Bump stable version to 4.6; patchlevel is "alpha"
    >git -C branch_reference checkout 88ccf09ba5b9f6042d7f2911dc1be6ae7a9aa308
    >---
    >MY BEST GUESS AT THE BRANCH POINT IS:
    >commit df14294df51035145dc7c5391d603b0d452bcd20
    >Author: Ethan A Merritt <merritt@u.washington.edu>
    >Date:   Tue Nov 22 21:12:06 2011 -0800
    >    update Bruce Ravel's contact info
    >git -C root_reference checkout df14294df51035145dc7c5391d603b0d452bcd20
    >diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| grep
    >-v "^---" | wc -l
    >diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| grep
    >-v "^+++" | wc -l
    >13 + 18
    >---
    >The branch-to-master diff with this is includes:
    >
    >diff -ur '--exclude=.git' root_reference/ChangeLog branch_reference/ChangeLog
    >--- root_reference/ChangeLog    2017-10-24 21:39:21.267669735 -0500
    >+++ branch_reference/ChangeLog  2017-10-24 21:31:56.447665382 -0500
    >@@ -1,5 +1,10 @@
    > 2011-11-22  Ethan A Merritt  <xxxxxx@xxxxxx>
    >
    >+       * Branchpoint for 4.6
    >+       cvs tag -b branch-4-6-stable
    >+
    >+2011-11-22  Ethan A Merritt  <xxxxxx@xxxxxx>
    >+
    >and the first branch on master after this includes:
    >
    >diff --git a/ChangeLog b/ChangeLog
    >index 90a47dc..d5670d7 100644
    >--- a/ChangeLog
    >+++ b/ChangeLog
    >@@ -1,5 +1,9 @@
    > 2011-11-22  Ethan A Merritt  <merritt@u.washington.edu>
    >
    >+       * Branchpoint for 4.6 (cvs tag -b branch-4-6-stable)
    >+
    >+2011-11-22  Ethan A Merritt  <merritt@u.washington.edu>
    >+
    >
    >but the version number is kept at 4.5.

    Dan's and HBB's choices are separated by only one commit in the
    sequence, which looks like this:

    2011-11-22T20:41:15Z :32059 Honor numeric locale when formatting contour lab
    2011-11-22T22:35:32Z :32062 Try to allow for coordinate offset caused by scr
    2011-11-22T05:26:43Z :32071 Bump stable version to 4.6;  patchlevel is "alph
    2011-11-23T05:12:06Z :34067 update Bruce Ravel's contact info
    2011-11-22T05:08:36Z :34073 *** empty log message ***
    2011-11-24T22:59:11Z :34075 LT_SINGLECOLOR flags explicit surface color

    I actually wouldn't be surprised if the right root point turned out to
    be the one in the middle - /Bump stable version to 4.6/. Perhaps Ethan
    can clear up which one of these is right.

    Note: Changing this in the conversion script is really trivial.  The
    relevant command sequence is

    # The 4.6 branch:
    /Try to allow for coordinate offset caused by/ assign v46root --singleton
    /Bump stable version to 4.6;/ assign bump46 --singleton
    <v46root>,<bump46> reparent --useorder --rebase

    All I have to do to change the root point is edit the
    selection expression in the first line.

4.4:

    HBB:
    >	branch-4-4-stable:1.3134.0.2
    >revision 1.3134
    >date: 2009/05/31 19:20:09;  author: sfeam;  state: Exp;  lines: +5 -0
    >branches:  1.3134.2;
    >Update

    Dan:
    >[5/30/09 7:30 PM] Child: Start branch for Release 4.4
    >git -C branch_reference checkout e3ff538655e5b5888d9aa60b63398fc62847e46f
    >---
    >MY BEST GUESS AT THE BRANCH POINT IS:
    >commit 65b26b2a31b4de73417d746abe96561b4655c699
    >Author: Ethan A Merritt <merritt@u.washington.edu>
    >Date:   Sat May 30 12:20:09 2009 -0700
    >    Update
    >git -C root_reference checkout 65b26b2a31b4de73417d746abe96561b4655c699
    >diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| grep
    >-v "^---" | wc -l
    >diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| grep
    >-v "^+++" | wc -l
    >1 + 8
    >---
    >The diff includes the following:
    >diff -ur '--exclude=.git' root_reference/ChangeLog branch_reference/ChangeLog
    >--- root_reference/ChangeLog    2017-10-24 21:16:50.131656512 -0500
    >+++ branch_reference/ChangeLog  2017-10-24 21:00:03.367646659 -0500
    >@@ -1,5 +1,10 @@
    > 2009-05-31  Ethan A Merritt  <xxxxxx@xxxxxx>
    >
    >+       Start branch for Release 4.4
    >+       Set VERSION to 4.4   PATCHLEVEL to alpha
    >+
    >+2009-05-31  Ethan A Merritt  <xxxxxx@xxxxxxx>
    >+
    >
    >and the first checkin after that is called "Branch point for version 4.4".
    >Although that message would suggest it's the branchpoint, it actually has
    >+       New stuff, i.e. code other than bugfixes or things identified as
    >+       being desireable for version 4.4, should be commited in the
    >+       development branch only (this one).
    >+
    >+       Bugfixes should be applied to both the development branch 4.3
    >+       (this one) and the new one (branch-4-4-stable).  When we release
    >+       4.4, we will bump the version number of the development branch to 4.5.
    >which suggests to me that this is the first commit on master after the
    >bifurcation.

    HBB and Dan agree, and that agrees with what I found.

4.2:

    HBB:
    >	branch-4-2-stable:1.2224.0.2
    >revision 1.2224
    >date: 2006/10/01 12:11:58;  author: broeker;  state: Exp;  lines: +15 -7
    >branches:  1.2224.2;
    >Reorganize top-level configuration of automake and autoconf to allow
    >version-testing automake.

    Dan:
    >[10/1/06 10:17 AM] Child: Jump to version 4.2, 1st release candidate.
    >git -C branch_reference checkout e14ada2e7b0ae4f80d8abeffb5a27d8587a3bbed
    >---
    >MY BEST GUESS AT THE BRANCH POINT IS:
    >commit e18d4e5da418c2ad5a98a2aff3237088aeee01c8
    >Author: Hans-Bernhard Broeker <xxxxxx@xxxxxx>
    >Date:   Sun Oct 1 17:11:57 2006 +0200
    >    Jump to version 4.2, 1st release candidate.
    >git -C root_reference checkout e18d4e5da418c2ad5a98a2aff3237088aeee01c8
    >diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"| grep
    >-v "^---" | wc -l
    >diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"| grep
    >-v "^+++" | wc -l
    >2 + 2
    >---
    >In this case HBB specifically made a note about branching.

    I think Dan got this one wrong; /Jump to version 4.2/ looks to me
    like branch first commit, not the root point (see the digram).

    Matters are slightly complicated by the fact that that content
    matches to two different commits.  

    2006-10-01T15:17:17Z  :3688 Jump to version 4.2, 1st release candidate.
    2006-10-01T15:11:57Z :22184 Jump to version 4.2, 1st release candidate.

    The later one looks like a manual merge onto the mainline, so I
    have rooted the earlier one to /Reorganize top-level configuration/.

4.0:

    HBB:
    >	branch-4-0-stable:1.1148.0.2
    >revision 1.1148
    >date: 2004/07/02 05:03:29;  author: sfeam;  state: Exp;  lines: +4 -0
    >branches:  1.1148.2;
    >#include gp_time.h

    Dan:
    >[7/7/04 12:34 PM] Child: Bugfix: Incorrect brace movement cause lost key
    >presses.
    >git -C branch_reference checkout 536b2f37fdc8438459e7c7b0f44132fcd2204114
    >---
    >MY BEST GUESS AT THE BRANCH POINT IS:
    >commit 093383fb4f9250b58d832fb10e581d90f48abb9c
    >Author: Ethan Merritt <xxxxxx@xxxxxx>
    >Date:   Wed Jun 30 22:03:30 2004 -0700
    >    #include gp_time.h
    >git -C root_reference checkout 093383fb4f9250b58d832fb10e581d90f48abb9c
    >diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"| grep
    >-v "^---" | wc -l
    >diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"| grep
    >-v "^+++" | wc -l
    >23 + 10
    >---
    >The distance being quite small and the commit in master after this is
    >"Renumbered head trunk version to 4.1.0", which is likely the first commit
    >after the bifurcation.  Note that Jun 30 is a ways from July 7, but that first
    >commit on the new branch is a fix that Ethan also wanted to include in the
    >stable release branch.

    OK, we have agreement here.

To sum up: everyone agrees on the root points for 5.2, 5.0, 4.0, and 4.4.

I think Dan made an error locating the 4.2 root point, but I could be
wrong. We also have differing ideas about the 4.6 root.

I'm going to to do some more analysis on the 3.7 branch, but the odds
that we'll have to write it off look pretty high.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Rightful liberty is unobstructed action, according to our will, within limits
drawn around us by the equal rights of others."
	-- Thomas Jefferson

Re: Successful branch-5-0-stable transplant

[Daniel J S. <dan...@ie...>]

On 10/24/2017 10:10 PM, Daniel J Sebald wrote:
> I'm going to look at that oldest branch and try to make sense of it.  As 
> I said before, I think that all of those checkins, which few if any seem 
> to have a counter-part in the root branch (as typically Ethan would do 
> with bug fixes across root and release branches).

I looked at this unresolved branch earlier this evening.  Within the 
branch itself there are no glaring "jumps", i.e., very large numbers of 
files that change.  I still can't resolve that root for "Windows 
linestyle fix."  From the cvs repository, here are the files that should 
have changed, the number of lines that changed, and the date it was changed:

=============================================================================

RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgnuplib.h,v
Working file: win/wgnuplib.h
head: 1.6
branch:
locks: strict
access list:
symbolic names:
	GNUPLOT_RELEASE_3_7_3: 1.4.2.2
	GNUPLOT_RELEASE_3_7_2: 1.4.2.2
	pre-macport: 1.4.2.2
	GNUPLOT_37_20000507: 1.4.2.2
	GNUPLOT_RELEASE_3_7_1: 1.4.2.2
	GNUPLOT_RELEASE_19991103: 1.4.2.2
	branch-pre-3-7-1: 1.4.0.2
[snip, none of these matches 1.4.2.1
----------------------------
revision 1.4.2.1
date: 1999/08/19 14:13:09;  author: lhecking;  state: Exp;  lines: +4 -1
Windows linestyle fix.
=============================================================================

=============================================================================

RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgraph.c,v
Working file: win/wgraph.c
head: 1.7
branch:
locks: strict
access list:
symbolic names:
	GNUPLOT_RELEASE_3_7_3: 1.5.2.2
	GNUPLOT_RELEASE_3_7_2: 1.5.2.2
	pre-macport: 1.5.2.2
	GNUPLOT_37_20000507: 1.5.2.2
	GNUPLOT_RELEASE_3_7_1: 1.5.2.1
	GNUPLOT_RELEASE_19991103: 1.5.2.1
	branch-pre-3-7-1: 1.5.0.2
[snip, there's a 1.5.2.1 for GNUPLOT_RELEASE_3_7_1 and 
GNUPLOT_RELEASE_19991103]
----------------------------
revision 1.5.2.1
date: 1999/08/19 14:13:09;  author: lhecking;  state: Exp;  lines: +12 -1
Windows linestyle fix.
=============================================================================

I've done comparisons for checkout's around 1999/08/19 and I don't see 
anything near only a dozen lines changed.  They are all above 1000 lines 
changed relative to the "Windows linestyle fix." version, and the diff 
shows no change for the two files listed above.

I could write a script that will do a comparison against every version. 
The git checkout commands are actually quite fast (fraction of a second) 
so it wouldn't take too long to compare against all versions, but I have 
a feeling there is an issue with the way the branches are constructed 
near the start of the repository.

The one odd thing that stands out is the following kind of pattern at 
the start of CVS files:

----------------------------
revision 1.1
date: 1998/04/15 19:16:26;  author: lhecking;  state: Exp;
branches:  1.1.1;
Initial revision
----------------------------
revision 1.1.1.2
date: 1998/04/15 19:21:47;  author: lhecking;  state: Exp;  lines: +107 -14
Import of beta 343.
----------------------------
revision 1.1.1.1
date: 1998/04/15 19:16:26;  author: lhecking;  state: Exp;  lines: +0 -0
Initial import of beta340.
----------------------------

In the git repository I do not see any changesets listed "Initial revision".

There is this entry that starts the master/trunk:

*** empty log message ***
Lars Hecking<lhe...@nm...>
4/15/98 2:21 PM
Initial import of beta340.
Include stdfn.h.
master (Remove all RCS/CVS cookies.)
origin/master (Remove all RCS/CVS cookies.)
origin/branch-5-2-stable (Release 5.2.1)
3.5 (Content from gnuplot-3.5.tar.gz)
4.0.2 (Massive change to all C sources:)

That trunk is branching from "3.5 (Content from gnuplot-3.5.tar.gz)" 
while all the others branch from "Import of beta 347.".  I wonder if the 
"Initial revision" files should have come ahead of all the "Import ..." 
changes.  For example, above both

revision 1.1
revision 1.1.1.1

have the same date/time stamp, which could lead to an arbitrary choice. 
Not sure what the issue is, but I'm confused about "Initial revision" 
not showing up as a changeset anywhere.

Dan

Re: Successful branch-5-0-stable transplant

[Daniel J S. <dan...@ie...>]

Here are my best guesses for the remaining branches (sans that oldest 
branch).

[5/30/09 7:30 PM] Child: Start branch for Release 4.4
git -C branch_reference checkout e3ff538655e5b5888d9aa60b63398fc62847e46f
---
MY BEST GUESS AT THE BRANCH POINT IS:
commit 65b26b2a31b4de73417d746abe96561b4655c699
Author: Ethan A Merritt <merritt@u.washington.edu>
Date:   Sat May 30 12:20:09 2009 -0700
     Update
git -C root_reference checkout 65b26b2a31b4de73417d746abe96561b4655c699
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
1 + 8
---
The diff includes the following:
diff -ur '--exclude=.git' root_reference/ChangeLog 
branch_reference/ChangeLog
--- root_reference/ChangeLog	2017-10-24 21:16:50.131656512 -0500
+++ branch_reference/ChangeLog	2017-10-24 21:00:03.367646659 -0500
@@ -1,5 +1,10 @@
  2009-05-31  Ethan A Merritt  <xxxxxx@xxxxxx>

+	Start branch for Release 4.4
+	Set VERSION to 4.4   PATCHLEVEL to alpha
+
+2009-05-31  Ethan A Merritt  <xxxxxx@xxxxxxx>
+

and the first checkin after that is called "Branch point for version 
4.4".  Although that message would suggest it's the branchpoint, it 
actually has
+	New stuff, i.e. code other than bugfixes or things identified as
+	being desireable for version 4.4, should be commited in the
+	development branch only (this one).
+
+	Bugfixes should be applied to both the development branch 4.3
+	(this one) and the new one (branch-4-4-stable).  When we release
+	4.4, we will bump the version number of the development branch to 4.5.
which suggests to me that this is the first commit on master after the 
bifurcation.


[11/21/11 11:26 PM] Child: Bump stable version to 4.6; patchlevel is "alpha"
git -C branch_reference checkout 88ccf09ba5b9f6042d7f2911dc1be6ae7a9aa308
---
MY BEST GUESS AT THE BRANCH POINT IS:
commit df14294df51035145dc7c5391d603b0d452bcd20
Author: Ethan A Merritt <merritt@u.washington.edu>
Date:   Tue Nov 22 21:12:06 2011 -0800
     update Bruce Ravel's contact info
git -C root_reference checkout df14294df51035145dc7c5391d603b0d452bcd20
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
13 + 18
---
The branch-to-master diff with this is includes:

diff -ur '--exclude=.git' root_reference/ChangeLog 
branch_reference/ChangeLog
--- root_reference/ChangeLog    2017-10-24 21:39:21.267669735 -0500
+++ branch_reference/ChangeLog  2017-10-24 21:31:56.447665382 -0500
@@ -1,5 +1,10 @@
  2011-11-22  Ethan A Merritt  <xxxxxx@xxxxxx>

+       * Branchpoint for 4.6
+       cvs tag -b branch-4-6-stable
+
+2011-11-22  Ethan A Merritt  <xxxxxx@xxxxxx>
+

and the first branch on master after this includes:

diff --git a/ChangeLog b/ChangeLog
index 90a47dc..d5670d7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
  2011-11-22  Ethan A Merritt  <merritt@u.washington.edu>

+	* Branchpoint for 4.6 (cvs tag -b branch-4-6-stable)
+
+2011-11-22  Ethan A Merritt  <merritt@u.washington.edu>
+

but the version number is kept at 4.5.


[8/20/14 1:37 PM] Child: Start of separate branch for version 5 stable 
releases
git -C branch_reference checkout 66a787634452661f02d7997a2a780165a89cedf0
---
MY BEST GUESS AT THE BRANCH POINT IS:
commit 9c68a0d5f752801b536c03694cceb8e66b1122cc
Author: Ethan A Merritt <merritt@u.washington.edu>
Date:   Tue Aug 19 21:42:44 2014 -0700
     Empirical adjustments to dashlength calculated as a function of 
linewidth
git -C root_reference checkout 9c68a0d5f752801b536c03694cceb8e66b1122cc
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
4987 + 10
---
The reason there is such a big difference here is that Ethan, when 
creating this branch, removed all the old FSF messages from the 
ChangeLog except for these two:
diff -ur '--exclude=.git' root_reference/ChangeLog 
branch_reference/ChangeLog
--- root_reference/ChangeLog    2017-10-24 21:59:55.967681819 -0500
+++ branch_reference/ChangeLog  2017-10-24 21:57:35.439680444 -0500
@@ -1,3 +1,7 @@
+2014-08-20  Ethan A Merritt  <merritt@u.washington.edu>
+
+       * Branchpoint for 5.0 (cvs tag -b branch-5-0-stable)
+
  2014-08-20 Ethan A Merritt  <merritt@u.washington.edu>

         * src/wxterminal/gp_cairo.c:  Distinct empirical scale factors for
@@ -1327,4985 +1331,4 @@

         >>>>> Bump version to 5.0 alpha <<<<<

and the first checkin on the root/master branch after the bifurcation 
was to change the release notes:
diff --git a/RELEASE_NOTES b/RELEASE_NOTES
index a08b981..3b77b8c 100644
--- a/RELEASE_NOTES
+++ b/RELEASE_NOTES
@@ -1,274 +1,6 @@
-		GNUPLOT VERSION 5.0.rc1 RELEASE NOTES
-		=====================================
+		GNUPLOT VERSION 5.1 NOTES
+		=========================


I'm going to look at that oldest branch and try to make sense of it.  As 
I said before, I think that all of those checkins, which few if any seem 
to have a counter-part in the root branch (as typically Ethan would do 
with bug fixes across root and release branches).

Dan


On 10/24/2017 08:22 PM, Daniel J Sebald wrote:
> On 10/24/2017 08:00 PM, Eric S. Raymond wrote:
>> I am pleased to report that the first branch rerooting -
>> branch-5-0-stable - has worked (head content is identical to CVS) and
>> have been incorporated into the reconvert script.
>>
>> One down, five to go.
> 
> I've been looking at this a little bit using the diff utility, but it 
> requires some inference from the checkin comments to project backward a 
> little further than the first commits in a branch.  Without going into 
> detail, I'll tell you what I have so far that might speed things for a 
> couple other branches.
> 
> First, that oldest branch I couldn't make sense of and I think it 
> actually may be bogus.  Rather, it might be that those 3.x series 
> commits should actually be mixed in with the master branch.  We'll come 
> back to this one.
> 
> [7/7/04 12:34 PM] Child: Bugfix: Incorrect brace movement cause lost key 
> presses.
> git -C branch_reference checkout 536b2f37fdc8438459e7c7b0f44132fcd2204114
> ---
> MY BEST GUESS AT THE BRANCH POINT IS:
> commit 093383fb4f9250b58d832fb10e581d90f48abb9c
> Author: Ethan Merritt <xxxxxx@xxxxxx>
> Date:   Wed Jun 30 22:03:30 2004 -0700
>      #include gp_time.h
> git -C root_reference checkout 093383fb4f9250b58d832fb10e581d90f48abb9c
> diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"| 
> grep -v "^---" | wc -l
> diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"| 
> grep -v "^+++" | wc -l
> 23 + 10
> ---
> The distance being quite small and the commit in master after this is 
>   "Renumbered head trunk version to 4.1.0", which is likely the first 
> commit after the bifurcation.  Note that Jun 30 is a ways from July 7, 
> but that first commit on the new branch is a fix that Ethan also wanted 
> to include in the stable release branch.
> 
> 
> [10/1/06 10:17 AM] Child: Jump to version 4.2, 1st release candidate.
> git -C branch_reference checkout e14ada2e7b0ae4f80d8abeffb5a27d8587a3bbed
> ---
> MY BEST GUESS AT THE BRANCH POINT IS:
> commit e18d4e5da418c2ad5a98a2aff3237088aeee01c8
> Author: Hans-Bernhard Broeker <xxxxxx@xxxxxx>
> Date:   Sun Oct 1 17:11:57 2006 +0200
>      Jump to version 4.2, 1st release candidate.
> git -C root_reference checkout e18d4e5da418c2ad5a98a2aff3237088aeee01c8
> diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"| 
> grep -v "^---" | wc -l
> diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"| 
> grep -v "^+++" | wc -l
> 2 + 2
> ---
> In this case HBB specifically made a note about branching.
> 
> Dan

YIQ color space palette - fix or remove?

[sfeam <sf...@us...>]

I propose to drop YIQ colorspace from 5.3

When color palette support was merged into gnuplot in 2001, it included
support for RGB HSV CMY YIQ XYZ color spaces.
It may well be that in the intervening 16 years no one has ever
tried to use YIQ.

Bug #1981 points out that it never worked

1) the YIQ_2_RGB() color conversion routine uses incorrect coefficients

2) the permitted range of I is [-.5957:.5957], for Q it is [-.5226:.5226]
but the "set palette" code and the grayscale conversion code truncate
all color components to [0:1] so it is not possible to enter general
YIQ triples

3) the "set palette defined (gray1 R G B, gray2 R G B, ...) syntax cannot
handle negative numbers because the leading - sign would be parsed
as an operator.   E.g.  set palette defined (0 0.5 -0.5 -0.5) is parse as
two numbers rather than four.   That isn't necessarily a fatal flaw since
there are other ways to define a palette, but "defined" does not and can
not work for the full range of YIQ values.

Furthermore the transform provided goes in the wrong direction.
It might make sense to accept YIQ values and produce a grayscale.
That's what black & white television did.   But what use case is there
for providing a grayscale value and converting it to a YIQ triple that
cannot be displayed without subsequenting re-converting it to RGB?

(1) and (2) are fixable.  (3) is not.  
Given that this never worked and as noted it has no obvious
use anyhow, is it OK to simply remove all mention of YIQ support
rather than trying to repair it?

	Ethan

Re: Successful branch-5-0-stable transplant

[Daniel J S. <dan...@ie...>]

On 10/24/2017 08:00 PM, Eric S. Raymond wrote:
> I am pleased to report that the first branch rerooting -
> branch-5-0-stable - has worked (head content is identical to CVS) and
> have been incorporated into the reconvert script.
> 
> One down, five to go.

I've been looking at this a little bit using the diff utility, but it 
requires some inference from the checkin comments to project backward a 
little further than the first commits in a branch.  Without going into 
detail, I'll tell you what I have so far that might speed things for a 
couple other branches.

First, that oldest branch I couldn't make sense of and I think it 
actually may be bogus.  Rather, it might be that those 3.x series 
commits should actually be mixed in with the master branch.  We'll come 
back to this one.

[7/7/04 12:34 PM] Child: Bugfix: Incorrect brace movement cause lost key 
presses.
git -C branch_reference checkout 536b2f37fdc8438459e7c7b0f44132fcd2204114
---
MY BEST GUESS AT THE BRANCH POINT IS:
commit 093383fb4f9250b58d832fb10e581d90f48abb9c
Author: Ethan Merritt <xxxxxx@xxxxxx>
Date:   Wed Jun 30 22:03:30 2004 -0700
     #include gp_time.h
git -C root_reference checkout 093383fb4f9250b58d832fb10e581d90f48abb9c
diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
23 + 10
---
The distance being quite small and the commit in master after this is 
  "Renumbered head trunk version to 4.1.0", which is likely the first 
commit after the bifurcation.  Note that Jun 30 is a ways from July 7, 
but that first commit on the new branch is a fix that Ethan also wanted 
to include in the stable release branch.


[10/1/06 10:17 AM] Child: Jump to version 4.2, 1st release candidate.
git -C branch_reference checkout e14ada2e7b0ae4f80d8abeffb5a27d8587a3bbed
---
MY BEST GUESS AT THE BRANCH POINT IS:
commit e18d4e5da418c2ad5a98a2aff3237088aeee01c8
Author: Hans-Bernhard Broeker <xxxxxx@xxxxxx>
Date:   Sun Oct 1 17:11:57 2006 +0200
     Jump to version 4.2, 1st release candidate.
git -C root_reference checkout e18d4e5da418c2ad5a98a2aff3237088aeee01c8
diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
2 + 2
---
In this case HBB specifically made a note about branching.

Dan

Successful branch-5-0-stable transplant

[<es...@th...>]

I am pleased to report that the first branch rerooting -
branch-5-0-stable - has worked (head content is identical to CVS) and
have been incorporated into the reconvert script.

One down, five to go.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

You know why there's a Second Amendment?  In case the government fails to
follow the first one.
         -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993

Re: Can any of you identify the following people by email address?

[Eric S. R. <es...@th...>]

Hans-Bernhard Bröker <HBB...@t-...>:
> But we should pick _one_ of us to contact them that way.

I've sent them email.

> They have decided not to publish a clear name on those user profile pages,
> though, so I guess it's safe to assume they won't want one shown in our git
> log, either.

I don't think pudh144 or dcb431 are hiding - I was able to identify them with
a bit more web searching.  Laboratory Man, on the other hand, seems to be
trying to stay off the radar.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Can any of you identify the following people by email address?

[Ethan A M. <sf...@us...>]

On Tuesday, October 24, 2017 3:53:26 PM PDT Hans-Bernhard Bröker wrote:
> Am 24.10.2017 um 23:22 schrieb Eric S. Raymond:
> > Can any of you identify the following people by email address?
> > 
> > laboratoryman = Laboratory Man <lab...@us...>
> > pudh4418 = Unknown User <pud...@us...>
> > dcb314 = Unknown User <dc...@us...>
> > wtf3 = Unknown User <wt...@us...>
> > ceprio = Unknown User <ce...@us...>
> > 
> > These addresses appear in ChangeLog files without a human name
> > attached.
> 
> wtf3 is, apparently, a typo in the ChangeLog entry.  That's supposed to
> be "wrf3".
> 
> These are all actual SourceForge user account names, usually from Bugs
> or Patches trackers, so they are supposed to be reachable, if not
> directly at those mail addresses, then via their SourceForge accounts
> pages' "Send Message" feature.  But we should pick _one_ of us to
> contact them that way.  Ethan?

I nominate Dan :-)
 
> They have decided not to publish a clear name on those user profile
> pages, though, so I guess it's safe to assume they won't want one shown
> in our git log, either.  They may have only gotten an SF.net account to
> post those entries, as for most of the time we had to keep our trackers
> restricted to logged-in users.  SPAM, SPAM, lovely SPAM...

Indeed.  But arguably if xxx can be contacted via an sf.net address to
ask who they really are, that by itself demonstrates that  xx...@us... 
is a real contact address.  If that's what they want to use - let them. 

	Ethan

Re: Can any of you identify the following people by email address?

[Hans-Bernhard B. <HBB...@t-...>]

Am 24.10.2017 um 23:22 schrieb Eric S. Raymond:
> Can any of you identify the following people by email address?
> 
> laboratoryman = Laboratory Man <lab...@us...>
> pudh4418 = Unknown User <pud...@us...>
> dcb314 = Unknown User <dc...@us...>
> wtf3 = Unknown User <wt...@us...>
> ceprio = Unknown User <ce...@us...>
> 
> These addresses appear in ChangeLog files without a human name attached.
> 

wtf3 is, apparently, a typo in the ChangeLog entry.  That's supposed to 
be "wrf3".

These are all actual SourceForge user account names, usually from Bugs 
or Patches trackers, so they are supposed to be reachable, if not 
directly at those mail addresses, then via their SourceForge accounts 
pages' "Send Message" feature.  But we should pick _one_ of us to 
contact them that way.  Ethan?

They have decided not to publish a clear name on those user profile 
pages, though, so I guess it's safe to assume they won't want one shown 
in our git log, either.  They may have only gotten an SF.net account to 
post those entries, as for most of the time we had to keep our trackers 
restricted to logged-in users.  SPAM, SPAM, lovely SPAM...

Re: Can any of you identify the following people by email address?

[Daniel J S. <dan...@ie...>]

On 10/24/2017 04:22 PM, Eric S. Raymond wrote:
> Can any of you identify the following people by email address?
> 
> laboratoryman = Laboratory Man <lab...@us...>
> pudh4418 = Unknown User <pud...@us...>
> dcb314 = Unknown User <dc...@us...>
> wtf3 = Unknown User <wt...@us...>
> ceprio = Unknown User <ce...@us...>
> 
> These addresses appear in ChangeLog files without a human name attached.

These look like anonymous contributions from the bug and patch trackers. 
  In order:

https://sourceforge.net/p/gnuplot/patches/236/ (Creator "No one of 
consequence" registered as laboratoryman, stick with "Laboratory Man", 
more superhero-ish)

https://sourceforge.net/p/gnuplot/bugs/1616/ (There's a name in a 
comment but I'm not sure it is the original submission, otherwise 
"pudh4418")

https://sourceforge.net/p/gnuplot/bugs/1584/ (dcb is Creator, someone's 
initials most likely, so perhaps "D C B")

Can't find wtf3 in sourceforge history

https://sourceforge.net/p/gnuplot/patches/731/ ("Ceprio" looks to be 
someone's name, that should work)

Dan

Can any of you identify the following people by email address?

[<es...@th...>]

Can any of you identify the following people by email address?

laboratoryman = Laboratory Man <lab...@us...>
pudh4418 = Unknown User <pud...@us...>
dcb314 = Unknown User <dc...@us...>
wtf3 = Unknown User <wt...@us...>
ceprio = Unknown User <ce...@us...>

These addresses appear in ChangeLog files without a human name attached.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"As to the species of exercise, I advise the gun. While this gives [only]
moderate exercise to the body, it gives boldness, enterprise, and independence
to the mind.  Games played with the ball and others of that nature, are too
violent for the body and stamp no character on the mind. Let your gun,
therefore, be the constant companion to your walks."
        -- Thomas Jefferson, writing to his teenaged nephew.