[gentoo-dev] Job offer for a Ph.D holder in an innovative startup

2009-10-30 Thread Jean-Noël Rivasseau
Hi,

I am the CEO of a small web startup and we currently need to hire a software
developer. For financial reasons this absolutely needs to be a Ph.D holder
that has just defended his thesis (eg, first job for the candidate).

We are looking for a person with strong programming skills and a passion for
computer science. Being an open source partisan is a big plus, our company
is running only on free software, our servers are Gentoo of course. The job
is more about general web development than server maintenance. We code in
Java (Groovy), Python, JavaScript, Bash and others. We have lots of
projects, so interesting challenges and a lot of work awaits worthy
candidates :)

We are based in France but we totally work remotely, so you can work from
anywhere in the world if you got broadband. I myself am moving to Canada
soon. To be paid by our company though, it is possible that you have to get
a French adress (residency), for legal reasons (haven't really looked into
this yet, currently all team members are French). For this reason, it would
probably be easier to work with French people, but I can try to see if it
can work out with a foreigner if people are interested. I think it can.

The salary will be (very) good.

If you are interested in this or know someone who could be interested,
please get in touch.

Elvanor


Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

2008-03-05 Thread Jean-Noël Rivasseau
I totally second this proposal.

I think this would be especially great for small or rarely used packages. I
can think of at least a dozen packages that I'd love to see in Portage, but
they are not in the tree. Allowing for people that are not developers to
maintain easy or not crucial packages is a good thing. It would not require
much effort for these people (since some packages are updated like once a
year), and even if the ebuilds are of low quality, that would not be a big
problem (we could mark those ebuilds specially so that if we developers have
some time to spare, we can review them).

The only problem I see, like Anant mentionned, is that we would need to
restrict commit access to parts of the tree. Not sure if that is possible.

Elvanör

On Wed, Mar 5, 2008 at 6:11 PM, Anant Narayanan [EMAIL PROTECTED] wrote:

 Hi,

  If you have something you'd wish for us to chat about, maybe even
  vote on, let us know !  Simply reply to this e-mail for the whole
  Gentoo dev list to see.

 If it's not too late for this month's meeting, I'd like to discuss the
 possibility of including a new post in our developer base - the
 package maintainer.

 a) The requirements to become a package maintainer for Gentoo may be
 lesser than that of the full-fledged developer. This serves a couple
 of purposes:
- Users might become more motivated to becoming a maintainer for
 Gentoo, since it would require less time and effort from their end
- Might reduce the number of orphaned packages we have in the tree

 b) Some existing developers might want to switch to this post, if they
 feel that package maintenance is all they really want to do with
 Gentoo. This has the advantage of requiring lesser time from their
 side, while not feeling the pressure of being responsible. We
 already have arch-testers, so this will fit in nicely with our current
 development model.

 c) The actual developer post may be taken up by existing developers
 who make wide-ranging or significant changes to Gentoo, as a whole.
 Examples include: package manager development, eclasses,
 documentation; basically anything that would require a GLEP or commit
 access to the whole tree - you get the idea.

 Some of you may argue that we already have proxy-maintainers. That's a
 great idea, all I'm asking for is for us to formalize the position.
 Giving a proxy-maintainer an official acknowledgement will definitely
 attract more users to contribute. Meanwhile, developers can do
 innovative things that they really like without having to maintain
 packages just because of a formality. Giving package maintainers
 commit access to parts of the tree might turn out to be tricky though,
 this needs discussion with infra.

 I'd really like for us to think through this proposal - I strongly
 believe that this will improve the quality of Gentoo development as a
 whole, and reduce the number of open bugs and their turnaround times.

 Cheers,
 Anant

 P.S. As some of you may have already guessed, this proposal is based
 on Debian's approval of a similar position in their developer
 hierarchy last year: http://www.us.debian.org/vote/2007/vote_003

 P.P.S. Maybe this is more suited for -project, but everyone knows that
 nobody reads that list :-p
 --
 gentoo-dev@lists.gentoo.org mailing list




Re: [gentoo-dev] New developer : Ingmar Vanhassel (ingmar)

2008-01-16 Thread Jean-Noël Rivasseau
Welcome (from a very new dev too), and thanks for the good work on KDE 4!

On 1/16/08, Richard Freeman [EMAIL PROTECTED] wrote:

 Denis Dupeyron wrote:
 
  Please everybody, give a very warm welcome to Ingmar.
 

 Welcome aboard!
 --
 gentoo-dev@lists.gentoo.org mailing list




Re: [gentoo-dev] New developer : Jean-No??l Rivasseau (elvanor)

2008-01-08 Thread Jean-Noël Rivasseau
Hi,

Don't worry, I may very well return to Vancouver some day as I really love
the place. Actually, I am thinking of returning there on Autumn 2008 for at
least 6 monthes. I wonder if I can be part of two conspiracies at once?!

Jean-Noël

