[pkg-discuss] /contrib repository rough proposal

[Stephen Hahn]

  Over the past few weeks, we seen a sequence of messages asking about
  how to publish a package/where to publish a package/etc.:
   
http://mail.opensolaris.org/pipermail/pkg-discuss/2008-May/003232.html
http://mail.opensolaris.org/pipermail/pkg-discuss/2008-May/003338.html
http://mail.opensolaris.org/pipermail/pkg-discuss/2008-May/003405.html
http://mail.opensolaris.org/pipermail/pkg-discuss/2008-June/003996.html

  (One of the aspects of this problem that you might not care about, but
  I needed to figure out was whether or not Sun could act as a relayer
  of packages with some legal safety--happily, we can, under terms
  similar to those used for the plugins/modules used on some of the
  other sites.  (Thanks to David C, and Judy and Jeff for figuring this
  out.))

  So, to answer these questions, the model David and I have been toying
  with is a "contrib" repository, with the largest component being
  binary packages from the recipes in the spec-files-extra or the F/OSS
  package base projects

  http://pkgbuild.sourceforge.net/
  http://opensolaris.org/os/project/pkgbase/

  (depending on what Laca and company say, of course).  I would expect
  to take other contributions using a process like

  0.  Claim package from a list, or otherwise advertise, so that
      duplicate work is avoided.  You can also deliver your own
      OSS/redistributable software via this repository, subject to #4
      below.
                                                                                
  1.  Get package to build and install on OpenSolaris 2008.05.
                                                                                
  2.  Run a private depot.  Use pkgsend open, pkgsend import, pkgsend
      close to create a package in your private depot. 

  3.  Either send us the URL to your private depot (running in readonly        
      mode if public!), or use pkgrecv and GNU tar to collect your             
      package in transaction form--and send us a URL to that file.             
                                                                                
  4.  The /contrib project members will vote on inclusion, based on
      following best practices on naming and metadata.  If you like, the
      project can revise your metadata for completeness, or you can
      update your proposed package based on that review. 
                                                                        
  As a component's importance becomes better understood, it is expected
  that the ARC process and integration into a consolidation would
  follow.  In this case, the component would be dropped from /contrib,
  or left to satisfy only older installations.  (You can view this as a
  promotion from a less stable repository to a more stable one.)
  
  Thoughts?  

  - Stephen

* If you're already targeting integration into the SFW or JDS
  consolidations, you can ignore this proposal; those consolidations are
  the best choice for direct inclusion of OSS into 2008.05's successors.
  (If you work for Sun Microsystems' Software division, this proposed
  repository is not for delivery of your software; feel free to write me
  privately if you're not sure where your component should be delivered.)

-- 
sch at sun.com  http://blogs.sun.com/sch/