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

On Sun, Apr 20, 2008 at 10:46 AM, Arjen de Korte wrote:
>  We need a pre3 to fix this since this has been a long standing bug. This
>  path is hardcoded in the example configuration, where running
>  ./configure should set this path properly. In fact, Charles fixed this
>  in the trunk, but apparently we didn't backport the fix to Testing.
Good
>  catch!
I apologize for not keeping up with development lately - I'm sure you
have all been there at one point or another.

Arjen, I assume you are referring to changeset 963. Would you like me
to backport that?

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).

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.

Sorry, I'll put away my soapbox for now.

-- 
- Charles Lepple

> 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