This is vxl/core/doc/meetings/2003-meeting-plan.txt.

http://cvs.sourceforge.net/viewcvs.py/vxl/vxl/core/doc/meetings/2003-meeting-plan.txt?view=markup
will get you to this file, but SourceForge WebCVS is a few hours
behind the live CVS.

Thanks to everyone for all the positive responses about the 2003 VXL
teleconference.  I will be away Tue. (11/4) to Thu. (11/6) of this
week with minimal e-mail, so I am attempting to put the agenda
formation process in the hands of CVS.  Please modify and commit this
file as you see fit, especially the agenda section.

The VXL developer community will have a teleconference on November 11,
2003 at 7:00 MST(ouch) 9:00 AM EST, 14:00 GMT, 15:00 CET
E-mail Fred Wheeler, or add a note here if
that day/time is bad for you.  We will change the plan if the
situation warrants.

What you should do:
  1. If you want to call in, make sure your name is below.
  2. Make sure the agenda has items you are interested in.

Participation
-------------

If you wish to participate in the teleconference, add your name and
e-mail address here, or e-mail Fred Wheeler (wheeler at crd.ge.com).
All this means is that you will get the call-in information.  Before
the meeting I will e-mail the teleconference call-in numbers and
access codes.  I do not want those numbers to end up on the web so I
will not send them to the mailing list.

If you want to call in just for certain items, let me know and we'll
work it out -Fred Wheeler (wheeler at crd.ge.com).

Tim Cootes (Manchester), Tim.Cootes at man.ac.uk
Geoff Cross (Visual Geometry Solutions), geoff at visualgeometrysolutions.com
Andrew Fitzgibbon (Oxford), awf at robots.ox.ac.uk
Brad King (Kitware), brad.king at kitware.com
Brendan McCane (Alberta), mccane at cs.ualberta.ca
Amitha Perera (GE), perera at crd.ge.com
Ian Scott (Manchester), ian.m.scott at stud.man.ac.uk
Michal Sofka (Rensselaer), sofka at cs.rpi.edu
Fred Wheeler (GE), wheeler at crd.ge.com
Gary Yang (Rensselaer), yangg2 at cs.rpi.edu

Web whiteboarding
-----------------

I've set up a web-based whiteboard/chat tool at
http://monica.cs.rpi.edu:8080/~perera/vxlchat/. It should work with
any Java-enabled browser. I'm not sure how useful it'll be for the
tcon. Perhaps we can type up the minutes in the chat window as we
go. -- Amitha Perera.

Agenda
------

I would like to help make sure this teleconference happens and is
productive, but I am hoping that others with more VXL and TargetJr
experience will step in to lead and steer the discussion where
appropriate.  My original proposed "half-baked" agenda was not meant
to be definitive.  Most of those items are copied below, but some have
lines indicating they need to be "seconded".  Remove that line to
"second" the agenda item if you think that item should be discussed in
the conference call.  Some people have e-mailed agenda items to me.
They are added below.

Items that are not seconded, or are not deemed important enough to
discuss will be passed over during the conference call.  For now all
items should stay to poll for interested parties and comments.

*** VXL Principles - What is the VXL copyright exactly?
Are we marking files properly?  Consistently?

*** VXL Principles - Is VXL in danger of becoming like Target Jr.?
Someone has suggested a concern about bloat and feature creep.  Any real danger here?

*** VXL Principles - Backward compatibility and deprecating old APIs
VXL is old enough that we have to be careful about backward
compatibility. See note [1] below.

*** Configuration - Windows DLLs
Last year Fred Wheeler tried to do this the declspec code markup way,
but abandoned the effort.  Amitha Perera has been working on this
recently with more success.
If there is anything to discuss it should take the form of a serious
proposal - IMS.

*** Configuration - Are people happy with new CMake export scheme

*** Configuration - Are people happy with new CMake configuration

*** Configuration - Is it OK to be so dependent on CMake?

*** Configuration - How do people structure their internal private code that uses VXL?
Remove this line to "second" this item if you think this is something we should discuss.

*** Language - Is anyone interested in TCL/Python/Matlab bindings

*** V3P - NEW: Move netlib from LINPACK to LAPACK
Any volunteers?

*** V3P - Why VCLize V3P?  V3P packages are already portable.  Upgrades tough after we VCLize.

*** V3P - XML in v3p
GE and Brown use Xerces XML libraries with VXL.
If GE has a serious proposal for this, then it is worth presenting - IMS.

*** Core - "Ownership" of core VXL libs - discussion started on list a few months ago

*** Core - vidl upgrade to vil2
Brown recently did this.  Any difficulties or open issues?

*** Core - NITF support in vil
GE is doing this now by porting Target code.
That's good, but is there any value to discussing this - IMS?

*** Contrib - Any promotion candidates
rpl/rrel might be a good candidate.
Trigger for promotion was "Multiple sites using same library"

*** Contrib - What are people working on?  Are there more opportunities to share code?

*** Communication - CVS commit mailing list painful to read
Summary to VXL maintainers after major changes better (or CHANGES.txt)
Remove this line to "second" this item if you think this is something we should discuss.

*** Communication - New release system
Brendan McCane e-mailed me about this issue, but his concern may be
settled by the fact that Ian has started the regular release process.
I don't plan to do the next release myself - IMS?

*** Communication - http://vxl.sourceforge.net/developers.html
Is it a good idea? Should we encourage all maintainers to use it. IMS.
Remove this line to second this item.

*** Communication - To Do list may invite new users to contribute
We should brainstorm some more easy and hard to-do items to add to this list.

*** Testing - Borland C++ dashboard builds (Part of the "deal" with Kitware)
We are now in the middle of the Borland port.
That's good, but is there any value to discussing this - IMS?



Notes:

[1]: Deprecating old APIs.
     I think that VXL is now old enough that we have to be careful
     about backward compatibility. We need a clear mechanism for
     deprecating and changing interfaces. My suggestion: At a minimum,
     it must be documented, either in meeting notes or on the mailing
     list. It should be marked deprecated, and *in the comments* a
     date or release number given for when the function will be
     removed. In general, the deprecation must have a publically
     posted rationale. This rationale could go into CHANGES.txt. I
     further suggest something like this:

          #if VXL_VERSION < 1003  // 1.0.3 (1.0.03)
          //: document
          // \deprecated Scheduled for removal in version 1.0.3.
          // Replace uses of f() with calls to g() and h().
          void f();
          #endif // deprecated function

     Further, the body of f() should be marked as deprecated with 
     VXL_DEPRECATED, to provide run-time information about 
     deprecated function calls. This code would stay within the 
     #if-#endif block at least till version 1.0.4. After that it 
     may be removed from the code entirely.

     I think deprecating old and broken interfaces is important in 
     making the VXL API clear and consistent. However, it is also 
     important to advise users of impending deprecations and give 
     enough time to correct internal code.




END
