[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU accepted as a mentoring organization in GSOC 2014

From: Thomas Schwinge
Subject: Re: GNU accepted as a mentoring organization in GSOC 2014
Date: Tue, 25 Feb 2014 09:53:57 +0100
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)


On Mon, 24 Feb 2014 20:29:31 +0100, jemarch@gnu.org (Jose E. Marchesi) wrote:
> Hi guys.  Good news: we [GNU] are in.  [...]

> Well, this is all for now... keep in mind that the formal students
> application date opens on 10 March, but you will be undoubtly contacted
> much earlier by enthusiast students..

A few random ideas that I had re project ideas, in addition to
<http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/>.  By
no means have I thought a lot about these, so you may easily convince me
if they're not suitable.

Are there any Debian projects?  Maybe something to expand on Justus'
continuous integration buildbot instance?  (I'd still envision a system
where you can drop in a patch, and then everything on top of that is
rebuilt and tested, so that you can, say, change something in MIG, and be
sure that nothing breaks in glibc, GDB, and so on.)

GCC: Front end for MIG RPC files.  We have MIG, and it works, but this
may be an interesting project for someone who wants to dive into the
compiler, creating a rather simple front end.

GDB: »catch syscall«; pretty-printing of mach_msg.
<https://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.html>.  That
translates to us to »break mach_msg« with suitable RPC name matching.
Pretty printing of mach_msg arguments à la rpctrace.  Might these days be
implemented as a Python pretty-printer in GDB.

glibc: implement interfaces that we are currently missing.  Is this a
suitable task; can we identify a set of missing implementations that a
student could work on implementing?  See
<http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#missing> for a
list, or at the end of
<http://darnassus.sceen.net/~hurd-web/open_issues/systemd/>, »Required

Ada (GNAT) and Google Go "porting" tasks.  I'd again suggest to keep
these in: the porting part should be rather easy to resolve now; the
important part then is to get the changes integrated upstream.  And then,
focus on proper interfacing with the Hurd: RPC interface, properly
integrated into the language.

On IRC it has been raised the idea about »implement[ing] Hurd specific
features in GNU utilities«.  This would be primarily support for
translators, I presume, and primarily for passive one, so that ls lists
them à la symlinks on Unix, and tar archives them, etc.?  Certainly a
valid task, but I'd rather have us focus on

Are the X.org items once listed on their wiki,
still valid, and should thus be reinstated on

LLVM: I have once been working on fixing some things upstream re Hurd
support, but don't currently have the bandwidth for continuing that --
worth adding as a project?  This is basically open ended -- culminating
in porting the sanitizers, a big task,
<http://darnassus.sceen.net/~hurd-web/open_issues/_san/>, which then GCC
also will benefit from.

Anything else?


Attachment: pgpUr79PGMp67.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]