Releases of jedmodes

[G. Milde]

On 27.05.06, Jörg Sommer wrote:
> Hello Paul,
> 
> Paul Boekholt schrieb am Sat 27. May, 12:41 (+0200):
> > On Fri, 26 May 2006 18:15:52 +0200, Jörg Sommer <joerg at alea.gnuu.de> said:
> > 
> > > after some experiences with the pre-release of the jedmodes archive I
> > > would prefer to have static archive which we can use to setup the
> > > package. The forward and backward of patches and other problems eats up
> > > time. One day you find a bug and create a dpatch, the next day the bug is
> > > fixed in the upstream release.
> > 
> > As Günter pointed out, you can just send the patch to the upstream
> > maintainer, and he'll apply the patch upstream, or he'll tell you why
> > it's not a bug and you can dpatch it downstream if you want to, it won't
> > be fixed upstream and certainly not the next day.
> 
> If refered to the cvs conflict marks and patches like ding. I've ever
> thought we can shorten the way of reporting bugs against your's and
> Günther's modes, because your on the list. But if it's not so, next time
> you get a bug report.

Thanks a lot. I have to fix the source at Jedmodes anyway (if the bug is
real), so these dpatches are eating my time too.

Also, a bug report is faster to read, understand and react to than a
commit report about an undocumented dpatch.

---------

> > Missing autoloads are not a bug BTW, the autoload would itself become
> > a bug if the autoloaded function moves to another file.
> 
> If your mode is not loadable without additive actions it's a bug. The
> mode does not run and I would not request the users to find out what
> should they load before the can use a mode. 

Principally, a mode that doesnot evaluate "out of the box" is a bug
in the jed-extra package (not necessarily in the mode, if adequate
documentation is provided).

However, this is not the case for the X modes in jed-extra/extra. These
are not in the jed library path by default and the documentation clearly
states that they:

  * are experimental or exotic
  * may require additional configuration from the users part

(if this did not come out clearly, README.Debian needs to be improved).

We have the following conflict between usability and non-invasiveness:

  Modes in jed-extra/, jed-extra/utils and jed-extra/drop-in should
  (IMO) run without change in the default configuration of jed-extra.

  Leaving autoload() definitions to jed-extra/utils/ini.sl can save a lot
  of hazzle, code duplication and maintaining work (e.g. if a mode
  definition is moved to some other place in the Jed standard library).

but
 
  Evaluation of an ini.sl file with autoloads in the jed.d/ config file
  is an action that the average user cannot revert!
  

Also:

  while Paul generally favours the maintenance friendly generic autoloads
  in user space,
  
  I (GM) want to keep my basic modes self contained.


Currently my compromise is:

* modes in jed-extra/, jed-extra/utils and jed-extra/drop-in are
  self-contained, i.e. define the needed autoload() and requires() to
  run without additional configuration.

* jed.d/50jed-extra.sl evaluates jed-extra/ini.sl

  This is a non-revertible change to the behaviour of jed without
  jed-extra, however it is intended to only include sufficiently
  stable, really helpfull and non-intruding changes --- in other words,
  it should contain what an average user would expect as enhancements
  to the usability, look and feel of Jed when installing an extra package.
  
  (For the Jed purist on a system with a jed-extra loving administrator,
  the --skip-debian-startup command line option is a last resort)
  
* Alternative startup configuration is available in the
  doc/jed-extra/examples/
  
  These include also jed.rc examples which contain u.a.:
  
  % Utilities (required by the other modes)
  %   Initialization adds autoloads for utility functions:
  %    - slows down startup
  %    + lets private modes use the util functions without need for autoloads,
  %      some "extra" modes rely on these autoloads as well
  %    + lets Help>Apropos find util functions right from the start
  % () = evalfile($1+"utils/ini.sl"); 
  
* Modes that either
  
  - need additional configuration steps
  - need additional helper apps (like dict)
  - are not tested
  - are only of interest to a limited group of users
  
  go to jed-extra/extra/
  
  This way they are installed with jed-extra.deb and can be activated
  by a power-user.


I.e. IMO 

  * there is no need for a missing autoloads() patch for modes in
    jed-extra/extra.
  * missing autoloads() in the "basic" modes are to be fixed, either
    upstream (my preference) or,  by creating (and maintaining!) a
    dpatch.


> I think it is a bug if the functions a mode depends on are not in the
> whole archive.

Again this is a bug of the jed-extra package. We should either exclude
modes depending on "outside help" or include the missing helper modes.
(Remember, Jedmodes is not a "release" but a collection and not all
modes listed here do have their sources in the Jedmodes-CVS.)


Günter

-- 
Milde ife.et.tu-dresden.de