New subject: Vote: code auditing

16 Feb 2006

Ged Murphy wrote:

...
   B - Sections of ReactOS which require auditing are
'locked',
 that being that the source is fully available to download and
 build, but no development work should be undertaken until
 the said code has passed the audit. The lock will be
 removed only when that section of code has been audited. 

I am in agreement with proposal B, freezing of un-audited sections. Here 
are my reasons:

Firstly I'll elaborate on what a lock does:
Any developer can 'get-a-lock' on a file. Having this lock means only 
that developer can commit to that file*. A locked file cannot be 
modified, deleted or renamed in the repository by anyone else.

To set a lock on a file, you lock it as per your client syntax and set 
the subversion property svn:needs-lock. When this property is set on a 
file, a checked out or updated file is made read only locally. (except 
for the person who holds the lock*). This acts as a warning that the 
file should not be modified. Users of Tortoise will also have a 
graphical overlay stating a file is locked.

Locks can be removed by any developer in a process called 
breaking-the-lock. (ownership of the lock can also be taken known as 
stealing-the-lock, although that's not important for us). The ability to 
Break the lock ensures that no one developer has control over the lock. 
Anyone can remove a lock at any time.

Users and developers alike will not notice a lock unless they try to 
modify locked code, so it would in no way inhibit general usage.

*(a user named 'audit' can be set up to do the initial locking of the 
files)

What the lock would do is act as a barrier for any further development 
on non-audited code. Code which has not been audited must be deemed as 
'tainted' until it has passed an audit.

I do however think that what we deem as tainted can be narrowed down. 
All usermode applications along with all Wine libs and many other areas 
(to be discussed) will bypass the lock immediately.

Code which has not yet passed the audit should not be improved, 
committed to, developed (whatever the phrase). There are 2 good reasons 
for this. Firstly, there is a possibility that this code needs to be 
removed, so it is a complete waste of a developers time to improve this 
code.

Secondly (and most importantly), by freezing this code, it puts more of 
an incentive on developers to audit it. e.g. if someone is working on 
some code which requires a particular section of un-audited code to be 
modified, or exposes a bug in some un-audited code, the developer must 
audit the said code in order to fix the problem. Only then will they be 
able to take advantage of this with their ReactOS improvement/addition.

If this code wasn't frozen, the chances are, the developer will tweak 
the un-audited code and carry on regardless. Thus un-audited code will 
tend to take a back seat.

I agree with Gé, in that if some method is not put in place to ensure 
our code is audited, people will conveniently forget about it.

Not only must we been seen to be pro-active with the audit for the 
general public to see (e.g. osnews, slashdot), but we must also ensure 
we do not alienate developers who feel _very_ strongly about the 
un-audited code. By reopening the repository, with the addition of 
locking un-audited code, I think we can strike a fair compromise for all 
parties, and ensure the audit takes place.

Ged.

RE: [ros-dev] Vote: code auditing