Posible project

[Robert Fitzsimons]

> Could you please send me a short CV and let me know what your 
> strengths are

I'll revert to my opening email on the dev list:
http://driverdev.linuxdriverproject.org/pipermail/devel/2007-July/000000.html

To add to that I've about 10 years working in the IT field, in roles
that have involved combinations of programming, system/network
administration, hardware installation, etc.

I've been involved in all stages of different projects including design,
implementation and maintenance.  With positions from junior programmer
through to team lead.

To give a weakness.  Even though I'm a native English speaker my written
English (grammar/spelling) can be very bad sometimes.

> what language(s) you prefer

The only one that really counts for Linux kernel development is C, you
could also add familiarity with assembler, makefiles, and shell
scripting as useful skills.  I've got all these covered.

> And a general assessment of your productivity 
> would be of interest... 10 lines/day, 100, 1000, 10000???

Lines/day is the wrong way to evaluate a developers productivity, and
not relevant for this type of project.

We need to remember who the customer is and what the final product is.
The customer is the general Linux using community which includes the
hardware manufacture and its customers.  The final product is a longterm
maintainable driver that is merged into Linux's tree.

The standards for code and design for inclusion in the Linux kernel are
extremely high, a functional drive that has just been thrown together
will not cut it.

> How much time could you expect to devote to the project per week?

I would hope to be able to spend a couple of evenings a week, time over
weekends, etc.  I would imagine that many developers work in spurts and
might spend a couple nights working long hours with gaps in between. 

If the documentation is open, small groups of developers can coordinate
the division of work into smaller more manageable tasks.

I think the role of the prjmgr's for LDP is to help get the each project
off the ground, with a small group of developers if needed/possible.
Act as a communications channel between the developers and manufacture.
Then periodically touch base with the developers and keep the hardware
manufacture and general community informed of the progress.  If problems
occur with time or other resources they should try and resolve them by
changing/adding developers, contacting the manufacture, etc.

> The next step should be to define the scope of effort and determine 
> whether additional resources are required.  Since Greg has an idea of 
> the type of driver required, perhaps he could provide a reasonable 
> effort of the time/effort required to write same.

This is a very difficult task for me and imagine the same for Greg.  On
code that I'm familiar with it might only be minutes or hours to make a
change but for someone unfamiliar withe code it could take days, weeks
or even months.

To give an up in the air guess.  I would have to say a month, but I'm
almost always wrong (short and long) with these types of guesses.  Also
we don't have a true understanding of the requirements.

> What about source code management?  There has been some chaos in the 
> kernel tree over this particular subject.  What is the current 
> standard?  Are we obliged to use it for our development work?

I would imagine project specific git trees are the way to go.

> I think our detailed correspondence regarding the project would best 
> be done off-list

Actually we should try and conduct everything in the open if possible,
protecting the contact details of manufacture staff would be very
reasonable, etc.  Also if the full datasheets can't be made available to
the public, we should at least try for custom versions which include
just the information needed to write and maintain the drivers.

Robert