Community Meeting 2005-03-18

From World Wind Wiki

(Difference between revisions)

Jump to: navigation, search

Current revision

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

[edit] 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
NLT servers
- status update
- timing of "complete data" re next release after 1.3.1
1.3.2+ release
- when/what
roadmap
- for future WW releases / ports
- for data updates
- 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)

[edit] 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> "< nhv> 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> "< nhv> 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 < nhv> 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 < nhv> 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 < nhv> 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 < nhv> exactly maybe NLT should have a web accessable project management timeline page
04:43 < nhv> 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 < nhv> 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 < nhv> 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 < nhv> 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 < nhv> 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 < nhv> 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 < nhv> 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 < nhv> bug history needs to be in *one* place
04:58 < nhv> 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 < mashi> 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 < nhv> 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

Retrieved from "https://worldwindcentral.com/wiki/Community_Meeting_2005-03-18"

Categories: Dev Documentation | Meetings

Community Meeting 2005-03-18

From World Wind Wiki

Current revision

[edit] Agenda

[edit] ShockFire's Comments

Views

Personal tools

-On IRC #worldwind, irc.freenode.net, 2300 UTC, 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==
-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)
 We need to decide how long the beta testing period should last.  (Bull)
 Critical items to be fixed. (Spacechicken)
 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:
+<ol>
+<li>Introduction
+<ul>
+<li>identify "moderator"(jessi?), who
+  decides when to move on to next Agenda topic</li>
+<li>provide URL to Agenda on Wiki</li>
+<li>update Agenda with last-minute ideas</li>
+</ul></li>
+<li>1.3.1 release
+<ul>
+<li>how/when to release it</li>
+</ul></li>
+<li>NLT servers
+<ul>
+<li>status update</li>
+<li>timing of "complete data" re next
+  release after 1.3.1</li>
+</ul></li>
+<li>1.3.2+ release
+<ul>
+<li>when/what</li>
+</ul></li>
+<li>roadmap
+<ul>
+<li>for future WW releases / ports</li>
+<li>for data updates</li>
+<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
+:20 < ShockFire> I'll give my comments on the meeting which I missed yesterday in a few minutes, for which I am very sorry
+:21 < ShockFire> I read the full log
+:26 < ShockFire> ok, here goes, I'll start with your comments nhv, after which I'll address the topics discussed yesterday
+:27 < ShockFire> "< nhv> 3) me thinks that DirectX is here to stay and NLT is not interested in using OpenGL"
+:27 < ShockFire> I think that's the main point behind the whole porting story
+:27 < ShockFire> NLT has limited funds, and feel comfortable with C#/DX, and will thus stick with it
+: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))
+:29 < ShockFire> we have base code, in C#, that will be used for all platforms
+:29 < ShockFire> this base code will call a rendering engine
+:30 < ShockFire> this engine will be platform specific: DX for windows, (maybe) OGL for linux or even mac
+:30 < ShockFire> the porters would be coding the rendering engine, not recoding the entire app
+:31 < ShockFire> also I think it's very unlikely NLT will switch to OGL, even when it's proven to work for WW
+:31 < ShockFire> maybe we'll use OGL for all the platforms in a far future, but I don't see it coming soon
+:31 < ShockFire> "< nhv> 4) That WWs stated target audience is school age students"
+:32 < ShockFire> I've mainly kept this in mind whenever I have to make WW decisions
+: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"
+:33 < ShockFire> I know, but since NLT will stick with DX for now, it's less work than porting DX to linux :)
+:33 < nhv> mashi  not to bad if there is a high level published API that is adhered to by all
+:33 < ShockFire> and this is just what I think and suspect
+:34 < ShockFire> this is in no way a -rule- that anyone should follow
+:34 < ShockFire> ok, any questions before I move onto the main meeting stuff?
+: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)
+:37 < ShockFire> -- 1.3.1 release --
+:37 < ShockFire> what I missed from the meeting was an actual release date
+:37 < ShockFire> it seems however that we need to get our stuff together by monday
+:38 < ShockFire> patch/full is fine
+:38 < ShockFire> don't label it as a beta, because I don't think it's a beta
+:38 < ShockFire> which brings us to the naming convention stuff:)
+: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)"
+:39 < ShockFire> it's bad, but I see why we do it this way
+:40 < nhv> would be *very* nice if these *crazy* things were talked about a bit  not in details but we *need* a release by XXX
+:40 < nhv> could make things much smoother
+:41 < ShockFire> yeah I'd like a to have a deadline for every releae
+:41 < ShockFire> it doesn't have to be perfect, but it WILL help
+:41 < ShockFire> I don't nescesarily need/want a list of change we need for that specific version though, just a date will do
+:42 < nhv> exactly maybe NLT should have a web accessable project management timeline page
+:43 < nhv> maybe WW should ....
+: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)
+:45 < nhv> that works
+:45 < ShockFire> after the 1.3.1 release, we'll start the same thing, but this time call it 1.3.2
+:45 < nhv> or 1.2.1a1 a2  b1 b2 ....
+:46 < ShockFire> yeah but when you have alphas it's hard to keep a numbering scheme because people will commit when they like to
+:46 < nhv> whatever works is fine
+:46 < ShockFire> also we don't want to go making a new installer for a new alpha each day
+:47 < nhv> it would be nice to have a mechanism in place for bug fixes to releases
+: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
+:48 < ShockFire> -- NLT<>community communication --
+: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
+:50 < nhv> or ...   want to insure that when several people are working on the same thing that they communicate with eachother
+: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
+:50 < ShockFire> also the community needs to do the same by organising their work in a central place
+:51 < ShockFire> about the way we communicate:
+:51 < nhv> this is where working in a CVS branch that gets merged in later *really* helps
+:51 < ShockFire> - discussions and meetings are nice for IRC (and maybe some other form of IM)
+:52 < ShockFire> - I do not care whether we submit bugs to the wiki/SF/custom page/write on chicken eggs and send by airmail
+:52 < ShockFire> though the eggs method has proven to be problematic :P
+:53 < ShockFire> - I think we need to seperate different 'stages' to get things organized
+:54 < ShockFire> - for each stage we need a clear, simple and public document that describes what to do
+:54 < ShockFire> here are some examples:
+:54 < ShockFire> 1. a user finds a bug
+:54 < ShockFire> this user will go the a document for input
+:55 < ShockFire> the user will go to the part that reads "What should I do when I find a bug in NWW?"
+:55 < ShockFire> the user will then follow the simple instructions below that question
+:55 < ShockFire> 2. a developer will try to fix a bug
+:56 < ShockFire> this developer will go the a document for code-changes
+: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?"
+:56 < ShockFire> (follow instructions)
+: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
+:57 < nhv> bug history needs to be in *one* place
+:58 < nhv> collective bug histories
+:58 < ShockFire> of course there should also be guides like this for requesting features and stuff like that
+: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)
+: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
+:02 < mashi> I agree.. keep them in one place.  SourceForge worked pretty good imho, the wiki a bit more chaotic?
+:02 < ShockFire> yeah I think SF has a slight advantage
+:03 < ShockFire> -- 1.3.2 --
+:03 < ShockFire> I don't really have special wishes for 1.3.2
+: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
+:04 < nhv> or if we move off of SF to ues SVN there are some other tools available such as http://projects.edgewall.com/trac/
+:04 < ShockFire> SF will support SVN someday
+:04 < ShockFire> they're working on it
+:05 < ShockFire> just don't have a date set for it, but it'll be there
+:05 < ShockFire> I already did naming convention and ports
+:06 < ShockFire> I wouldn't mind a roadmap, but I know this can literally change on the NLT side within a day
+: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
+: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
+:51 < ShockFire> yeah but nobody made any definitive decision
+[[Category:Dev Documentation]]
+[[Category:Meetings]]