Re: GSoC 2016: proposal accepted!

Sam writes:
> Your proposal
>
https://summerofcode.withgoogle.com/dashboard/project/6280060281552896/overview/
> has been formally accepted for Google Summer of Code 2016.
>
> Congratulations!

Thank you :) I'm really glad that it got accepted (especially considering
the
relatively low number of slots for GNU this year).

> 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.)

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?

> This will require updating gnulib imports as necessary, merging in the
> various patches submitted over the years and fixing the windows
> socket/handle issue.

I'm thinking of starting directly off with the gnulib imports, as a lot of
code depends on them (and the last import seems to have broken stuff).
Makefile.devel pulls gnulib from git, I guess that's what I do, too? (There
are also "stable" releases, but AFAIK they aren't used that much.)

> Please ask questions here.

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]?

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? 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.

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.

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

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

> Good luck and thanks!

Thank you :)

[1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
[2] https://www.gnu.org/prep/standards/html_node/Writing-C.html#Writing-C

------------------------------------------------------------------------------
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