Vote: code auditing

[Ged Murphy]

Vote topic : Ensure code auditing is carried out
Start date : 16/02/06
Period : 7 days discussion, 7 days voting

With the success of proposal B in the recent vote and the old repository 
reopening for business, we need to discuss ways to ensure the code is 
audited and doesn't take a backseat.

Following the correct voting procedure, there will be a 7 day discussion 
period, followed by a 7 day voting period.
Until this decision is made, I propose for the repository to be fully 
open, with developers being diligent with their actions.

This topic has been discussed somewhat between developers, although not 
extensively.
Two viable proposals have so far been put forward and are as follows :

 A - The repository is completely open to all development and ReactOS 
developers must take it upon themselves to ensure all code is audited.

 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.


Discussion of these topics and any further proposals should be in reply 
to this topic.

[Brandon Turner]

Ged Murphy wrote:

>   Vote topic : Ensure code auditing is carried out
>  Start date : 16/02/06
>  Period : 7 days discussion, 7 days voting
>
>  With the success of proposal B in the recent vote and the old 
>  repository reopening for business, we need to discuss ways to ensure 
>  the code is audited and doesn't take a backseat.
>
>  Following the correct voting procedure, there will be a 7 day 
>  discussion period, followed by a 7 day voting period.
>  Until this decision is made, I propose for the repository to be fully 
>  open, with developers being diligent with their actions.
>
>  This topic has been discussed somewhat between developers, although 
>  not extensively.
>  Two viable proposals have so far been put forward and are as follows :
>
>  A - The repository is completely open to all development and ReactOS 
>  developers must take it upon themselves to ensure all code is audited.
>
>  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.
>  
Well it looks like you and Art are both doing your own thing...
But same question goes to you:
"The lock will be removed only when that section of code has been audited."
Does this mean any part of the code during the audit found to be dirty 
need to be rewritten before it is unlocked?  And if so, how long before 
you think the kernel will be unlocked?

>  
>  Discussion of these topics and any further proposals should be in 
>  reply to this topic.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>  
Brandon

[Ged Murphy]

Brandon Turner wrote:
>  
>  "The lock will be removed only when that section of code has been 
>  audited."
>  Does this mean any part of the code during the audit found to be dirty 
>  need to be rewritten before it is unlocked?  And if so, how long 
>  before you think the kernel will be unlocked? 
Well it's all up for discussion, but that is the original proposal.
As for how long before the kernel is unlock, well I suppose that'll 
depend on 2 things:
-  How much of the kernel is actually locked (it hasn't been decided 
what constitutes dirty. e.g. GreatLord proposes only assembly)
-  How quickly people rewrite the 'dirty' code

[Rick Langschultz]

I think Option B looks like the best plan of action. However people  
shouldn't have the ability to check out the tainted or potentially  
tainted source code. I think that once each module is audited the  
repository should be unlocked. That way developers can continue  
coding on particular pieces of ReactOS, unless they are under lock.  
Commiting code should be allowed _only_ after ReactOS has underwent a  
full code audit.
On Feb 16, 2006, at 4:36 PM, Ged Murphy wrote:

>   Vote topic : Ensure code auditing is carried out
>  Start date : 16/02/06
>  Period : 7 days discussion, 7 days voting
>
>  With the success of proposal B in the recent vote and the old  
>  repository reopening for business, we need to discuss ways to  
>  ensure the code is audited and doesn't take a backseat.
>
>  Following the correct voting procedure, there will be a 7 day  
>  discussion period, followed by a 7 day voting period.
>  Until this decision is made, I propose for the repository to be  
>  fully open, with developers being diligent with their actions.
>
>  This topic has been discussed somewhat between developers, although  
>  not extensively.
>  Two viable proposals have so far been put forward and are as follows :
>
>  A - The repository is completely open to all development and  
>  ReactOS developers must take it upon themselves to ensure all code  
>  is audited.
>
>  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.
>
>
>  Discussion of these topics and any further proposals should be in  
>  reply to this topic.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Brandon Turner]

That was the orginal plan, and we just voted against it.

Brandon

Rick Langschultz wrote:

