On Thu, Sep 27, 2007 at 07:21:15AM -0600, Peter W. Morreale wrote:

quoted text
> On Wed, 2007-09-26 at 19:32 -0700, Greg KH wrote:

> > Hi all,

> >

> > You are getting this message because you have expressed interest in the

> > Linux Driver project.  I have set up a mailing list for this, which

> > everyone is now subscribed to.  If you want off of the list, just follow

> > the directions at the bottom of this message, or email me directly, I'll

> > be glad to take you off.

> >

>

> Terrific. Thanks for your efforts Greg.

>

> As a matter of infrastructure, I'm wondering whether the newly released

> Novell "Policy Forge" site might be a very useful tool for coordinating

> some of these efforts.   You can check it out here:

>

> http://developer.novell.com/forge/bin/view/NovellForge

>

> Briefly, Policy Forge is a controlled access Forge site, hosted at

> Novell.  It provides registered members with a private:

>

> * bugzilla

> * subversion repository

> * wiki

> * ftp site

> * mailing lists 

As much as I would like to recommend using the Novell infrastructure, I

can't.  We currently have access to a dedicated server and free

bandwidth on which we can put any of the above if we so desire.  We also

have full control over the box, with some very capable sysadmins helping

us out.
Also, all of that would be a lot of overkill for what we need to do

here.
To do a project, I expect the following to be used:

	- email between the developers, project managers, and company

	  involved.  We can create separate mailing lists to make this

	  easy if necessary, or if confidentiality is needed by the

	  company.

	- patches for the code sent by email to the above.

	- We can easily set up git to store kernel modifications in

	  while they are being developed, if the developer(s) need them.

	  (subversion sucks on so many levels, let's just not even go

	  there...)
And that's it.  No "feature trackers" or bugzilla is needed, as that's

not how the Linux kernel development groups work, and we need to

intergrate our output into the kernel development process.  If we were

to set up some separate process, that would just make it harder to

intergrate, and cause bigger problems (as some kernel subsystems are

now finding out despite them being told to avoid this...)
thanks,
greg k-h