diff options
Diffstat (limited to 'HACKING')
| -rw-r--r-- | HACKING | 79 |
1 files changed, 43 insertions, 36 deletions
@@ -145,6 +145,17 @@ * For more information, refer to the extensive discussion associated with automake bug#13578. +=========================================================================== += Setting the development environment + +* The required and optional dependencies used by Automake and its test suite + can be automatically fetched using the GNU Guix package manager with the + following command: + + $ guix environment automake --ad-hoc \ + gettext help2man texinfo libtool flex bison dejagnu zip icedtea \ + python gcc-toolchain gfortran pkg-config vala + ============================================================================ = Working with git @@ -156,58 +167,48 @@ latest stable version of Autoconf installed and available early in your PATH. -* The Automake git tree currently carries three basic branches: 'micro', - 'maint' and 'master'. +* The Automake git tree currently carries three basic branches: 'master', + 'next' and 'maint'. -* The 'micro' branch, reserved to changes that should go into the next - micro release; so it will just see fixes for regressions, trivial - bugs, or documentation issues, and no "active" development whatsoever. - Since emergency regression-fixing or security releases could be cut - from this branch at any time, it should always be kept in a releasable - state. - -* The 'maint' branch is where the development of the next minor release +* The 'master' branch is where the development of the next release takes place. It should be kept in a stable, almost-releasable state, to simplify testing and deploying of new minor version. Note that this is not a hard rule, and such "stability" is not expected to be - absolute (emergency releases are cut from the 'micro' branch anyway). + absolute (emergency releases are cut from the 'maint' branch anyway). + +* When planning a release a dedicated branch should be created and after + the release is done, the release branch is to be merged both into the + 'master' branch and the 'maint' branch. -* The 'master' branch is reserved for the development of the next major +* Besides merges from release branches, the 'maint' branch can contain + fixes for regressions, trivial bugs, or documentation issues, that + will be part of an emergency regression-fixing or security releases. + As a consequence it should always be kept in a releasable state and no + "active" development should be done whatsoever. + +* The 'next' branch is reserved for the development of the next major release. Experimenting a little is OK here, but don't let the branch grow too unstable; if you need to do exploratory programming or over-arching change, you should use a dedicated topic branch, and only merge that back once it is reasonably stable. -* The 'micro' branch should be kept regularly merged into the 'maint' - branch, and the 'maint' branch into the 'master' branch. It is advisable - to merge only after a set of related commits have been applied, to avoid - introducing too much noise in the history. +* The 'master' branch should be kept regularly merged into the 'next' + branch. It is advisable to merge only after a set of related + commits have been applied, to avoid introducing too much noise in + the history. * There may be a number of longer-lived feature branches for new developments. They should be based off of a common ancestor of all active branches to which the feature should or might be merged later. -* After a new minor release is done, the 'maint' branch is to be merged - into the 'micro' branch, and then a "new" 'maint' branch created - stemming from the resulting commit. - Similarly, after a new major release is done, the 'master' branch is to - be merged into both the 'micro' and 'maint' branches, and then "new" - 'master' branch created stemming from the resulting commit. - -* When fixing a bug (especially a long-standing one), it may be useful - to commit the fix to a new temporary branch based off the commit that - introduced the bug. Then this "bugfix branch" can be merged into all - the active branches descending from the buggy commit. This offers a - simple way to fix the bug consistently and effectively. - * When merging, prefer 'git merge --log' over plain 'git merge', so that a later 'git log' gives an indication of which actual patches were merged even when they don't appear early in the list. -* The 'master', 'maint' and 'micro' branches should not be rewound, i.e., - should always fast-forward, except maybe for privacy issues. For - feature branches, the announcement for the branch should document - the rewinding policy. +* The 'master', 'maint' and 'next' branches should not be rewound, + i.e., should always fast-forward, except maybe for privacy issues. + For feature branches, the announcement for the branch should + document the rewinding policy. If a topic branch is expected to be rewound, it is good practice to put it in the 'experimental/*' namespace; for example, a rewindable branch dealing with Vala support could be named like "experimental/vala-work". @@ -274,6 +275,12 @@ ... removed in commit 'v1.11-1674-g02e9072' of 01-01-2012, "dist: ditch support for lzma"... +* If the commit is a tiny change that is exempt from copyright paperwork, the + commit message should contain a separate line after the detailed list of + touched files like the following: + + Copyright-paperwork-exempt: yes + ============================================================================ = Test suite @@ -380,11 +387,11 @@ <https://savannah.gnu.org/projects/automake>. Be sure to link a version to the complete announcement (from the version you sent to the automake list, as get archived on - <http://lists.gnu.org/archive/html/automake/>). + <https://lists.gnu.org/archive/html/automake/>). ----- -Copyright (C) 2003-2017 Free Software Foundation, Inc. +Copyright (C) 2003-2018 Free Software Foundation, Inc. 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 @@ -397,7 +404,7 @@ 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, see <http://www.gnu.org/licenses/>. +along with this program. If not, see <https://www.gnu.org/licenses/>. Local Variables: mode: text |