>   I think Option B looks like the best plan of action.
> However people  
>  shouldn't have the ability to check out the tainted or potentially  
>  tainted source code. I think that once each module is audited the  
>  repository should be unlocked. That way developers can continue  
>  coding on particular pieces of ReactOS, unless they are under lock.  
>  Commiting code should be allowed _only_ after ReactOS has underwent a  
>  full code audit.
>  On Feb 16, 2006, at 4:36 PM, Ged Murphy wrote:
>
> >   Vote topic : Ensure code auditing is carried out
> >  Start date : 16/02/06
> >  Period : 7 days discussion, 7 days voting
> >
> >  With the success of proposal B in the recent vote and the old  
> >  repository reopening for business, we need to discuss ways to  ensure 
> >  the code is audited and doesn't take a backseat.
> >
> >  Following the correct voting procedure, there will be a 7 day  
> >  discussion period, followed by a 7 day voting period.
> >  Until this decision is made, I propose for the repository to be  
> >  fully open, with developers being diligent with their actions.
> >
> >  This topic has been discussed somewhat between developers, although  
> >  not extensively.
> >  Two viable proposals have so far been put forward and are as follows :
> >
> >  A - The repository is completely open to all development and  ReactOS 
> >  developers must take it upon themselves to ensure all code  is audited.
> >
> >  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.
> >
> >
> >  Discussion of these topics and any further proposals should be in  
> >  reply to this topic.
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[mf]

Brandon Turner wrote:
>   That was the orginal plan, and we just voted against
> it.
>  
>  Brandon
>   
That's the idea with politics, you amend a proposal until the original 
purpose of the proposal is completely reverted, and you end up with a 
new set of useless silly rules with possible flaws, loopholes etc. If 
you can't get people to accept something, just confuse them with even 
more proposed rules, preferably vague but essentially the same as what 
they originally voted against.

mf

[Sylvain Petreolle]

You still can download it atm without using SVN at all.

--- Rick Langschultz <rlangschultz(a)cox.net> a écrit :

>   I think Option B looks like the best plan of action.
> However people  
>  shouldn't have the ability to check out the tainted or potentially  
>  tainted source code.  
Kind regards,
Sylvain Petreolle (aka Usurp)
--- --- --- --- --- --- --- --- --- --- --- --- ---
Tired of a proprietary Windows on your computer ?
Use free ReactOS instead ( http://www.reactos.org )

[Ged Murphy]

Ged Murphy wrote:
>   Vote topic : Ensure code auditing is carried out
>  Start date : 16/02/06
>  Period : 7 days discussion, 7 days voting
>
>  With the success of proposal B in the recent vote and the old 
>  repository reopening for business, we need to discuss ways to ensure 
>  the code is audited and doesn't take a backseat.
>
>  Following the correct voting procedure, there will be a 7 day 
>  discussion period, followed by a 7 day voting period.
>  Until this decision is made, I propose for the repository to be fully 
>  open, with developers being diligent with their actions.
>
>  This topic has been discussed somewhat between developers, although 
>  not extensively.
>  Two viable proposals have so far been put forward and are as follows :
>
>  A - The repository is completely open to all development and ReactOS 
>  developers must take it upon themselves to ensure all code is audited.
>
>  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.
>
>
>  Discussion of these topics and any further proposals should be in 
>  reply to this topic. 
The poll is has been opened in the forums.

Ged.

[Brandon Turner]

" 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 have asked 3-4 times but still havent got an answer as far as I can tell.  Does the
definition of "audit" in the pharse mean the code needs to be looked through and
documented and bad code be marked.  Or does it mean all that and the marked code needs to
be rewritten for it to be considered "audited".

Brandon

P.S. If the formatting is messed up in this email, im sorry.



Ged Murphy wrote:

>   Ged Murphy wrote:
>
> >   Vote topic : Ensure code auditing is carried out
> >  Start date : 16/02/06
> >  Period : 7 days discussion, 7 days voting
> >
> >  With the success of proposal B in the recent vote and the old 
> >  repository reopening for business, we need to discuss ways to ensure 
> >  the code is audited and doesn't take a backseat.
> >
> >  Following the correct voting procedure, there will be a 7 day 
> >  discussion period, followed by a 7 day voting period.
> >  Until this decision is made, I propose for the repository to be fully 
> >  open, with developers being diligent with their actions.
> >
> >  This topic has been discussed somewhat between developers, although 
> >  not extensively.
> >  Two viable proposals have so far been put forward and are as follows :
> >
> >  A - The repository is completely open to all development and ReactOS 
> >  developers must take it upon themselves to ensure all code is audited.
> >
> >  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.
> >
> >
> >  Discussion of these topics and any further proposals should be in 
> >  reply to this topic. 
>
>  The poll is has been opened in the forums.
>
>  Ged.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[art yerkes]

On Thu, 23 Feb 2006 21:35:06 -0500
Brandon Turner <turnerb7(a)msu.edu> 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 have asked 3-4 times but still havent got an answer as far as I can tell.  Does the
> definition of "audit" in the pharse mean the code needs to be looked through and
> documented and bad code be marked.  Or does it mean all that and the marked code needs to
> be rewritten for it to be considered "audited".
>  
>  Brandon
>  
>  P.S. If the formatting is messed up in this email, im sorry. 
For my part, I vote for marked.  We can decide whether some specific file
needs to remain locked one at a time and branch as necessary.
-- 
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind.  Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)