[Source] Xj3D teleconference proposal: development branch merging

[Alan Hudson]

On 9/1/2011 4:10 PM, Don Brutzman wrote:
> Attendees:  Alan Hudson Shapeways, Wayne Warren Ph.D. student at U. Wash
> using Xj3D/X3D/VRML for many years; Hyokwang Lee PartDB; Terry Norbraten
> and Don Brutzman, NPS.  We each introduced ourselves and discussed our
> interests in Xj3D.
>
> Commit log is important to keep track of what a change is about.
> Critical areas are the filter chain and the SAV interface, which
> should get Alan's prior OK.  Other things like installer or
> alternate OS builds are different and OK for many people to
> bang on.
>
>
> PartDB is interested in merging their code changes.  VT has
> already said they are interested in merging their code changes.
> NPS definitely has changes we want to merge as well.
>
> The previously existing installer InstallShield is old and
> Alan is not interested in maintaining.  The version used is
> free but commercial codebase.  NPS has had excellent
> experience with izpack, it is open source.  That is an
> existing and up-to-date capability.
Xj3D also uses izpack.  Its just an old copy.  But it has no ant 
dependency.  I'm fine see a new installer created but if it requires ant 
then I'd leave the old one around.  But as said, I don't really consider 
end-user usage of Xj3D a high priority.
> We also discussed use of both Ant and/or Make.  NPS uses ant.
> We all agreed that build_common.xml, build.xml/build_NPS.xml
> and Makefile are all OK to keep going for whoever wants to
> keep them operational.
no exactly what I was thinking.

I'd like to move totally to ant.  One derived from the build_common.xml 
I put in there.  I don't want to end up with 3 build systems.  Right now 
make and ant are both supported.  I'd like to review the current ant 
script in HEAD.  If it meets everyones needs then lets just move to it.

>
> 	http://www.xj3d.org/arch/codedoc.html
>
> Our goal is for everyone to converge on the trunk, rather
> than to the NPS branch.
>
> Something else that will help is to discuss what are
> group criteria for declaring a dev release or official
> release.  Alan gave us a quick summary, it is a labor-intensive
> process and worth future meeting.  It is not a showstopper
> for sharing notes on what we each want to do and then converging
> our commits.
>
> VT do you mostly agree, or have questions, or improvements?
>
> We will use the source at web3d.org list as primary communication method.
> Silence equals assent.  If a few days go by, you should be OK.
> That way we only need to do teleconferences when needed (2-3-4 weeks).
Good summary of the discussion.

This was said earlier but wanted to reiterate.  Silence on new nodes = 
ascent.  Architectural or technology changes need discussion.  If your 
introducing new jars into the lib directory then we should be discussing 
those dependencies.

I said I'd try and list what I considered core areas of the codebase 
verses non-core.

If your checking into these directories we should discuss:

         org/web3d/browser/*
         org/web3d/vrml/lang/*
         org/web3d/vrml/nodes/*
         org/web3d/vrml/nodes/proto/*
         org/web3d/vrml/util/*
         org/web3d/vrml/scripting/*
         org/web3d/net/protocol/*
         org/web3d/net/content/*
         org/web3d/net/resolve/*
         org/web3d/x3d/jaxp/*
         org/xj3d/core/eventmodel/*
         org/xj3d/core/loading/*
         org/xj3d/loaders/ogl/*
         org/xj3d/impl/core/eventmodel/*
         org/xj3d/impl/core/loading/*
         org/xj3d/io/*
         org/web3d/vrml/parser/*
         org/web3d/parser/*
         org/web3d/parser/vrml97/*
         org/web3d/parser/x3d/*
         org/web3d/vrml/sav/*
         org/web3d/vrml/export/*
         org/web3d/vrml/export/compressors/*
         org/web3d/vrml/renderer/common/browser/*
         org/web3d/vrml/renderer/common/input/*
         org/web3d/vrml/renderer/ogl/browser/*
         org/web3d/vrml/renderer/ogl/input/*

These are open:

         org/web3d/vrml/renderer/common/nodes/*
         org/web3d/vrml/renderer/common/nodes/core/*
         org/web3d/vrml/renderer/common/nodes/enveffects/*
         org/web3d/vrml/renderer/common/nodes/geom3d/*
         org/web3d/vrml/renderer/common/nodes/group/*
         org/web3d/vrml/renderer/common/nodes/interpolator/*
         org/web3d/vrml/renderer/common/nodes/lighting/*
         org/web3d/vrml/renderer/common/nodes/navigation/*
         org/web3d/vrml/renderer/common/nodes/render/*
         org/web3d/vrml/renderer/common/nodes/shape/*
         org/web3d/vrml/renderer/common/nodes/texture/*
         org/web3d/vrml/renderer/common/nodes/time/*
         org/web3d/vrml/renderer/ogl/*
         org/web3d/vrml/renderer/norender/nodes/*
         org/web3d/vrml/renderer/norender/nodes/core/*
         org/web3d/vrml/renderer/norender/nodes/enveffects/*
         org/web3d/vrml/renderer/norender/nodes/geom3d/*
         org/web3d/vrml/renderer/norender/nodes/group/*
         org/web3d/vrml/renderer/norender/nodes/interpolator/*
         org/web3d/vrml/renderer/norender/nodes/lighting/*
         org/web3d/vrml/renderer/norender/nodes/navigation/*
         org/web3d/vrml/renderer/norender/nodes/render/*
         org/web3d/vrml/renderer/norender/nodes/shape/*
         org/web3d/vrml/renderer/norender/nodes/texture/*
         org/web3d/vrml/renderer/norender/nodes/time/*


Basically if your creating a new node it needs little discussion and has 
little architectural impact.  If your changing how the runtime works or 
changing an existing node then it requires more discussion.

-- 
Alan Hudson, Director 3D Tools Shapeways
www.shapeways.com