Regarding the process discussion we had durring the stand-up. I think that we 
need to evaluate which changes require a RFC on a case-by-case basis. Some 
patches don't make sense as an RFC, for example compliation warnings, typos or 
formatting fix-ups. This is becuase these are trivial changes and requesting 
comments for a typo is pretty silly. Also, I don't know that any of the things 
we intend to go in <open-fcoe>/debug/ need to be validated.

That being said, functionality changes, features and non-trivial bug fixes 
(most of them) should follow the process-

discussion on [email protected]<mailto:[email protected]> and internally
RFC to [email protected]<mailto:[email protected]>
comments and replies
patch is finalized
mailed to fcoe-patches
john tests and gives aproval
patch mailed without RFC to [email protected]<mailto:[email protected]>
Rob pulls patches into repos, tests and mails to linux-scsi (when appropriate)

Our goal is to put out the highest quality patches possible without overloading 
validation with trivial stuff.

Thanks,

//Rob
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel

Reply via email to