Re: [gentoo-dev] Google SOC 2008
On Thursday 28 February 2008 11:22:13 Roy Marples wrote: So the only thing left (aside from bug fixing) is to instruct OpenRC dependency code that it's in a prefix and to respect the noprefix keyword in services, or to provide dummy services. This is now done. I have OpenRC fully working in a prefixed non priviledged install on a NetBSD box. The only question I have left is what mechanism resets service state, as the prefixed state dir needs will presist between reboots which isn't desirable. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On 03-03-2008 13:36:25 +, Roy Marples wrote: On Thursday 28 February 2008 11:22:13 Roy Marples wrote: So the only thing left (aside from bug fixing) is to instruct OpenRC dependency code that it's in a prefix and to respect the noprefix keyword in services, or to provide dummy services. This is now done. I have OpenRC fully working in a prefixed non priviledged install on a NetBSD box. Can you define how this is working? Do you just have NetBSD and install OpenRC in /my/arbitrary/path, or do you have a full set of utilities under /my/arbitrary/path with OpenRC as one of them? The only question I have left is what mechanism resets service state, as the prefixed state dir needs will presist between reboots which isn't desirable. startprefix could maybe start some sort of process that lives on, activated like keychain does, such that multiple startprefix invocations do not start the system all the time -- if that is desired at all. In a real scenario it may be just a hook from the host OS's start/stop mechanism to tell OpenRC in what state it should run. If a service such as PostgreSQL is killed (maybe a reboot?) does OpenRC then know it is not running any more? I guess it does, so that's good enough, IMO. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Mon, 2008-03-03 at 15:53 +0100, Fabian Groffen wrote: On 03-03-2008 13:36:25 +, Roy Marples wrote: On Thursday 28 February 2008 11:22:13 Roy Marples wrote: So the only thing left (aside from bug fixing) is to instruct OpenRC dependency code that it's in a prefix and to respect the noprefix keyword in services, or to provide dummy services. This is now done. I have OpenRC fully working in a prefixed non priviledged install on a NetBSD box. Can you define how this is working? Do you just have NetBSD and install OpenRC in /my/arbitrary/path, or do you have a full set of utilities under /my/arbitrary/path with OpenRC as one of them? The only question I have left is what mechanism resets service state, as the prefixed state dir needs will presist between reboots which isn't desirable. startprefix could maybe start some sort of process that lives on, activated like keychain does, such that multiple startprefix invocations do not start the system all the time -- if that is desired at all. In a real scenario it may be just a hook from the host OS's start/stop mechanism to tell OpenRC in what state it should run. Must admit not having looked at OpenRC yet - maybe I understood sth. wrong, but: +1 for registering OpenRC into host OS's specific init.d mechanism. Here I'm doing so with distccd on ia64-hpux, having some (host OS specific) script in (not yet gentoo-) prefix, understanding additional '--install [name]' - or have a separate command for that. This needs to be run as root once to register into host OS's init.d mechanism. For hpux fex this just is adding some symlinks: /sbin/init.d/name - /my/prefix/sbin/init.d/distccd /sbin/rc3.d/S990name - /sbin/init.d/name # to start in runlevel 3 /sbin/rc2.d/K100name - /sbin/init.d/name # to kill for runlevel 2 When doing so with OpenRC's main process, it could integrate smoothly with normal system reboot and start prefixed init.d scripts. /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Mon, 3 Mar 2008 15:53:20 +0100, Fabian Groffen [EMAIL PROTECTED] wrote: On 03-03-2008 13:36:25 +, Roy Marples wrote: On Thursday 28 February 2008 11:22:13 Roy Marples wrote: So the only thing left (aside from bug fixing) is to instruct OpenRC dependency code that it's in a prefix and to respect the noprefix keyword in services, or to provide dummy services. This is now done. I have OpenRC fully working in a prefixed non priviledged install on a NetBSD box. Can you define how this is working? Do you just have NetBSD and install OpenRC in /my/arbitrary/path, or do you have a full set of utilities under /my/arbitrary/path with OpenRC as one of them? I did this in OpenRC source rm -rf /home/roy/pkg make PREFIX=/home/roy/pkg PKG_PREFIX=/usr/pkg install Create Gentoo style init script in /home/roy/pkg/etc/init.d for say boinc export PATH=$PATH:/home/roy/pkg/bin:/home/roy/pkg/sbin rc-update add boinc default rc default boinc started The only question I have left is what mechanism resets service state, as the prefixed state dir needs will presist between reboots which isn't desirable. startprefix could maybe start some sort of process that lives on, activated like keychain does, such that multiple startprefix invocations do not start the system all the time -- if that is desired at all. In a real scenario it may be just a hook from the host OS's start/stop mechanism to tell OpenRC in what state it should run. If a service such as PostgreSQL is killed (maybe a reboot?) does OpenRC then know it is not running any more? I guess it does, so that's good enough, IMO. This needs to be done on startup rc sysinit rc default Which is pretty much what we do in Gentoo anyway. Just ensure that the sysinit runlevel only runs once, as it will remove all state when run again. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Mon, 03 Mar 2008 16:50:49 +0100, Michael Haubenwallner [EMAIL PROTECTED] wrote: For hpux fex this just is adding some symlinks: /sbin/init.d/name - /my/prefix/sbin/init.d/distccd /sbin/rc3.d/S990name - /sbin/init.d/name # to start in runlevel 3 /sbin/rc2.d/K100name - /sbin/init.d/name # to kill for runlevel 2 When doing so with OpenRC's main process, it could integrate smoothly with normal system reboot and start prefixed init.d scripts. Yes, that should work fine if it ends up calling /sbin/init.d/name start and /sbin/init.d/name stop to start and stop it. You just have to somehow inject rc sysinit into the boot process to remove all state data. But a better way would be like so /my/prefix/sbin/rc-wrapper #/bin/sh case $1 in start) /my/prefix/sbin/rc default;; stop) /my/prefix/sbin/rc single;; esac As you then get OpenRC handling the dependency order if you have 1 service. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
joshua jackson wrote: All, Google is once again doing the summer of code for students. I'm helping organize it this year and am putting out a call for some elements to help. 1) We need idea's for things to do. Diego has already submitted some via his blog which have been taken into consideration. - crossbuild support for a gentoo compatible package manager (up to the student pick which) - eselect pm and emerge wrapper for alternate package managers. 2) We need mentors, so far confirmed I have: Diego and Saleem add me. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
I have some ideas to improve GNAP (last year was a nice experience): - live upgrade - squashfs pkgs - unionfs i think this 3 task can fit in only one project. - use new catalyst This is the hardest one adn must be a different project. regards El mar, 26-02-2008 a las 10:32 -0800, joshua jackson escribió: All, Google is once again doing the summer of code for students. I'm helping organize it this year and am putting out a call for some elements to help. 1) We need idea's for things to do. Diego has already submitted some via his blog which have been taken into consideration. 2) We need mentors, so far confirmed I have: Diego and Saleem -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
Check your idea into cvs.. ;) On 2/29/08, JoseAlberto [EMAIL PROTECTED] wrote: I have some ideas to improve GNAP (last year was a nice experience): - live upgrade - squashfs pkgs - unionfs i think this 3 task can fit in only one project. - use new catalyst This is the hardest one adn must be a different project. regards El mar, 26-02-2008 a las 10:32 -0800, joshua jackson escribió: All, Google is once again doing the summer of code for students. I'm helping organize it this year and am putting out a call for some elements to help. 1) We need idea's for things to do. Diego has already submitted some via his blog which have been taken into consideration. 2) We need mentors, so far confirmed I have: Diego and Saleem -- gentoo-dev@lists.gentoo.org mailing list -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On 28-02-2008 11:22:13 +, Roy Marples wrote: On Wed, 27 Feb 2008 15:21:58 +0100, Fabian Groffen [EMAIL PROTECTED] wrote: I'm not sure how far OpenRC actually can deal with unprivileged installs, so that are just things we have to find out along the way. Provided you have permissions to start the configured programs, then it's fine. OpenRC now supports PREFIX=/home/roy/foo and PKG_PREFIX=/home/roy/bar. PREFIX is where OpenRC installs to (also respects DESTDIR). PKG_PREFIX is where packages install to if different. So the only thing left (aside from bug fixing) is to instruct OpenRC dependency code that it's in a prefix and to respect the noprefix keyword in services, or to provide dummy services. Right. Assuming this will be enough to start, that means one GSoC project less ;) Thanks for the work anyway! -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Tue, 26 Feb 2008 10:32:45 -0800 joshua jackson [EMAIL PROTECTED] wrote: All, Google is once again doing the summer of code for students. I'm helping organize it this year and am putting out a call for some elements to help. 1) We need idea's for things to do. Diego has already submitted some via his blog which have been taken into consideration. 2) We need mentors, so far confirmed I have: Diego and Saleem Something nice would be to reimplement revdep-rebuild as a package set for portage-2.2 (the ground work for that is already done, but most of the processing logic from revdep-rebuild is still missing). Unlike most other portage-related ideas this one doesn't require a huge understanding of portage internals, and I'd be willing to mentor applicants for this. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Google SOC 2008
On 26-02-2008 10:32:45 -0800, joshua jackson wrote: All, Google is once again doing the summer of code for students. I'm helping organize it this year and am putting out a call for some elements to help. 1) We need idea's for things to do. Diego has already submitted some via his blog which have been taken into consideration. - sandbox porting to Darwin, Solaris, FreeBSD (flameeyes), NetBSD and OpenBSD (would love AIX, IRIX, True64, HPUX and Interix too ;) ) - sandbox implementation of bug #205312 - baselayout porting to Prefix (mostly the start stop mechanisms) - scanmacho (scanelf for Darwin) tool (to replace otool) - make packages.g.o searchable - combine packages.g.o and tinderbox.d.g.o - binary Prefix bootstrap (ultimately using what's on tinderbox.d.g.o) 2) We need mentors, so far confirmed I have: Diego and Saleem For the above things where I don't step on others' toes, yes. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Wed, 27 Feb 2008 09:42:05 +0100, Fabian Groffen [EMAIL PROTECTED]
wrote:
- baselayout porting to Prefix (mostly the start stop mechanisms)
What start stop mechanics do you mean?
OpenRC already has full FreeBSD jail support in services like do
depend() { keyword nojail; }
That effectively disables the automatic running of services by rc itself,
such as fsck, mounting and stuff as that's taken care of by the host OS.
Running in Prefix is pretty much the same as a jail from OpenRC's
perspective
(correct me if I'm wrong) so all we would have to do is tell OpenRC that
it's
currently in a jail. Presently this is done only for FreeBSD by testing
sysctl values. Maybe we could turn this into a compile option for Prefix.
Also, we now support services in directories other than /etc/init.d,
although
this is currently hard coded to /usr/local/etc/init.d.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
Fabian Groffen [EMAIL PROTECTED] wrote: On 26-02-2008 10:32:45 -0800, joshua jackson wrote: All, Google is once again doing the summer of code for students. I'm helping organize it this year and am putting out a call for some elements to help. 1) We need idea's for things to do. Diego has already submitted some via his blog which have been taken into consideration. - sandbox porting to Darwin, Solaris, FreeBSD (flameeyes), NetBSD and OpenBSD (would love AIX, IRIX, True64, HPUX and Interix too ;) ) - sandbox implementation of bug #205312 - baselayout porting to Prefix (mostly the start stop mechanisms) - scanmacho (scanelf for Darwin) tool (to replace otool) - make packages.g.o searchable - combine packages.g.o and tinderbox.d.g.o - binary Prefix bootstrap (ultimately using what's on tinderbox.d.g.o) 2) We need mentors, so far confirmed I have: Diego and Saleem For the above things where I don't step on others' toes, yes. Probaby i could do some mentor work afterall :-) -- Damian Florczyk aka thunder Gentoo Developer, Gentoo/NetBSD Development Lead -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On 27-02-2008 10:46:43 +, Roy Marples wrote:
On Wed, 27 Feb 2008 09:42:05 +0100, Fabian Groffen [EMAIL PROTECTED]
wrote:
- baselayout porting to Prefix (mostly the start stop mechanisms)
What start stop mechanics do you mean?
OpenRC already has full FreeBSD jail support in services like do
depend() { keyword nojail; }
That effectively disables the automatic running of services by rc itself,
such as fsck, mounting and stuff as that's taken care of by the host OS.
Running in Prefix is pretty much the same as a jail from OpenRC's
perspective
(correct me if I'm wrong) so all we would have to do is tell OpenRC that
it's
currently in a jail. Presently this is done only for FreeBSD by testing
sysctl values. Maybe we could turn this into a compile option for Prefix.
Also, we now support services in directories other than /etc/init.d,
although
this is currently hard coded to /usr/local/etc/init.d.
Well... that's great! But a jail or a (ch)root is in general not the
same as a prefix. I have to look more closely at what openrc does
these days, but for the (ancient) version of baselayout we have in
prefix now, I recall that:
a) most of it didn't compile on Darwin and Solaris
b) hence we only use basically the functions.sh script (hacked up)
so what we need to have working is:
${EPREFIX}/etc/init.d/postgresql start
and similar.
And maybe even a sort of init-level stuff, such that one can start all
services in the Prefix and stop them as well. That basically gets quite
useful once Prefix goes privileged and you could start sshd, slapd,
apache2, etc, etc. on privileged ports, and you really would like those
to be started as well in some correct order (on e.g. Solaris).
--
Fabian Groffen
Gentoo on a different level
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen [EMAIL PROTECTED]
wrote:
Well... that's great! But a jail or a (ch)root is in general not the
same as a prefix.
No, but it's the same kettle of fish as chroots, jails and vps systems -
basically
there is a need to disable dependencies that provide what the host already
does.
We current have nojail for FreeBSD jails, novps for VServer/OpenVZ systems
and
a few others. I would be trivial to add another no for prefix :)
I have to look more closely at what openrc does
these days, but for the (ancient) version of baselayout we have in
prefix now, I recall that:
a) most of it didn't compile on Darwin and Solaris
It compiles and works on Linux/glibc/uclibc, FreeBSD-6 and NetBSD-4.
So it stands a fair chance of working on Darwin for sure.
I have no idea about Solaris, but it should work as it sports libkvm which
we
use to find processes.
b) hence we only use basically the functions.sh script (hacked up)
so what we need to have working is:
${EPREFIX}/etc/init.d/postgresql start
and similar.
And maybe even a sort of init-level stuff, such that one can start all
services in the Prefix and stop them as well. That basically gets quite
useful once Prefix goes privileged and you could start sshd, slapd,
apache2, etc, etc. on privileged ports, and you really would like those
to be started as well in some correct order (on e.g. Solaris).
If OpenRC compiles and /bin/sh points to a POSIX shell it should work as it
stands.
At present there is no need for the default interpreter to be changed, but
there may
be the need for Prefix.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On 27-02-2008 13:56:51 +, Roy Marples wrote:
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen [EMAIL PROTECTED]
wrote:
Well... that's great! But a jail or a (ch)root is in general not the
same as a prefix.
No, but it's the same kettle of fish as chroots, jails and vps systems -
basically
there is a need to disable dependencies that provide what the host already
does.
Ok, the host will for instance do net, so need net should indeed not
fail. However I could imagine that need net would just get satisfied
or something, like by a dummy.
We current have nojail for FreeBSD jails, novps for VServer/OpenVZ systems
and
a few others. I would be trivial to add another no for prefix :)
I just need the machinery of runscript as first thing, I suppose. If
we need a dozen of no* things for that, it probably indicates some
problem, but could work for me. I want a framework to start and stop
daemons in Prefix, and it feels obvious that we can reuse existing code
for that.
I have to look more closely at what openrc does
these days, but for the (ancient) version of baselayout we have in
prefix now, I recall that:
a) most of it didn't compile on Darwin and Solaris
It compiles and works on Linux/glibc/uclibc, FreeBSD-6 and NetBSD-4.
So it stands a fair chance of working on Darwin for sure.
Well... I've some experience here, and I'm not as sure as you ;)
Anyway, I concur the codebase has changed dramatically since, and
probably in favour of portability.
I have no idea about Solaris, but it should work as it sports libkvm which
we use to find processes.
Part of the summer of code project to me would be to 1) evaluate to what
extent this is all necessary in the Prefix equivalent and 2) create/fix
the code.
And maybe even a sort of init-level stuff, such that one can start all
services in the Prefix and stop them as well. That basically gets quite
useful once Prefix goes privileged and you could start sshd, slapd,
apache2, etc, etc. on privileged ports, and you really would like those
to be started as well in some correct order (on e.g. Solaris).
If OpenRC compiles and /bin/sh points to a POSIX shell it should work as it
stands.
Ok, then we already fail here.
/bin/sh is no way POSIX, it is just bourne, so that's where we come in
and simply use /usr/bin/env {sh,bash,posix-sh} or a full path to make
your assumption true.
At present there is no need for the default interpreter to be changed, but
there may
be the need for Prefix.
See above. But that's trivial work, that we do all the time. For the
GSoC I see more challenges in the rest of the job and to make some
obvious examples.
But then again, it was just a mere suggestion. If everything is already
there then fine, but we still need someone (Google code or not) to do
it, as it's currently not. I'm not sure how far OpenRC actually can
deal with unprivileged installs, so that are just things we have to find
out along the way.
--
Fabian Groffen
Gentoo on a different level
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Wednesday 27 February 2008 14:21:58 Fabian Groffen wrote:
On 27-02-2008 13:56:51 +, Roy Marples wrote:
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen [EMAIL PROTECTED]
wrote:
Well... that's great! But a jail or a (ch)root is in general not the
same as a prefix.
No, but it's the same kettle of fish as chroots, jails and vps systems -
basically
there is a need to disable dependencies that provide what the host
already does.
Ok, the host will for instance do net, so need net should indeed not
fail. However I could imagine that need net would just get satisfied
or something, like by a dummy.
Correct. lu_zero wanted OpenRC to work out of the box in a vanilla fbsd jail,
hence the keyword instead of dummy scripts.
If OpenRC compiles and /bin/sh points to a POSIX shell it should work as
it stands.
Ok, then we already fail here.
/bin/sh is no way POSIX, it is just bourne, so that's where we come in
and simply use /usr/bin/env {sh,bash,posix-sh} or a full path to make
your assumption true.
make SH=/usr/local/bin/bash
now tweaks all the scripts accordingly.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
joshua jackson a écrit : 2) We need mentors, so far confirmed I have: Diego and Saleem What kind of work is involved there? I wouldn't mind being a mentor but I'd like to know a bit more about what's expected from a good mentor. Thanks, Rémi -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
Rémi Cardona wrote: joshua jackson a écrit : 2) We need mentors, so far confirmed I have: Diego and Saleem What kind of work is involved there? I wouldn't mind being a mentor but I'd like to know a bit more about what's expected from a good mentor. Thanks, Rémi There's a few requirements. Being decent in a language or multiple languages would certainly be a plus, as the students are writing code. having someone writing something in C or C++ when you've never touched it wouldn't exactly work out that well obviously. Having time to interact with the student as well. They are getting paid as are we as an organization, so helping them and giving them idea's is needed. Touching base and making sure they are still progressing on their projects. Its summer...but they are being paid to work so it is a job as I hope as a mentor you would take a similar approach as well. Basically you act as a technical boss/mentor/leader to someone. One area I'm working on for this year is goals within the overall goal that can be implemented hopefully even if the project isn't fully finished before the end of the project. For the mentor it won't be a full time commitment but having time to talk with/help someone with their project and explain how to implement this feature or get this information from Gentoo's system would take some time. As a warning some people come on board with excellent programming ability that you don't need to do much with/for. Some well its their first real jump into programming and need more attention. I plan on having a few additional questions for the Gentoo related applications to help define that kind of thing and hope to get people together in such a way. As well a few of the people who are helping run it have agreed to help poke/get updates from the mentors and step in and help in whatever way possible to the students as well. Basically, we want as many projects to succeed as possible and become a daily tool or vastly improved tools as possible. Its certainly something that is possible. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On 2/26/08, joshua jackson [EMAIL PROTECTED] wrote: Rémi Cardona wrote: joshua jackson a écrit : 2) We need mentors, so far confirmed I have: Diego and Saleem What kind of work is involved there? I wouldn't mind being a mentor but I'd like to know a bit more about what's expected from a good mentor. I hope to have documentation up by the end of the week. Thanks, Rémi There's a few requirements. Being decent in a language or multiple languages would certainly be a plus, as the students are writing code. having someone writing something in C or C++ when you've never touched it wouldn't exactly work out that well obviously. You will reviewing the student's ideas and work. You will need whatever skills are required to to that; it will depend highy on what project you choose to mentor. Having time to interact with the student as well. They are getting paid as are we as an organization, so helping them and giving them idea's is needed. Touching base and making sure they are still progressing on their projects. Its summer...but they are being paid to work so it is a job as I hope as a mentor you would take a similar approach as well. You should expect to spend a minimum of five (5) hours a week doing reviews of your student's code. Ideally you would make remarks for readability and documentation as well as design and implementation. You should meet with your student regularly to discuss progress; if the student is having problems they should be brought up and dealt with. You should run your students code to make sure it functions as he or she said it would. If it has tests, run those too. If it doesn't have tests; ask the student to write some ;) Basically you act as a technical boss/mentor/leader to someone. I would argue that you are a peer, not a boss. In the end, someone the student should probably take advice from in order to have a decently working product by summer's end. One area I'm working on for this year is goals within the overall goal that can be implemented hopefully even if the project isn't fully finished before the end of the project. For the mentor it won't be a full time commitment but having time to talk with/help someone with their project and explain how to implement this feature or get this information from Gentoo's system would take some time. As a warning some people come on board with excellent programming ability that you don't need to do much with/for. Some well its their first real jump into programming and need more attention. I plan on having a few additional questions for the Gentoo related applications to help define that kind of thing and hope to get people together in such a way. While true I don't think it is fair for the 'superstar' guy to just let him do whatever. *review their code*. Read it, run it, see what it does. If the student says they wrote it in 3 hours and it is awesome and well commented try running it through a profiler; find places where it could be improved. Look for poorly implemented algorithms, memory leaks, over-use of memory etc... As well a few of the people who are helping run it have agreed to help poke/get updates from the mentors and step in and help in whatever way possible to the students as well. Basically, we want as many projects to succeed as possible and become a daily tool or vastly improved tools as possible. Its certainly something that is possible. My ideas are all insane (I probably only did half when I was a mentor) but I want the students to have a good experience and I want the code to not suck and that requires a mentor who actually gives a damn and is willing to put time into it. -Alec -- gentoo-dev@lists.gentoo.org mailing list -- gentoo-dev@lists.gentoo.org mailing list
