At Mon, 10 May 2010 16:23:17 +0200, Joseph Wakeling wrote: > What I'd like to know is if there are any recommended practices for > making my work "friendly" to the GSL in the sense that it can be readily > incorporated back if/when it gets the necessary level of approval.
Since I'm limited in the time I can spend on GSL these days the main thing is for any code I deal with to be well tested and debugged in actual use before submission. If it is in specific areas like linear algebra maybe other people like Patrick Alken can help. If there are multiple changes needed after something is submitted it becomes problematic, particularly if they necessitate changes to the API. > (i) Is it OK to have functions named along the lines of, > > gsl_mylib_func() > > ... as per typical GSL fashion, so that the API will remain > stable if/when the code is incorporated into GSL? I'd recommend using the prefix mylib_ to avoid confusion with existing gsl functions. > (ii) Are there any recommended practices related to VCS that will > make it easier to incorporate a semi-independent project into > GSL and preserve version history? Currently bzr branch http://bzr.savannah.gnu.org/r/gsl/trunk > (iii) What's the appropriate etiquette to follow regarding discussion, > of the project status? How much discussion can/should I make on > this and other GSL lists, for example? I would like the work to > be developed in as close collaboration with the wider GSL > community as possible. You can use this list, it is the best place I think. -- Brian Gough
