Hi Coly,

I'm glad to hear about your interest in working on FreeIPMI.  Actually,
myself and A.B. spoke about starting a testsuite soon.  We still need to
flesh out some details, but if you'd like to help, we can always use the
extra help.

Al

--
Albert Chu
[EMAIL PROTECTED]
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


----- Original Message -----
From: coly li <[EMAIL PROTECTED]>
Date: Thursday, December 8, 2005 5:42 pm
Subject: Re: [Freeipmi-devel] FreeIPMI meeting notes + Todos

> Hi,every one. I just join this maillist these days. I've worked on 
> IPMIfor three years, including driver, FW and system software. I 
> want to do
> something for this project, for example writing some testsuite, or
> documentations.
> 
> Where can I start ?
> 
> Coly
> 
> 
> 
> ? 2005-12-08?? 11:23 -0800?Albert Chu???
> > MEETING NOTES
> > 
> > Compliance Testing:
> > 
> > Linux IPMI Test Suite
> > ---------------------
> > 
> > Use testsuites for major open source applications as a "starter"
> > testsuite for both vendors and users.  Vendors get extra testing and
> > some assurance open source projects will work with their hardware.
> > Users of IPMI (including someone like Cyclades) get extra assurance
> > their technology will work with certain hardware.  Open source
> > projects get more testing of their tools.  Combination of multiple
> > projects covers more IPMI functionality than any one project (can
> > likely) cover on their own.
> > 
> > TODOS:
> > Zresearch - Start on FreeIPMI Testsuite
> > LLNL - Get/devel IPMItool testsuite, speak to OpenIPMI author
> > General todo: Try to build momentum on this.
> > 
> > IPMItool + Ipmipower:
> > ---------------------
> > 
> > Idea is HPC features of Ipmipower would be very useful in 
> Ipmitool. 
> > Ipmitool would get HPC features and Ipmipower gets more IPMI
> > specification coverage.
> > 
> > Interest: Cyclades
> > TODO: Continue discussions on it with Ipmitool author.  Just need 
> to start.
> > 
> > ICTS
> > ----
> > Why is the ICTS testsuite only available to "IPMI Adopters".  
> This is
> > stupid, users want it too for testing.
> > 
> > TODO: Zresearch, LLNL, anyone: Bug Intel people.
> > 
> > FreeIPMI in Redhat
> > ------------------
> > 
> > Get vendor support by getting FreeIPMI into RHEL.
> > 
> > TODO: LLNL and SLAC will bug Redhat on our weekly conference calls.
> > 
> > FreeIPMI TODOS
> > --------------
> > 
> > Zresearch TODO: Raw Hex command support
> > 
> > Zresearch TODO: Perl/Python Bindings(?)
> > (Al: Sorry, my notes weren't clear, I'm not sure.)
> > 
> > Zresearch TODO: Adveritse/document Guile, point to howto's, 
> supply templates
> > 
> > Web GUI/Windows Compilation of FreeIPMI
> > ---------------------------------------
> > 
> > I don't know if we came to a conclusion, I can't remember.  Sorry.
> > Maybe vendors can tell us if this is important to them and would 
> make> them more interested in FreeIPMI.
> > 
> > FreeIPMI Coding
> > ---------------
> > 
> > CVS Tagging: Announce to freeipmi-devel before making a release tag.
> > 
> > CVS branching: Branch experimental code and work independently until
> > it is reasonably complete.  Then merge into head.  Incomplete 
> changes> or major architectural changes (i.e. UDM would have fallen 
> under this)
> > aren't submitted into the head until completion.
> > 
> > fiid_template_t: We will always stay to spec.  Never deviate!
> > 
> > fiid_template_t/fiid_obj_t reorganization: We will all think 
> about it
> > and discuss further on the mailing list.  There are many different
> > methods to re-architect the underlying objects to meet this need.
> > 
> > lan session management in libfreeipmie: We all agreed that session
> > management is getting more difficult in IPMI 2.0.  A rearchitect or
> > new set of APIs may be necessary to make session management
> > manageable.
> > 
> > libfreeipmi re-org: The directory libfreeipmi/src/ is large and
> > big. We agreed that subsections of the library could be put in
> > subdirectories or organized in some better manner.
> > 
> > LGPL: We need to consider LGPLing libfreeipmi for the potential 
> it may
> > be used by more vendors.  To be discussed in more detail on the
> > mailing list.
> > 
> > UDM: One remaining big bug.  Another set of eyes would be useful, so
> > Al Chu will try and hunt this one down.
> > 
> > Multihost LAN API: Many possible implementations and API
> > possibilities.  We'll all think about it and discuss further on the
> > mailing list.
> > 
> > --
> > Albert Chu
> > [EMAIL PROTECTED]
> > Computer Scientist
> > High Performance Systems Division
> > Lawrence Livermore National Laboratory
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Freeipmi-devel mailing list
> > Freeipmi-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/freeipmi-devel
> > 
> 
> 
> 



_______________________________________________
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Reply via email to