Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
I'm thinking that all work for 4.2.1 should be done on the
4.2.x branch, and future work should be done on trunk until
an appropriate branch has been created. That way we avoid
having to be careful about bulk merges from trunk to 4.2.1...
Everything that is on 4.2.x should be safe for trunk.
Unfortunately, I think that would mean that we would need to
do nightly testing on the 4.2.x branch, possibly in addition
to trunk.
Right, that's a big problem. Another problem with this approach
is that it has the potential to destabilize the branch.
I don't mind it being unstable,
Stability is increasingly important as we approach a release.
Every major breakage (like the one we just had on trunk) sets
us back by days if not a week, sometimes up to 10 days when
the build servers are busy.
provided that we are actually testing
that branch. I don't think we are testing 4.2.x, so we don't even know
if it is stable or not. When we get close to release time, we should
probably be testing 4.2.x almost exclusively.
Scott tells me we have been testing 4.2.x in nightly builds for
some time. I just haven't gotten around to publishing the results
yet. I need to do it soon. I think I'll need Andrew's help to set
up the script(s).
The second problem can be mitigated by tagging the branch when
it's known to be stable. I don't think there's anything we can
do about the first problem except alleviate it by implementing
a more intelligent test harness. I'm not sure we have cycles
for that...
Are you saying that the test infrastrucure doesn't allow us to test
4.2.x at all? I can see how that would be a serious problem. How are we
expected to verify that the code that is on 4.2.x is good?
What I'm saying is that it might be a hard sell to get Rogue Wave
to run two (or more) sets of nightly builds for stdcxx, one for
trunk and one for each branch, unless it's much more lightweight
than it is now.
Is there some convention or process we could put in place that
would make the bulk merge issue less painful? I wake up in the
middle of the night thinking about how we're going to manage
it for 4.2.1. Maybe it won't be so bad, but it does seem like
it will be a lot work and could be pretty error prone.
Well, for a while there Farid was working directly on 4.2.x and merging
back to trunk. That solution would work. Another obvious option would be
to require users to merge their own changes out. We were doing this for
a hile, but I've noticed that this hasn't been happening lately.
It hasn't because we haven't been testing the branch (or
publishing the results). We could switch nightly builds to 4.2.x
but then we'll have the same problem on trunk and/or on any other
branch (such as 4.3 or 5.0, once they've been created). We already
have a number of patches and tests that we've been waiting to
commit because they're not appropriate for 4.2.x and we've been
treating trunk as a copy of 4.2.x. I think that's a mistake.
We should commit these patches otherwise they are at risk of
becoming out of sync with the files they patch. Then it'll be
a chore to apply them all.
I guess my point is that it doesn't matter if it's a branch or
trunk that gets tested, or where some/many of us do their work,
there's nothing we can do to get away from merging the changes
at some point. So it seems that we need to come up with
a solution to the merging problem, independently of what we
do about testing.
Martin
