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.
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Brandon
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
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
You still can download it atm without using SVN at all.
--- Rick Langschultz rlangschultz@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 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.
" 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Thu, 23 Feb 2006 21:35:06 -0500 Brandon Turner turnerb7@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.
-
art yerkes -
Brandon Turner -
Ged Murphy -
mf -
Rick Langschultz -
Sylvain Petreolle