From: Euan M. <lu...@us...> - 2001-06-19 08:15:40
|
Listening to the latrest round of coding approach discussions, here's what I think the approach should be based on: 1) Requirements Decide on the area of functionality, and what specific functionality, is to be coded Method: - discuss functionality on Arianne-main - compile ideas into a single document - poll to decide between competing approaches - decide on specific features to be coded into a given release, by polling for: - importance, on Arianne-main - difficulty, on Arianne-dev n.b. This means that we should not have a seperate Arianne- Poll mailing-list I know, I know, this means I've changed my mind. But I've thought about it more :-) 2) Architecture Decide on how the code will be structured, to account for: - other, later, code that will have to use it - Arianne's multi-platform requirement - bandwidth conservation - ping tolerance - execution efficiency - execution speed Method: - Discuss on Arianne-dev - compile ideas into a single document - poll to decide between competing approaches - if required: - amend the specific feature list for the next release - publish the amended list to Arianne-main - if required, re-poll to get the amended list accepted - document the design in UML (optional?) 3) Implement - Code the functionality, as agreed in 1 & 2 above 4) Publish on test server 5) Amend implementation 6) Publish in next Beta release 7) Amend implentation 8) Publish next release - bug-fix only repeat of last Beta What do you all think? Cheers, Euan xl...@us... 'I would live all my life in nonchalance and insouciance, Were it not for making a living, which is rather a nouciance' - Ogden Nash |
From: Benjamin `Q. L. <ari...@qu...> - 2001-06-19 08:34:54
|
Euan Mee a =E9crit=A0:=20 > What do you all think? Sorry to be rude: BullShit. I'm not gonna wait 3 weeks of dicussion before writing a line of code, correcting a bug, changing some kind of implementation that is not optimized or things like that... There is, for the moment, very few people comitting code, and I really do not want this number to decrease one more time because of the rigidity of your system. --=20 Benjamin `Quisar' Lerman qu...@qu... http://www.ambre.net/= quisar "Si les yeux pouvaient tuer et enfanter, les rues seraient pleines de ca= davres et de femmes grosses." Valery |
From: <x51...@fe...> - 2001-06-19 13:36:02
|
Mensaje citado por: Benjamin `Quisar' Lerman <ari...@qu...= >: > Euan Mee a =E9crit=A0:=20 > > What do you all think? >=20 > Sorry to be rude: BullShit. >=20 > I'm not gonna wait 3 weeks of dicussion before writing a line of code, > correcting a bug, changing some kind of implementation that is not > optimized or things like that... k, on that you are right. But we can decrease the timelines. And discuss on ML the functionality requiered. > There is, for the moment, very few people comitting code, and I really > do not want this number to decrease one more time because of the > rigidity of your system. Yes, you are right. But this method can save us a few emails of why this has been coded or wh= y code=20 is not stable and so... Anyway obvious things should be done in a automatic thing. To fix a bug i= s=20 automatic, to design Object System is not... most of the code can be done= =20 without delay, the point is what to do, really howto do it is not so impo= rtant. Miguel Angel Blanch Lardin =20 -- http://www.arianne.cx -- Arianne -- The free open source massively multiplayer online role playing game nuclear cia fbi spy password code encrypt president bomb iran irak korea = cuba Ala yihad mosad kgb free freedom human rights yugoslavia kosovo ebola dna= =20 =20 -- Echelon must die -- |
From: Euan M. <lu...@us...> - 2001-06-20 01:40:05
|
On 19 Jun 2001, at 15:35, x51...@fe... wrote: > Mensaje citado por: Benjamin `Quisar' Lerman > > Euan Mee a =E9crit=A0: > > > What do you all think? > > Sorry to be rude: BullShit. > > I'm not gonna wait 3 weeks of dicussion before writing a line > > of code, correcting a bug, changing some kind of > > implementation that is not optimized or things like that... > > k, on that you are right. But we can decrease the timelines. And > discuss on ML the functionality requiered. I don't suggest at any time that there are 3 week coding holidays. What I do say is: in a given functional area, we must agree what is to be coded, and how, before coding. Why write code for something that's not wanted or needed, or which ignores the decisions on RP functionality? Code all you like in the areas which are agreed on. Wait for the requirements to be agreed before coding new areas. An example: coding is ongoing for the Renderer,and various other areas. Why is waiting a short while before coding the Perception systems, or the Weather Model, when the discussions on how they work are still ongoing, such a difficult thing to do? > > There is, for the moment, very few people comitting code, and > > I really do not want this number to decrease one more time > > because of the rigidity of your system. > > Yes, you are right. > But this method can save us a few emails of why this has been > coded or why code is not stable and so... Having a set of documents that lets newcomers know whats going on, and how the various bits fit together, both as interfacing modules, and as tasks in the overall planned sequence of events, can only help make it easier for new coders to join. Making it easier for coders to slot in means an *in*creasing number of coders. > Anyway obvious things should be done in a automatic thing. To fix > a bug is automatic, to design Object System is not... most of the > code can be done without delay, the point is what to do, really > howto do it is not so important. Exactly. Cheers, Euan xl...@us... 'I would live all my life in nonchalance and insouciance, Were it not for making a living, which is rather a nouciance' - Ogden Nash |
From: <x51...@fe...> - 2001-06-20 10:53:35
|
> Wait for the requirements to be agreed before coding new > areas. > > An example: > coding is ongoing for the Renderer,and various other areas. > > Why is waiting a short while before coding the Perception > systems, or the Weather Model, when the discussions on > how they work are still ongoing, such a difficult thing to do? Yes, I must to agree with Quisar here... The whole system can't be waiting on a decision to be taken on a small area like perception is. IMO is better to discuss fast and then change code if we need new requirements. > > > There is, for the moment, very few people comitting code, and > > > I really do not want this number to decrease one more time > > > because of the rigidity of your system. > > > > Yes, you are right. > > But this method can save us a few emails of why this has been > > coded or why code is not stable and so... > > Having a set of documents that lets newcomers know whats > going on, and how the various bits fit together, both as > interfacing modules, and as tasks in the overall planned > sequence of events, can only help make it easier for new > coders to join. > > Making it easier for coders to slot in means an *in*creasing > number of coders. Yeah, sound perfect, but: a) someone has to write the papers. b) someone has to worry to update papers. Really, that is pretty hard... And we shouldn't add more burocrazy to the project, so that changing a line of code will mean to fill 50 forms and update 30 documents. But the idea take as a light-simple process could be good. Miguel Angel Blanch Lardin -- http://www.arianne.cx -- Arianne -- The free open source massively multiplayer online role playing game nuclear cia fbi spy password code encrypt president bomb iran irak korea cuba Ala yihad mosad kgb free freedom human rights yugoslavia kosovo ebola dna -- Echelon must die -- |
From: Brian R. <row...@ha...> - 2001-06-20 18:45:32
|
On 20 Jun 2001 12:53:17 +0200, x51...@fe... wrote: > > > Wait for the requirements to be agreed before coding new > > areas. > > > > An example: > > coding is ongoing for the Renderer,and various other areas. > > > > Why is waiting a short while before coding the Perception > > systems, or the Weather Model, when the discussions on > > how they work are still ongoing, such a difficult thing to do? > > Yes, I must to agree with Quisar here... > The whole system can't be waiting on a decision to be taken on a small area like > perception is. IMO is better to discuss fast and then change code if we need > new requirements. I agree with this idea... talk fast, change fast. We can depend on cvs to allow us to reverse bad changes. But on _design_ changes or additions I think that we should be more formal. -- "Teach a man to make fire, and he will be warm for a day Set a man on fire, and he will be warm for the rest of his life." - John Hrastar |
From: <x51...@fe...> - 2001-06-19 13:31:11
|
Mensaje citado por: Euan Mee <lu...@us...>: > Listening to the latrest round of coding approach discussions, > here's what I think the approach should be based on: > > 1) Requirements > Decide on the area of functionality, and what specific > functionality, is to be coded > > Method: > - discuss functionality on Arianne-main > - compile ideas into a single document > - poll to decide between competing approaches > - decide on specific features to be coded into a given release, > by polling for: > - importance, on Arianne-main > - difficulty, on Arianne-dev > > n.b. This means that we should not have a seperate Arianne- > Poll mailing-list I know, I know, this means I've changed my > mind. But I've thought about it more :-) > > 2) Architecture > Decide on how the code will be structured, to account for: > - other, later, code that will have to use it > - Arianne's multi-platform requirement > - bandwidth conservation > - ping tolerance > - execution efficiency > - execution speed > > Method: > - Discuss on Arianne-dev > - compile ideas into a single document > - poll to decide between competing approaches > - if required: > - amend the specific feature list for the next release > - publish the amended list to Arianne-main > - if required, re-poll to get the amended list accepted > - document the design in UML (optional?) > > 3) Implement > - Code the functionality, as agreed in 1 & 2 above > > 4) Publish on test server > > 5) Amend implementation > > 6) Publish in next Beta release > > 7) Amend implentation > > 8) Publish next release - bug-fix only repeat of last Beta > > What do you all think? I like it :) We should do this on that way. I will place this on the Website unless there is any objections. Miguel Angel Blanch Lardin -- http://www.arianne.cx -- Arianne -- The free open source massively multiplayer online role playing game nuclear cia fbi spy password code encrypt president bomb iran irak korea cuba Ala yihad mosad kgb free freedom human rights yugoslavia kosovo ebola dna -- Echelon must die -- |