## page was renamed from EmacsenTeam = Debian Emacsen team = == Contact == * debian-emacsen@lists.debian.org * #debian-emacs on irc.debian.org == Scope == * Emacs Lisp addon packages * GNU Emacs backports i.e. does not (yet) include any main archive Emacsen themselves. == Membership == Defined by our [[https://salsa.debian.org/groups/emacsen-team/-/group_members|salsa group]] (not (yet) by tracker.debian.org). We typically grant full membership to non-DDs who * are already in the Uploaders field for several team packages, at least some of which they prepared for NEW themselves; and * know when to ask for review before pushing, especially when it comes to importing new upstream releases. == Addons packaging policy == * All projects must have a real upstream. This can be a release tarball, VCS, or webpage with a bare file-version.el. The important point is that Upstream-Contact must be in control of releases. This means that projects that only exist on "emacswiki.org" should not be part of Debian. If you find a package that has ''Emacswiki'' as the source, and doesn't have a new project upstream, please bring it to the attention of the team. * All binary packages installing into site-lisp/elpa (in particular all packages using dh_elpa) should be named `elpa-foo` where `foo` is the ELPA package name. + Note that this is often different to the upstream repository name. E.g. Binary package `elpa-f` is called 'f.el' by upstream. * Source package names are upstream project names. Prefix 'emacs-' or suffix '-el' if and only if that name is too generic. As a special case, if the upstream project name ends in '.el', replace this with '-el'. I.e. Do not add an `elpa-` prefix to the source package name. * We use one git repository for each upstream package. * We keep the upstream source in the packaging git repository. * Versions should be based on those used by the upstream author, not e.g. MELPA + Though if there is a discrepancy, try to get it resolved with upstream before uploading. * The ELPA version declared in a package's headers should match its actual version in all but unusual cases; This is needed for proper dependency resolution, but many upstreams rely on MELPA infrastructure to generate correct headers. + The dh_elpa(1) man page documents the most elegant method to generate this metadata at build time. * Maintainer field should be `Debian Emacsen team ` * We generally expect to be able to work on packages as a [[Teams/DebianEmacsenTeam/Team|team]] * See [[Teams/DebianEmacsenTeam/elpa-hello|elpa-hello]] for sample debian/* files snippets that use dh_elpa and follow policy. == `:core` ELPA packages == * "`:core` ELPA packages" is upstream's name for Emacs Lisp packages that are included in Emacs releases but which also see independent new releases to GNU ELPA, more frequently than Emacs as a whole gets released. * For some of these packages, we package them twice: there is the copy installed when you install Emacs, and there is also an `elpa-` package. This is so that we can offer users newer releases than they would otherwise get in our stable releases, given how our release cycle and Emacs's do not line up well. * This scheme only works if '''addon packages are never allowed to fall behind the version shipped with Emacs'''. That is, after Emacs is updated in Debian, but before our freeze begins, '''all `:core` ELPA packages must be updated to at least the version shipped with Emacs'''. * Otherwise, the version shipped with Emacs can take precedence over the version shipped separately, which is bad for users. See also Debian bug#1035757. == Meetings == * [[Teams/DebianEmacsenTeam/Meetings/DC15]] * [[Teams/DebianEmacsenTeam/Meetings/DC16]] * [[Teams/DebianEmacsenTeam/Meetings/DC17]] == Subpages == * [[Teams/DebianEmacsenTeam/Tips|Tips]] == Useful links == * [[https://salsa.debian.org/emacsen-team/wiki|Old team wiki content]] (not yet fully migrated to here) * [[https://tracker.debian.org/teams/emacsen/|Tracker overview of all team packages]]