[Twg] TWG meeting minutes for 2011-04-20

Thu Apr 21 19:38:28 UTC 2011

Attached are the meeting minutes from today's TWG call where we started the discussion of what OpenSFS will require for release collateral and delivery of patches that result from our RFPs.

Please post questions/comments to discuss at lists.opensfs.org<mailto:discuss at lists.opensfs.org>

Thanks,

--jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensfs.org/pipermail/twg_lists.opensfs.org/attachments/20110421/7e3e40c5/attachment.html>
-------------- next part --------------
OpenSFS Technical Working Group
Meeting minutes : 04/21/2011

Concall: start : 9:30a PT, adjourn : 10:10a PT

Next meeting: Thursday, 4/28/2011 @ 9:30a PDT/12:30p EDT
   Dial-in numbers are 715-726-4994 or 866-304-8294.  
   Meeting ID and password are 72090 (note the new code)

Attending :
   Name              Organization   email
   ----------------- -------------- ----------------------------
   Diego Moreno      Bull           Diego.Moreno-Lazaro at bull.net
   Cory Spitz        Cray           spitzcor at cray.com
   John Carrier      Cray           carrier at cray.com
   Alex Kulyavtsev   FNAL           aik at fnal.gov
   Steve Simms       IU             ssimms at indiana.edu                            
   Joshua Walgenbach IU             jjw at indiana.edu
   Chris Morrone     LLNL           morrone2 at llnl.gov
   Shay Seager       OpenSFS        shay at opensfs.org
   Dave Dillow       ORNL           dillowda at ornl.gov
   Andreas Dilger    Whamcloud      adilger at whamcloud.com
   Nathan Rutman     Xyratex        nathan_rutman at xyratex.com

Agenda ------------------------------------

   release collateral

Discussion --------------------------------

   The release material is independent of who is hosting the canonical
   branch or who is managing the next release.  OpenSFS is paying for
   code development and we need to set expectations for what is required
   to land the new features in a release branch.

   Baseline requirements are 
      -  design documents
      -  test plan
      -  results of tests

   Sun/Oracle used a procedure where the developer would
      * push the patches into a development branch of the source tree
      * request two inspectors to review the patches
      * run tests against the private branch
      * report results of the tests to the gatekeeper
   The gatekeeper would then negotiate with the developer whether the
   feature was ready for inclusion.   For OpenSFS, it was suggested that
   we include scale testing to the list of tests to be run before
   posting the results to the gatekeeper.  

   Note that this list is similar to the submission guidelines offered
   by Whamcloud on their wiki (see "Patch landing process" at
      http://wiki.whamcloud.com/display/PUB/Submitting+Changes).

   >> OpenSFS should provide our own reference to these steps to clearly
   set our expectations of the vendors.  The guidelines should be
   release neutral, but acknowledge that they should be tailored to the
   steps of the current release manager. 

   In addition, Sun/Oracle had checklists that the developer needed to
   consider before actually submitting the patch.  These included
   considerations of impact of the patch on recovery, scaling and
   interoperability.  There were also coding style checklists to ensure
   that the code was compatible with the kernel.  (Whamcloud has a copy
   of the coding style manual at 
      http://wiki.whamcloud.com/display/PUB/Coding+Guidelines ).

   As part of the coding guidelines, OpenSFS expects appropriate
   copyright statements for the new features.  These typically follow
   the license of whatever module is being modified.  

   >> OpenSFS should provide a copy of both types of checklists to the
   vendors.  Andreas and Nathan said they would send the historical
   Lustre submission checklists to the TWG reflector.

   The following are the proposed deliverables which should be included
   in the RFP contracts : 

      1) We require design documents available for community review

         The TWG is responsible for approving the designs after
         confirming that they meet the requirements in the RFP and
         then recommending that implementation of the designs begins.

      2) We require the code to land upstream

         This means we will follow standard Lustre guidelines (as
         described above) for delivering the patches to the canonical
         tree.  

         * We expect the vendor to request two qualified, impartial
            inspectors rather than the TWG itself to review the feature
            submissions.   (We acknowledge that the TWG itself does not
            have the expertise to do the review, though some of its
            members do.)

         * Patches need to be sized to facilate easy review. [Do we have
            guidelines for patch size?]

         * At the time of patch submission there needs to be a test
            plan. Results need to be posted publically to the patch as
            tests are completed.  

         * We expect the ongoing development branch to be publically
            readable. Though we desire a stable top of tree, we expect
            vendors to provide tags covering significant milestones (eg,
            test completion) so that the tagged stable branch can be
            inspected and tested by the community.

adjourn 10:10 PT