John Denker wrote: > On 01/28/2007 04:43 PM, Martin Spott wrote: > > Well, you see: Communication between developers is a nice thing and we > > practice this quite often, cross-checking isn't that bad either ;-) > > Spoken like a true pilot.
Good guess - this is one of my hobbies :-) http://foxtrot.mgras.net/bitmap/EDDI/imm017_17.jpg > ============================================= > > Those who can read and write the project CVS repository presumably > find CVS very convenient. > > Meanwhile it would be wise to occasionally think about how things > look to other contributors, i.e. those who cannot directly write > to the repository. > > Such contributors find CVS vastly less convenient. It is a big > hassle to manage patches, even when there are only one or two > people working on something. [...] But what do you actually expect ? As you already realized: > Bottom line: Two points: > -- Flightgear is not the first project to face this situation. > It would be nice to have some decent tools to support a > project-within-project development model. The simple question is: How should these tools work ? I don't think there's a real solution to this problems that adresses all your concerns. You'll _always_ face the situation in such a project that some people have write access to the repository and some don't. FlightGear certainly is a bit special in that strinkingly few people 'manage' a pretty complex piece of software and these people are a limited resource, but what do you actually want to do about this ? Take your patch for the HSI as an example. Of those few people who have write access to the repository - and still participate in development - there are maybe probably only two or three who have real-live experience with the use of a HSI and therefore a 'feel' for it's use. But these people have a day job which comsumes a significant amount of time and as testing such a HSI patch 'in flight' comsumes some time as well. So there is a conflict arising in which the person who could do the test simply decides to devote his time to the paid job instead of FlightGear. Finally, the person who submitted the patch isn't at fault, the person who could test it isn't either. One of the solutions to get the best out of this situation is to simply re-submit the patch one or two weeks later. I know from experience that it can get pretty annoying waiting several weeks for the commit of a patch that is pretty obvious .... to the submitter. Maybe one solution to reduce such delays lies in convincing other people to test such a patch and make them comment on it. Linux kernel developers "sign-off" most or even all of the patches that get into the kernel source tree. A model of certain similarity could ease the task of everyone who is involved into FlightGear development. The word "community" is certainly one that's being used inflationary. In fact what people call a "community" typically characterizes a group of people that turns into complete silence when the call for voluntary work is announced ;-) Yet, having a community of people that _really_ support each other in a group of more than just two would be beneficient for FlightGear. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
