Re: It is time for a feature freeze (it is NOW or never).

[Nick Roberts]

 > > Otherwise new features will have no place to go and will quite
 > > likely get bundled in with bug-fixes.
 > 
 > New features can go into branches if really necessary.

By new features, I just mean patches that might break functionality. They
might be too small to justify a separate branch.

 > > Also, from the mailing list archives, I see that a year elapsed
 > > between the first pretest and the release of Emacs 21.1. So I would
 > > like to see a target date for the release so that the "freeze"
 > > doesn't drag on indefinitely.
 >
 > Nope.  There is no point in releasing it before it is ready.  And
 > there is no sense in delaying further once it is ready.

Well, Confucius might say something like that. If there was a nominal date,
developers like Kai, could make a judgement as to whether or not there was
enough time to merge new features of Tramp.

 >                                                         And there is
 > no point in telling a lot of voluntary that they have to deliver on a
 > certain date or lose their non-job.

It would just be something to aim for. I don't remember talking about penalty
clauses. Currently, for all I know, features of GDB needed by gdb-ui.el may
be obsolete before the next Emacs release.

Nick