lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Update code and patches "RFC" :)


From: Nelson Henry Eric
Subject: Re: LYNX-DEV Update code and patches "RFC" :)
Date: Mon, 21 Oct 1996 12:36:05 +0900 (JST)

Please pardon arbitrary cutting; the thread is:
> > > >What's the general feeling about updating the version string to 2-6-1?
> > > 
> > >   I think it would be a counterproductive "convenience" at this
> > > time.  You'd be creating a new version without basic issues about how
> > 
> > there all along <g>), I see that at some point we should freeze it at a
> > 2-6-1 as soon as the patches settle down and give a fixed platform from
> 
> It seems that one purpose of freezing this code set is solving some
> user problems.  (The other purpose is giving Lynx developers/ hackers a

From the point of view of a provider of a user service, I would like to
have something tangible to work with.  Will the following work?
     o) Allow Hiram to gather patches together, add tweaks and manually
apply what can't be easily patched, and roll all this together into
a 2-6update1019.zip, as he has done so well up to now.  The date stamp
would correspond to the top date in the CHANGES file which would of
course necessarily go with the update.  If the update were named and
dated in a specific manner, a few other people could offer to mirror
them on their servers to take some load off of Hiram's (and still people
would know who put in all the work).
     o) Once Hiram gets an update together, Subir could clear the slate
on his "unofficial" patch list, and then start from #1 again.  New
patches sent in should be made `diff -c' against the _updated_ code set.
Any patches left over from the last round, like the present #7 and #11
(lucky numbers!), could be moved to a new category like `patches needing
more exercise', and perhaps named rather than numbered.  They could also
be moved to the beginning of the list, e.g. #1 and #2, if they were re-
worked against the updated code set.
     o) When Subir's list of patches gets unwieldy again, Hiram could
do another update, and the cycle would start over again.
     o) People applying Hiram's update and then distributing a complete,
updated code set might want to do what was done before, something like
offering lynx2-6RP (`R'epeatedly `P'atched, until it becomes otherwise),
with reference made to the top date in CHANGES.  This gets around the
version problem.

__Henry
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;



reply via email to

[Prev in Thread] Current Thread [Next in Thread]