SourceJuicer Contrib Process 

 Use at Own Risk: As provided in the Web Site Terms of Use, the Hosts may or may not pre-screen or perform compatibility testing on the Materials, and by using this repository You agree to assume all risks in Using the Materials. These risks include, but are not limited to, errors, viruses, worms, time-limited software that expires without notice, defamatory or offensive content, and the possibility that the Materials infringe or misappropriate the intellectual property rights of others.


OpenSolaris Source Juicer Contrib Repo Process

 The following describes the automated process used to add, update and remove packages from the contrib repo using the OpenSolaris SourceJuicer web application. If you need a package to port, here is a Contrib Repo Porting List.

Porting Guidelines

  1. Standard install locations should be used.
     2. Make sure you respect the namespace and the files that are installed by a package don't conflict with files in other packages.
     3. 32-bit and 64-bit Libraries should be provided when libraries are ported.
     4. The SunStudio compiler should be used when possible, since it normally produces faster code.
     5. Dtrace, FMA, ZFS, SMF and other powerful OpenSolaris features should be taken advantage of. Dtrace probes can be added. SMF manifests can be added instead of rc files, etc...
     6. Make sure all the dependencies are included in the manifest

Open Source License Notes

  1. Just after submission, prior to validation, Sun Contributors must add a comment to their package that includes the internal Open Source Review (OSR) number that references an approved OSR for the package (ie. OSR#12345 has been approved).
     2. When a Sun Approver notices an OSR comment that hasn't been verified already by an OSR verification comment (ie. OSR#12345 verified) they should look up the OSR number in the internal database and add a comment to the package that indicates the OSR has been verified or needs work.
     3. Packages submitted by Sun Contributors can not be promoted to contrib without an approved OSR, and should not be validated or included in the pending repo until an approved OSR has been verified.
     4. Non-Sun Contributors do not need to add OSR comments, but they need to ensure the package uses valid open source license(s) and the full text of all open source licenses used in the package are included in the copyright file.

Contrib Repo Package Add and Update Process

  1. On the Submit page, the Contributor enters a package identifier and uploads the package spec file, copyright file and any other source files used in the build and submits the package entry for validation.
     2. On the Review page, an Approver (Package Advocate) validates the spec file and copyright file containing the open source license text. If there are issues, the Approver can add comments to the package entry so the Contributor can correct the issues and re-submit the package.
     3. After a package has been validated it is automatically built.
     4. If build is successful, package is publish to the pending repo. If a build fails, the submitter can correct any issues and re-submit the package for building.
     5. On the Review page, an Approver (Package Advocate) reviews the package spec file(s), build log, package info, package manifest, package dependencies and install directory locations (namespace) and votes. TWO "+1" votes and NO "-1" votes within 24 hours are required for a package to be promoted to the contrib repo. If there are issues, the Approver can add comments to the package entry so the Contributor can correct the issues and re-submit the package.
     6. After the Contributor has installed and tested the package from the pending repo they indicate that the package is ready and the approved package is published to the contrib repo. [not implemented yet. Send email to sourcejuicer-discuss to let the team know you are ready for the package to be promoted to contrib]

Contrib Repo Package Removal Process

In Work
 Reasons for removing a package include:

  • Package can not be easily fixed and updated
  • Package is not licensed properly
  • Package causes security issues
  • Package causes severe failures
  • Package has been made obsolete by another package
last modified by admin on 2009/10/26 12:31
Collectives
Project


© Sun Microsystems Inc. 2009
XWiki Enterprise 1.8.2.19075 - Documentation
Terms Of Use | Privacy | Trademarks | Copyright Policy | Site Guidelines | Site map | Help
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Use.