What the procedure now? Is there a need to provide patches for 6.3, or is
this only done for serious bug? That is new features go only into 6.4 as
usual.

My last minor patch (allowing exec sql vacuum) didn't make it into cvs it
seems. Should this be updated in 6.3 or should I just resubmit with changes
for 6.4?

Michael
-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

Tue, 3 Mar 1998 11:55:39 +0100 (CET)
Michael Meskes <meskes@topsystem.de>
patches now that 6.3 has been released
> What the procedure now? Is there a need to provide patches for 6.3, or is
> this only done for serious bug? That is new features go only into 6.4 as
> usual.
>
> My last minor patch (allowing exec sql vacuum) didn't make it into cvs it
> seems. Should this be updated in 6.3 or should I just resubmit with changes
> for 6.4?

What we did for v6.2.1 which seemed to work pretty well was this:

if a patch can fit into v6.2.1, we wrote it into /pub/patches and updated the
README in the same directory. Of the literally hundreds (thousands?) of
changes for v6.3, there were only ~7 patches posted for v6.2.1 fixes. Of
course, we also submitted the patch separately for the development code tree.

If the patch diverged from a clean v6.2.1 installation, we just submitted it
for the next release and left it at that. I think that _minor_ and obvious bug
fixes could go into the code tree now, and then Marc can choose whether to
include them in any new snapshot releases or on the CDROM. We are holding off
on submitting new work for a week or two, partly to recover from the last few
weeks and partly to see how solid v6.3 is...

                                                          - Tom


Tue, 03 Mar 1998 13:19:16 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] patches now that 6.3 has been released
On Tue, 3 Mar 1998, Michael Meskes wrote:

> What the procedure now? Is there a need to provide patches for 6.3, or is
> this only done for serious bug? That is new features go only into 6.4 as
> usual.

	Correct...v6.4 will be as different from v6.3, as v6.3 was from
v6.2.1...

> My last minor patch (allowing exec sql vacuum) didn't make it into cvs it
> seems. Should this be updated in 6.3 or should I just resubmit with changes
> for 6.4?

	Over time, it gets slightly harder, but if you can, make it a
seperate patch that we can add to the ftp server itself and that ppl can
download. (and, of course, add it in for v6.4 *grin*)




Tue, 3 Mar 1998 08:27:41 -0500 (EST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] patches now that 6.3 has been released
The Hermit Hacker writes:
> 	Over time, it gets slightly harder, but if you can, make it a
> seperate patch that we can add to the ftp server itself and that ppl can
> download. (and, of course, add it in for v6.4 *grin*)

Okay, here's the missing bug fix of two minor bugs. I hope I don't have to
keep both source trees from now on. :-)

