Public Access to Perforce?

David Rhodus sdrhodus at
Wed Aug 18 06:24:52 PDT 2004

On Wed, 18 Aug 2004 16:47:02 +0400, Roman Kurakin <rik at> wrote:
> David Rhodus wrote:
> >On Mon, 16 Aug 2004 01:04:03 -0400, Chris BeHanna <chris at> wrote:
> >
> >
> >>    Forgive me if this already exists.  I searched the list archives,
> >>google, and and did not find any way for non-committers to
> >>have read-only access to the p4 repo.
> >>
> >>    Is there a read-only account that the general public could use?
> >>
> >>
> >
> >With the perforce trees being hidden away without public access to the
> >changes, this makes the FreeBSD project no longer an open source
> >project.
> >
> >
> This hides only development proccess, not a stable result.
> If you don't have access to my home disks were I keep my
> intermediate code with additional debug/hacks and so on
> while I am debuggin new functionality would affect open
> source status of results of my work?
> rik

No this is not what I'm talking about, I don't think that level of
development work is able to sustain here.  The development work should
be done in the public cvs tree were it is open to public scrutiny and
were a section of the community can help on the development process. 
The current method of merging large commits back into the cvs tree
from the perforce tree's should be inexcusable by the FreeBSD
community.  If perforce is the choice for FreeBSD a line needs to be
drawn and completely move over to it.  Then when the commercial
problem comes from someone, well, we now have the foundation.  I'm
sure they can work something out with perforce.  Even if that means
contracting someone for ~80hrs of development work to write a perforce

The FreeBSD project has a -stable and a -current tree.  This system
has been under heavy abuse for the past several years now which is one
of the leading causes of the major bulk of the development work to be
pushed into perforce trees.  This issue and the overwhelming unneeded
complexity the code base has grown into are the reasons the
development work is now being done were the public isn't able to
access the code until a large commit hits the cvs tree. These large
commits are a not harder to audit than a small steady stream of
changes, which has always been the preferred method.

                                            Steven David Rhodus
                                            <drhodus at>

More information about the freebsd-current mailing list