Community Meeting 2005-03-18

On IRC #worldwind-dev, irc.freenode.net, 2300 UTC, 2005-03-18.

Transcript: http://worldwind.arc.nasa.gov/dev/community-meeting-2005-03-18.txt

Agenda
We need to decide how long the beta testing period should last. (Bull)

Critical items to be fixed. (Spacechicken)

Critical items to be added. (SC)

Non-critical items to be added. (SC)

User docs (SC)

Developer docs. (SC)

Buzz- Scraping RSS feeds for geocodes, displaying as icons, clickable. (ah)

Edu -Playback of video/pictures on billboard(s) for narration, supplemental materials. Audio playback as well. (ah)

Edu - Use above feature to build some educational content. (ah)

Edu - External trigger for driving scripts from external programs (worldwind://) (ah)

Tech - Get the CPU usage down

dpatton:  Introduction  identify "moderator"(jessi?), who decides when to move on to next Agenda topic provide URL to Agenda on Wiki update Agenda with last-minute ideas 

1.3.1 release  how/when to release it </li>

NLT servers  status update</li> timing of "complete data" re next release after 1.3.1</li> </ul></li>

1.3.2+ release  when/what</li> </ul></li>

roadmap  for future WW releases / ports</li> for data updates</li> generally: communication between NLT and community - I would like for the OS team to be kept up to date on what the NLT team is doing (this is fine when jessi is around). (Bull) - Schedule regular meetings. (Bull)</li> </ul></li> </ol>

ShockFire's Comments
Excerpts of 2005-03-19 discussion

04:20 < ShockFire> I'll give my comments on the meeting which I missed yesterday in a few minutes, for which I am very sorry 04:21 < ShockFire> I read the full log 04:26 < ShockFire> ok, here goes, I'll start with your comments nhv, after which I'll address the topics discussed yesterday 04:27 < ShockFire> " 3) me thinks that DirectX is here to stay and NLT is not interested in using OpenGL" 04:27 < ShockFire> I think that's the main point behind the whole porting story 04:27 < ShockFire> NLT has limited funds, and feel comfortable with C#/DX, and will thus stick with it 04:28 < ShockFire> I'm not really into the whole porting thing, but here's what I think would be best for both sides (NLT and porters (since NLT                  will support porting, but unlikely help code the port themselves)) 04:29 < ShockFire> we have base code, in C#, that will be used for all platforms 04:29 < ShockFire> this base code will call a rendering engine 04:30 < ShockFire> this engine will be platform specific: DX for windows, (maybe) OGL for linux or even mac 04:30 < ShockFire> the porters would be coding the rendering engine, not recoding the entire app 04:31 < ShockFire> also I think it's very unlikely NLT will switch to OGL, even when it's proven to work for WW 04:31 < ShockFire> maybe we'll use OGL for all the platforms in a far future, but I don't see it coming soon 04:31 < ShockFire> " 4) That WWs stated target audience is school age students" 04:32 < ShockFire> I've mainly kept this in mind whenever I have to make WW decisions 04:32 < ShockFire> when mashi asks me "do we want that black or white?" I don't think "I want it black" but "the users (kids) would probably like                  white" 04:33 < ShockFire> I know, but since NLT will stick with DX for now, it's less work than porting DX to linux :) 04:33 mashi not to bad if there is a high level published API that is adhered to by all 04:33 < ShockFire> and this is just what I think and suspect 04:34 < ShockFire> this is in no way a -rule- that anyone should follow 04:34 < ShockFire> ok, any questions before I move onto the main meeting stuff? 04:36 < ShockFire> I'm going to skip the funding part because I don't think I have anything to say about that (however I do think that we will be                  doing crazy things from time to time simply to keep going) 04:37 < ShockFire> -- 1.3.1 release -- 04:37 < ShockFire> what I missed from the meeting was an actual release date 04:37 < ShockFire> it seems however that we need to get our stuff together by monday 04:38 < ShockFire> patch/full is fine 04:38 < ShockFire> don't label it as a beta, because I don't think it's a beta 04:38 < ShockFire> which brings us to the naming convention stuff:) 04:39 < ShockFire> yep, that's mainly what I meant by "crazy things" in "(however I do think that we will be doing crazy things from time to time                  simply to keep going)" 04:39 < ShockFire> it's bad, but I see why we do it this way 04:40 would be *very* nice if these *crazy* things were talked about a bit  not in details but we *need* a release by XXX 04:40 could make things much smoother 04:41 < ShockFire> yeah I'd like a to have a deadline for every releae 04:41 < ShockFire> it doesn't have to be perfect, but it WILL help 04:41 < ShockFire> I don't nescesarily need/want a list of change we need for that specific version though, just a date will do 04:42 exactly maybe NLT should have a web accessable project management timeline page 04:43 maybe WW should .... 04:44 < ShockFire> my vision on the naming convention is this: first we had the 1.3 release, then people will do commits to CVS, which is when we                   have 1.3.1 in alpha state, then the deadline-day will come which means we do not add more features - call it a beta - and do                   incremental releases to IRC (1.3.1 beta 1, 1.3.1 beta 2, etc) 04:45 that works 04:45 < ShockFire> after the 1.3.1 release, we'll start the same thing, but this time call it 1.3.2 04:45 or 1.2.1a1 a2 b1 b2 .... 04:46 < ShockFire> yeah but when you have alphas it's hard to keep a numbering scheme because people will commit when they like to 04:46 whatever works is fine 04:46 < ShockFire> also we don't want to go making a new installer for a new alpha each day 04:47 it would be nice to have a mechanism in place for bug fixes to releases 04:47 < ShockFire> of course when you need to send the compiled source during alpha state to someone, you are free to give it a number you can come up with 04:48 < ShockFire> -- NLT<>community communication -- 04:49 < ShockFire> the main problem is that we want to decrease the chance that two people are working on the same thing, because this is/will be                  our main productivity killer 04:50 or ... want to insure that when several people are working on the same thing that they communicate with eachother 04:50 < ShockFire> I think Chris needs to give some more details about which parts of the code he's working on, even if he can't fully explain what's going to change 04:50 < ShockFire> also the community needs to do the same by organising their work in a central place 04:51 < ShockFire> about the way we communicate: 04:51 this is where working in a CVS branch that gets merged in later *really* helps 04:51 < ShockFire> - discussions and meetings are nice for IRC (and maybe some other form of IM) 04:52 < ShockFire> - I do not care whether we submit bugs to the wiki/SF/custom page/write on chicken eggs and send by airmail 04:52 < ShockFire> though the eggs method has proven to be problematic :P 04:53 < ShockFire> - I think we need to seperate different 'stages' to get things organized 04:54 < ShockFire> - for each stage we need a clear, simple and public document that describes what to do 04:54 < ShockFire> here are some examples: 04:54 < ShockFire> 1. a user finds a bug 04:54 < ShockFire> this user will go the a document for input 04:55 < ShockFire> the user will go to the part that reads "What should I do when I find a bug in NWW?" 04:55 < ShockFire> the user will then follow the simple instructions below that question 04:55 < ShockFire> 2. a developer will try to fix a bug 04:56 < ShockFire> this developer will go the a document for code-changes 04:56 < ShockFire> the developer will go to the part that reads "What should I do when I want to fix a user-reported bug in NWW?" 04:56 < ShockFire> (follow instructions) 04:57 < ShockFire> I do not care whether these instructions say you have to use the SF bug list or the wiki, either one should work 04:57 bug history needs to be in *one* place 04:58 collective bug histories 04:58 < ShockFire> of course there should also be guides like this for requesting features and stuff like that 04:58 < ShockFire> yep, whichever we choose, we pick one and stick with that (don't go posting bugs on the wiki when the guide tells you to use SF) 04:59 < ShockFire> my explanation is a bit simplified and stupidified, but I think this is what we need in general, a list of guides that tell you what to do to automagically get things organized 05:02 I agree.. keep them in one place. SourceForge worked pretty good imho, the wiki a bit more chaotic? 05:02 < ShockFire> yeah I think SF has a slight advantage 05:03 < ShockFire> -- 1.3.2 -- 05:03 < ShockFire> I don't really have special wishes for 1.3.2 05:03 < ShockFire> I'll try to do some good 1.3.1 testing on the school PCs, and translate that into possible changes we need in 1.3.2 05:04 or if we move off of SF to ues SVN there are some other tools available such as http://projects.edgewall.com/trac/ 05:04 < ShockFire> SF will support SVN someday 05:04 < ShockFire> they're working on it 05:05 < ShockFire> just don't have a date set for it, but it'll be there 05:05 < ShockFire> I already did naming convention and ports 05:06 < ShockFire> I wouldn't mind a roadmap, but I know this can literally change on the NLT side within a day

05:47 < TheBean> UShockFireU Simple communication was one of the points of the meeting last night.....the concensus being a single source was needed for people to check 05:48 < TheBean> It seemed to be agreed that a Wiki page with tables etc would be the best way.....the Wiki has RSS feeds....easy to check....blah blah 05:51 < ShockFire> yeah but nobody made any definitive decision