[metapost] Extending metapost

[Taco Hoekwater]

L. Nobre G. wrote:
> On Fri, 4 Feb 2005, Taco Hoekwater wrote:
> 
>>I'd be happy to code and propose such an extension for the next
>>'feature' release of MP.
> 
> Does that mean that others can also code and propose 'features'?

The actual source is public domain, and lives in CVS at sarovar.
You can do with that whatever you like, but: it is very unlikely
that your altered sources will ever be accepted by any TeX
distribution. So, if you only need a private extension, you can
go right ahead and ignore the rest of this e-mail.

For the rest:

Yes, but there are some rules. Extensions for the program that's
called metapost (the one that runs mptrap, and is passed on to
the TeX distributions as 'the metapost distribution' by us
(the implementation team) on behalf of John D. Hobby) must abide
the following:

* Current behaviour of metapost cannot be altered in any way
* Conflicts with existing metafont behaviour are forbidden
* Extensions should be small in scope
* It has to fit in syntactically with the rest of the language
* Once in, it stays in and becomes immutable
* There has to be a clear reason why compiled code is to be
   preferred over a macro solution
* The implementation language has to be a web change file
* Documentation and QA tests must exist
* JDH has the final word on anything
* All proposals to JDH have to be approved by the implementation
   team first
* Actual releases are prepared by the implementation team

Some of these rules are based on agreements made with JDH,
others are simple project maintenance rules. The development
model mimics that of e-TeX quite closely.

--

We also want to (eventually) create a program with extensions
that are allowed to break compatibility. For the moment, this
is codenamed "megapost" because the first thing we want to do
is 64bit arithmetic (a partial patch by Giuseppe Bilotta exists).
This program has another set of rules:

* Conflicts with existing metafont or metapost behaviour are
   forbidden, but only for input that does not generate errors
   or warnings.
* It has to fit in syntactically with the rest of the language
* Once in, it stays in and becomes immutable
* The code has to be at least partially written in web
* The implementation team has the final word on anything
* Actual releases are prepared by the implementation team

-- 

The 'implementation team' is a group of people originally
brought together by Hans Hagen and Karl Berry. Current assignments
are roughly like this (there could be mistakes/omissions. if so,
I'm sorry):

   Hans Hagen: coordination, communication with JDH
   Karl Berry: facilities (mailing list, website), documentation,
               communication with TeX distributors
   Taco Hoekwater: tracking/cvs, web code maintenance, build system
   Giuseppe Bilotta: web code
   Boguslav Jackowski: macro code

We have a private mailing list set up for technical implementation
stuff. People that are willing to do *actual work* are invited to
join the team, please e-mail me or Karl Berry if that is the case.


Greetings,

Taco