From: Stefano Lattarini Date: Wed, 15 May 2013 20:54:15 +0000 (+0200) Subject: Merge branch 'micro' into maint X-Git-Tag: v1.13b~32 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=52a760136d216ab867f02fd295d0b3d77d1ad438;p=thirdparty%2Fautomake.git Merge branch 'micro' into maint * micro: post-release: micro version bump (1.13.2a) release: stable micro release 1.13.2 vala tests: skip in a cross compiler setup HACKING: miscellaneous fixes, updates and enhancements NEWS: minor improvements to wording (about new versioning scheme) Signed-off-by: Stefano Lattarini --- 52a760136d216ab867f02fd295d0b3d77d1ad438 diff --cc HACKING index b52660089,cebcb7246..435eb7777 --- a/HACKING +++ b/HACKING @@@ -35,19 -35,8 +35,18 @@@ which should be updated by hand whenever the GPL gets updated (which shouldn't happen that often anyway :-) - * Changes other than bug fixes must be mentioned in NEWS. Important - bug fixes should be mentioned in NEWS, too. + * Changes other than *trivial* bug fixes must be mentioned in NEWS. +* Changes which are potentially controversial, require a non-trivial + plan, or must be implemented gradually with a roadmap spanning several + releases (either minor or major) should be discussed on the list, + and have a proper entry in the PLANS directory. This entry should be + always committed in the "maint" branch, even if the change it deals + with is only for the master branch, or a topic branch. Usually, in + addition to this, it is useful to open a "wishlist" report on the + Automake debbugs tracker, to keep the idea more visible, and have the + discussions surrounding it easily archived in a central place. + ============================================================================ = Naming @@@ -200,13 -191,12 +201,13 @@@ 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' and 'maint' branches should not be rewound, i.e., should - always fast-forward, except maybe for privacy issues. For 'next' - (if that will ever be implemented), and for feature branches, the - announcement for the branch should document rewinding policy. If a - topic branch is expected to be rewound, it is good practice to put + * 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. It is usually a good idea to keep rewindable - branches in the 'experimental/*' "namespace"; i.e., give them names - like 'experimental/testsuite-work' or 'experimental/djgpp-for-WinNT'. ++ 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". ============================================================================ = Writing a good commit message