[Flightgear-devel] Re: Options saving patches
Sorry to be annoying yet again, but that's what I'm best at: * Erik Hofman -- Saturday 17 December 2005 10:48: I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. And I would like to postpone the 1.0 release, until FlightGear is ready to be called 1.0. Saving GUI states is one piece of that puzzle, as are landing/taxi lights. There are no finished patches available for that yet? So? What keeps us from working on them and waiting until they are finished? (No, I won't be working on that, but I'm also not pressing for 1.0.) Either the 1.0 number means anything, then fgfs better be complete. Or it doesn't mean anything, then let's release it when it's done and call the next releases 0.9.10++. Or is there a compelling reason to rush out 1.0 *now*? One that we aren't told for whatever reason? Does anyone pay for it whose business depends on it? (MathWorks?) Or is it that fgfs needs for some reason to be called 1.0.0 for SCALE 2006? And why? Other reasons? Do we deserve to know about them? Doesn't look like it. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Melchior FRANZ wrote: Sorry to be annoying yet again, but that's what I'm best at: * Erik Hofman -- Saturday 17 December 2005 10:48: I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. And I would like to postpone the 1.0 release, until FlightGear is ready to be called 1.0. What's this, now you want releases that have missing options for some OS'es?? Saving GUI states is one piece of that puzzle, as are landing/taxi lights. There are no finished patches available for Give me a patch and I'll commit it, until then there's little room for discussion. that yet? So? What keeps us from working on them and waiting until they are finished? (No, I won't be working on that, but I'm also not pressing for 1.0.) I don't like the idea of FlightGear 0.9.9.1223 just because no one cared to implement taxi lights. As a matter of fact I've seen several multi million dollar simulators that didn't implement them, Why? Probably because they're just eye-candy and add little to the simulator part of the program. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Erik Hofman wrote: Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I just noticed, that this patch could break compilation, since in sg_patch.cxx the new method is called makeDir and in the header it's still makedir. I know, I should always test before sending, but it was late yesterday and it was only a coding style fix... I'm about to add a --fghome command line option along with FGHOME enviroment variable support as of Melchior's request. Hope to post a new version today, which should be worth porting. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Stefan Seifert wrote: Erik Hofman wrote: Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I just noticed, that this patch could break compilation, since in sg_patch.cxx the new method is called makeDir and in the header it's still makedir. I know, I should always test before sending, but it was late yesterday and it was only a coding style fix... I noticed this already. I think I like it to be called create() instead, but that's a different matter. I'm about to add a --fghome command line option along with FGHOME enviroment variable support as of Melchior's request. Hope to post a new version today, which should be worth porting. I haven't checked the code yet, but I seem to recall this is already available somewhere? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Erik Hofman wrote: I noticed this already. I think I like it to be called create() instead, but that's a different matter. Maybe createDir? Because it's a member of SGPath which may as well be the path to a file. So it'd be confusing if path_to_a_file.create() created a directory. I haven't checked the code yet, but I seem to recall this is already available somewhere? Don't know. The other code uses the HOME environment variable, which my patch is using, too. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Melchior FRANZ wrote: Either the 1.0 number means anything, then fgfs better be complete. Or it doesn't mean anything, then let's release it when it's done and call the next releases 0.9.10++. Or is there a compelling reason to rush out 1.0 *now*? One that we aren't told for whatever reason? Does anyone pay for it whose business depends on it? (MathWorks?) Or is it that fgfs needs for some reason to be called 1.0.0 for SCALE 2006? And why? Other reasons? Do we deserve to know about them? Doesn't look like it. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. Huh!?! We are making a huge controversy over the difference of plus or minus 0.0.1 Maybe we should drop the arbitrary version numbering scheme (and I do see the version numbers as 99.9.9% arbitrary) and go with code names for our releases. Would that make people happier? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
On Saturday 17 December 2005 16:10, Curtis L. Olson wrote: Maybe we should drop the arbitrary version numbering scheme (and I do see the version numbers as 99.9.9% arbitrary) and go with code names for our releases. Would that make people happier? Curt. No what would make us more happy is to know why there is such an urgency to have two FG releases in the space of a couple of months when up till now we've been releasing about once per year. What has prompted this change? This decision didn't involve the developers at all. Not even a guys what do you think about having another release in January that just contains bug fixes? Are we changing to a frequent release cycle or what? When will the next release be after 1.0? March or April? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Paul Surgeon wrote: On Saturday 17 December 2005 13:40, Erik Hofman wrote: Melchior FRANZ wrote: Sorry to be annoying yet again, but that's what I'm best at: * Erik Hofman -- Saturday 17 December 2005 10:48: I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. And I would like to postpone the 1.0 release, until FlightGear is ready to be called 1.0. What's this, now you want releases that have missing options for some OS'es?? No, that's not what Melchior implied or said at all. What he said is that he would prefer if we hold off with ANY 1.0 release until FG is ready to be called version 1.0. He didn't mention any OS's in an exclusion list did he? Give me a patch and I'll commit it, until then there's little room for discussion. So in other words all the developers, we're going to release 1.0 whether they like it or not because you or Curt say so?! I thought this was a community project but I was clearly wrong. It would appear that we have zero say over this matter and even less chance of getting any honest answers from either you or Curt. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I would also like to know what this urgency for a 1.0 release is but all we get are answers that skirt the issue or no answers at all. Look, if we took half the time that we spend worrying about arbitrary version numbers and spent it developing code and fixing bugs, we'd be at v2.0 by now. I'm sorry that some people get so bent out of whack over something so arbitrary, but I know that we just aren't going to make everyone happy all the time. There's no grand conspiracy here, no secrecy. Let's keep it clean here, there may be children in the room. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Paul Surgeon wrote: No what would make us more happy is to know why there is such an urgency to have two FG releases in the space of a couple of months when up till now we've been releasing about once per year. What has prompted this change? This decision didn't involve the developers at all. Not even a guys what do you think about having another release in January that just contains bug fixes? Are we changing to a frequent release cycle or what? When will the next release be after 1.0? March or April? Look, rolling out a new release is a massive effort. We need to do a release more than once a year. But my time can be very limited depending on what other paying projects I'm involved with during the year. So I try to find a balance between a new release date that is appropriate for the project and my available time. Discussing this with the development community is ok, but at the end of the day, I have to pick a time that matches my personal schedule, otherwise there will be no release at all. And we need releases, just like we need to invite people over to our homes ... sometimes that's the only way certain messes will get cleaned up. If you want to pay me a fair salary, then you would be most welcome to tell me how and when to spend my time doing whatever it is you want me to do. Until then, I need to make my own decisions that strike the best balance I can come up with between the needs of this project and the needs of my family and jobs. That means there are external constraints to the flightgear release schedule that discussion on the list has no affect on. It's not a perfect world, so I'm sure you and others have and will continue to have plenty to complain about. But I'm getting really sick of hearing about version numbers so this is my last message on the topic for a while. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
On Saturday 17 December 2005 11:40, Erik Hofman wrote: Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I was delighted to see a form of the options saving patches going into CVS, since I've been using the earlier versions with no troubles at all for some time now. I was less delighted to find that SG no longer builds... sg_path.cxx: In member function `void SGPath::create_dir(mode_t)': sg_path.cxx:203: error: `subdir' undeclared (first use this function) sg_path.cxx:203: error: (Each undeclared identifier is reported only once for each function it appears in.) make[3]: *** [sg_path.o] Error 1 I really hope this is made to work at least as well as the earlier patches because I think it's a _great_ feature and one that makes life with FG that little bit more pleasant... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
AJ MacLeod wrote: I really hope this is made to work at least as well as the earlier patches because I think it's a _great_ feature and one that makes life with FG that little bit more pleasant... Yeah well, I was trying to outsmarten myself, and got hit in the back. It took me way longer than anticipated (due to some local problems it took almost the whole day for me to get it in) and by the time I was (almost) finished I had to leave :-(. Thanks to Frederic it should compile and work all correctly again. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Options saving patches
I guess what Curt was saying is, him being the release manager of the project, has to find appropriate and free time do all the things for a release, which is fair enough and understandable. Perhaps we can have more people to help doing a release? Personally I've only witnessed one release of FG (0.9.9). And I don't know what's the policy of this whole project. But could anyone else share the workload of doing a release? Or it has to be Curt and Curt alone? If we can do releases at any time, then surely we would have more control on what we could put into a release? I think most people, especially developers, prefers figuring out a features list or goals for a release, and then work towards them. When these are done, then we might want to go for a one month or two months code freeze/bug fix/stabilising/testing, followed by the release. And perhaps we could figure out some sort of roadmap? Look, rolling out a new release is a massive effort. We need to do a release more than once a year. But my time can be very limited depending on what other paying projects I'm involved with during the year. So I try to find a balance between a new release date that is appropriate for the project and my available time. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