On 1/8/08, Robin H. Johnson [EMAIL PROTECTED] wrote:

 On Tue, Jan 08, 2008 at 01:29:43PM +0100, Denis Dupeyron wrote:
  Jean-No??l currently lives in Paris, France, but he studied in
  Vancouver, Canada for some time.
 Why'd you leave Vancouver? We need to get a Vancouver conspiracy going
 again, there hasn't been one since mr_bones_ ran away! (hey, 4
 developers is still enough to conspire right?)

 Welcome aboard.

 --
 Robin Hugh Johnson
 Gentoo Linux Developer  Infra Guy
 E-Mail : [EMAIL PROTECTED]
 GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85




Re: [gentoo-dev] Re: New eclass osgi.eclass

2007-12-20 Thread Jean-Noël Rivasseau
Hello all,

I have a new version of the eclass ready, with much of the remarks
addressed. It now goes by the name java-osgi and in the new form,
should be ready to enter the tree.

I fixed the performance problem I mentionned earlier, cleaned up the
eclass API, and simplified the code almost everywhere.

Waiting for your feedback.

Cheers

Elvanör


java-osgi.eclass
Description: Binary data


Re: [gentoo-dev] Re: New eclass osgi.eclass

2007-12-07 Thread Jean-Noël Rivasseau
Thanks all for this feedback. I think this is sufficient to warrant
some modifications as suggested, and I propose to postpone the
inclusion in tree a little bit.

Regarding performance, there is an important point to note as IMHO it
is much more penalizing than using basename or such.

The fact that I use the jar utility to unzip a file, combined with the
fact that jar does not have an option to specify a destination
directory, is troublesome. I have to copy the .jar file to the
destination directory and then remove it. This .jar file can be
several MBs of course.

Initially I was using zip but I replaced it with jar in order to avoid
a dependency on zip. But maybe it's not worth the performance penalty.

Regards,

Elvanör


On Dec 6, 2007 1:11 PM, Petteri Räty [EMAIL PROTECTED] wrote:
 Steve Long kirjoitti:
  Alistair Bush wrote:
  Im sure Elvanor can't wait for you constructive feedback on his eclass
  and depending on your feedback the eclass will enter the tree this
  weekend.
 
  A couple of very minor performance points, which I think are more
  significant in eclasses. Firstly the basename thing Donnie pointed out
  before:

 Well usually you don't noticy any differences. In global scope things
 could have some effect of course.

 
  You have a couple of functions that take, say, 4 or 5 arguments. It would be
  more robust to use a case, eg:
  case $# in
  5)..;;
  4)..;;
  *) die Incorrect use of $FUNCNAME;;
  esac
  ..than if (($#4)); then ..; else .. ;fi
 

 Well imho they are equivalent and eclass maintainers should go with what
 they prefer.

 
  With regard to:
   debug-print-function ${FUNCNAME} $*
  if you want debug-print-function to get the arguments correctly, use $@
  not $* (cf 'Special Parameters' in man bash for a proper explanation: this
  applies to all arrays. http://wooledge.org/mywiki/BashFAQ/073 shows how to
  manipulate all members of an array, eg to add a prefix.)

 Doesn't matter as arguments are just written to a file and for some
 reason this form is used all over the base in eclasses but shouldn't
 hurt to use [EMAIL PROTECTED] with new code.


 
  This use of counter in _java-pkg_osgijar-fromfile is odd:
  while [[ -n ${1} ]]; do
  # while [[ $1 ]] or while (($#)) also work
 if [[ ${1} == --noversion ]]; then
noversion=1
 else
arguments[${counter}]=${1}
((++counter))
 fi
 shift 1 # just shift?
  done
 
  (([EMAIL PROTECTED]  3))  die At least three arguments (not
  counting --noversion) are needed for java-pkg_osgijar-fromfile()
 
  You can either just add to the array with: arguments+=($1)
  or add using the counter: arguments[counter++]=$1
  and then check: ((counter  3))  die ..
 
  Arithmetic context[1] applies in array indexes, so you don't need to use a $
  for variables and you can post/pre-incr etc there.
  Yuu can also use it for C-style flags, with 0 as false and non-zero true:
  if [[ ${noversion} == 1 ]];
  can be
  if ((noversion));
 
  This is handy since unset variables evaluate as zero, which is false inside
  ((..)), so a simple flag=1 is all that's needed, ie you don't have to set a
  default, although ofc it's more robust to do so, especially for functions.
  declare -i flag=0 # makes a local var which can only have integer values
  assigned (setting it to string typically evaluates to zero; arithmetic
  context is used for all assignments, so a string which happens to be a
  variable with an integer will return that value.)
 
  [1] http://wooledge.org/mywiki/ArithmeticExpression
 

 We really don't need to create the arguments array at all. We could just
 check if ${1} is --noversion and then use shift. After that we can use
 the positional arguments as usual so instead of ${arguments[0]} we can
 use just ${1}.

 Regards,
 Petteri



���^����(� ��X��X