RE: [ros-dev] Re: Vote: code auditing

[Dann B. Smith]

Which is why I stated a couple weeks ago thaqt politics has NO place in
an engineering project.

At all.

Ever.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of mf
Sent: Friday, February 17, 2006 1:55 AM
To: ReactOS Development List
Subject: [ros-dev] Re: Vote: code auditing

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
_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

This is my first post to the ros-dev, but I would like to make some 
proposals. I have already posted in the forum, but nobody seems to 
notice ;-)

As this topic seems to be very actual now, I will repeat it here. So 
here are my ideas about the code audit:

1.) Keep the old and new code seperated like this:

- divide the repositories, so that files are either in the audited or in 
the old repository.

- Make an additional makefile (or add an entry to the existing one) in 
the new repository (together with the needed rbuild files), wich will be 
able to build the complete reactos from the files from both repositories.

- files from both repositories could be put in two subfolders of a folder:
ROS\auditet...
ROS\old...

- so "make full" for example could then build the complete reactos

This has several advantages, I think:
- Every file is there only once, you would not have to mess around with 
different versions of a file, because of a patch in only one repository
- When working on something wich is in the new repository, you would not 
have to test it in both repositories or commit it to both repositories.
- When you build the sources you will always build the newest ones 
either updated ones from the old repository or from the audited one.
- you can easyly test your work on files in the new repository or 
rewritten parts from the old repository, because all the needed files 
are already there and you can also directly test it in reactos.
- when moving a file to the new repository, there's no need to test if 
it builds, if it did before.

2.) Mark the old code:
Another thing I thought about: Maybe the files that are not audited 
should be marked in the header, so the code is not excidently included 
in another OSS and maybe even back to ROS later. Maybe even change the 
license, so the source is only alowed to be used for informational 
purposes, but is not to be included in other OSS. The audited files 
could also be marked like "This file was audited on ../../.. revision 
.... by ..."

Both ideas would allow the devs and others to work on ROS like before 
and it would be almost as clean as the "current" plan.

I hope I could make it clear enough, what I mean.
What do you think about these ideas?

-- ThePhysicist

[David Hinz]

I think it's a bit complicated, as you have to mess around alot with 
different makefiles, but it _could_ work.

But the thing is, this actually is like locking all unaudited modules in 
trunk and let devs allow to change things in the audited modules. Your 
way is just a bit more complicated.

I'm not an expert, so just wait for the devs' comments.

Greets,

David Hinz

Timo Kreuzer schrieb:
> This is my first post to the ros-dev, but I would like to make some 
> proposals. I have already posted in the forum, but nobody seems to 
> notice ;-)
>
> As this topic seems to be very actual now, I will repeat it here. So 
> here are my ideas about the code audit:
>
> 1.) Keep the old and new code seperated like this:
> divide the repositories, so that files are either in the audited or in
>
> the old repository.
> Make an additional makefile (or add an entry to the existing one) in
>
> the new repository (together with the needed rbuild files), wich will be 
> able to build the complete reactos from the files from both repositories.
> files from both repositories could be put in two subfolders of a folder:
>
> ROS\auditet...
> ROS\old...
> so "make full" for example could then build the complete reactos
>
> This has several advantages, I think:
> Every file is there only once, you would not have to mess around with
>
> different versions of a file, because of a patch in only one repository
> When working on something wich is in the new repository, you would not
>
> have to test it in both repositories or commit it to both repositories.
> When you build the sources you will always build the newest ones
>
> either updated ones from the old repository or from the audited one.
> you can easyly test your work on files in the new repository or
>
> rewritten parts from the old repository, because all the needed files 
> are already there and you can also directly test it in reactos.
> when moving a file to the new repository, there's no need to test if
>
> it builds, if it did before.
>
> 2.) Mark the old code:
> Another thing I thought about: Maybe the files that are not audited 
> should be marked in the header, so the code is not excidently included 
> in another OSS and maybe even back to ROS later. Maybe even change the 
> license, so the source is only alowed to be used for informational 
> purposes, but is not to be included in other OSS. The audited files 
> could also be marked like "This file was audited on ../../.. revision 
> .... by ..."
>
> Both ideas would allow the devs and others to work on ROS like before 
> and it would be almost as clean as the "current" plan.
>
> I hope I could make it clear enough, what I mean.
> What do you think about these ideas?
>
> -- ThePhysicist

[Timo Kreuzer]

David Hinz schrieb:
> I think it's a bit complicated, as you have to mess around alot with 
> different makefiles, but it _could_ work.

The makefiles are generated auttomatically. You just have to make sure 
that the .rbuild files point to the right directories. So when moving a 
folder to the new repository you will have to change all the .rbuild 
files that point to that folder's .rbuild file. You could even write a 
small tool, wich will do this, I think.
If everything is put into one new repository, you will have to edit alot 
of rbuild files, too, because of the new structure.
> But the thing is, this actually is like locking all unaudited modules 
> in trunk and let devs allow to change things in the audited modules. 
> Your way is just a bit more complicated.

There wouldn't be the need of locking modules. If the devs vote to do 
it, ok, if not, my idea would work, too. It just makes sure that audited 
and unaudited code is seperated. And if devs are working on something in 
the old repository, they will always be reminded, that they are actually 
workng on unaudited code and might decide for themselves (if the modules 
are not locked) to audit this before going on. And everyone can quickly 
see, what has been audited and what not. It might help to get the audit 
going, even without locking.
> I'm not an expert, so just wait for the devs' comments.
>
> Greets,
>
> David Hinz

Thanks for the comment. Looks like ROS life has a little moved from the 
forums to the mailinglist ;-)