[AC general-docs] draft XEmacs Developer's Guide

APPROVE COMMIT general-docs With this patch the XEmacs Developer's Guide is a fairly self-contained and internally consistent guide to best current practices of the XEmacs Project. I hope it will turn into a policy document, but that would require the Review Board to show some interest in policy.... It remains rather incomplete; contributions welcome. Once again many thanks to Bill Wohler whose MH-E Developer's Guide formed the framework for this document, and for his permission to publish it under the GPL. Also to the XEmacs reviewers and developers who have built the procedures and discussed the policies over the years. Index: ChangeLog =================================================================== RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/general-docs/ChangeLog,v retrieving revision 1.16 diff -u -r1.16 ChangeLog --- ChangeLog 2005/05/07 12:23:53 1.16 +++ ChangeLog 2007/05/12 08:32:10 ＠＠ -0,0 +1,51 ＠＠ +2007-05-13 Stephen J. Turnbull <stephen(a)xemacs.org&gt; + + Publish xemacs-devguide. + + * Makefile (EXPLICIT_DOCS): Add xemacs-devguide.texi. + +2007-05-13 Stephen J. Turnbull <stephen(a)xemacs.org&gt; + + * texi/xemacs/xemacs-devguide.texi: + (Philosophy): Rewrite to look like XEmacs current practice. + +2007-02-17 Stephen J. Turnbull <stephen(a)xemacs.org&gt; + + Fix up xemacs-devguide. + + * texi/xemacs/xemacs-devguide.texi: + Remove all the silly Edited: and Written: tags. + Implicit self-approval: This is decided, we just need to fix + the commit trigger. + Guide variables: Update dates and add DEVGUIDE. Use it. + xemacs-design: Update references to note it's inactive. + Copyrights: Update mine, improve formatting slightly. + Fix typos. + + (Nodes borrowed from other projects not adapted to XEmacs): + New appendix. Update menus. + (Philosophy): Revise desiderata. Deprecate GFDL. + (Committer): Clarify usage. + (Committer Welcome Message): Update package tree size estimate. + (Release Engineer): Clarify "ex oficio". + (The Work Flow): Clarify absence of binary packages. + (About Copyright Assignment): Clarify FSF policy on XEmacs. + (ChangeLogs): Clarify syntax of log entries. + (Copying): Moved whole node. + + (The Package Maintainer Role): + (Getting Started as a Package Maintainer): + (Advice to Package Maintainers): + New subnodes of XEmacs Package Maintainer. + + (Support Requests): + (Bugs): + (Feature Requests): + (Patch Queue): + (File Releases): + (News): + (Surveys): + (Free Software Directories): + Move these nodes and subnodes into new Appendix, update pointers. + A few desultory fixups. + Index: Makefile =================================================================== RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/general-docs/Makefile,v retrieving revision 1.13 diff -u -r1.13 Makefile --- Makefile 2005/05/07 12:23:54 1.13 +++ Makefile 2007/05/12 08:32:10 ＠＠ -27,6 +27,7 ＠＠ # We'll need something like this. #EXPLICIT_DOCS = texi/*.texi texi/xemacs/*.texi texi/packages/*.texi -EXPLICIT_DOCS = texi/xemacs/fontconfig.texi +EXPLICIT_DOCS = texi/xemacs/fontconfig.texi \ + texi/xemacs/xemacs-devguide.texi include ../../XEmacs.rules Index: texi/xemacs/xemacs-devguide.texi =================================================================== RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/general-docs/texi/xemacs/xemacs-devguide.texi,v retrieving revision 1.1 diff -u -r1.1 xemacs-devguide.texi --- texi/xemacs/xemacs-devguide.texi 2005/02/01 16:08:35 1.1 +++ texi/xemacs/xemacs-devguide.texi 2007/05/12 08:32:12 ＠＠ -3,16 +3,16 ＠＠ ＠c Generate HTML with: ＠c (shell-command "texi2html -number -monolithic xemacs-devguide.texi" nil) ＠c -＠c Preamble edited: stephen 2005-01-20 ＠c %**start of header ＠setfilename ../../info/xemacs-devguide.info ＠settitle xemacs-devguide ＠c %**end of header -＠c Version variables. -＠set EDITION 0.5 -＠set UPDATED 2005-01-20 -＠set UPDATE-MONTH January, 2005 +＠c Developer's Guide variables. +＠set DEVGUIDE ＠cite{XEmacs Developer's Guide} +＠set EDITION 0.6 +＠set UPDATED 2007-02-17 +＠set UPDATE-MONTH February, 2007 ＠c Other variables. ＠set XEMACSORG XEmacs.ORG ＠＠ -22,6 +22,7 ＠＠ ＠set C-E-X the ＠i{comp.emacs.xemacs} Usenet newsgroup ＠set ANNOUNCE-LIST the ＠email{xemacs-announce＠(a)xemacs.org,XEmacs Announcements} mailing list ＠set BETA-LIST the ＠email{xemacs-beta＠(a)xemacs.org,XEmacs Beta} mailing list +＠c xemacs-design is currently not operative; substitute xemacs-beta ＠set DESIGN-LIST the ＠email{xemacs-design＠(a)xemacs.org,XEmacs Design} mailing list ＠set REVIEW-LIST the ＠email{xemacs-review＠(a)xemacs.org,XEmacs Review} mailing list ＠set PATCHES-LIST the ＠email{xemacs-patches＠(a)xemacs.org,XEmacs Patches} mailing list ＠＠ -29,19 +30,20 ＠＠ ＠set BUILDREPORTS-LIST the ＠email{xemacs-buildreports＠(a)xemacs.org,XEmacs Build Reports} mailing list ＠copying -This is Edition ＠value{EDITION} of the ＠cite{XEmacs Developers Guide}, +This is Edition ＠value{EDITION} of the ＠value{DEVGUIDE}, last updated ＠value{UPDATED}. -Copyright ＠copyright{} 2000, 01, 02, 03, 2004 Bill Wohler -Copyright ＠copyright{} 2005 Free Software Foundation +Copyright ＠copyright{} 2000, 2001, 2002, 2003, 2004 Bill Wohler +Copyright ＠copyright{} 2005, 2007 Free Software Foundation + ＠quotation -The ＠cite{XEmacs Developers Guide} is free documentation; you can +The ＠value{DEVGUIDE} is free documentation; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. -The ＠cite{XEmacs Developers Guide} is distributed in the hope that it +The ＠value{DEVGUIDE} is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. ＠＠ -57,11 +59,11 ＠＠ ＠dircategory XEmacs Editor ＠direntry -* XEmacs Developers Guide: (xemacs-devguide). UNOFFICIAL EARLY DRAFT. +* XEmacs Developer's Guide: (xemacs-devguide). DRAFT. ＠end direntry ＠titlepage -＠title The XEmacs Developers Guide +＠title The XEmacs Developer's Guide ＠subtitle Edition ＠value{EDITION} ＠subtitle ＠value{UPDATE-MONTH} ＠author Stephen J. Turnbull ＠＠ -97,18 +99,7 ＠＠ * The Work Roles:: * The Work Flow:: * XEmacs Resources on the Internet:: - -Nodes borrowed from other projects, not adapted to XEmacs: - -* Support Requests:: -* Bugs:: -* Feature Requests:: -* Patch Queue:: -* File Releases:: -* News:: -* Surveys:: -* Free Software Directories:: -* Copying:: +* Nodes borrowed from other projects not adapted to XEmacs:: * Index:: ＠detailmenu ＠＠ -129,6 +120,11 ＠＠ * Commit Access:: * Committer Welcome Message:: +XEmacs Package Maintainer + +* The Package Maintainer Role:: +* Advice to Package Maintainers:: + XEmacs Reviewer * Appointing New Reviewers:: ＠＠ -155,7 +151,7 ＠＠ Submit the Patch -* Proposed Optional Alternate Procedure for Reviewers:: +* Optional Alternate Procedure for Reviewers:: Patch Review ＠＠ -178,6 +174,16 ＠＠ Nodes borrowed from other projects, not adapted to XEmacs +* Support Requests:: +* Bugs:: +* Feature Requests:: +* Patch Queue:: +* File Releases:: +* News:: +* Surveys:: +* Free Software Directories:: +* Copying:: + Bugs * Category:: ＠＠ -211,8 +217,6 ＠＠ ＠node Acknowledgments, Introduction, Top, Top ＠chapter Acknowledgments -＠c Edited: stephen 2005-01-18 - Special thanks go to Bill Wohler, whose ＠emph{MH-E Developers Guide} formed the framework for this document, and contributed a lot of text as well, for permission to redistribute the derived work under the GNU ＠＠ -227,8 +231,6 ＠＠ ＠node Introduction, Philosophy, Acknowledgments, Top ＠chapter Introduction -＠c Edited: stephen 2005-01-18 - ＠cindex Introduction ＠cindex ＠value{XEMACSORG} ＠＠ -250,7 +252,7 ＠＠ ＠cindex xemacs-design And remember, this is your document. If you think something is bogus, -start a movement on ＠value{DESIGN-LIST}. One of the tenets of the +start a movement on ＠value{BETA-LIST}. One of the tenets of the philosophy is rough consensus. If you can get a rough consensus to agree with your point of view, then the document shall be changed accordingly. ＠＠ -265,19 +267,7 ＠＠ Feel free to submit patches to ＠value{PATCHES-LIST}. Please try to review and edit a whole node at a time. They're short; it's not that -great a burden. XEmacs Reviewers: If you review and approve of a node -as is, please add a comment just below the ＠samp{＠＠node} and sectioning -commands in the node like - -＠example -＠＠c Reviewed: ＠var{name} ＠var{date} -＠end example - -Otherwise, edit the node and add a comment - -＠example -＠＠c Edited: ＠var{name} ＠var{date} -＠end example +great a burden. ＠end cartouche ＠＠ -286,14 +276,12 ＠＠ ＠node Philosophy, The Work Roles, Introduction, Top ＠chapter Philosophy -＠c Edited: stephen 2005-01-18 - ＠cindex Philosophy -＠strong{Currently pretty much everything in this node is hardly -representative of the ＠value{PROJECT}. Sometimes stephen thinks much of -this would be a good statement of values, other times he doesn't. What -do you think? Submit a patch!} +＠strong{This node is hardly +changed from the ＠emph{MH-E Developers Guide}, and is not +representative of the ＠value{PROJECT}. However, everything here has +been espoused by XEmacs developers at one time or another.} This chapter discusses the philosophy and principles of the XEmacs project. The first section covers our coding philosophy, while the ＠＠ -306,51 +294,52 ＠＠ follows: ＠enumerate - ＠item -Keep the code small and fast +Keep the C code fast. ＠item -Refrain from adding lots of code to the codebase that would be better -served with hooks. +Refrain from adding lots of code to the C codebase that would be better +served with Lisp. ＠item -In order to provide maximum compatibility with other MH interfaces and -MH itself, XEmacs should use MH itself as much as possible. XEmacs is, -after all, a interface to MH and therefore should not implement MH. +XEmacs is a cross-platform application. Features should work on all +platforms. ＠item XEmacs should be easy to use out-of-the-box for new users. - ＠end enumerate -That last priority struggles mightily with the other priorities. For -example, the user ＠i{could} write his own hooks for many features. -However, the average user is not going to do so. Indeed, the -customization buffer may be too intimidating and providing radio -buttons and checkboxes in the menu may be the way to go in some cases. - ＠cindex customize +We should get as much mileage out of ＠code{customize} as we can to +reduce the amount of code that users have to write. + +XEmacs at any time has a ＠emph{stable} branch and uses the ＠emph{trunk} +for development. We do not freeze the trunk, except for the short +period of time needed to create a consistent release branch. The +release branch in principle should only be changed for bug fixes. (In +the past this principle has been honored as much in the breach as in the +observance; nevertheless, it's a good starting point.) + +A change in the major version number indicates a pervasive change +affecting all users. For example, the introduction of Mule in version +20, the extensive user of the package system in 21, and Unicode support +in 22. A change in the minor version number reflects addition of +features, and accompanies an initial public release. A change in the +patchlevel reflects bugfix releases of the stable branch, while on the +trunk patchlevels are fairly arbitrary, reflecting regular beta +releases. + +The stable branch has a single gatekeeper, the listed maintainer. +Changes are made only by the maintainer, or at his convenience with +explicit authorization. Any XEmacs reviewer may make or authorize +changes to the trunk. Having commit privileges does ＠emph{not} +authorize changes; commit privileges are for the convenience of the +project and of regular contributors, but do not imply a direct say in +decisions. Conversely, we are always looking for new reviewers; the +review board is self-maintaining, but not closed. -In a less contentious way, making XEmacs easier to use may mean better -integration with other software packages (such as ＠code{tm} or -＠code{goto-addr}). Or pre-written hook functions could be provided. We -should get as much mileage out of ＠code{customize} as we can to reduce -the amount of code that users have to write. - -One other subject related to philosophy is to what constitutes a major -release. Major releases signal to the user that the new version may -not work as it did before and that reading of the release notes is -mandatory. Major releases occur when incompatible changes are made -that are visible to the user. Types of changes include changing the -name of or deleting functions, key bindings, and customization -variables. The converse is true; these sorts of changes should not be -applied to minor releases. - -By itself, merely adding a new feature does not just justify a major -release. On the other hand, a major release is called for if the code -is completely rewritten, even if the user cannot notice any -difference. +Individual packages, like the stable branch, may have a listed +maintainer. In those cases, the listed maintainer is the gatekeeper. ＠heading Guiding Principles ＠＠ -358,9 +347,8 ＠＠ ＠enumerate 1 ＠item -While we all are scratching an itch on this project, we also have very -few users and a great desire to have more. Our users are sacrosanct; -we will go the extra distance to please our users. +We all are scratching an itch on this project. We respect each others' +goals, which are quite varies. ＠item Using vulgar language towards our users and/or developers is ＠＠ -370,10 +358,8 ＠＠ The team makes decisions by consensus through articulated arguments. If one wants to express an opinion, they do it by presenting evidence to support their claim in a respectful way, and not by insulting -others' points of view. While it takes some time and effort to -articulate the reasons behind one's point of view, we enjoy the -process and often gain a better understanding of the issues by the -end. +others' points of view. Where consensus seems hard to achieve, what we +try first may be decided by a vote in the Review Board. ＠item We are all committed to a high-quality product. We have no artificial ＠＠ -417,9 +403,16 ＠＠ ＠end ifhtml ＠strong{Please ensure that the copyright notice of every file accurately -reflects your contribution, whether you have assigned your copyright or -not. This will aid future project admins greatly if there ever is a -merger.} +reflects your contribution, whether you have assigned your copyright to +the FSF or not. This will aid future project admins greatly if there +ever is a merger of XEmacs with Emacs.} ``Accurately reflects'' means +that if you have not assigned your contribution, ＠emph{your name} should +appear in a copyright notice, along with an accurate list of the years +in which your contributions were made. If you have assigned your +contribution, you should list the FSF (or other assignee) as copyright +holder, and make sure that the list of years is appropriately updated. +In both cases, an accurate ChangeLog detailing your changes (file and +function) should accompany the patch. You ＠strong{must} reference the GPL correctly in every file. ＠＠ -427,17 +420,24 ＠＠ they have various different licenses. ＠emph{Be careful}: it is typically ＠strong{not} permissible to mix excerpts from different documents with each other, or with XEmacs code, unless they have -＠emph{identical} licenses. +＠emph{identical} licenses. In particular, the XEmacs Texinfo manuals +(the ＠emph{XEmacs User's Guide}, the ＠emph{XEmacs Lisp Reference}, and +the ＠emph{XEmacs Internals Manual}) have a unique license which is not +the GPL or the GFDL, and is incompatible with both. All code and data files must be licensed under the GPL (or a compatible license) so that they can be added to XEmacs, and others may modify them. Documentation files must be licensed under an approved free license or an OSI-approved open source license. Where possible, GPL-compatible -licenses are preferred. +licenses are preferred. If at all possible, avoid the GNU Free +Documentation License, because it ＠emph{is incompatible with the GPL}, +implying that text cannot be copied freely between docstrings and the +Texinfo manual, except by the copyright holder. The ＠uref{http://www.gnu.org/prep/standards.html, GNU -Coding Conventions} is required reading. +Coding Conventions} is required reading. Note that XEmacs has its own +slightly different, version. ＠xref{Top, Coding Standards, ,standards}. Before checking in files, load ＠file{lisp-mnt} into Emacs, and run ＠code{lm-verify} within the lisp file you are editing to ensure that ＠＠ -463,8 +463,6 ＠＠ ＠node The Work Roles, The Work Flow, Philosophy, Top ＠chapter The Work Roles -＠c Created: stephen 2005-01-20 - On the one hand, ``open source'' means that you are free to take the existing program, make it into whatever you want, and nobody will stop you. On the other hand, ``open source'' means that you are free to ＠＠ -475,7 +473,7 ＠＠ Allowing people to fill roles that suit them, and creating a work flow that lets them share the products of their work without getting in each -other's ways, are the foundations of the project. +others' way, are the foundations of the project. ＠heading People and the Project ＠＠ -533,24 +531,25 ＠＠ ＠item Reviewer A developer who may authorize developers, including himself, to write to the XEmacs CVS repository. ＠xref{XEmacs Reviewer}. Should participate -in ＠value{BETA-LIST} ＠ref{xemacs-beta}, ＠value{DESIGN-LIST} -＠ref{xemacs-design}, and ＠value{PATCHES-LIST} ＠ref{xemacs-patches}. +in ＠value{BETA-LIST} ＠ref{xemacs-beta}, ＠value{PATCHES-LIST} +＠ref{xemacs-patches}, and ＠value{REVIEW-LIST} +＠ref{xemacs-review}. ＠item XEmacs Review Board The reviewers as a group, responsible for delegating access to ＠value{PROJECT} resources to developers. A self-selecting cabal. The current members are noted on the -＠uref{http://www.xemacs.org/Develop/jobs.html,＠emph{Job List}}. +＠uref{http://www.xemacs.org/Develop/jobs.html,＠emph{Jobs List}}. ＠xref{Jobs List}. ＠item Chairman of the Board -＠item CEO -＠item Maintainer -＠item Benevolent Dictator for Life +＠itemx CEO +＠itemx Maintainer +＠itemx Benevolent Dictator for Life Call it what you like, we don't have one any more, by deliberate choice. ＠item Meta-maintainer -＠item Mr. XEmacs +＠itemx Mr. XEmacs The reviewer responsible for trying to keep track of what isn't getting done, and finding someone to do it. The latter title allows him to tell his mother how important he is. More seriously, the meta-maintainer ＠＠ -559,8 +558,8 ＠＠ ＠value{BETA-LIST} ＠ref{xemacs-beta}. ＠item Release engineer -＠item Stable release engineer -＠item Package release engineer +＠itemx Stable release engineer +＠itemx Package release engineer Responsible for the quality control and adminstrative details of distributing some coherent package of functionality. The ＠dfn{stable release engineer} manages the core distribution, including the build ＠＠ -573,8 +572,8 ＠＠ ＠c #### Write nodes for these posts! ＠item Postmaster -＠item Webmaster -＠item CVS Manager +＠itemx Webmaster +＠itemx CVS Manager Administrators of the various Internet-based services important to XEmacs users and developers. ＠c #### Write nodes for these posts! ＠＠ -620,10 +619,10 ＠＠ give the community information about the variety of platforms and features XEmacs is being configured for. Bug reports are submitted to ＠value{BETA-LIST}, preferably via ＠kbd{M-x report-xemacs-bug RET}. +＠value{BETA-LIST} is also the channel to lobby for their favorite new +features. Build reports are submitted to ＠value{BUILDREPORTS-LIST} -via the ＠kbd{M-x build-report RET} utility. Testers may -also wish to subscribe to ＠value{DESIGN-LIST}, to lobby for -their favorite new features. +via the ＠kbd{M-x build-report RET} utility. However, for those who do wish to make contributions to the collection of bytes that we call ``XEmacs'', there are a number of formal roles, ＠＠ -637,10 +636,14 ＠＠ ＠cindex committer ＠c MH-E says that committers may be _assigned_ bugs + A ＠dfn{committer} is one who is authorized to check in approved changes into the CVS repository, including changes to private branches they may -maintain. Developers who do not have CVS access contribute by -submitting patches to ＠value{PATCHES-LIST}. +maintain. Note that, in contrast to the use of this term on many +projects, being a committer is simply an administrative convenience; +committers must wait for approval to check in changes. +Developers who do not have CVS access contribute by submitting patches +to ＠value{PATCHES-LIST}. Commit access is generally given to those who have submitted several good patches, to ``well-known'' developers on request, and to XEmacs ＠＠ -656,8 +659,6 ＠＠ ＠node Commit Access, Committer Welcome Message, Committer, Committer ＠subsection Commit Access -＠c Edited: stephen 2005-01-18 - ＠cindex commit access ＠cindex cvs.xemacs.org committer accounts ＠＠ -771,8 +772,8 ＠＠ Which will get just the redtape package. You can get all the packages with the module name "packages". I'd strongly suggest that you get the whole packages tree as usually packages require some functionality from -other packages. But be warned, the packages tree is quite big (80+ MB -as of 11/2002). +other packages. But be warned, the packages tree is quite big (120+ MB +as of 2007/02). Committing patches to CVS: ------------------------- ＠＠ -913,6 +914,271 ＠＠ Of course the package maintainer does have control over the decision to release. +＠menu +* The Package Maintainer Role:: +* Getting Started as a Package Maintainer:: +* Advice to Package Maintainers:: +＠end menu + + + +＠node The Package Maintainer Role, Advice to Package Maintainers, , XEmacs Package Maintainer +＠subsection The Package Maintainer Role + +The ＠dfn{package maintainer} is basically a liaison between two +communities: the XEmacs developers, and the users of the package, who +will typically not be Lisp programmers, and perhaps not programmers at +all. Because the package maintainer represents the interest of a +community which often is not otherwise active in XEmacs development, he +is the ultimate authority on what goes into the package. Probably he +will extremely rarely wish to oppose changes made by members of the +Review Board (who have the authority to review and approve changes to +any part of XEmacs). However, he should feel free to make any changes +he thinks useful for his package; he does not need to ask anyone's +permission, and may approve or veto submissions by other users, and +incorporate them in -modesthe package as he sees fit. + +The responsibility accepted is simply to pay attention to the package. +The package maintainer should stay on top of progress in the upstream +versions of the libraries in the package, and should subscribe to the +XEmacs Beta and XEmacs Patches mailing lists to watch for bug reports +and patches relevant to it. + +We also hope and expect that the package maintainer will take part in +updating and improving the package, but we don't expect him to be a +coding wizard. It's possible to be a package maintainer even with +very little knowledge of the code. One can always ask for advice on +XEmacs Beta, or directly of experts on whatever the problem area is. +The roles of the package maintainer and of the core team are +complementary: the package maintainer stays in contact with his +community and finds out what the needs are; the core team provides +advice, information about how XEmacs works, and often patches and +documentation. + + + +＠node Getting Started as a Package Maintainer, Advice to Package Maintainers, The Package Maintainer Role, XEmacs Package Maintainer +＠subsection Getting Started as a Package Maintainer + +The first step is to check out the package from CVS in +read-write mode. This is done as follows: + +＠example +export CVSROOT=:ext:xemacs＠cvs.xemacs.org:/pack/xemacscvs +export CVS_RSH=/usr/bin/ssh +cvs checkout packages +＠end example + +This will take a while, and about 120MB of space. It's possible to do +without most of the packages (for example, most modes can delete all of +the mule-packages subtree), but the Lisp programming language makes it +very easy to call functions in one package from another, and +interdependencies are frequent. Unless one is really really tight for +space, it's best to start by just checking out the whole thing, and +prune it back later. + +The package developer is welcome to change anything in the subtree that +contains the package. However, there are a couple of administrative +files that are conceptually the "property" of the package system. These +are ＠file{package-info.in} and the ＠file{Makefile}. There is almost +surely no need to change either at this time, except to change the +＠samp{MAINTAINER} variable in the ＠file{Makefile} to contain the +maintainer's name and email address. The package maintainer should +never change the ＠samp{VERSION} variable; that is automatically +maintained by the package release engineer (currently Norbert Koch) who +does the releases of new versions of packages. You should keep the +＠samp{AUTHOR_VERSION} variable in sync with upstream, if that makes +sense. It may be possible and convenient to have ＠code{AUTHOR_VERSION +== VERSION}; ask the package release engineer about it if that seems +attractive. + +So now you can (with the above environment settings) + +＠example +cd packages/xemacs-packages/＠var{package_name} +xemacs Makefile +# change MAINTAINER to your name and address +# make a patch with cvs diff > my.patch and send it to XEmacs Patches +cvs commit -m "Update MAINTAINER name and address." Makefile +＠end example + +which is a good test that everything is working. You can find out +more about CVS and the XEmacs repository at ＠url{http://cvs.xemacs.org}. + +Many maintainers who have a separate repository for the upstream project +do not send patches, but simply announce a synch to upstream. However, +at least at first it is advisable to send patches, so that other +developers can give you advice. + +The next step is to copy the ＠file{packages/Local.rules.template} file +to ＠file{packages/Local.rules}, and edit it to fit your environment. +The main things are to make sure that the ＠samp{XEMACS} variable points +to the appropriate XEmacs binary, and that the ＠samp{STAGING} directory +is set to something useful. Now you can build a test package by simply +typing ＠kbd{make bindist}. + +Then copy the updated upstream files over the existing ones. Try +making a package with make bindist. Use the new code, too, to see if +you find any bugs. If not, you can commit the new files to CVS. + +When you make a commit, you should notify the package release engineer, +currently ＠email{viteno＠(a)xemacs.org,Norbert Koch}, about your +intentions. Norbert is pretty aggressive about making new packages and +putting them up for download. If you don't want that after a given +change, you should tell him so. (This advice may or may not apply to +the next release engineer.) + +For internal communication purposes, we make aliases for the maintainer +and the package ＠samp{＠(a)xemacs.org}. The package maintainer addresses are + +＠example +＠var{firstname.lastname}＠(a)xemacs.org +＠var{cvsuser}＠(a)xemacs.org +＠end example + +You can use these publically as you see fit, or not. The package +addresses are + +＠example +＠var{package}-bugs＠(a)xemacs.org +＠var{package}-discuss＠(a)xemacs.org +＠var{package}-patches＠(a)xemacs.org +＠var{package}-maintainer＠(a)xemacs.org +＠end example + +The last alias is set to the maintainer address. The ＠samp{bugs-} and +＠samp{discuss-} aliases are redirected to XEmacs Beta, and the +＠samp{patches-} address to the XEmacs Patch forum. You can ask that +these be changed at any time, for example if you prefer to get mail +about the XEmacs package in upstream project channels rather than XEmacs +channels. + + + +＠node Advice to Package Maintainers, , Getting Started as a Package Maintainer, XEmacs Package Maintainer +＠subsection Advice to Package Maintainers + +This section contains some as yet unorganized advice to package +maintainers, especially those who are coming from a community which uses +XEmacs but normally develops in a language other than Lisp. +(a)emph{I.e.}, the maintainer of an editor mode. + +＠heading Setting Up to Build Your Package + +Building a package almost always requires the presence of the +＠emph{source code} for other packages. Almost all packages depend on +the ＠file{xemacs-base} package, for example. Therefore the recommended +procedure is to check out the whole package tree, configure +(a)file{Local.rules}, and do a full build with ＠kbd{make} from the top. +(After that you should keep the tree up-to-date with ＠kbd{cvs update +-dP} and occasionally do a ＠kbd{make} to keep things in order.) Having +done this once, you can thereafter normally simply do ＠kbd{make} and +＠kbd{make bindist} in your package's top directory. + +We know this is annoying, but disk space is cheap, and the requirement +for a full build is a one-time thing. After that, you can just do make +bindist in your package's directory. Suggestions for improvement of the +process ＠emph{are} welcome, but they must account for the need to +provide macro definitions and autoloads. + +＠heading Lisp macros and autoloads + +Lisp provides ＠dfn{macros}, which involve ＠dfn{expansion}, which means +evaluating a Lisp expression which constructs a new Lisp expression. +When a macro is invoked by the interpreter, the second expression is +then ＠dfn{applied} to the actual arguments to give the actual result. + +This separation of expansion from application means that expansion can +take place without knowing the actual arguments. The most important +example is at compile time. As a design principle, ＠emph{compiled code +cannot expand macros} (because it's unnecessary and inefficient), so you +must have all definitions of macros used available at compile time. The +somewhat similar ＠dfn{defsubst} is like C ＠samp{inline}; it's advice to +the compiler, but the function can be called in the usual way. So +although it's not strictly necessary, it's desirable for efficiency that +defsubst definitions be available to the compiler. + +Since Lisp is very dynamic, it's possible to for code to call functions +that haven't been defined yet, as long as the call isn't evaluated until +after the function definition is loaded. The ＠dfn{autoload} facility +allows definitions to be loaded the first time they are used. + +＠heading Application to the XEmacs package infrastructure + +When a package is built, of course its Lisp libraries are compiled. To +ensure that necessary definitions are available, the libraries of the +packages named in the ＠samp{REQUIRES} Make variable are required, and +the autoload definitions are loaded from generated libraries called +＠file{auto-autoloads} in each package. + +So you should at least do ＠kbd{make autoloads} from the top of the +package tree. (It should be possible to do a more minimal set of +auto-autoloads, just the ones that your package and packages it depends +on use, but there's no automatic way to compute that set.) + +Since the compile process involves expanding macros, which is executing +package code, it will speed up the build process for your package to do +a full "make" from the top. The speedup may or may not be measurable, +since make itself and simply starting XEmacs to do the compilation are +pretty time-consuming. + +＠heading For the future + +Some attempts have been made to track the dependencies on macros and +autoloads, but the problem turns out to be fairly hard because it's +possible to dynamically compute the names of functions to call, and +things like that. Thus a program to analyze dependencies must +actually understand Lisp semantics. We've found it most reliable to +just build the packages, and set up dependencies when errors +occur. + +＠heading Getting Help with Your Package + +If you want advice on the code itself, just post it to XEmacs Patches, +which is basically designed to put new code that is believed to be ready +to be committed in front of the reviewers. Since you're the maintainer, +you should mention explicitly that you want review. Otherwise people +will assume you know what you're doing, even though you know you +don't. + +If you're more interested in whether it's a good idea or people will use +it, then post to XEmacs Beta, where a lot more people will see it. +Alternatively you may want to post to package-specific channels, either +an upstream project or the channels devoted to the language it +manipulates. To the extent that fixes have been submitted by the +community, this fits into the latter case, and you only need to consult +XEmacs channels if they don't work as expected. + +Finally, if it's a little of both, you can cross-post. This is useful +in cases where you know you want to commit this patch but you want +advice on what needs to be done next. + +＠heading Learning About Emacs Lisp + +In this case posting to XEmacs Beta and/or comp.emacs.xemacs is best, +because there are many competent Lisp hackers who are not core +developers. In many cases, for example, font lock and indentation, this +is probably not so much "learning Lisp" as "learning how Emacsen do font +lock and indentation". Still, these are skills that are quite common +outside of the core developer group. + +Many of the editor features are (unfortunately) relatively +fork-specific. Emacs and XEmacs do them somewhat differently, +especially font-lock. Nevertheless, you may also get some help on +channels like comp.emacs and gnu.emacs.help. (Not +＠samp{emacs-devel＠(a)gnu.org}, please; XEmacs-specific stuff is off-topic +there, and even individual gurus won't be able to help much, since +XEmacs code has diverged substantially. + +For Emacs Lisp itself, there's some tutorial material in +＠ref{Top,the XEmacs Lisp Reference manual, , lispref}, and GNU +distributes an Emacs Lisp tutorial. However, the GNU tutorial is really +more of a generic Lisp tutorial, with a few examples drawn from the +Emacs domain. The Lisp Reference is pretty well organized; if you have +trouble finding references to what you need to do, or don't understand +what it says, feel free to report it as a bug. It's not always possible +to improve it, but it's always worth trying! + ＠node XEmacs Reviewer, Meta-Maintainer, XEmacs Package Maintainer, The Work Roles ＠＠ -962,7 +1228,6 ＠＠ ＠node Appointing New Reviewers, Welcoming New Reviewers, XEmacs Reviewer, XEmacs Reviewer ＠subsection Appointing New Reviewers -＠c Created: stephen 2005-01-19 ＠strong{This node needs improvement!!} ＠cindex ＠value{BOARD} ＠＠ -1176,7 +1441,10 ＠＠ including such things as ensuring that generated files are committed to CVS, tagging CVS, updating release documentation, creating and uploading tarballs, and making announcements. Release engineers are ＠emph{ex -oficio} members of the XEmacs Review Board. +oficio} members of the XEmacs Review Board. That is, if you are willing +to accept the responsibility of release engineering, and the Board is +willing to accept you, you will be appointed as Reviewer if you aren't +already. ＠c #### MAKE A SEPARATE NODE CORRESPONDING TO jobs.html, AND FIGURE OUT ＠c HOW TO AUTOMAGICALLY UPDATE AND PUBLISH IT AS jobs.html. ＠＠ -1203,7 +1471,6 ＠＠ ＠node The Work Flow, XEmacs Resources on the Internet, The Work Roles, Top ＠chapter The Work Flow -＠c Created: stephen 2005-01-20 This section is a description of current best practices, rather than an attempt to define a standard. ＠＠ -1215,8 +1482,10 ＠＠ ＠table ＠emph ＠item Get the sources. -XEmacs is distributed with source, but CVS simplifies management of your -improvements. +＠value{PROJECT} tarballs are always distributed as source (except in +the case of the Windows installer), but CVS simplifies management of +your improvements. (Third-party vendors such as *nix distributions and +Cygwin may distribute binary packages, but XEmacs no longer does.) ＠item Write low-profile code. Don't distract your users or colleagues from their work. Just make it ＠＠ -1230,11 +1499,14 ＠＠ ＠item Create the patch. Dot the i's, cross the t's. Make sure that it's easy to add to the code -base. +base. The best way is by using ＠code{cvs diff -uN} against the tip of +the branch or trunk you intend to have the patch applied to. The +exception is ChangeLog patches, which may be generated using ＠code{cvs +diff -U 0 ChangeLog}, or submitted as plain test. ＠item Submit the patch. -Compose the message so it's easy to find, easy to identify, easy to -review, and easy to apply. +Compose the message, especially the Subject: header, so it's easy to +find, easy to identify, easy to review, and easy to apply. ＠item Review the patch. The primary function of the ＠value{BOARD} is to help you improve your ＠＠ -1281,17 +1553,19 ＠＠ the FSF (or other free software trust), which is required by its covenants of incorporation to actively defend free software it holds. You may also wish to respect the wishes of Richard Stallman, the first -author and still major contributor to the development of Emacs. +author and current maintainer of Emacs. Finally, you may wish to support the FSF's advocacy of free software by assigning your copyright to the FSF. At the present time, the ＠value{PROJECT} neither advocates nor discourages this action; it's up to you. -Also, be aware that at the time of writing, January 2005, -Richard Stallman had recently denied that such assignments would +Also, be aware that in January 2005 +Richard Stallman explicitly denied that such assignments would facilitate adoption of XEmacs code by GNU Emacs; if you want your code to be used in GNU Emacs, you will have to resubmit it directly to the -GNU Emacs project. +GNU Emacs project. (The assignment is acceptable for use in Emacs, but +Emacs developers are not allowed to port others' code from XEmacs to GNU +Emacs, even if it's assigned; the original developer must do that.) Get more information about procedures from the ＠email{emacs-devel＠(a)gnu.org,GNU Emacs developers' mailing list} or from ＠＠ -1305,7 +1579,6 ＠＠ ＠node Scratching That Itch, Get the Sources, About Copyright Assignment, The Work Flow ＠section Scratching That Itch -＠c Edited: stephen 2005-01-18 ＠c #### needs revision As always in free software, a patch starts life when some developer ＠＠ -1319,7 +1592,8 ＠＠ ＠node Get the Sources, Write Low-Profile Code, Scratching That Itch, The Work Flow ＠section Get the Sources -Maybe he's never worked on XEmacs before. In that case, he'll need to +Maybe the developer has never worked on XEmacs before. In that case, +he'll need to check out the ＠samp{xemacs} module from the CVS repository ＠ref{CVS Repository}. True, he may already have the whole package because he built from source after downloading a tarball. However, tarballs often ＠＠ -1327,7 +1601,7 ＠＠ maintainer off like a patch that doesn't apply because it was generated against an old version. Furthermore, the developer needs to keep track of the original file in order to generate a correct patch, which can be -quite difficult if you go through several iterations woring on a complex +quite difficult if you go through several iterations working on a complex issue. It's true that CVS has problems in advanced usage, but for these simple housekeeping tasks it works very well. Use CVS. ＠＠ -1407,8 +1681,7 ＠＠ ＠node Add a ChangeLog Entry, Create the Patch, Test Your Changes, The Work Flow ＠section Add a ChangeLog Entry -＠c Created: stephen 2005-01-21 -＠strong{Needs revision!!} +＠strong{Needs review!!} Add a log entry to ＠file{ChangeLog} file in the ancestor directory closest to each changed file. ＠＠ -1421,8 +1694,6 ＠＠ ＠node ChangeLogs, Log Messages, Add a ChangeLog Entry, Add a ChangeLog Entry ＠subsection ChangeLogs -＠c Edited: stephen 2005-01-18 - ＠strong{This section is pretty close to correct for XEmacs. Needs review.} ＠cindex ChangeLog ＠＠ -1472,6 +1743,12 ＠＠ 4 a} (＠code{add-change-log-entry-other-window}) which inserts this text for you (even from a diff!), please do follow its conventions. +Note that the date, the full name, and the email address are separated +by pairs of ASCII spaces, the date is in YYYY-MM-DD format, and the +email address enclosed in angle brackets. The leading space in the log +entries is encoded as an ASCII TAB, not as 8 spaces. These formatting +rules are mandatory, because ChangeLog modes depend on these heuristics. + Multiple targets with the same text may appear in the same entry. ＠cindex Debian ＠＠ -1498,8 +1775,6 ＠＠ ＠node Log Messages, , ChangeLogs, Add a ChangeLog Entry ＠subsection Log Messages -＠c Edited: stephen 2005-01-18 - ＠strong{This section, written by Bill Wohler for MH-E and lightly edited to substitute ``XEmacs'' for ``MH-E'', is pretty close to correct for XEmacs, at least in the case of implicit self-approval. Needs review.} ＠＠ -1554,7 +1829,7 ＠＠ (The following lines describe the current patch creation standard for developers without commit access, committers, and reviewers alike. An -optional alternative procedure for ＠emph{reviewers only} is likely to be +optional alternative procedure for ＠emph{reviewers only} was adopted in first quarter 2005.) Patches should be created using a standard diff(1) such as provided by ＠＠ -1593,7 +1868,7 ＠＠ (The following lines describe the current patch submission procedure for developers without commit access, committers, and reviewers alike. An -optional alternative procedure for ＠emph{reviewers only} is likely to be +optional alternative procedure for ＠emph{reviewers only} was adopted in first quarter 2005.) Send the patch by email to ＠value{PATCHES-LIST}. The subject line ＠＠ -1654,13 +1929,13 ＠＠ commit the changes to CVS as appropriate. ＠menu -* Proposed Optional Alternate Procedure for Reviewers:: +* Optional Alternate Procedure for Reviewers:: ＠end menu -＠node Proposed Optional Alternate Procedure for Reviewers, , Submit the Patch, Submit the Patch -＠subsection Proposed Optional Alternate Procedure for Reviewers +＠node Optional Alternate Procedure for Reviewers, , Submit the Patch, Submit the Patch +＠subsection Optional Alternate Procedure for Reviewers Patches that are self-approved by a reviewer, and are either expected to be non-controversial or are part of a project that has the general ＠＠ -1670,8 +1945,9 ＠＠ ＠value{PATCHES-LIST}. This may be referred to as ＠dfn{implicit self-approval}. -＠strong{This procedure is not yet in effect, and the commit-trigger has -not yet been implemented at the time of writing. (2005-01-20)} +＠strong{The commit-trigger has +not yet been implemented at the time of writing. For this reason +implicit self-approvals should still be avoided. (2007-05-13)} ＠＠ -1684,7 +1960,7 ＠＠ (The following lines describe the current patch submission procedure for developers without commit access and committers. Reviewers may optionally use ``commit-and-review,'' described later. Another optional -alternative procedure for ＠emph{reviewers only} is likely to be adopted +alternative procedure for ＠emph{reviewers only} was adopted in first quarter 2005. Called ``implicit self-approval,'' it was described in the previous section.) ＠＠ -1712,7 +1988,7 ＠＠ ＠item REVISE The reviewer is demanding certain revisions, or the patch will be -vetoed. May be obsolete; current practice seems to favor use of +vetoed. May be obsolete; current practice strongly favors use of ＠strong{QUERY} both for required revisions and for further discussion, and there seems to be little need to distinguish these cases. ＠＠ -1898,10 +2174,9 ＠＠ -＠node XEmacs Resources on the Internet, Support Requests, The Work Flow, Top +＠node XEmacs Resources on the Internet, Copying, The Work Flow, Top ＠chapter XEmacs Resources on the Internet -＠c Edited: stephen 2005-01-18 ＠strong{Write this node! Get mailing list and newsgroup information from the ＠uref{http://www.xemacs.org/Lists/, mailing list page}, available as the module ＠emph{xemacsweb} ＠ref{CVS Repository}. ＠＠ -1926,8 +2201,6 ＠＠ ＠node Project Website, CVS Repository, XEmacs Resources on the Internet, XEmacs Resources on the Internet ＠section Project Website -＠c Edited: stephen 2005-01-18 - ＠strong{Needs review. Adrian?} ＠cindex Project Website ＠＠ -1949,8 +2222,6 ＠＠ ＠node CVS Repository, comp.emacs.xemacs, Project Website, XEmacs Resources on the Internet ＠section CVS Repository -＠c Edited: stephen 2005-01-18 - ＠cindex CVS Repository ＠c #### update the specific links for convenience!! ＠＠ -1978,10 +2249,13 ＠＠ ＠node xemacs-design, xemacs-patches, xemacs-beta, XEmacs Resources on the Internet ＠section The xemacs-design Mailing List -＠strong{Write me!} +This list is currently inactive. Traffic that used to go to +＠value{DESIGN-LIST} should be directed to ＠value{BETA-LIST} instead. +＠strong{Concerning content, write me!} + ＠node xemacs-patches, xemacs-mule, xemacs-design, XEmacs Resources on the Internet ＠section The xemacs-patches Mailing List ＠＠ -2003,203 +2277,613 ＠＠ -＠c ########################################################################## -＠c #### I haven't seriously worked on the following material. -- stephen #### -＠c ########################################################################## +＠node Copying, Nodes borrowed from other projects not adapted to XEmacs, XEmacs Resources on the Internet, Top +＠appendix GNU GENERAL PUBLIC LICENSE +＠center Version 2, June 1991 -＠node Support Requests, Bugs, XEmacs Resources on the Internet, Top -＠chapter Support Requests +＠display +Copyright ＠copyright{} 1989, 1991 Free Software Foundation, Inc. +59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -＠cindex Support Requests +Everyone is permitted to copy and distribute verbatim copies +of this license document, but changing it is not allowed. +＠end display -Support requests are made to ＠value{BETA-LIST}. Developers should read -the mailing list frequently, and after a period of inactivity, browse -the ＠uref{http://list-archive.xemacs.org/xemacs-beta/,recent archives}. +＠appendixsec Preamble + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software---to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. -＠node Bugs, Feature Requests, Support Requests, Top -＠chapter Bugs + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. -＠c Edited: stephen 2005-01-18 + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. -＠strong{We don't have a tracker. We should. Describe what it should -look like here.} + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. -＠cindex Bugs -＠cindex priority -＠cindex bugs, priority + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. -Bug reports, feature requests, and discussions that are expected to lead -to bug reports or feature requests are created in -＠uref{https://sourceforge.net/bugs/?group_id=13357, Bugs}. Most -bugs should be set to a priority of 5. + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. -＠cindex bug-gnu-emacs -＠cindex Debian + The precise terms and conditions for copying, distribution and +modification follow. -Developers should follow the ＠i{bug-gnu-emacs} mailing lists/newsgroup -and move bug reports into Bugs if it has not been done already. -Similarly, XEmacs bugs reported in other systems should be transfered to -＠value{XEMACSORG}. The bug may be cut and pasted into a new bug report, or a -URL to the source of the original bug report may be all that appears -in the bug report. +＠iftex +＠appendixsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION +＠end iftex +＠ifinfo +＠center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION +＠end ifinfo -A brief lifecycle of a bug proceeds something like this. A bug is -entered. A developer ensures that the Category, Priority and Group are -correct. The Group for an Open bug should be set to the version of -software in which the bug was found, or CVS if it was found in the -latest and greatest. +＠enumerate 0 +＠item +This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The ``Program,'' below, +refers to any such program or work, and a ``work based on the Program'' +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term ``modification.'') Each licensee is addressed as ``you.'' -The assignment of bugs in Bugs follows the honor system. If you see an -open bug that you think you could handle, assign the bug to yourself. -Bugs that remain open should be reviewed by a member of the -＠value{BOARD}, who should try to find a developer to work on the bug. +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. -If you fix a bug, set the resolution to Fixed and group to CVS. Please -also assign the bug to yourself if you have not done so already, so -you get credit in the -＠uref{https://sourceforge.net/tracker/reporting/?atid=113357&what=tech&span=&period=lifespan&group_id=13357#b, -reports}. If a documentation change is not required, set the status to -Closed. If a documentation change is required, set the category to -Documentation, and assign the bug to the documentation tsar, -leave the status Open, and set the priority to 3 to set it -aside in listings sorted by priority. +＠item +You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. -See ＠ref{File Releases} for a motivation of why this process is useful. +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. -The rest of this section describes the categories and groups that have -been set up for the XEmacs project. +＠item +You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: -＠menu -* Category:: -* Status:: -* Group:: -* Resolution:: -＠end menu +＠enumerate a +＠item +You must cause the modified files to carry prominent notices +stating that you changed the files and the date of any change. -＠node Category, Status, Bugs, Bugs -＠section Category +＠item +You must cause any work that you distribute or publish, that in +whole or in part contains or is derived from the Program or any +part thereof, to be licensed as a whole at no charge to all third +parties under the terms of this License. -＠cindex category -＠cindex bug category +＠item +If the modified program normally reads commands interactively +when run, you must cause it, when started running for such +interactive use in the most ordinary way, to print or display an +announcement including an appropriate copyright notice and a +notice that there is no warranty (or else, saying that you provide +a warranty) and that users may redistribute the program under +these conditions, and telling the user how to view a copy of this +License. (Exception: if the Program itself is interactive but +does not normally print such an announcement, your work based on +the Program is not required to print an announcement.) +＠end enumerate -Several categories have been created for the XEmacs project organized by -function. They include ＠i{General}, ＠i{UI}, ＠i{MIME}, ＠i{Security}, -＠i{Documentation}, and ＠i{Contrib} +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. -＠table ＠b +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. -＠item General +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. -＠cindex general bug category -＠cindex bug categories, general +＠item +You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: -The ＠dfn{General} category is used for bugs that do not belong in any of -the other categories. +＠enumerate a +＠item +Accompany it with the complete corresponding machine-readable +source code, which must be distributed under the terms of Sections +1 and 2 above on a medium customarily used for software interchange; or, -＠item UI - -＠cindex UI bug category -＠cindex bug categories, UI +＠item +Accompany it with a written offer, valid for at least three +years, to give any third party, for a charge no more than your +cost of physically performing source distribution, a complete +machine-readable copy of the corresponding source code, to be +distributed under the terms of Sections 1 and 2 above on a medium +customarily used for software interchange; or, -The ＠dfn{UI} category is used for bugs in the software that the user sees -such as font-lock, key definitions, menus, and customization. +＠item +Accompany it with the information you received as to the offer +to distribute corresponding source code. (This alternative is +allowed only for noncommercial distribution and only if you +received the program in object code or executable form with such +an offer, in accord with Subsection b above.) +＠end enumerate -＠item MIME +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. -＠cindex MIME bug category -＠cindex bug categories, MIME +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. -The ＠dfn{MIME} category is used for bugs that pertain to MIME. +＠item +You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. -＠item Security +＠item +You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. -＠cindex security bug category -＠cindex bug categories, security +＠item +Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. -The ＠dfn{Security} category is used for bugs in the security arena. At -present, XEmacs does not include any security code, so this category might -be used for PGP interaction. +＠item +If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. -＠item Documentation +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. -＠cindex documentation bug category -＠cindex bug categories, documentation +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. -The ＠dfn{Documentation} category is used for bugs in the documentation -arena. In addition, if there are any code changes made as a result of a -bug report or feature request that require changes to the documentation, -the category of that issue should be set to Documentation after the bug -has been fixed or the feature implemented. Assign the issue to -＠i{wohler} for editing and/or writing of the documentation, and set -the priority to 3 to set the issue aside in listings sorted by priority. +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. -＠item Contrib +＠item +If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. -＠cindex contrib bug category -＠cindex bug categories, contrib +＠item +The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. -The ＠dfn{Contrib} category is used for all bugs in the contributed -software. +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and ``any +later version,'' you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. -＠end table +＠item +If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. -＠node Status, Group, Category, Bugs -＠section Status +＠iftex +＠heading NO WARRANTY +＠end iftex +＠ifinfo +＠center NO WARRANTY +＠end ifinfo -＠cindex status -＠cindex bug status +＠item +BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW＠. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE＠. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU＠. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. -The bug ＠dfn{status} is divided into four sections: ＠i{Open}, -＠i{Closed}, ＠i{Deleted} and ＠i{Pending}. +＠item +IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. +＠end enumerate -＠table ＠b +＠iftex +＠heading END OF TERMS AND CONDITIONS +＠end iftex +＠ifinfo +＠center END OF TERMS AND CONDITIONS +＠end ifinfo -＠item Open +＠page +＠appendixsec How to Apply These Terms to Your New Programs -＠cindex open bug status -＠cindex bug status, open + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. -When bugs are initially created, they are marked ＠dfn{Open}. + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the ``copyright'' line and a pointer to where the full notice is found. -＠cindex discussing bugs -＠cindex bugs, discussing -＠cindex features, discussing +＠smallexample +＠var{one line to give the program's name and an idea of what it does.} +Copyright (C) 19＠var{yy} ＠var{name of author} -The Bugs and Feature Requests sections are also used as a method to -get the ball rolling among developers. They are used to register what -we feel we should work on. For example, a developer may have questions -about the way XEmacs handles MIME that we should discuss before we -attempt to fix it: What do other people do? How should we attack this? -That developer opens a bug report in the MIME category and a -discussion ensues. Once the disposition of the issue is resolved, the -bug is assigned to a developer. Later, when the bug is fixed, the bug -can be closed. +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. -Discussion about entirely new features should be opened in the Feature -Requests section (＠pxref{Feature Requests}) but otherwise handled in -the same way. +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE＠. See the +GNU General Public License for more details. -＠item Closed +You should have received a copy of the GNU General Public License along +with this program; if not, write to the Free Software Foundation, Inc., +59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. +＠end smallexample -＠cindex closed bug status -＠cindex bug status, closed +Also add information on how to contact you by electronic and paper mail. -When all aspects of a bug have been fixed, including code and -documentation, the bug is marked ＠dfn{Closed}. +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: -When setting the status to Closed, the group should be set to Fixed, -Works For Me, Invalid, or Rejected. +＠smallexample +Gnomovision version 69, Copyright (C) 20＠var{yy} ＠var{name of author} +Gnomovision comes with ABSOLUTELY NO WARRANTY; for details +type `show w'. This is free software, and you are welcome +to redistribute it under certain conditions; type `show c' +for details. +＠end smallexample -＠item Pending +The hypothetical commands ＠samp{show w} and ＠samp{show c} should show +the appropriate parts of the General Public License. Of course, the +commands you use may be called something other than ＠samp{show w} and +＠samp{show c}; they could even be mouse-clicks or menu items---whatever +suits your program. -＠cindex pending bug status -＠cindex bug status, pending +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a ``copyright disclaimer'' for the program, if +necessary. Here is a sample; alter the names: -You can set the status to ＠dfn{Pending} if you are waiting for a -response from the tracker item author. When the author responds, the -status is automatically reset to that of Open. Otherwise, if the +＠smallexample +＠group +Yoyodyne, Inc., hereby disclaims all copyright +interest in the program `Gnomovision' +(which makes passes at compilers) written +by James Hacker. + +＠var{signature of Ty Coon}, 1 April 1989 +Ty Coon, President of Vice +＠end group +＠end smallexample + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. + + +＠node Nodes borrowed from other projects not adapted to XEmacs, Index, Copying, Top +＠appendix Nodes borrowed from other projects not adapted to XEmacs + +＠c ######################################################################### +＠c #### I haven't seriously worked on the included material. -- stephen #### +＠c ######################################################################### + +＠menu +* Support Requests:: +* Bugs:: +* Feature Requests:: +* Patch Queue:: +* File Releases:: +* News:: +* Surveys:: +* Free Software Directories:: +＠end menu + + +＠node Support Requests, Bugs, , Top +＠chapter Support Requests + +＠cindex Support Requests + +Support requests are made to ＠value{BETA-LIST}. Developers should read +the mailing list frequently, and after a period of inactivity, browse +the ＠uref{http://list-archive.xemacs.org/xemacs-beta/,recent archives}. + + + +＠node Bugs, Feature Requests, Support Requests, Top +＠chapter Bugs + +＠strong{We don't have a tracker. We should. Describe what it should +look like here.} + +＠cindex Bugs +＠cindex priority +＠cindex bugs, priority + +Bug reports, feature requests, and discussions that are expected to lead +to bug reports or feature requests are created in +＠uref{https://sourceforge.net/bugs/?group_id=13357, Bugs}. Most +bugs should be set to a priority of 5. + +＠cindex bug-gnu-emacs +＠cindex Debian + +Developers should follow the ＠i{bug-gnu-emacs} mailing lists/newsgroup +and move bug reports into Bugs if it has not been done already. +Similarly, XEmacs bugs reported in other systems should be transfered to +＠value{XEMACSORG}. The bug may be cut and pasted into a new bug report, or a +URL to the source of the original bug report may be all that appears +in the bug report. + +A brief lifecycle of a bug proceeds something like this. A bug is +entered. A developer ensures that the Category, Priority and Group are +correct. The Group for an Open bug should be set to the version of +software in which the bug was found, or CVS if it was found in the +latest and greatest. + +The assignment of bugs in Bugs follows the honor system. If you see an +open bug that you think you could handle, assign the bug to yourself. +Bugs that remain open should be reviewed by a member of the +＠value{BOARD}, who should try to find a developer to work on the bug. + +If you fix a bug, set the resolution to Fixed and group to CVS. Please +also assign the bug to yourself if you have not done so already, so +you get credit in the +＠uref{https://sourceforge.net/tracker/reporting/?atid=113357&what=tech&span=&period=lifespan&group_id=13357#b, +reports}. If a documentation change is not required, set the status to +Closed. If a documentation change is required, set the category to +Documentation, and assign the bug to the documentation tsar, +leave the status Open, and set the priority to 3 to set it +aside in listings sorted by priority. + +See ＠ref{File Releases} for a motivation of why this process is useful. + +The rest of this section describes the categories and groups that have +been set up for the XEmacs project. + +＠menu +* Category:: +* Status:: +* Group:: +* Resolution:: +＠end menu + +＠node Category, Status, Bugs, Bugs +＠section Category + +＠cindex category +＠cindex bug category + +Several categories have been created for the XEmacs project organized by +function. They include ＠i{General}, ＠i{UI}, ＠i{MIME}, ＠i{Security}, +＠i{Documentation}, and ＠i{Contrib} + +＠table ＠b + +＠item General + +＠cindex general bug category +＠cindex bug categories, general + +The ＠dfn{General} category is used for bugs that do not belong in any of +the other categories. + +＠item UI + +＠cindex UI bug category +＠cindex bug categories, UI + +The ＠dfn{UI} category is used for bugs in the software that the user sees +such as font-lock, key definitions, menus, and customization. + +＠item MIME + +＠cindex MIME bug category +＠cindex bug categories, MIME + +The ＠dfn{MIME} category is used for bugs that pertain to MIME. + +＠item Security + +＠cindex security bug category +＠cindex bug categories, security + +The ＠dfn{Security} category is used for bugs in the security arena. At +present, XEmacs does not include any security code, so this category might +be used for PGP interaction. + +＠item Documentation + +＠cindex documentation bug category +＠cindex bug categories, documentation + +The ＠dfn{Documentation} category is used for bugs in the documentation +arena. In addition, if there are any code changes made as a result of a +bug report or feature request that require changes to the documentation, +the category of that issue should be set to Documentation after the bug +has been fixed or the feature implemented. Assign the issue to +＠i{wohler} for editing and/or writing of the documentation, and set +the priority to 3 to set the issue aside in listings sorted by priority. + +＠item Contrib + +＠cindex contrib bug category +＠cindex bug categories, contrib + +The ＠dfn{Contrib} category is used for all bugs in the contributed +software. + +＠end table + +＠node Status, Group, Category, Bugs +＠section Status + +＠cindex status +＠cindex bug status + +The bug ＠dfn{status} is divided into four sections: ＠i{Open}, +＠i{Closed}, ＠i{Deleted} and ＠i{Pending}. + +＠table ＠b + +＠item Open + +＠cindex open bug status +＠cindex bug status, open + +When bugs are initially created, they are marked ＠dfn{Open}. + +＠cindex discussing bugs +＠cindex bugs, discussing +＠cindex features, discussing + +The Bugs and Feature Requests sections are also used as a method to +get the ball rolling among developers. They are used to register what +we feel we should work on. For example, a developer may have questions +about the way XEmacs handles MIME that we should discuss before we +attempt to fix it: What do other people do? How should we attack this? +That developer opens a bug report in the MIME category and a +discussion ensues. Once the disposition of the issue is resolved, the +bug is assigned to a developer. Later, when the bug is fixed, the bug +can be closed. + +Discussion about entirely new features should be opened in the Feature +Requests section (＠pxref{Feature Requests}) but otherwise handled in +the same way. + +＠item Closed + +＠cindex closed bug status +＠cindex bug status, closed + +When all aspects of a bug have been fixed, including code and +documentation, the bug is marked ＠dfn{Closed}. + +When setting the status to Closed, the group should be set to Fixed, +Works For Me, Invalid, or Rejected. + +＠item Pending + +＠cindex pending bug status +＠cindex bug status, pending + +You can set the status to ＠dfn{Pending} if you are waiting for a +response from the tracker item author. When the author responds, the +status is automatically reset to that of Open. Otherwise, if the author doesn't respond within 14 days, then the item is given a status of Deleted. ＠＠ -2238,9 +2922,9 ＠＠ release. Just be sure to mention the issue number in the ChangeLog so that it can be noted in the next release announcement. -＠item mh-e* +＠item XE* -Bugs in groups starting with mh-e have either been found in the given +Bugs in groups starting with XE have either been found in the given version if the Status is Open, or fixed in the given version if the Status is Closed. ＠＠ -2362,12 +3046,10 ＠＠ ＠node Feature Requests, Patch Queue, Bugs, Top ＠chapter Feature Requests -＠c Edited: stephen 2005-01-18 - ＠cindex Feature Requests Developers should check the -＠uref{https://sourceforge.net/patch/?group_id=13357, Feature Requests} +Feature Requests occasionally for new feature requests and comment on the feature's usefulness and integrity. Unless a positive comment has ＠c #### define "reasonable" ＠＠ -2387,8 +3069,6 ＠＠ ＠node Patch Queue, File Releases, Feature Requests, Top ＠chapter Patch Queue -＠c Edited: stephen 2005-01-18 - ＠cindex Patch Queue Developers should check ＠value{PATCHES-LIST} ＠＠ -2408,8 +3088,6 ＠＠ ＠node File Releases, News, Patch Queue, Top ＠chapter File Releases -＠c Edited: stephen 2005-01-18 - ＠strong{This node and all of its children need to be reviewed and adapted to the XEmacs process. One topic that ＠emph{must} be addressed is regenerating and checking in generated files.} ＠＠ -2444,8 +3122,6 ＠＠ ＠node Release Schedule, Release Prerequisites, File Releases, File Releases ＠section Release Schedule -＠c Edited: stephen 2005-01-18 - ＠strong{Totally bogus for XEmacs historical practice, probably totally unrealistic as future policy.} ＠＠ -2508,8 +3184,6 ＠＠ ＠node Release Prerequisites, Updating NEWS, Release Schedule, File Releases ＠section Release Prerequisites -＠c Edited: stephen 2005-01-18 only to fix a makeinfo error - ＠cindex Release Prerequisites ＠cindex Coding Conventions ＠cindex Emacs Lisp Coding Conventions ＠＠ -2576,12 +3250,12 ＠＠ ＠end enumerate The previous steps usually catch most items. To use a finer sieve, use -the following commands. These assume that the last version of the XEmacs -package was 6.0. +the following commands. These assume that the last version of XEmacs +was 21.4.20. ＠example - cvs log -rmh-e-6_0 - cvs diff -rmh-e-6_0 + cvs log -rr21-4-20 + cvs diff -rr21-4-20 ＠end example See section ＠ref{Updating ChangeLogs} before checking in this file. ＠＠ -2710,15 +3384,21 ＠＠ ＠item ＠strong{Module} ＠tab ＠strong{Tarball} -＠item src -＠tab mh-e-M.N.tgz +＠item Full distro +＠tab xemacs-X.Y.Z.tar.gz -＠item doc -＠tab mh-e-doc-M.N.tgz +＠item Patch +＠tab xemacs-X.Y.Z-X.Y.(++Z).patch.gz -＠item contrib -＠tab mh-e-contrib-M.N.tgz +＠item Sources only +＠tab xemacs-X.Y.Z-src.tar.gz +＠item Compiled Lisp +＠tab xemacs-X.Y.Z-elc.tar.gz + +＠item Formatted Info +＠tab xemacs-X.Y.Z-info.tar.gz + ＠end multitable ＠end quotation ＠＠ -2730,40 +3410,8 ＠＠ ＠cindex version numbers The tarballs listed in the table above are built as follows: - -＠itemize - -＠cindex CVS, co - -＠item If ＠var{module} has not been checked out -already, check it out: - -＠example -export CVS_RSH=ssh -cvs -d -z3 $USER＠＠cvs.mh-e.sourceforge.net:/cvsroot/mh-e co -r ＠var{release} ＠var{module} -＠end example - -＠item If ＠var{module} has been checked out -already, set the sticky tag for the release: - -＠example -cvs update -r ＠var{release} -＠end example - -＠item Build the tarball. - -＠example -cd ＠var{module} -make dist -＠end example - -＠end itemize -The ＠code{make dist} command ensures that the tarball is named correctly -and that the tar extracts in a subdirectory that has the same name as -the tarball's prefix. For example, if ＠var{release} was mh-e-5_2, then -the tarball would be named mh-e-5.2.tgz and would extract into the -directory named mh-e-5.2. +＠strong{Write me!} ＠node Creating ＠value{XEMACSORG} Releases, Updating the Tracker, Creating Tarballs, File Releases ＠section Creating ＠value{XEMACSORG} Releases ＠＠ -2772,61 +3420,16 ＠＠ ＠cindex releases ＠cindex tarballs, making -First, create the tarballs (＠pxref{Creating Tarballs}). Then -＠uref{https://sourceforge.net/project/admin/editpackages.php?group_id=13357, -add the release} per the instructions in -＠uref{https://sourceforge.net/docman/display_doc.php?docid=6445&group_id=1#filereleasesteps, -The File Release System}. Be sure to check the box labeled -＠code{Preserve my pre-formatted text}. Use the entire ＠file{README} -file for the release notes and the appropriate section of the -＠file{NEWS} file for the Change Log. - -If there were any beta releases leading up to this release, -＠uref{https://sourceforge.net/project/admin/editreleases.php?package_id=11309&group_id=13357, -edit the release} and set the Status to Hidden. +＠strong{Write me!} ＠node Updating the Tracker, Announce the Release, Creating ＠value{XEMACSORG} Releases, File Releases ＠section Updating the Tracker ＠cindex Updating the Tracker -After XEmacs is released, update the tracker. First, change the group to -mh-e-doc-(a)var{m.n} (for example, mh-e-doc-1.3) for all open -＠uref{https://sourceforge.net/tracker/?group_id=13357&atid=113357, -bugs} and -＠uref{https://sourceforge.net/tracker/?group_id=13357&atid=363357&, -features} with a category of Documentation and a group of CVS. The -list is restricted to open issues since it is possible that an issue -was given a category of Documention for inclusion in the release -notes and then closed. Such an issue would not force a manual update. - -Then change the name of the group CVS to mh-e-(a)var{m.n} for both -＠uref{https://sourceforge.net/tracker/admin/index.php?group_id=13357&atid=113357&add_group=1, -bugs} and -＠uref{https://sourceforge.net/tracker/admin/index.php?group_id=13357&atid=363357&add_group=1, -features}. For example, when XEmacs version 6.0 is released, rename the -CVS group to mh-e-6.0. Then create a new CVS group. This should be -done for doc and contrib releases too. - -An exception to this occurs when releasing beta releases. The group -name in the series of beta releases leading up to the actual release -is reused. That way, in the end all the existing issues are left -pointing to the actual release rather than a beta. For example, CVS -would first be renamed to mh-e-6.1.90 which would in turn be renamed -to mh-e-6.1.91 which would in turn be renamed to mh-e-7.0. - -Another oddity occurs when you make a patch release. When you change -the name of the group from CVS to mh-e-(a)var{m.n.p}, you will probably -effect mainline work. So go back to -＠uref{https://sourceforge.net/tracker/?group_id=13357&atid=113357, -bugs} and -＠uref{https://sourceforge.net/tracker/?group_id=13357&atid=363357, -features}, and browse all issues with the new mh-e-(a)var{m.n.p} group -name. Perform a mass group name change from mh-e-(a)var{m.n.p} to CVS -for all issues that do not appear in the patch release. It may also be -easier to add a new group name of mh-e-(a)var{m.n.p} and set the group -of the items in the patch release to it. +＠strong{Write me! (and install a Tracker!)} + ＠node Announce the Release, Updating the Emacs Repository, Updating the Tracker, File Releases ＠section Announce the Release ＠＠ -2838,8 +3441,6 ＠＠ ＠node Updating the Emacs Repository, Updating the Debian Package, Announce the Release, File Releases ＠section Updating the Emacs Repository -＠c Edited: stephen 2005-01-19 - ＠strong{Needs review. Although on the face of it this obviously has nothing to do with XEmacs, in fact there are probably hints here for XEmacs release engineers.} ＠＠ -3018,6 +3619,7 ＠＠ time to put the new code on the Emacs branch. This makes it possible to detect changes to XEmacs that an Emacs developer may make later. + ＠node Updating the Debian Package, Updating the XEmacs Package, Updating the Emacs Repository, File Releases ＠section Updating the Debian Package ＠＠ -3025,9 +3627,9 ＠＠ ＠cindex Debian Package, Updating ＠cindex Debian -This task is the duty of Peter Galbraith <＠i{psg＠(a)debian.org}&gt;. It may -be useful to others to want to make an unofficial package of the CVS -tree. +＠strong{Edit me! Or maybe not: currently the various distros have +their own maintainers. It might be useful for Debian/Ubuntu because of +the complex Debian Emacs policy.} To build a Debian package, you'll need to have installed the Debian package ＠code{build-essential} as well as those listed in the ＠＠ -3085,7 +3687,6 ＠＠ ＠node Updating the Online Documentation, Updating the Free Software Directories, Updating the XEmacs Package, File Releases ＠section Updating the Online Documentation -＠c Edited: stephen 2005-01-19 ＠strong{Adrian, please review.} ＠cindex Updating the Online Documentation ＠＠ -3135,7 +3736,6 ＠＠ ＠node Updating the Free Software Directories, After the Release, Updating the Online Documentation, File Releases ＠section Updating the Free Software Directories -＠c Edited: stephen 2005-01-18 ＠strong{Add FreshMeat, at least.} Update the ＠i{source-tarball} and ＠i{version} fields in the FSF/UNESCO ＠＠ -3181,8 +3781,6 ＠＠ ＠node News, Surveys, File Releases, Top ＠chapter News -＠c Edited: stephen 2005-01-18 - ＠strong{Needs review.} ＠cindex News ＠＠ -3214,8 +3812,7 ＠＠ As only the first paragraph is shown on the ＠value{XEMACSORG} front page, it should be written wisely. Emulate the look and feel of previous news postings. The first sentence should be the same as the first sentence -in the description on the -＠uref{https://sourceforge.net/projects/mh-e/, Summary} page. The +in the description on the home page. The following sentences are typically copied from the first paragraph of the release notes and should briefly describe the benefit of the release or otherwise entice the reader to read further. The contrib ＠＠ -3227,12 +3824,6 ＠＠ Read on for more details. ＠end example -Use the following for the second paragraph: - -＠example - Project home page at: http://mh-e.sourceforge.net/. -＠end example - Finally, include the release notes from ＠file{NEWS}. Because the introductory paragraph was already used, include the release notes starting with the ``New Features'' item. To avoid ugly wrapping, first ＠＠ -3265,18 +3856,17 ＠＠ ＠node Surveys, Free Software Directories, News, Top ＠chapter Surveys -＠c Edited: stephen 2005-01-18 - ＠strong{Interesting. Should we do this, maybe?} ＠cindex Surveys The project admin may create -＠uref{https://sourceforge.net/survey/?group_id=13357, Surveys}. The +＠c #### need to fix the group_id +＠uref{https://sourceforge.net/survey/?group_id=, Surveys}. The interface is backwards. First you create questions and note the question IDs. Then you create a survey and list the question IDs. -＠node Free Software Directories, Copying, Surveys, Top +＠node Free Software Directories, , Surveys, Top ＠chapter Free Software Directories ＠cindex FSF/UNESCO Free Software Directory ＠＠ -3340,404 +3930,8 ＠＠ ＠c * Public Forums:: ＠c * Anonymous FTP Space:: ＠c ＠end menu - -＠node Copying, Index, Free Software Directories, Top -＠appendix GNU GENERAL PUBLIC LICENSE -＠center Version 2, June 1991 - -＠display -Copyright ＠copyright{} 1989, 1991 Free Software Foundation, Inc. -59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - -Everyone is permitted to copy and distribute verbatim copies -of this license document, but changing it is not allowed. -＠end display - -＠appendixsec Preamble - - The licenses for most software are designed to take away your -freedom to share and change it. By contrast, the GNU General Public -License is intended to guarantee your freedom to share and change free -software---to make sure the software is free for all its users. This -General Public License applies to most of the Free Software -Foundation's software and to any other program whose authors commit to -using it. (Some other Free Software Foundation software is covered by -the GNU Library General Public License instead.) You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -this service if you wish), that you receive source code or can get it -if you want it, that you can change the software or use pieces of it -in new free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid -anyone to deny you these rights or to ask you to surrender the rights. -These restrictions translate to certain responsibilities for you if you -distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must give the recipients all the rights that -you have. You must make sure that they, too, receive or can get the -source code. And you must show them these terms so they know their -rights. - - We protect your rights with two steps: (1) copyright the software, and -(2) offer you this license which gives you legal permission to copy, -distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain -that everyone understands that there is no warranty for this free -software. If the software is modified by someone else and passed on, we -want its recipients to know that what they have is not the original, so -that any problems introduced by others will not reflect on the original -authors' reputations. - - Finally, any free program is threatened constantly by software -patents. We wish to avoid the danger that redistributors of a free -program will individually obtain patent licenses, in effect making the -program proprietary. To prevent this, we have made it clear that any -patent must be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and -modification follow. - -＠iftex -＠appendixsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION -＠end iftex -＠ifinfo -＠center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION -＠end ifinfo - -＠enumerate 0 -＠item -This License applies to any program or other work which contains -a notice placed by the copyright holder saying it may be distributed -under the terms of this General Public License. The ``Program,'' below, -refers to any such program or work, and a ``work based on the Program'' -means either the Program or any derivative work under copyright law: -that is to say, a work containing the Program or a portion of it, -either verbatim or with modifications and/or translated into another -language. (Hereinafter, translation is included without limitation in -the term ``modification.'') Each licensee is addressed as ``you.'' - -Activities other than copying, distribution and modification are not -covered by this License; they are outside its scope. The act of -running the Program is not restricted, and the output from the Program -is covered only if its contents constitute a work based on the -Program (independent of having been made by running the Program). -Whether that is true depends on what the Program does. - -＠item -You may copy and distribute verbatim copies of the Program's -source code as you receive it, in any medium, provided that you -conspicuously and appropriately publish on each copy an appropriate -copyright notice and disclaimer of warranty; keep intact all the -notices that refer to this License and to the absence of any warranty; -and give any other recipients of the Program a copy of this License -along with the Program. - -You may charge a fee for the physical act of transferring a copy, and -you may at your option offer warranty protection in exchange for a fee. - -＠item -You may modify your copy or copies of the Program or any portion -of it, thus forming a work based on the Program, and copy and -distribute such modifications or work under the terms of Section 1 -above, provided that you also meet all of these conditions: - -＠enumerate a -＠item -You must cause the modified files to carry prominent notices -stating that you changed the files and the date of any change. - -＠item -You must cause any work that you distribute or publish, that in -whole or in part contains or is derived from the Program or any -part thereof, to be licensed as a whole at no charge to all third -parties under the terms of this License. - -＠item -If the modified program normally reads commands interactively -when run, you must cause it, when started running for such -interactive use in the most ordinary way, to print or display an -announcement including an appropriate copyright notice and a -notice that there is no warranty (or else, saying that you provide -a warranty) and that users may redistribute the program under -these conditions, and telling the user how to view a copy of this -License. (Exception: if the Program itself is interactive but -does not normally print such an announcement, your work based on -the Program is not required to print an announcement.) -＠end enumerate - -These requirements apply to the modified work as a whole. If -identifiable sections of that work are not derived from the Program, -and can be reasonably considered independent and separate works in -themselves, then this License, and its terms, do not apply to those -sections when you distribute them as separate works. But when you -distribute the same sections as part of a whole which is a work based -on the Program, the distribution of the whole must be on the terms of -this License, whose permissions for other licensees extend to the -entire whole, and thus to each and every part regardless of who wrote it. - -Thus, it is not the intent of this section to claim rights or contest -your rights to work written entirely by you; rather, the intent is to -exercise the right to control the distribution of derivative or -collective works based on the Program. - -In addition, mere aggregation of another work not based on the Program -with the Program (or with a work based on the Program) on a volume of -a storage or distribution medium does not bring the other work under -the scope of this License. - -＠item -You may copy and distribute the Program (or a work based on it, -under Section 2) in object code or executable form under the terms of -Sections 1 and 2 above provided that you also do one of the following: - -＠enumerate a -＠item -Accompany it with the complete corresponding machine-readable -source code, which must be distributed under the terms of Sections -1 and 2 above on a medium customarily used for software interchange; or, - -＠item -Accompany it with a written offer, valid for at least three -years, to give any third party, for a charge no more than your -cost of physically performing source distribution, a complete -machine-readable copy of the corresponding source code, to be -distributed under the terms of Sections 1 and 2 above on a medium -customarily used for software interchange; or, - -＠item -Accompany it with the information you received as to the offer -to distribute corresponding source code. (This alternative is -allowed only for noncommercial distribution and only if you -received the program in object code or executable form with such -an offer, in accord with Subsection b above.) -＠end enumerate - -The source code for a work means the preferred form of the work for -making modifications to it. For an executable work, complete source -code means all the source code for all modules it contains, plus any -associated interface definition files, plus the scripts used to -control compilation and installation of the executable. However, as a -special exception, the source code distributed need not include -anything that is normally distributed (in either source or binary -form) with the major components (compiler, kernel, and so on) of the -operating system on which the executable runs, unless that component -itself accompanies the executable. - -If distribution of executable or object code is made by offering -access to copy from a designated place, then offering equivalent -access to copy the source code from the same place counts as -distribution of the source code, even though third parties are not -compelled to copy the source along with the object code. - -＠item -You may not copy, modify, sublicense, or distribute the Program -except as expressly provided under this License. Any attempt -otherwise to copy, modify, sublicense or distribute the Program is -void, and will automatically terminate your rights under this License. -However, parties who have received copies, or rights, from you under -this License will not have their licenses terminated so long as such -parties remain in full compliance. - -＠item -You are not required to accept this License, since you have not -signed it. However, nothing else grants you permission to modify or -distribute the Program or its derivative works. These actions are -prohibited by law if you do not accept this License. Therefore, by -modifying or distributing the Program (or any work based on the -Program), you indicate your acceptance of this License to do so, and -all its terms and conditions for copying, distributing or modifying -the Program or works based on it. - -＠item -Each time you redistribute the Program (or any work based on the -Program), the recipient automatically receives a license from the -original licensor to copy, distribute or modify the Program subject to -these terms and conditions. You may not impose any further -restrictions on the recipients' exercise of the rights granted herein. -You are not responsible for enforcing compliance by third parties to -this License. - -＠item -If, as a consequence of a court judgment or allegation of patent -infringement or for any other reason (not limited to patent issues), -conditions are imposed on you (whether by court order, agreement or -otherwise) that contradict the conditions of this License, they do not -excuse you from the conditions of this License. If you cannot -distribute so as to satisfy simultaneously your obligations under this -License and any other pertinent obligations, then as a consequence you -may not distribute the Program at all. For example, if a patent -license would not permit royalty-free redistribution of the Program by -all those who receive copies directly or indirectly through you, then -the only way you could satisfy both it and this License would be to -refrain entirely from distribution of the Program. - -If any portion of this section is held invalid or unenforceable under -any particular circumstance, the balance of the section is intended to -apply and the section as a whole is intended to apply in other -circumstances. - -It is not the purpose of this section to induce you to infringe any -patents or other property right claims or to contest validity of any -such claims; this section has the sole purpose of protecting the -integrity of the free software distribution system, which is -implemented by public license practices. Many people have made -generous contributions to the wide range of software distributed -through that system in reliance on consistent application of that -system; it is up to the author/donor to decide if he or she is willing -to distribute software through any other system and a licensee cannot -impose that choice. - -This section is intended to make thoroughly clear what is believed to -be a consequence of the rest of this License. - -＠item -If the distribution and/or use of the Program is restricted in -certain countries either by patents or by copyrighted interfaces, the -original copyright holder who places the Program under this License -may add an explicit geographical distribution limitation excluding -those countries, so that distribution is permitted only in or among -countries not thus excluded. In such case, this License incorporates -the limitation as if written in the body of this License. - -＠item -The Free Software Foundation may publish revised and/or new versions -of the General Public License from time to time. Such new versions will -be similar in spirit to the present version, but may differ in detail to -address new problems or concerns. - -Each version is given a distinguishing version number. If the Program -specifies a version number of this License which applies to it and ``any -later version,'' you have the option of following the terms and conditions -either of that version or of any later version published by the Free -Software Foundation. If the Program does not specify a version number of -this License, you may choose any version ever published by the Free Software -Foundation. - -＠item -If you wish to incorporate parts of the Program into other free -programs whose distribution conditions are different, write to the author -to ask for permission. For software which is copyrighted by the Free -Software Foundation, write to the Free Software Foundation; we sometimes -make exceptions for this. Our decision will be guided by the two goals -of preserving the free status of all derivatives of our free software and -of promoting the sharing and reuse of software generally. - -＠iftex -＠heading NO WARRANTY -＠end iftex -＠ifinfo -＠center NO WARRANTY -＠end ifinfo - -＠item -BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY -FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW＠. EXCEPT WHEN -OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES -PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED -OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF -MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE＠. THE ENTIRE RISK AS -TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU＠. SHOULD THE -PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, -REPAIR OR CORRECTION. - -＠item -IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING -WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR -REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, -INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING -OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED -TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY -YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER -PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE -POSSIBILITY OF SUCH DAMAGES. -＠end enumerate - -＠iftex -＠heading END OF TERMS AND CONDITIONS -＠end iftex -＠ifinfo -＠center END OF TERMS AND CONDITIONS -＠end ifinfo - -＠page -＠appendixsec How to Apply These Terms to Your New Programs - - If you develop a new program, and you want it to be of the greatest -possible use to the public, the best way to achieve this is to make it -free software which everyone can redistribute and change under these terms. - - To do so, attach the following notices to the program. It is safest -to attach them to the start of each source file to most effectively -convey the exclusion of warranty; and each file should have at least -the ``copyright'' line and a pointer to where the full notice is found. - -＠smallexample -＠var{one line to give the program's name and an idea of what it does.} -Copyright (C) 19＠var{yy} ＠var{name of author} - -This program is free software; you can redistribute it and/or -modify it under the terms of the GNU General Public License -as published by the Free Software Foundation; either version 2 -of the License, or (at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE＠. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License along -with this program; if not, write to the Free Software Foundation, Inc., -59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. -＠end smallexample - -Also add information on how to contact you by electronic and paper mail. - -If the program is interactive, make it output a short notice like this -when it starts in an interactive mode: - -＠smallexample -Gnomovision version 69, Copyright (C) 20＠var{yy} ＠var{name of author} -Gnomovision comes with ABSOLUTELY NO WARRANTY; for details -type `show w'. This is free software, and you are welcome -to redistribute it under certain conditions; type `show c' -for details. -＠end smallexample - -The hypothetical commands ＠samp{show w} and ＠samp{show c} should show -the appropriate parts of the General Public License. Of course, the -commands you use may be called something other than ＠samp{show w} and -＠samp{show c}; they could even be mouse-clicks or menu items---whatever -suits your program. - -You should also get your employer (if you work as a programmer) or your -school, if any, to sign a ``copyright disclaimer'' for the program, if -necessary. Here is a sample; alter the names: - -＠smallexample -＠group -Yoyodyne, Inc., hereby disclaims all copyright -interest in the program `Gnomovision' -(which makes passes at compilers) written -by James Hacker. - -＠var{signature of Ty Coon}, 1 April 1989 -Ty Coon, President of Vice -＠end group -＠end smallexample - -This General Public License does not permit incorporating your program into -proprietary programs. If your program is a subroutine library, you may -consider it more useful to permit linking proprietary applications with the -library. If this is what you want to do, use the GNU Library General -Public License instead of this License. -＠node Index, , Copying, Top +＠node Index, , Nodes borrowed from other projects not adapted to XEmacs, Top ＠unnumbered Index ＠printindex cp _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches