Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Yes, bring it on for those already wanting 850. Hence I could already work on swiss 850 airports, to have it ready without any hassle for 2.9 Terrasync integration. Could you let me know as soon as Europe/Switzerland could be used? Maybe as early/parallel 2.9 git, download or whatever. Thanks Michael --- On Thu, 6/7/12, ys wrote: > From: ys > Subject: Re: [Flightgear-devel] The next FlightGear release (summer 2012) > To: "FlightGear developers discussions" > > Date: Thursday, June 7, 2012, 7:36 PM > Just to add a note what is already > running on this jenkins right now, on different slaves: > - hgtchop available SRTM-3 data (I make use of the no data > filled files I provide), this a one day job on very old > machine > - terrafitting the data (another one day job on the same old > machine) > - taking recent xplane apt.dat and splitting into single > airport files (one hour job) > - creating xml files like showed at scenery list, per > airport, still experimental > - running genapts850 on every single airport file, creating > airport and airport area folders for further scenery > creation, still experimental > - pushing this data to a public server (not realised yet, > waiting for proposals where this should be) > > This is all created in a jenkins workspace which can be > shared then by fgfs-construct slaves. What regions or how > many tiles this slaves could/should create depends on a new > "regional" grid that has to be defined. One benefit of this > workflow could be: Everyone use the same elevation data for > scenery creation, everyone use the same apt.dat data etc. > The fgfs-construct job definitions may vary from region to > region. People can concentrate on updating resources and > jenkins scenery slaves are eating this automatically. > > Theoretically every machine around the globe can act as a > jenkins slave when the recent terragear toolchain is > installed and distinct ports are open in network. The > fgfs-construct jobs are heavy and may run some days. Having > some powerful servers as "main" slaves would be nice. Role > for main slaves could also be taking over the jobs when some > smaller nodes are off for any reason. > > Yes, just promoting this jenkins world scenery workload idea > again, comments still welcome anytime. In case there is a > machine/server which can act as a slave please just send me > a note. You can get access to this jenkins immediately, I > would also help to install all tools and setup the jobs to > be done ;-) > > Cheers, Yves > > > > > Am 07.06.2012 um 17:35 schrieb ys : > > > As I mentioned some weeks ago I think we should leave > path of creating world scenery in one task. I made a > proposal how to create world scenery in chunks all day and > nights with jenkins on different machines for different > regions. The sources for this creation process can remain on > one "master", the many fgfs-construct slaves will need a bit > of cpu power (more slaves welcome here anytime for testing). > What I miss at the moment is a tool like terramaster for > this process, where one can follow recent scenery creation > process by created tiles i.e. The jenkins artifacts can be > pushed to a terrasync server, daily, weekly, monthly or in > whatever cycle. A tool like terramaster should reflect the > versioning of the region/tiles visually somehow, but this is > not the most important part of course. > > > > For me the scenery release should not follow the core > release plan. A need for the next release cycle might be > moving the outdated static apt.dat from the base package to > a new place, but of course only in case someone really > follows the plan to get a dynamical apt data solution > for next flightgear. I know the plan with jenkins scenery > creation might cause some inconsistency the first weeks and > months, but once the creation process is in sync with data > there remain only small areas to update and we can follow > regular and great apt.dat updates coming in every months by > a huge group of contributors chez xplane. > > > > There is probably no other way (or I didnt here > anything different here): apt.dat in 810 format is a scenery > development blocker, independent of release numbers. > > > > Cheers, Yves > > > > > > > > > > Am 07.06.2012 um 15:55 schrieb Björn Kesten > > : > > > >> Good to know. > >> > >> I'd dedicate some CPU time to world scenery > generation, but I'm not > >> sure how many months that would take... :S > >> > >> > -- > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways > today's security and > >> threat landscape has changed and how IT managers > can respond. Discussions > >> will include endpoint security, mobile security and > the latest in malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> ___ > >> Flightgear-devel ma
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear
I changed my git username with this command line: git config --global user.name "My name" Sorry for the noise. Cheers, Julien Nguyen Le 07/06/2012 16:49, Martin Spott a écrit : > Julien Nguyen wrote: > >> Oh, it's me... >> >> Have I done something wrong ? (I don't know with this nickname was used by >> the way) > I think the key is to understand the particular difference between the > GIT repository and the Gitorious web site. > Apparently Gitorious somehow manages to translate the GIT nicknames > into Gitorious accounts, but of course the GIT repository doesn't know > about the Gitorious web site. Therefore a "git log" will show just the > names (and/or EMail addresses) you put into every single GIT commit. > > Cheers, > Martin. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
> Rembrandt has been around for quite a few months now, > and the changes required to make an aircraft Rembrandt-compatible are > pretty small, even if the changes to add proper lights are more involved. > > If I was being harsh I'd suggest that the aircraft maintainers should > "man up and do it". > There's still plenty of time before the release... > I didn't think it harsh myself , but from my point of view , I'd rather not waste time on something I can't see or use... I get about 5 fps and a brilliant green terrain , with a duplicate black aircraft , not shadow , right beside the main aircraft. I think this is an ATI driver problem here since the view resizes every time a dialog or text pops up on the screen. Syd -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Stuart Buchanan wrote: > So you would prefer not to mention it in the change log and release > note? In order to save everybody from pointless discussion, I won't disclose my preference. Anyhow I'd vote for seriously taking into account, that, for a large fraction of FlightGear's user base, Rembrandt probably won't work as expected - simply because it implies such a wide variety of potential pitfalls. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
On Thu, Jun 7, 2012 at 10:44 PM, Martin Spott wrote: > Stuart Buchanan wrote: > >> I'm not sure that is correct, but my memory is dim. My recollection was that >> even after we converted the main cvs branch to OSG, we kept a plib branch >> that was used for a subsequent release. I was wrong - 1.9.0 was indeed OSG-based. > There's a key difference: The OSG port, at least when it was added to > CVS, was pretty functional almost from day one, even on feeble graphics > cards. That's substantially different with Rembrandt, where some of > the essentials still don't work properly on moderately powerful cards > (even after obeying the recommendations Fred has been posting to this > list). The other key difference is that Rembrandt is an optional graphics feature that's switched off by default. OSG was a complete switch from plib, with no option to allow users to not use it. I think we're comparing apples with oranges. > Don't get me wrong, I'm not against Rembrandt in general, instead, I > think it's a cool idea - but, according to my opinion, "cool" is not > sufficient for applying as an 'official' release feature. So you would prefer not to mention it in the change log and release note? Historically, we've put all sorts of features in the change log. If we caveat that it is under development, I don't see any harm. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Stuart Buchanan wrote: > I'm not sure that is correct, but my memory is dim. My recollection was that > even after we converted the main cvs branch to OSG, we kept a plib branch > that was used for a subsequent release. There's a key difference: The OSG port, at least when it was added to CVS, was pretty functional almost from day one, even on feeble graphics cards. That's substantially different with Rembrandt, where some of the essentials still don't work properly on moderately powerful cards (even after obeying the recommendations Fred has been posting to this list). The OSG port just developed that slow because there was strong lobbying against it. Rembrandt, in contrast, has been widely adopted by developers but apparently there's still a lot do be done. Don't get me wrong, I'm not against Rembrandt in general, instead, I think it's a cool idea - but, according to my opinion, "cool" is not sufficient for applying as an 'official' release feature. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
On Thu, Jun 7, 2012 at 5:04 PM, Gijs de Rooy wrote: > Hi all! > > Calling something a major release is not just a matter of "what's possible", > but also "what's done". > > There's a lot possible with Rembrandt, but 99% of our aircraft don't use it. > And lots of aircraft look ugly with Rembrandt > (non-translucent windows and fake shadows mostly). I just checked the few > aircraft that I remember being included in the base > package: only one has Rembrandt lights (c172p)! A very good point, and one I hadn't considered in depth. > I'm afraid we will get a forum-tsunami when we promote this release with > "support for real time generated shadows and lights", > if even the majority of the base package's aircraft aren't showing how nice > it can look... Rembrandt has been around for quite a few months now, and the changes required to make an aircraft Rembrandt-compatible are pretty small, even if the changes to add proper lights are more involved. If I was being harsh I'd suggest that the aircraft maintainers should "man up and do it". There's still plenty of time before the release... > On our IRC channel, someone brought up the idea of including Rembrandt in > the release, but not mentioning it (explicitly) in > the changelog/press-release; and thus versioning it 2.8.0. That'll keep the > expectations low, and allow aircraft developers to > spend some months (till the next release) on getting their aircraft > Rembrandt-ready. As we don't update the aircraft downloads > in-between releases, users need to wait till the next release anyway before > they can download a fair number of Rembrandt-ready > aircraft... You make a very good argument for 2.8.0 rather than 3.0.0. I think we should still mention Rembrand in the release note. I think it's perfectly reasonable to talk about it as a development feature that has still to be supported by all aircraft and shaders. I really don't like the idea of not including it in the changelog. After all, we want people to become excited by it and update aircraft/shaders etc. > The next release could then be called 3.0.0. This would be in line with the > Plib-OSG switch. The OSG transition started with 1.9.0. > That release was a "step back", as we lost shadows, 3D clouds etc. The > period thereafter was spent on bringing back some of the > features (eg. 3D clouds) and allowed developers to get used to the new > possibilities (shaders). FlightGear 2.0.0 was then released > with the key-sentence: "FlightGear 2.0.0 reflects the maturation of the > OpenSceneGraph". I'm not sure that is correct, but my memory is dim. My recollection was that even after we converted the main cvs branch to OSG, we kept a plib branch that was used for a subsequent release. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Le 07/06/2012 18:04, Gijs de Rooy a écrit : > There's a lot possible with Rembrandt, but 99% of our aircraft don't > use it. And lots of aircraft look ugly with Rembrandt > (non-translucent windows and fake shadows mostly). I just checked the > few aircraft that I remember being included in the base > package: only one has Rembrandt lights (c172p)! Tsss, two now, counting the f-14b (though she lakes fancy afterburners flames and missiles launch nice illuminations). > I'm afraid we will get a forum-tsunami when we promote this release > with "support for real time generated shadows and lights", > if even the majority of the base package's aircraft aren't showing how > nice it can look... That's why I would like to see it included as an experimental and optional feature, disabled by default, which is the case right now. > On our IRC channel, someone brought up the idea of including Rembrandt > in the release, but not mentioning it (explicitly) in > the changelog/press-release; and thus versioning it 2.8.0. Anders presented that as an easter egg. Xiii likes easter eggs :-) > That'll keep the expectations low, and allow aircraft developers to > spend some months (till the next release) on getting their aircraft > Rembrandt-ready. As we don't update the aircraft downloads > in-between releases, users need to wait till the next release anyway > before they can download a fair number of Rembrandt-ready > aircraft... I must admit that this is a good argument for keeping Rembrandt out of the next release. In this case keeping 3.0 for a later release with ready aircrafts is consistent. Anyway an experimental/optional feature shouldn't trigger a major number. In any case, having a well known roadmap (and a communication policy ?) for 3.0 would be a good thing. Alexis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Just to add a note what is already running on this jenkins right now, on different slaves: - hgtchop available SRTM-3 data (I make use of the no data filled files I provide), this a one day job on very old machine - terrafitting the data (another one day job on the same old machine) - taking recent xplane apt.dat and splitting into single airport files (one hour job) - creating xml files like showed at scenery list, per airport, still experimental - running genapts850 on every single airport file, creating airport and airport area folders for further scenery creation, still experimental - pushing this data to a public server (not realised yet, waiting for proposals where this should be) This is all created in a jenkins workspace which can be shared then by fgfs-construct slaves. What regions or how many tiles this slaves could/should create depends on a new "regional" grid that has to be defined. One benefit of this workflow could be: Everyone use the same elevation data for scenery creation, everyone use the same apt.dat data etc. The fgfs-construct job definitions may vary from region to region. People can concentrate on updating resources and jenkins scenery slaves are eating this automatically. Theoretically every machine around the globe can act as a jenkins slave when the recent terragear toolchain is installed and distinct ports are open in network. The fgfs-construct jobs are heavy and may run some days. Having some powerful servers as "main" slaves would be nice. Role for main slaves could also be taking over the jobs when some smaller nodes are off for any reason. Yes, just promoting this jenkins world scenery workload idea again, comments still welcome anytime. In case there is a machine/server which can act as a slave please just send me a note. You can get access to this jenkins immediately, I would also help to install all tools and setup the jobs to be done ;-) Cheers, Yves Am 07.06.2012 um 17:35 schrieb ys : > As I mentioned some weeks ago I think we should leave path of creating world > scenery in one task. I made a proposal how to create world scenery in chunks > all day and nights with jenkins on different machines for different regions. > The sources for this creation process can remain on one "master", the many > fgfs-construct slaves will need a bit of cpu power (more slaves welcome here > anytime for testing). What I miss at the moment is a tool like terramaster > for this process, where one can follow recent scenery creation process by > created tiles i.e. The jenkins artifacts can be pushed to a terrasync server, > daily, weekly, monthly or in whatever cycle. A tool like terramaster should > reflect the versioning of the region/tiles visually somehow, but this is not > the most important part of course. > > For me the scenery release should not follow the core release plan. A need > for the next release cycle might be moving the outdated static apt.dat from > the base package to a new place, but of course only in case someone really > follows the plan to get a dynamical apt data solution for next flightgear. I > know the plan with jenkins scenery creation might cause some inconsistency > the first weeks and months, but once the creation process is in sync with > data there remain only small areas to update and we can follow regular and > great apt.dat updates coming in every months by a huge group of contributors > chez xplane. > > There is probably no other way (or I didnt here anything different here): > apt.dat in 810 format is a scenery development blocker, independent of > release numbers. > > Cheers, Yves > > > > > Am 07.06.2012 um 15:55 schrieb Björn Kesten > : > >> Good to know. >> >> I'd dedicate some CPU time to world scenery generation, but I'm not >> sure how many months that would take... :S >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.
Re: [Flightgear-devel] Nasal performance
Thorsten, > Heiko and Vivian, please try the following version and let me know if this > improves anything. If possible, do all tests with the weather tile type 'Test' > (that has no randomness in the cloud configuration selection, so it delivers a > fairly reproducable situation in terms of cloud count). > > http://users.jyu.fi/~trenk/files/advanced_weather_v1.47.tgz Yes, that improves it here really much! First, quite subjective impression: -Less stutters, more stable -framerate impact comparable with Default clouds Now it seems to make fun, and makes FGFS does looks great again! Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Hi all! Calling something a major release is not just a matter of "what's possible", but also "what's done". There's a lot possible with Rembrandt, but 99% of our aircraft don't use it. And lots of aircraft look ugly with Rembrandt (non-translucent windows and fake shadows mostly). I just checked the few aircraft that I remember being included in the base package: only one has Rembrandt lights (c172p)! I'm afraid we will get a forum-tsunami when we promote this release with "support for real time generated shadows and lights", if even the majority of the base package's aircraft aren't showing how nice it can look... On our IRC channel, someone brought up the idea of including Rembrandt in the release, but not mentioning it (explicitly) in the changelog/press-release; and thus versioning it 2.8.0. That'll keep the expectations low, and allow aircraft developers to spend some months (till the next release) on getting their aircraft Rembrandt-ready. As we don't update the aircraft downloads in-between releases, users need to wait till the next release anyway before they can download a fair number of Rembrandt-ready aircraft... The next release could then be called 3.0.0. This would be in line with the Plib-OSG switch. The OSG transition started with 1.9.0. That release was a "step back", as we lost shadows, 3D clouds etc. The period thereafter was spent on bringing back some of the features (eg. 3D clouds) and allowed developers to get used to the new possibilities (shaders). FlightGear 2.0.0 was then released with the key-sentence: "FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph". > 2) Which aircraft do we ship in the base package? Keep in mind that the 777 family got merged, so you'll end up with more aircraft than before, when keeping the same selection. But they share the same model mostly, so I won't consider it as a problem... Gijs -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
As I mentioned some weeks ago I think we should leave path of creating world scenery in one task. I made a proposal how to create world scenery in chunks all day and nights with jenkins on different machines for different regions. The sources for this creation process can remain on one "master", the many fgfs-construct slaves will need a bit of cpu power (more slaves welcome here anytime for testing). What I miss at the moment is a tool like terramaster for this process, where one can follow recent scenery creation process by created tiles i.e. The jenkins artifacts can be pushed to a terrasync server, daily, weekly, monthly or in whatever cycle. A tool like terramaster should reflect the versioning of the region/tiles visually somehow, but this is not the most important part of course. For me the scenery release should not follow the core release plan. A need for the next release cycle might be moving the outdated static apt.dat from the base package to a new place, but of course only in case someone really follows the plan to get a dynamical apt data solution for next flightgear. I know the plan with jenkins scenery creation might cause some inconsistency the first weeks and months, but once the creation process is in sync with data there remain only small areas to update and we can follow regular and great apt.dat updates coming in every months by a huge group of contributors chez xplane. There is probably no other way (or I didnt here anything different here): apt.dat in 810 format is a scenery development blocker, independent of release numbers. Cheers, Yves Am 07.06.2012 um 15:55 schrieb Björn Kesten : > Good to know. > > I'd dedicate some CPU time to world scenery generation, but I'm not > sure how many months that would take... :S > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Hello, > Two questions have to be discussed and answered until the release > branches get created on July, 17th: > > 1) What's the version number of the new release? > a) 2.8.0 > b) 3.0.0 Keep it consistent: 2.8.0 My reasons: -Rembrandt is still experimental and Fred's To-Do-list is still big. I would like to see it included, like now we have in 2.7.0. But as it is experimental, it doesn't work on all systems (and it won't as it is deferred shading and so will naturally need some power) and a lot of things missing it isn't a reason to break our version number system. With that I can still see that some shaders doesn't work yet with and without rembrandt and together with the updated other shaders (skydome/ lightfield as an example)- I'm sure there are people who will complain about. -the random buildings are great, but can't remember that we increased version number with the 3d clouds or the trees. > 2) Which aircraft do we ship in the base package? > a) just the c172 > b) same as before > c) [name your preferred aircraft] b) > 3) Should we keep last year's commit policy for aircraft during the > feature freeze? > a) yes > b) no Does not make sense to me to stop commit to aircraft during feature freeze, as long they won't break other important things. Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear
Julien Nguyen wrote: > Oh, it's me... > > Have I done something wrong ? (I don't know with this nickname was used by > the way) I think the key is to understand the particular difference between the GIT repository and the Gitorious web site. Apparently Gitorious somehow manages to translate the GIT nicknames into Gitorious accounts, but of course the GIT repository doesn't know about the Gitorious web site. Therefore a "git log" will show just the names (and/or EMail addresses) you put into every single GIT commit. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Good to know. I'd dedicate some CPU time to world scenery generation, but I'm not sure how many months that would take... :S -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re : The next FlightGear release (summer 2012)
Firefox did 2.0 -> 13.0 between 2011 and 2012... ;-) not saying this is the way to go for the years to come, but the enhancements seen since the start of 2.0, are, I think, worth a good, stable 3.0. Major numbering do attract more people, too. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
On Thu, Jun 7, 2012 at 2:17 PM, Michael wrote: > Personally I'd leave 3.0 for the new apt 850 support. If that's not in for > summer leave it at 2.8. I think we need a new world scenery generation to take place to take full advantage of apt 850 support. I don't know if that's on the cards for this summer release. I disagree that we should leave 3.0.0 for apt 850 support. That's not to say that 850 support (and the implicit world scenery generation) isn't worthy of a version increment. On Thu, Jun 7, 2012 at 2:28 PM, Björn Kesten wrote: > If the new autogen will be included, I'm also in favor for a 3.0.0 version > numbering. The current "next" branch of git will form the basis for the summer release, so it will include all the regionalized textures, object-masking and random building work that has taken place. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
If the new autogen will be included, I'm also in favor for a 3.0.0 version numbering. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Personally I'd leave 3.0 for the new apt 850 support. If that's not in for summer leave it at 2.8. --- On Thu, 6/7/12, Stuart Buchanan wrote: > From: Stuart Buchanan > Subject: Re: [Flightgear-devel] The next FlightGear release (summer 2012) > To: "FlightGear developers discussions" > > Date: Thursday, June 7, 2012, 2:39 PM > On Sat, Jun 2, 2012 at 8:36 PM, > Torsten Dreyer wrote: > > Two questions have to be discussed and answered until > the release > > branches get created on July, 17th: > > > > 1) What's the version number of the new release? > > a) 2.8.0 > > b) 3.0.0 > > Given the introduction of Rembrandt, I'd suggest 3.0.0. > It's > a major new feature, and is appropriate to bump the major > version number up for. it also allows us to side-step > the issue > of the a future 2.10.0 release. :) > > Also, release numbers are cheap, and X-Plane, MSFS are > already > on version 10, so we've got some space to catch up :) > > > 2) Which aircraft do we ship in the base package? > > a) just the c172 > > b) same as before > > c) [name your preferred aircraft] > > I don't see any reason to restrict the distribution to just > the c172p, > unless the base package has increased in size > significantly. > > I've no opinion on changing the set of aircraft. > > > 3) Should we keep last year's commit policy for > aircraft during the > > feature freeze? > > a) yes > > b) no > > Assuming you mean the version currently defined under the > release plan > in the wiki, then Yes. I think it strikes the right > balance to allow aircraft > developers some time to work with the stable binaries. > > -Stuart > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's > security and > threat landscape has changed and how IT managers can > respond. Discussions > will include endpoint security, mobile security and the > latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
On Sat, Jun 2, 2012 at 8:36 PM, Torsten Dreyer wrote: > Two questions have to be discussed and answered until the release > branches get created on July, 17th: > > 1) What's the version number of the new release? > a) 2.8.0 > b) 3.0.0 Given the introduction of Rembrandt, I'd suggest 3.0.0. It's a major new feature, and is appropriate to bump the major version number up for. it also allows us to side-step the issue of the a future 2.10.0 release. :) Also, release numbers are cheap, and X-Plane, MSFS are already on version 10, so we've got some space to catch up :) > 2) Which aircraft do we ship in the base package? > a) just the c172 > b) same as before > c) [name your preferred aircraft] I don't see any reason to restrict the distribution to just the c172p, unless the base package has increased in size significantly. I've no opinion on changing the set of aircraft. > 3) Should we keep last year's commit policy for aircraft during the > feature freeze? > a) yes > b) no Assuming you mean the version currently defined under the release plan in the wiki, then Yes. I think it strikes the right balance to allow aircraft developers some time to work with the stable binaries. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Scenery/Web tools branch, master,
You'll find his name on gitorious ;-) http://gitorious.org/fg/sceneryweb/commit/01cd74bef43ff957270c4d56743b284f23a32732 > To: flightgear-devel@lists.sourceforge.net > From: martin.sp...@mgras.net > Date: Thu, 7 Jun 2012 11:14:21 + > Subject: Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear > Scenery/Web tools branch, master, > > Flightgear-commitlogs wrote: > > The branch, master has been updated > > > > - Log - > > > commit 01cd74bef43ff957270c4d56743b284f23a32732 > > Author: Blackiris > > Date: Wed Jun 6 10:29:37 2012 +0200 > > > >Add footer and other HTML stuff > > Could anyone tell me who this weird contributor "Blackiris" is in > real life ? > > Cheers, > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Scenery/Web tools branch, master,
Oh, it's me... Have I done something wrong ? (I don't know with this nickname was used by the way) Le 07/06/2012 13:14, Martin Spott a écrit : > Flightgear-commitlogs wrote: >> The branch, master has been updated >> >> - Log - >> commit 01cd74bef43ff957270c4d56743b284f23a32732 >> Author: Blackiris >> Date: Wed Jun 6 10:29:37 2012 +0200 >> >> Add footer and other HTML stuff > Could anyone tell me who this weird contributor "Blackiris" is in > real life ? > > Cheers, > Martin. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Scenery/Web tools branch, master,
Flightgear-commitlogs wrote: > The branch, master has been updated > > - Log - > commit 01cd74bef43ff957270c4d56743b284f23a32732 > Author: Blackiris > Date: Wed Jun 6 10:29:37 2012 +0200 > >Add footer and other HTML stuff Could anyone tell me who this weird contributor "Blackiris" is in real life ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
