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

[Arnaud Quette]

fellows,

2008/4/23, Arjen de Korte <nut+devel at de-korte.org>:
> > 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.

it's cool that you've written down what I've in mind.
I've too much bothered you with the current process, forcing us to
backport too many things from the trunk to Testing, and wasting our
precious time.

I still have to think a bit more on the schedule, but I'll make an
announce once 2.2.2 is out to rework the dev. process and allow us to
focus on the real points.

Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/