-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hanno Schlichting wrote:

> I've seen lots of checkins recently stating "Comply with repository policy".
> 
> I haven't seen any announcement of a new official repository policy.
> Have I missed it?
> 
> I'd be especially interested who exactly is responsible for changing
> code so that it complies with the new policy. How much of the initial
> work is automated and taken care of by some small group of people and
> what is left to the individual package maintainers? How are packages
> without maintainers handled? What about trunk vs. old branches?

The testing for compliance and the automated part of the fixups are
maintained in the 'zope.repositorypolicy' project:

  http://svn.zope.org/zope.repositorypolicy/trunk

There is a nightly test run which checks out all top-level projects and
verifies conformance (using the checker) against each projects "trunk"
and "release branches."  Projects which flunk that check show up on the
"shame list" mailed to the zope-tests test aggregator, e.g.:

 https://mail.zope.org/pipermail/zope-tests/2010-April/013877.html

That script ignores tags (we aren't rewriting history), as well as
branches whose names don't look "release-like".

I have been using the checker / fixer to get projects I feel
responsibility for into complieance with the policy.  The process
normally involves:

 - Check out the project (easiest to do the whole tree).

   $ svn co $ZSVN/myproject

 - In the trunk and each "release" branch:

   o Run the checker script, e.g.::

    $ cd myproject/trunk
    $ /path/to/zrp/bin/zope-org-check-project .
    ... <list of errors> ...

   o Run the automated fixups::

     $ /path/to/zrp/bin/zope-org-fix-project .
     ... <list of automated fixups> ...

   o Find and fix anything the automated fixer couldn't handle.
     I nearly always have to fix up the 'author' in setup.py, for
     instance.:

     # Repeat until the checker runs clean
     $ /path/to/zrp/bin/zope-org-check-project .
     ... <errors which couldn't be fixed automatically> ...
     $ gvim setup.py # fix 'author', etc.

   o Add any files created by the fixer::

     $ svn add LICENSE.txt COPYRIGHT.txt

   Repeat in each of the "release" branches, then check it all in:

    $ cd ..
    $ svn commit -m "Comply with repository policy."

My theory is that I will clean up the stuff I care about, and others
will clean up the stuff they care about.  The stuff which stays on the
"shame list" can be identified cleanly as "unmaintained."  We can figure
out what to do about them after some time period has elapsed.

Note that I pulled one project (Zelenium) out of the repository
altogether, because it contained third-party code I couldn't relicense
to the ZPL:  I moved its trunk over to Launchpad, and left only a stub
behind in the zope.org SVN.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku+FNkACgkQ+gerLs4ltQ5WeACfUikaZKiJsbIoJ3UJ4a14PVQz
K6sAoIlyzbnhdOZUu2uK5qKFTmYA75hc
=GdR8
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to