From: Jean-Philippe <jpm...@fr...> - 2012-05-13 22:16:05
|
Hi, Wolf-Dieter, all. > First of all, thank you all for your hard work to make SD 2.0 happen. > I hope you all had time to enjoy this event. Thanks to you too ; you're right, now 2.0 is out, we can enjoy seeing it quite welcome in many places (and also see what we need to do ;-) > Reading all the last mails I see that there is a strong readiness to invest > into the perfectioning of our teamwork. Yes, really good to hear :-) Now, as for your detailed and clear talk, I agree with most of it, but see below for more : > - Using the Wiki is nice, but to be honest, having documents that are part > of the svn-repo would be better. I would propose to use OpenOffice > documents, cause it is available with linux and windows and we can use the > math part and drawings in the documents to clarify tings much better. > Remember for most of us, English is not the native language. I agree the Wiki is poor as far as formatting is concerned, as well as "off-line" work (very poor here ;-). On the other end, it's very much stronger at collaborative writing ... Anyway, it is easy to insert links to ODF documents located in the SVN repo, and thus to share them in a simple way ... so if it helps us writing better documents, I agree. > - Let us start at the end now. Let us talk about the long time target first. > I'm sure we do not have the same view on it, but this does not mean, that > these individual views are incompatible. Having a better understanding of > the individual targets we will have a chance to define the development > direction for the next releases and after fixing the main steps per release, > we will be able to decide much better about the order of our next steps. > Remember, there are some principal decisions to do (i.e. change the graphics > engine, next simulation). And one of our most time consuming errors was, to > do things in the wrong order. We will have to rework some of our existing > code to allow new features from our wish list. We will see, that we will not > be able to implement all as fast as other parts. So we should define not > only one next step, but a sequence of next steps. +1 > - A principle we already used is votes, but the way we voted was > unsophisticatedly. Let us define the way how a vote has to be prepared and > finally done. The reason is, that we all have one vote, but for most votes > we will not all have the same information and knowledge about the topic we > have to vote about. To use voting in a serious way, we should make sure that > all have the chance to get the complete understanding of the consequences of > the different options we have to vote about. And to complete it we should > clearly define a right of veto for cases, that would force someone of the > team to do or work on things he cannot or may not work on. These things are > used in real world as well wherever a vote is the basic principle. True. As Kristof said, will need more time to decide. But getting better decisions is worth it. > - Let us split all future work/whishes into two main categories: Bug fixing > and development. The main criteria is, that bug fixing may not change things > for the existing release in a way that fixes the one bug intentionally but > raises others unintentionally. As an example ... > ... Therefore we cannot simply fix this bug, we have > to develop a new version of the simulation and make the setup files work > with the new version in a way that keeps the feeling of the car be same for > human drivers and does not change the robots results using the optimized > setups. Quite unclear to me ... is it about not changing existing code / setups in order to implement a new feature / fix a big bug, but rather fork it and only change the new "branch" ? (can be implemented through our module system, SVN branching, explicit versionning based on settings / data like in the track module, ...) If so ... yes, we can achieve it, and even make it easier ... but let's be careful about not multiplying variants of the same code / setups / artwork ... we could quickly get overwhelmed ... > - Let us discuss about the context of the development for modifications of > existing features before someone starts to change things. As example we > should look to the bugs we found in the track generation of the last > release. Trying to do some proof of concept tests, I tried to create some > test tracks. But I had to learn that our track generation is broken! The > calculation of the pit buildings is wrong now. We have no track editor, you > have to use the TORCS editor. But the TORCS track editor does not use a > program SD2-trackgen, it looks for trackgen. What we have to learn here is, > that the system we are working on is build from not clearly independent > parts. There are a lot of dependencies and as we have to accept, most of us > will not know all that is needed to decide about changes and their > consequences alone. To avoid such unpleasant surprise, we should define how > we discuss and prepare changes of existing code. +1 > - Let us discuss about the rules how to prepare and implement new features. > For some new features it is easy to make sure that existing features are not > affected. As example ... Here we should discus about what should be > implemented how to make the new interface be usable for all we will want to > have in the future. +1 > - Let us define the way we distribute new packages. We all are talking about > releases, but to be honest, this is a limitation we should overcome as soon > as possible. Why wait with a new set of tracks, cars, robots, until a > release? If it is ready, we could distribute it as AddOn package for the > last full release. Just for the tracks a lot of work is independent from > other development steps. Same is for car sets using existing tracks and > robots. Let us take this chance and use the independence to speed up our > work, keep speed-dreams in the press and maybe find new teammates for > development. A new release will be much smarter in size, if we do not have > to copy all the track and car textures again and again. New track/car data > is much smaller and will be needed for new features data, but the textures > and the car models itself? Instead of modifying the existing cars/models a > bit let us create fantastic new models. Definitely a good idea ... as Kristof said, needs some kind of automatic consistency check between data and code variants. But also possibly a source of big mess if are not careful. >> (do we all agree on this HQ release target ?) > For me I have to say, Jean-Philippe, the quality of code, release and > development is very important. > We all are limited in time, so we have to use it as much as possible. > Instead of working on many things a bit and get nothing finished we should > discuss and decide the next steps together. +1 So, let's go on :-) What about going on with Kilo's and my idea of : - 1 wiki page listing what we want for 2.1 - 1 wiki page listing what each dev.artist is willing to work on for 2.1 ? and make these 2 pages feed each other ? And then, study carefully the consequences, dependencies, the technical needs for making us able to develop these ideas in the way WD suggests (improve modularity of the code, make branches, ... etc ... ) ? And then iterate on the wiki pages from what we learned about the consequences, What about (parallel work) going on defining a clear release method with rules that every of us will have to officialy and formaly accept ? Who works on writing what here ? Come on :-) (I've started the "rules" stuff already, and will go on ; help welcome) Cheers, Jean-Philippe. |