[Nut-upsdev] backporting changes from the trunk [was: Re: [Nut-upsuser] 2.2.2-pre2 64 bit rpm tested on openSUSE 10.3]

[Arjen de Korte]

> 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