Describes the CAcert software development process, from developer to test system to production system.
This sounds very outdated to me, but may be interesting as a historical document... 
BernhardFröhlich
The email below is a starting point for this documentation. Q: How does one get a testsystem account?
> From: Philipp Guehring [mailto:philipp@cacert.org] > Sent: Monday, September 07, 2009 4:13 PM > To: cacert-devel@lists.cacert.org > Subject: Re: Change text on the website > > Hi, > > > there are patches on test1 ... when they are tested by some guys, they > > will checked into a VCS ... then the admin detects that there are > > changes between test1 and www.cacert.org (WCO) ... what's the next step? > > No, the process works differently. > On the testsystems, we have a refresh procedure. > You can trigger the refresh procedure by going to the directory > /testsystem.skel and running ./update.sh > The refresh procedure downloads the new tarball and the new SQL table > structure definitions from the production system, and deploys > everything, so that you have a clean testsystem again. > The only things that are left on the testsystem afterwards are the data > in the database (the database-structure is diffed and patched, the data > itself stays in place), and a backup of the old website version. > So your old patches can be found in the old website versions, which > aren't active anymore, and you will have to redeploy patches you want to > test again. > > Since the refresh cleans away any patches, we usually avoid doing it > while others are currently testing their patches, and wait for the > patches to be fully tested, before we do the next refresh. > > Additionally, we are using additional testsystems, so that developers > can test independently. > > > (a) copy the file from test1 to WCO ... and loose the changes which had > > been made to WCO since the last copy of sources to test1? > > No, the patches/files are copied to a personal directory on the > production system, reviewed there and deployed when everything is fine. > Afterwards they are commited to the internal CVS, and from there, the > tarball is being generated. > > Evaldo is currently being tasked with researching a better version > control system / change management system that would allow a better > deployment process (and fulfills our security requirements). > > > (b) patch the sources from test1 with the ones from WCO? > > No, the old sources are archived, and fresh sources are taken. > > > okay ... guys ... WCO is a critical system ... both ways do NOT work > ... > > Yes, I agree. > > > if (a) takes place ... this means the the patch inbetween was not > > necessary ... > > > > if (b) takes place ... why had the patched been tested by several guys? > > ... the test were useless ... > > > > guys ... we're working on a critical system ... so every patch needs > a > > review of a second person (maybe more) ... > > Sounds like you are applying for the job? > > > ... and ... can you (or anybody else) explain, how the sources can be > > checked out, patched and checked in to a VCS? ... > > Someone was working on automatically importing the changes into a git > repository, but I haven't heard anything about it lately. > > > we @cacert want to use the power of open source development ... but all > > we do is to say 'here is the tarball, get it, patch it ... and ...' > > > > ... yes ... and what comes after the 'and ...'? > > The problem we have is that we see networked version control systems as > a security risk that we want to avoid. There have been > remote-code-execution exploits for CVS, Subersion, git, ... in the > past, > both against the servers and against the clients. > I have not heard about a high-security version control system that was > specifically designed and developed against remote-code-execution > attacks yet. > So we developed a version control architecture, where our production > system does not run a networked version control client/server, but we > are still having version histories and decentral version management > tools available. The architecture consists of a local CVS installation > on the production system that uses filesystem based repository, a tool > to automatically extract a cleaned version of the repository as a > tarball. > > > guys ... this is no open development for an open-source-project ... it's > > closed development for an open source project ... > > Have you uploaded your patches to http://bugs.cacert.org/ yet, so that > they are visible for reviewers? > > > > okay ... this mail causes me to keep awake half an hour more ... but > > hopefully it's worth ... > > Yes, thanks for reminding me about a few things. > > > ... i don't want to block cacert, work against cacert or do something > > against cacert ... > > > ... i want to bring cacert forward ... but sometimes there is the need > > to criticize ... and if this does not work in personal mail of via voice > > i use a cc-party ... or a mailing-list ... ;-) > > Hmm, cacert-devel should be the right place for this, yes. > > Best regards, > Philipp Gühring
see also Submit Patch