Please note that these suggestions are not official for OpenCSW. If you want to add something, please tag it properly

  • Source. [bonivart] Our packages are distributed in a convenient, ready-to-use binary form but open source standards require that source is provided. The GAR build system makes this possible but maybe a better way (for all packages regardless of how they were built) would be to have a source package for every binary package that would drop the source in /opt/csw/src/pkgname. To include source in the binary packages is not a very good solution since it would bloat package (download) size even though very few are interested in having the source.
  • Current status: [dagobert] This is being worked on by Dagobert. First there should be a package for GAR (almost there), then packages containing sources, patches and package descriptions. After these prerequisites the real "download source and compile" packages will follow.
  • Key. [bonivart] The key used to sign the catalog should have a passphrase known by more than a single person for obvious reasons.(Status: [phil] already handled)
    • Gary Law made an interesting suggestion that the key should be owned by the foundation/board.
  • Current status: [dagobert]: The key is held be all release managers for current as described in Release Process. The board does not has access to the key. It is passed only between persons needing the key directly.
  • Board. [bonivart] OpenCSW should have a board of three or five members that decide major issues. Tasks should be delegated to members to run as they see fit but if a user/member can't resolve an issue with the responsible person the issue can be escalated to the board.
  • Current status: [dagobert]: Done. The current board is named at Open Community Software Project Board
  • Release Process. [bonivart] The release process should not be run by a single person (for one thing - who checks his packages?). Testing should be documented via preferably a web app. Updates, especially security related, needs to be processed faster, they need an automated release.
    • We should be able notify the release group via an e-mail alias or better yet, the test web app should automatically notify all members of the release group. The first to respond should "own" the job.
    • The status of a package should be openly available to all via the same web app.
    • We need more automated checks to improve the quality of our packages. Some things are hard to predict but everytime we have a packaging problem we should try to implement a solution into the release process so it doesn't happen again.
  • Current status: [dagobert]: At the moment all current release manager are able to release packages as descibed in Release Process.
  • Pkg-get. [bonivart] Alternatives to pkg-get should be given equal status, that means access to catalog data and mentioned on web site, mirrors and so on.
  • Current status: [dagobert]: Done, e. g. on Testing Download
  • Distributed. [bonivart] Services related to OpenCSW should be distributed across several people to minimize risk. GAR is now a sourceforge project, build farms are being set up independent of each other, domain names are registered by several people and so on.
  • Current status: [dagobert]: Partly done
    • GAR on SourceForge: The projects "gar" and "opencsw" are administered by Dagobert and Sebastian
    • Build Farms: There are two farms as documented at OpenCSW Build Farms administered both by two people (Dagobert and Ben). Another farm by William is in reach.
    • Domain Name: The domain is currently owned by Dagobert. Transfer to the association is ok by me.
  • Maintainers. [bonivart] How maintainer applications are approved/rejected should be made open. There's no need for secret requirements or keeping the process in the dark from the community.
  • Current status: [dagobert]: Done. The process is documented at Member Signup
  • Copyright/License. [bonivart] It shouldn't be mandatory to display the license file during installation, instead it should be mandatory to include a license file in /opt/csw/share/doc/pkgname/LICENSE. Until build systems, pkg-get and other tools stop to require the copyright in the prototype file a short note about where to find the copyright file can be displayed like this: "Please see /opt/csw/share/doc/mailscanner/LICENSE for license information". That would fulfil the current requirement and stop the endless display of the GPL. (Status: [phil] already agreed to previously)
  • Current status: [dagobert]: Done, see Copyright files in GAR for details.
  • Packages in tiers. [bonivart] We should classify each package in a tier according to how common/critical/important it is. Tier 1 should be the packages that most will install and are likely to be critical on those systems, examples can be Apache2, Bind, MySQL, OpenSSL and Sendmail. Tier 2 should be packages similar to tier 1 but maybe not as common and/or critical, one example might be Perl. Tier 3 is the rest.
    • I envision tier 1 to be around 25 packages, tier 2 around 100 and tier 3 the rest.
    • Tier 1 packages must always be actively maintained, possibly by more than one maintainer for quick responses to security updates and bug reports. All tier 1 packages must be in GAR.
    • Tier 2 packages should be actively maintained by maintainers who use their own packages on a daily basis. Packages should be in GAR.
    • Tier 3 has no special requirements.
  • Current status: [dagobert]: TBD
  • Wiki link on main site. [bonivart] This wiki should be linked from the main site so users can find it. As of now Phil has some unspecified demands before adding the link.
  • Current status: [dagobert]: Needs clarification. [pfelecan]: what are the clarifications about? Phil's demands? Since the request they cannot be clarified? Hm… [dagobert]: This is likely to be solved when the new website from William with wiki-integration is up
  • ***[phil] Unspecified??? I specified them very clearly on the mailing list! Attempt some kind of common look-and-feel, and also have a prominent link to the main site. IE: The big "OpenCSW" logo on the top left of every page, should link to "the opencsw site". Which officially is And right now, I'll drop the lookandfeel bit. So there's just ONE THING you'd have to do(and keep it that way)
  • Download statistics. [bonivart] It would be very interesting to see statistics from the mirrors. The busiest ones would be best, like ibiblio, but the more, the merrier. That way we could see how current compares to stable, how much people still use 5.8 and which packages are most popular. It would be helpful data when deciding matters.[dagobert] Stats for iBiblio are open for everyone:
    1. Log in to <> User: guest Password: ibiblio
    2. Click on
    3. Click on Pages & Files
    4. Click on Directory Drilldown
    5. Click on Directory by Files Drilldown
    6. Click on /pub
    7. Click on /packages
    8. Click on /solaris
    9. Enjoy
  • Bootstrapping. [bonivart] It's a catch-22 that CSWgzip is needed (for systems not fully installed) which depends on CSWcommon which is gzipped. I propose that CSWcommon is distributed uncompressed just like CSWgzip, its size will increase from 4 KB to 23 KB which shouldn't be a problem. (Status: [phil] handled)
  • VM Image. [bonivart] We should publish a virtual machine image of OpenSolaris bootstrapped with OpenCSW ready to use. We could have our logo as the desktop backgroup and put readme documents on the desktop to help users get started with OpenCSW. The image could then be loaded into both VMWare and VirtualBox by users. VMWare can help with publishing and we could even upload a torrent to Pirate Bay to get cred within the younger crowd.
  • Custom Package Streams. [bonivart] We should offer users to click on any combination of packages on our web site and then create a package stream for them to download and use. This should be integrated into the new package browser.
  • Mirror access. [bonivart] Access to the mirrors should be distributed to more people, at least the whole board should have full access.
  • E-mail to retired maintainers. [bonivart] We should redirect e-mail to retired maintainers to make sure it's read and handled. Possibly it could go to the maintainers list.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License