Melchior, On Feb 3, 2007, at 1:23 AM, Melchior FRANZ wrote: > * > On Feb 2, 2007, at 2:18 AM, Melchior FRANZ wrote: >> Ah, it doesn't mean I don't have to fix it, but means I should >> implement the canopy soon. > > I didn't mean to complain about the canopy animation. The patch > was just a suggestion how to fix some minor problems.
Yes, I totally understand what you mean. I love the code you suggested, so I'll use it. :-) >> Yes, I'm also worried about putting code spreading all over the place >> in CVS. It's no good. >> I included the same code since each archived file should be >> independent from others that are not included in the base package. > > Yes, of course. Such code can't be generalized, it needs to be > repeated > in aircraft that need it. I found it only funny that broken code > infects several aircraft so quickly. Well, many new aircraft developers like myself want to have some reference that is closer to their own. So it happens sometimes regardless of the quality. I don't know if distributing the same (or almost the same) code in different package is a good idea. but as I mentioned before, it improves the usability since users don't have to download other aircraft that they might not want. This is a bit difficult to take balance with the maintainability. >> The problem here is that I should have not given the package to you >> as it was. >> I should have known what I should do and I should not do before that. > > No, no, no. That was fine. Code doesn't need to be perfect when > it's getting added to CVS. Heck, it doesn't need to be and become > perfect at all. CVS isn't storage for finished projects, it's > working space. We often add half-done aircraft to CVS and they are > worked on and improved as the author submits fixes and grow with > the project. Of course I can't make a perfect code at the early development stage, and do know what the CVS version is for. What I meant was not the code itself, but was the way I made the obsolete code spread. I simply limited the use of the new features only because the backward compatibility. Anyway, it is a good thing that many developers like you tell us what is available and what is obsolete. So I want to thank you for this. >> Okay, I understand another convention. >> "Do not write any code only for the backward-compatibility reason." >> I'll fix this immediately. > > Not exactly. But CVS/HEAD (sg, fg, data) is what's going to become > the next release, and all parts of it should be developed in parallel > and adopt new, improved ways of doing things, new features, etc. > None of the parts should be frozen and reject new features only > to remain compatible with past releases. CVS has such a frozen state > already: it's the tags. Check out with -rRELEASE_0_9_10 and you > *have* the compatibility and everything fits together (more or > less :-). > Aircraft added after the last release are supposed to become > compatible with the *next* release. If you want to make the > Ki-84' COMPAT_0_9_10 branchlet really compatible with 0.9.10, > then please submit patches for that. But don't limit your > possibilities by trying to make HEAD compatible with 0.9.10. That's what I exactly meant. Backward compatibility sometimes kills the possibility of the use of newly created features. I want my code fresh and cool even though the aircraft itself is old. :-p > >> - including A6M2/electrical.nas from each -set.xml for both Ki-84 and >> J7W. > > Bad idea. Fixing the bugs in each is the way to go. Agreed, even though it is a bit redundant, it can be an independent package. > >> - using fdm_initialized singal to start the updates() func. > > That's also not what I meant to say. Do it like you want, using that > signal or not. Just make your decisions based on the next release, > not on the last. The last one is history. Oh I do love to use the signal. I thoroughly check the code and there's a few difference between CVS and 0.9.10 in the code I've made or used. So it's not that hard to make patches for 0.9.10. I was thinking about how I want to maintain the code that I made, and the answer is I want to use the new features if it is either useful or simple. > > And now I'll stop (for a while :-) to comment on aircraft commits and > submissions and to fight for consistency within fgfs. This always > gets me into hot water, and most of the time I'm on my own. Oh no no no, don't stop it. shere your idea and thought with others. What's you're doing helps other developers but not gets yourself into hot water. I never complain what you said or what you mean. I simply want to thank you for doing this. Developers like me want to make their own creation better so introducing new features and suggestion are very welcome. Moreover, suggestion and discussion from the architectural perspective is very important. Don't even think about stopping it. This is what the list is for and it is the way to keep such a big project wholesome. Tat. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
