Please read the following as a list of possibilities. If the ideas are
terrible to you, just say so, I won't be offended.
> Source maintenance:
> Exim is in CVS because that was what my colleagues were familiar with at
> the time it was set up. Lots of people are now telling me that
> Subversion is the way to go. Although there are other source control
> systems around, Subversion is widely used for this kind of project, so
> many people are familiar with it. There was talk of changing the Exim
> source control system, but independently of that, I assume there would
> be no problem with running a second SCS on sesame if that's what we
> want.
I've told Philip this already, but to make it public, I would prefer
svn because I know it well, and I know it works. What do other people
prefer?
> Should access to the SCS be limited to those with accounts on sesame?
> Any kind of anonymous access would have to be appropriately protected -
> I have no knowledge of that side of things. Alternatively, we could put
> out snapshots as the Exim project does.
You could do it like other open source projects do it.
First, even though it's a pain, I think it would be beneficial to consider
asking people to sign a copyright assignment form like the GNU project does.
I like that PCRE is open source and under the BSD license, and would like
to keep it that way. Does any of you provide on giving money to hire the
lawyers? :)
Now, as far as using the repository. I think the PCRE repository should
have read only access to the world.
As far as commit access to the repository, I like gdb and gcc's
approach. There is a MAINTAINERS file, that describes the maintenance
procedure. PCRE would probably have only a few categories.
"Global Maintainer", would have the authority to accept or reject
patches for the entire project. This, for example, would initially
be Philip, and any one he deems appropriate.
"Responsible Maintainers", These are developers who have expertise
and interest in a particular area of PCRE. This, for example, would be
me for the autotools build system and AnotherUnnamedDeveloper for the
CMake build system.
and then finally, but not necessarily,
"Write After Approval Maintainers", These are developers who submit
patches, get peer reviewed, modify patches to everyone's pleasure,
fix the documentation, .... And then finally when they get permission
are allowed to commit. We could allow the global maintainers to do
the committing only, but the revision history would be lost. Also,
having "Write After Approval Maintainers" is a good way to lure
suckers, (Oops, I meant developers) into working on your project.
> Bugzilla:
> There aren't many bug reports for PCRE, so it may be that something as
> heavyweight as Bugzilla is somewhat of an overkill. However, since it is
> already running on sesame, it might be useful to use it to keep track of
> what reports there are.
I've never used Bugzilla. I have used Mantis (
http://www.mantisbt.org/)
and it is reasonable.
> WHERE DO WE GO FROM HERE?
> My aim in writing this document is to get all those involved to discuss
> the issues and come to some consensus. I am hoping that after the
> discussion there will be a group of people who volunteer to get involved
> with implementing whatever we decide, and subsequently to form part of a
> longer-term "PCRE development team".
Sounds great to me!
Thanks,
Bob Rossi
