Guidelines for tasks?

[Matthew Dillon]

:> Kip Macy wrote:
:> 
:>> I was wondering if you had thought about creating a more fine-grained
:>> set of tasks for working towards your design goals so that individuals
:>> can contribute smaller pieces. Or does it make more sense right now to 
:>> restrict work to those who really understand what you have in mind?
:>>
:>>         -Kip
:>>
:> 
:> I agree with Kip in this sense: a "task-tree", some library of existing 
:> open tasks that indicates how they are linked with other tasks (that are 
:> also in some state of pending/open/complete stage), would enable people 
:> to contribute in smaller chunks by taking on tasks, completing them and 
:> then dipping in again in some other area.  The ability to see how all 
:> the tasks relate to one another at any time may encourage those of us 
:> who really want to be a part of this exciting project to get involved 
:> but who are time-limited in terms of how much they can take on at one 
:> time or another.  Perhaps some visual/diagramatic representation (on the 
:> dragonfly site, perhaps) of such a tree (consisting of data drawn from a 
:> development database populated by individuals as they work on separate 
:> tasks) would work?  Just a thought :)  Anyone think of lightweight 
:> examples of such a thing rather than having to build one from scratch?
:> 
:> 
:
:I'm glad that I'm not completely out in left field on this one. I'm 
:CC'ing Matt this time in case he missed the message by accident.

    Well, I agree with the concept.  I'm not sure about a visual
    representation but we could create nested dependancies on a web page
    using tables.

    It's good to talk about this now because, as I have said, within a week
    or two a significant number of in-kernel codepaths are going to become
    available for external development.

    I am really only pre-committing myself to certain large scale one-man
    projects.  DEV messaging infrastructure, VFS messaging infrastructure,
    VFS name cache rewrite, initial SYSCALL message wrapping, and a few
    others that are basically one-man jobs which touch dozens or hundreds
    of files and get the subsystem to the point where additional work can
    be done in smaller chunks.
 
    e.g. when I do VFS all our filesystems will suddenly be a lot slower
    because they won't be reentrant any more, which means work could begin
    on making the most important filesystem(s) (ah.. probably just UFS)
    reentrant again.

    When I do the initial SYSCALL work then we immediately open up several
    additional projects, such as userland threads support, initial
    kernelland (rfork) thread hacks, and ultimately asynchronization of
    those system calls which can non-trivially block (mainly I/O calls).

    As I write down these things I am slowly going to build up a simplistic
    work tree in the Status section.  Some better way of organizing it
    might be in order.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>