[torquedev] array_changes and NUMA

David Beer dbeer at adaptivecomputing.com
Tue Jun 8 16:06:26 MDT 2010



----- Original Message -----
> On Tue, Jun 8, 2010 at 5:16 PM, Garrick Staples <garrick at usc.edu>
> wrote:
> >> Garrick,
> >>
> >> I'm sorry I was not paying attention to my mail. We really need to
> >> wait until 2.5 is released before NUMA is put into the trunk.
> >
> > Really, I never suggested that NUMA should be merged into trunk. It
> > was the
> > furthest thought from my mind.
> >
> > What am I suggesting is that you have a nightmare coming in the
> > future when you
> > do decide to merge NUMA into trunk. There are 2 reasons for this.
> > The first is
> > that there are massive, heaping gobs of non-NUMA changes in the NUMA
> > branch (mostly formatting changes). The second is similar code
> > development happening
> > in trunk at the same time.
> >
> > If it were me working on the NUMA branch, I would only make
> > NUMA-related changes in the NUMA branch. All other changes would be
> > commited to trunk and
> > then merged into NUMA.
> >
> > In summation, I don't think NUMA should be merged into trunk at this
> > time.
> 
> 
> Garrick is right, this is a nightmare waiting to happen when all of
> these branches need to get merged back into trunk. Formatting changes
> in a branch are a really bad idea and any branch that is going to be
> merged back into trunk should be tracking the changes that are
> happening in trunk and staying as synched as possible
> _______________________________________________ torquedev mailing list
> torquedev at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torquedev

Formatting changes done in NUMA will probably get left out of the merge. I'm ok with that because I probably did the formatting changes and I'm probably the one who is going to be merging them back, so I'll leave out things that aren't essential. 

As far as merging things back now, I know that this may well make my life more difficult when merging the NUMA branch back into trunk, but we're going to wait until 2.5 is released to make the changes. I just don't want to risk derailing the release of 2.5 by breaking the trunk. I probably could take some of the code contained in 

#ifdef NUMA_SUPPORT

and safely move it back now, but most of this code can be merged back fairly easily, and I doubt this will save me a lot in the long run. For now, I think its best if we wait for more testing and refining of the code before merging anything back in.

-- 
David Beer | Senior Software Engineer
Adaptive Computing


More information about the torquedev mailing list