Please recognize the following points: 1. We _never_ change anything on just a branch. Every branch change has to correspond to an equal or similar change in the trunk of the branch. There are just a few rare exceptions (perhaps a security fix does only apply to a certain branch), but unless you can strongly argue on them you are not allowed to break the role.
2. This means we always first change things on HEAD for OpenPKG-CURRENT. From there we do the Merge From Current (MFC) to the (currently) OPENPKG_1_STABLE branch. From there we to do the Merge From Stable to the (currently) OPENPKG_1_2_SOLID branch. At least _logically_. If more practical, _technically_ you can do the merges by copying and post-editing instead of "cvs update -j" commands, of course. 3. We try to mark all merges with the commit message prefixes "MFC:" and "MFS:" plus either the revision number of the take version (if you like) or at least a unambiguous message which later allows 1:1 correspondence to the revision merged. This is important to make sure one can identify the merges later. Only if you strictly follow these rules we can ensure that forthcoming OpenPKG 2.0 or a perhaps forthcoming OpenPKG 1.3 includes all fixes previous releases already contained. For example, today we fixed OpenSSH for CURRENT and for 1.2-SOLID, but not for 1-STABLE. This way a perhaps forthcoming OpenPKG 1.3 would again have the same bug not fixed. So, please be both very careful (to not do the wrong merges) and complete (not to forget a branch at all). Thanks. The OpenPKG Project Ralf S. Engelschall http://www.openpkg.org/ [EMAIL PROTECTED] Cross-Platform Software Packaging www.engelschall.com ______________________________________________________________________ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED]
