[csw-maintainers] ITP: opencsw-policy

Maciej (Matchek) Blizinski maciej at opencsw.org
Wed Dec 29 19:22:28 CET 2010


I'd like to discuss an intent-to-package (ITP) of the OpenCSW
packaging policy, yet another idea stolen^Winspired by Debian.

Our packaging standards have been historically stored in html files,
then ported to Wordpress, where they currently are.  Some bits of
packaging standards are in our wiki on wikidot.  I'd like to create a
standard place for our policy documentation.  Since we're a packaging
project, a Solaris package seems to be a perfect place to keep the
policy.

The primary benefit that I see is that you can post patches to the
mailing list, discuss them, and commit them when consensus is
achieved.  This is not possible in Wordpress (please correct me if I'm
wrong).  Keeping the source in Subversion will allow to create an
effective and democratic workflow of updates to the policy.

The policy will be written as a collection of text files in a
lightweight markup.  I suggest asciidoc.  During build phase, asciidoc
files will be transformed into HTML files (also potentially PDF and
troff).  The package will install all files (in all formats) into
/opt/csw/share/doc/opencsw_policy.

Example fragment of package prototype:

d none /opt/csw/share/doc/opencsw_policy 0755 root bin
f none /opt/csw/share/doc/opencsw_policy/index.html 0755 root bin
f none /opt/csw/share/doc/opencsw_policy/index.txt 0755 root bin
f none /opt/csw/share/doc/opencsw_policy/license 0644 root bin

The policy files will be licensed under the terms of GNU FDL.

Changes to the policy will be posted to the maintainers (or the devel)
list for discussion.  The initial submissions will be ports of
existing documentation on the wiki and in Wordpress.  Any subsequent
changes will be also posted to the mailing list before submission.

The policy package will have a maintainer, whose duty will be apply
posted patches after the consensus is reached.  The maintainer of the
policy package will have no discretionary control over the contents of
the package.  The ultimate say in the contents of the policy will
belong to the board.

How do you like this idea?  Do you have any comments or suggestions?

Maciej


More information about the maintainers mailing list