Re: GSoC 2016: proposal accepted!

> * Daniel Jour <[email protected]> [2016-04-23 08:54:31 +0000]:
> Sam writes:
>
>> I suggest that you clone the mercurial repo and commit your patches in
>> your branch.
>
> With "branch" you mean "branching by cloning"[1], right? (using mostly
> git, mercurial not having a "standard" branching approach was at first
> a bit shocking.)

whatever works for you.

> In order to have the code/patches accessible (and also safe) I'd like
> to put them to some remote repository: On sourceforge there's a "fork"
> button, which is probably doing exactly what is needed (creating a
> clone where I can push changes to). Or is there a better approach?

I don't know, but it sounds reasonable.

> A question regarding C coding style: src/CodingStyle has not much on this,
> when writing new code / fixing old code, what style should I try to follow?
> As far as I can see there's no "overall" consistent use of a single style.
> Should I try to follow the general GNU coding style[2]?

CLISP style is more geared towards "compactness" (e.g., only the closing
brace is ever on its own line, never the opening - unless it is the
first in a function and thus in the first column; no more than 2 spaces
for indentation &c).

> What's the "oldest" supported C standard? There's utils/varbrace.c to
> be able to write C99-like code but target C90, so I guess it's C90?

Yes, it has been like that for quite some time.

Your next step after making the release might be removing varbrace and
requiring C99 - are there any major compilers which don't support it?

> Should I keep the convention of using the var macro, or directly write
> C90 compatible code? As already said, I personally would choose the
> later, but it's no problem for me using var for declarations as
> currently done.

I suggest sticking with the current conventions for now.

> Then, regarding organization: Should we set up regular status reports?
> I guess I start building a (more) detailed list of what needs to be
> done, in order to be able to track progress.

If you have no questions for a week, please send e-mail here describing
your progress.
I am afraid you will be asking questions more frequently than sending
progress reports though :-)

> Being a GNU project, do you need any legal / licence related document
> from me?

Not really.  CLISP is GNU GPL v2+, so all your code is to be released
under that license; I assume you understand that. :-)
A simple note in an e-mail that you acknowledge and accept that fact and
do consent to releasing your code under GPLv2+ is fine.

> Is it ok if we keep this mailing list as "main communication channel"?

Yes, please!


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11803000
http://www.childpsy.net/ http://www.dhimmitude.org http://camera.org
http://mideasttruth.com http://honestreporting.com http://truepeace.org
Time would have been the best Teacher, if it did not kill all its students.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel