I don't believe in individual failure. We should try to put a system in place to avoid this next time.
A related issue is that GHC didn't get in either because they didn't have a good page with potential projects. I propose: * Several of us put the next deadline into our calendar (probably beginning of Feb, so I used 31st of January 2018). I just did so. * We collect ideas for next year already. I have created: https://github.com/teh/gsoc/blob/master/2018/projects.md - please send PRs and I'll give you commit bits. ~ On 15 March 2017 at 12:46, Domen Kožar <do...@dev.si> wrote: > We aren't participating in GSOC 2017, because I missed the submission > deadline. > > > That being said, I know people will be disappointed by this. I'm sorry, > I have no excuses really. I was overworked at that time and totally forgot > to watch the dates. > > I already applied us two times, I hope I'll gather the energy to try again > next year. > But since I screwed up this year, someone else can take over if wanted, > I understand not to be trusted :) > > Domen > > On Mon, Mar 13, 2017 at 6:23 PM, Anderson Torres < > torres.anderson...@gmail.com> wrote: > >> 2017-01-08 18:40 GMT-02:00 Profpatsch <m...@profpatsch.de>: >> > On 17-01-04 09:42pm, Vladimír Čunát wrote: >> >> On 01/04/2017 08:51 PM, Peter Simons wrote: >> >> > Another very important topic that needs to be addressed in Nix / >> Hydra >> >> > is the question of how to deal with code that wants to import build >> >> > products into the ongoing evaluation. [...] >> >> >> >> That feels rather vague topic ATM. My experience is that this kind of >> >> "figure it out how to..." tasks isn't very suitable for similar >> "project >> >> proposals" like for GSoC. Still, if we could converge on some more >> >> concrete plan beforehand, maybe the actual implementation would make a >> >> good topic... >> >> I would suggest three big fat proposals: >> >> 1 - The most flamewar-igniting one: getting rid of systemd dependency! >> It would be very nice if the init system was selectable, with a sane >> default (as openrc). >> It would be hard as hell to port certain software as Gnome stack, but >> I think it can be solved. >> >> 2 - Another for the even more courageous would be run a Nixos+kNetBSD >> (or kFreeBSD), as in Debian. It would be the definitive test for >> portability and independence of Nix model. >> >> 3 - Another set of defaults for the stdenv, as musl+clang. >> >> > >> > Sounds more like a task for a master’s thesis (or adventurous >> > bachelor’s thesis) to me. >> > >> > -- >> > Proudly written in Mutt with Vim on NixOS. >> > Q: Why is this email five sentences or less? >> > A: http://five.sentenc.es >> > May take up to five days to read your message. If it’s urgent, call me. >> > _______________________________________________ >> > nix-dev mailing list >> > nix-dev@lists.science.uu.nl >> > http://lists.science.uu.nl/mailman/listinfo/nix-dev >> _______________________________________________ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
