> One thing that we need to remember is that every commit message on > branches/Testing should refer back to one (or more) changesets in the > trunk. Otherwise, it is next to impossible to figure out which changes > still need to be merged. Another reason for this is traceability - if > we don't know that a change on branches/Testing has actually been > kicking around on the trunk for a while (at the very least, it should > be run through buildbot, or be built on another developer's machine), > then there is little reason to maintain the Testing branch (and I do > think it helps to keep it separate).
I'm not so sure about that last remark. Most problems only surface when we release a new version. Fortunately, some people are testing the -pre versions as well, so this also gives valueable feedback. On the other hand, the feedback we get from the SVN versions in the trunk/ and branches/Testing/ has been limited (if any at all). The best (only?) feedback for SVN is from the buildbot's, but we don't need to have separate versions in trunk/ and branches/Testing/ for that. I really think that having both trunk/ and branches/Testing/ is a burden now, instead of something that serves a purpose. > Assuming that we copy the 2.4.x branch from the trunk, we will have a > better chance at making sure things don't slip through the cracks, > since we will effectively start from a clean slate at that point. Personally, I think we would be better off without branches/Testing/ at all and pulling the -pre(x) and -stable versions from the trunk/ directly. New developments should be put in a branches/<new name>/ and be merged back in the trunk when finalized. By doing so, it would be a lot clearer to separate bug fixes and new developments. Best regards, Arjen _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
