From xemacs-m  Fri Apr  4 15:59:49 1997
Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id PAA26149
	for <xemacs-beta@xemacs.org>; Fri, 4 Apr 1997 15:59:48 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id NAA28400 for <xemacs-beta@xemacs.org>; Fri, 4 Apr 1997 13:59:49 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id OAA09992; Fri, 4 Apr 1997 14:01:28 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: XEmacs futures (Countdown to 20.1 and possible 19.16)
References: <m2208r57zr.fsf@altair.xemacs.org> <199704041621.LAA23611@anthem.CNRI.Reston.Va.US>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: David Moore <dmoore@ucsd.edu>
Date: 04 Apr 1997 14:01:28 -0800
In-Reply-To: "Barry A. Warsaw"'s message of Fri, 4 Apr 1997 11:21:44 -0500
Message-ID: <rvybay78hz.fsf@sdnp5.ucsd.edu>
Lines: 65
X-Mailer: Gnus v5.4.37/XEmacs 19.15

"Barry A. Warsaw" <bwarsaw@CNRI.Reston.VA.US> writes:

> I dunno, my inclination would be to go full steam ahead with v20 and
> *not* release a 19.16 or patched tarball.  Make life easy for yourself
> and just put up the patch page.  Get the next v20 out the door and
> encourage people to upgrade.

Depends on what "easier" means.  It's really hard to deal with bug
reports on patched systems.  If we're going to have a patch page, why
not let Vinnie make a tar with those patches applied?

Everyone keeps pounding away on 20.1.  Any crashing bugs that are fixed
which are applicable to both can be applied to 19.15.  Potentially other
small "oh shit" bugs for included packages can be applied.  But you
don't add any new packages, you don't stick in the latest & greatest
version of packages, etc.

I seriously thought about volunteering to do a 19.16 like this, as a lot
of the C work I'm currently doing is still on the 19.15 source tree.
But I'd much rather see someone else do it, as my current XEmacs
workspace is designed around someone else doing release control.

I'm really happy that Vinnie is running the patch web page, and it looks
great.  And if he is willing to do a tarball of the patches at
reasonable intervals, I say let him! :)

Everyone on the beta list moves on with their lives to 20.1.  Those
couple weirdos who want to do product support on a dead product can do
so.  At this point, I'm still one of those people, since I have to be in
the 19.15 tree to generate the "official" patches for the web page
anyways.  And if there are going to be patches available, I think I'd
_rather_ see them already applied in a tarball than haphazzardly fetched
from a web page.  At least there, we have a chance to being able to tell
which version bug reports are coming in from.


Summary, since I ramble too much.

1. If we are going to have official patches on a web page, then we might
   as well have a tarball release with them applied.  There is no real
   cost to anyone here.  The patches are there, we've called them
   official, it doesn't hurt to provide them in an already applied
   form.  AND it might be beneficial to us, since we can increment a
   version number.

2. Consider 19.15 dead from the point of view of this list.  This is the
   xemacs-beta list and we should be working on the future.  And that's
   XEmacs 20.  This lets us concentrate our resources, and gets Steve
   and other people out of two source trees.  The few of us who
   currently have need to still be in the 19.15 source tree can arrange
   the patches to 19.15.

3. I wouldn't mind seeing the set of patches collected at some point
   being called 19.16, but I don't think we should worry about that
   now.  Let's let Vinnie and me and whoever else do some 19.15pl# web
   pages and tarballs.  If in a month or two we think that number of
   patches to 19.15 has slowed significantly or that we're all sick of
   trying to support it, we can call the last set 19.16 if there is
   consensus and move on.  If we don't want to call it 19.16, that's
   fine too.

4. If there are political reasons why patched tarballs are going to hurt
   feelings, maybe you can let me know in private email, and I'll shut
   up. :)  Otherwise, I think we should all move on to 20.1 and let some
   other folks potentially handle patch tarballs.

