Re: [PROPOSED] Quicktrack to fixing typos

How do I move to fix the spelling of the word 'document' in a Proposal? 'documentl' sounds like the Austrian diminutive word for document... :) (Couldn't resist...) Nils. In message <[EMAIL PROTECTED]>, Manoj Srivastava writes: >Hi, >>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: > > > Ian

Bug#17621: PROPOSED]: About versions based on dates

Hi, >>"Guy" == Guy Maor <[EMAIL PROTECTED]> writes: Guy> Manoj Srivastava <[EMAIL PROTECTED]> writes: Marco> What about 960501? It's shorter. Marco> (This format has NO Y2K problems.) >> >> Really? When is 010501? Guy> That version would be written as 20010501. Marco was just pointing G

Re: [PROPOSED] Quicktrack to fixing typos

Hi, >>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: Ian> How about instead allowing the change to be made immediately in the Ian> development version, and retracted if anyone objects ? (I agree with Ian> whoever suggested a 3 day objection period.) Sounds good to me How about:

Re: Wanted - Un-SuperCite elisp package

Hi >>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: Ian> Does anyone have a piece of code that can automatically undo Ian> SuperCite ? Supercite? ;-) manoj -- At work, the authority of a person is inversely proportional to the number of pens that person is carrying. Manoj

Re: Wanted - Un-SuperCite elisp package

> "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: Ian> Does anyone have a piece of code that can automatically undo Ian> SuperCite ? SuperCite can undo SuperCite :) I don't know about automatically. -- Brought to you by the letters G and K and the number 3. "He's kissing Christian.

Re: FHS - transition

Quoting Ian Jackson ([EMAIL PROTECTED]): > This is explicitly NOT WHAT WE HAVE PROMISED OUR USERS. > > For years, we have promised them INCREMENTAL UPGRADEABILITY. We broke > that promise in 2.0, and I hope we never break it again. > > It is IMO _essential_ that a user can take a single package o

Re: FHS - transition

Charles Briscoe-Smith writes ("Re: FHS - transition"): > Ian Jackson wrote: ... > > * will require upgrade of many packages for forward compatibility. > > How many browsers are in use on each machine? How many machines are > upgraded one package at a time? (I suspect most are upgraded lock, stoc

Re: FHS - transition

Manoj Srivastava writes ("Re: FHS - transition"): > Ian Jackson <[EMAIL PROTECTED]> writes: > > To my mind, a flag day is a point in time when the entire universe > > must change simultaneously, or at least across which mechanisms do not > > interoperate. I feel that a flag day necessarily occurs

Wanted - Un-SuperCite elisp package

Does anyone have a piece of code that can automatically undo SuperCite ? Ian.

Re: FHS - transition

Hamish Moffatt writes ("Re: FHS - transition"): > On Thu, Oct 22, 1998 at 07:40:15PM -0300, Nicolás Lichtmaier wrote: > > The main point are: `Do things in a way that old programs would still > > work.' You can't know what weird setup a user is trying to use, perhaps he > > has a custom CGI script

Re: [PROPOSED] Quicktrack to fixing typos

Manoj Srivastava writes ("[PROPOSED] Quicktrack to fixing typos "): > Ok, how about this. I have provided a small period so that the > mailing list can exercise control, while still making it possible to > quickly correct small errors. > > =

Re: FWD: Bug#22007: [PROPOSED] Fixing of typo in packaging manual

Manoj Srivastava writes ("Re: FWD: Bug#22007: [PROPOSED] Fixing of typo in packaging manual"): > Hi, ... > I would agree, if this were extended to all the maintainers of > the policy packages (does not seem fair to single out just me from > the team). The current list of maintainers, who

Re: RfD: Policy of .sh boot scripts

Nicolás Lichtmaier writes ("Re: RfD: Policy of .sh boot scripts"): > It'd like to add this: > > These scripts should not depend on having correct settings in the PATH > variable. I disagree strongly. ALL scripts should use the value of the PATH variable they inherit (except some very special o

Re: Bug#17621: [PROPOSED]: About versions based on dates

* Md => Marco d'Itri Md> What about 960501? It's shorter. (This format has NO Y2K Md> problems.) I'd bet 000501 is earlier to dpkg than 990501. ;-) Regards, -- Davide G. M. Salvetti - IW5DZC [JN53fr] -

Re: Bug#17621: [PROPOSED]: About versions based on dates

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Marco> What about 960501? It's shorter. > Marco> (This format has NO Y2K problems.) > > Really? When is 010501? That version would be written as 20010501. Marco was just pointing out that abbreviating 19xx as xx doesn't always cause y2k pr

Re: Bug#17621: [PROPOSED]: About versions based on dates

Manoj Srivastava wrote: > At least we agree about new packages ;-) About older packages, > I am not sure. I think a single epoch, followed by sane dates, would > not really confuse people, and limit things to just one epoch, and > that having consistent date-formatted names is a big enough

Re: Bug#17621: [PROPOSED]: About versions based on dates

Hi >>"Marco" == Marco d'Itri <[EMAIL PROTECTED]> writes: Marco> On Oct 30, Manoj Srivastava <[EMAIL PROTECTED]> wrote: >> To prevent having to use epochs for every new upstream version, the >> version number should be changed to the following format in such >> cases: `1996-05-01', `1996-12-24'