diff -rcN interfaces/ecpg/preproc/ecpg.c interfaces/ecpg.mm/preproc/ecpg.c
*** interfaces/ecpg/preproc/ecpg.c	Tue Mar  3 08:29:49 1998
--- interfaces/ecpg.mm/preproc/ecpg.c	Tue Mar  3 11:52:45 1998
***************
*** 58,108 ****
  		/* after the options there must not be anything but filenames */
  		for (fnr = optind; fnr < argc; fnr++)
  		{
! 			char	   *filename,
! 					   *ptr2ext;
! 			int			ext = 0;
  
! 			filename = mm_alloc(strlen(argv[fnr]) + 4);
  
! 			strcpy(filename, argv[fnr]);
  
! 			ptr2ext = strrchr(filename, '.');
! 			/* no extension or extension not equal .pgc */
! 			if (ptr2ext == NULL || strcmp(ptr2ext, ".pgc") != 0)
  			{
! 				if (ptr2ext == NULL)
! 					ext = 1;	/* we need this information a while later */
! 				ptr2ext = filename + strlen(filename);
  				ptr2ext[0] = '.';
  			}
  
- 			/* make extension = .c */
- 			ptr2ext[1] = 'c';
- 			ptr2ext[2] = '\0';
- 
  			if (out_option == 0)/* calculate the output name */
  			{
! 				yyout = fopen(filename, "w");
  				if (yyout == NULL)
  				{
! 					perror(filename);
! 					free(filename);
  					continue;
  				}
  			}
  
- 			if (ext == 1)
- 			{
- 				/* no extension => add .pgc */
- 				ptr2ext = strrchr(filename, '.');
- 				ptr2ext[1] = 'p';
- 				ptr2ext[2] = 'g';
- 				ptr2ext[3] = 'c';
- 				ptr2ext[4] = '\0';
- 				input_filename = filename;
- 			}
- 			else
- 				input_filename = argv[fnr];
  			yyin = fopen(input_filename, "r");
  			if (yyin == NULL)
  				perror(argv[fnr]);
--- 58,102 ----
  		/* after the options there must not be anything but filenames */
  		for (fnr = optind; fnr < argc; fnr++)
  		{
! 			char	   *output_filename, *ptr2ext;
  
! 			input_filename = mm_alloc(strlen(argv[fnr]) + 5);
  
! 			strcpy(input_filename, argv[fnr]);
  
! 			ptr2ext = strrchr(input_filename, '.');
! 			/* no extension? */
! 			if (ptr2ext == NULL)
  			{
! 				ptr2ext = input_filename + strlen(input_filename);
! 				
! 				/* no extension => add .pgc */
  				ptr2ext[0] = '.';
+ 				ptr2ext[1] = 'p';
+ 				ptr2ext[2] = 'g';
+ 				ptr2ext[3] = 'c';
+ 				ptr2ext[4] = '\0';
  			}
  
  			if (out_option == 0)/* calculate the output name */
  			{
! 				output_filename = strdup(input_filename);
! 				
! 				ptr2ext = strrchr(output_filename, '.');
! 				/* make extension = .c */
! 				ptr2ext[1] = 'c';
! 				ptr2ext[2] = '\0';
! 				
! 				yyout = fopen(output_filename, "w");
  				if (yyout == NULL)
  				{
! 					perror(output_filename);
! 					free(output_filename);
! 					free(input_filename);
  					continue;
  				}
  			}
  
  			yyin = fopen(input_filename, "r");
  			if (yyin == NULL)
  				perror(argv[fnr]);
***************
*** 122,128 ****
  					fclose(yyout);
  			}
  
! 			free(filename);
  		}
  	}
  	return (0);
--- 116,123 ----
  					fclose(yyout);
  			}
  
! 			free(output_filename);
! 			free(input_filename);
  		}
  	}
  	return (0);
diff -rcN interfaces/ecpg/preproc/preproc.y interfaces/ecpg.mm/preproc/preproc.y
*** interfaces/ecpg/preproc/preproc.y	Tue Mar  3 08:29:49 1998
--- interfaces/ecpg.mm/preproc/preproc.y	Fri Feb 27 16:56:12 1998
***************
*** 607,613 ****
  /* FIXME: instead of S_SYMBOL we should list all possible commands */
  sqlcommand : S_SYMBOL | SQL_DECLARE;
  
! sqlstatement_words : sqlstatement_word
  		   | sqlstatement_words sqlstatement_word;
  	
  sqlstatement_word : ':' symbol 
--- 607,613 ----
  /* FIXME: instead of S_SYMBOL we should list all possible commands */
  sqlcommand : S_SYMBOL | SQL_DECLARE;
  
! sqlstatement_words : /* empty */
  		   | sqlstatement_words sqlstatement_word;
  	
  sqlstatement_word : ':' symbol 
diff -rcN interfaces/ecpg/test/perftest.pgc interfaces/ecpg.mm/test/perftest.pgc
*** interfaces/ecpg/test/perftest.pgc	Tue Mar  3 08:29:49 1998
--- interfaces/ecpg.mm/test/perftest.pgc	Fri Feb 27 17:01:39 1998
***************
*** 16,21 ****
--- 16,22 ----
  		usec+=1000000;
  	}
  	printf("I needed %ld seconds and %ld microseconds for the %s test.\n", sec, usec, text);
+ 	exec sql vacuum;
  }
  
  int
***************
*** 106,113 ****
  	exec sql drop index number1;
  
  	exec sql drop table perftest1;
- 
- 	exec sql commit;
  
  	return (0);
  }
--- 107,112 ----


Michael

-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

Tue, 3 Mar 1998 14:31:01 +0100 (CET)
Michael Meskes <meskes@topsystem.de>
Re: [HACKERS] patches now that 6.3 has been released