From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19119 invoked by alias); 11 May 2010 14:42:07 -0000 Received: (qmail 19000 invoked by uid 22791); 11 May 2010 14:42:06 -0000 X-SWARE-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BAYES_50,TW_BZ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 May 2010 14:42:01 +0000 Received: from localhost ([127.0.0.1]:50477 helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBqed-0005MT-Bp; Tue, 11 May 2010 10:41:51 -0400 Date: Tue, 11 May 2010 14:42:00 -0000 Message-ID: <43eihiijup.wl%bjg@gnu.org> From: Brian Gough To: Joseph Wakeling Cc: gsl-discuss@sourceware.org Subject: Re: Flat (uniform) random distribution and some development/contribution queries In-Reply-To: <4BE816D5.8060106@webdrake.net> References: <4BE7EAAD.20603@webdrake.net> <4BE816D5.8060106@webdrake.net> User-Agent: Wanderlust/2.15.6 (Almost Unreal) Emacs/23.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2010-q2/txt/msg00015.txt.bz2 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