[ZF] A couple of github issues

[Jim Fulton]

There are a couple of issues we need to address:

1. In github, developers can't create repos.  This is a problem, both
   for ad hoc conversion of projects from svn to git, and for our
   existing (possibly too cavalier) workflow for creating new
   projects.

   The existing "process" is: someone asks on zope-dev and Tres or I
   create the project for them.  There are many problems with this
   process, among them:

   - it clutters zope-dev

   - it requires someone to be a repo-creation "specialist" (former
     employees of ZC know that that's a euphemism).

   - it doesn't specify who the specialists are (and I don't
     particularly want to be one).

   There are a number of ways to mitigate this.  I'll throw some out
   for discussion:

   - use bitbucket which has saner permissions (or try to get github
     to fix their permissions)

   - convert the svn repos in mass. This doesn't address new projects,
     but we have a lot of conversions ahead of us.

   - Write and maintain an application that authenticates contributors
     and creates repos for them. (This will be a pain to write and
     maintain. Not it!)

   - Switch to a more course-grained repository-management strategy,
     managing multiple Python projects in a single git repo.  Github
     seems to be oriented to organizations with a few large repos.
     You can see this especially in their pricing model for private
     repos.  This is why ZC decided to use bitbucket.

   - Identify some specialists and create a process other than
     zope-dev for requesting repos.

2. Converting from svn2git requires an authors.txt file.  This
   contains svn login ids and github email addresses.  The former
   are accessible publically via svn.zope.org and the later are
   accessible publicly via git log.  This file isn't static, so it
   needs to be managed via VCS.

   Currently it's managed in a top-secret repo in bitbucket (which
   allows free private repos fro up to 8 users).

   Our current stance is that the authors.txt file should only be
   revealed to contributors. This means that conversions have to be
   done by specialists (aka Tres or Jim) or that authors.txt has to be
   handed out by authors.txt hand-out specialists (Tres or Jim).

   IMO, the authors.txt file should be made available in a public
   repo. If we really really think that this public information should
   be revealed only to contributors, we could pay github $7/mo and put
   it in a private repository accessible to developers.  This would
   have the added advantage that developers could manage their own
   entries.

I am *not* up for remaining a conversion or an authors.txt
distribution specialist.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm