Re: GSoC 2016: proposal accepted!

[Daniel J. <dan...@gm...>]

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