Hi
everyone have notice ReactOS website, svn, mailing list, went down.
The svn and web server was never down the problem was the
DNS server whent down by hardware failour and it took time
getting it back online again. Longer that we did expect.
I've tried fixing this! 8^(
include/psdk/winnt.h line 3666 is the orig.
[CC] subsystems/win32/win32k/dib/dib1bpp.c
In file included from subsystems/win32/win32k/w32k.h:16,
from subsystems/win32/win32k/dib/dib1bpp.c:20:
include/ddk/ntifs.h:404: error: redeclaration of `enum _AUDIT_EVENT_TYPE'
include/ddk/ntifs.h:405: error: conflicting types for 'AuditEventObjectAccess'
include/psdk/winnt.h:3666: error: previous definition of 'AuditEventObjectAccess' was here
include/ddk/ntifs.h:407: error: conflicting types for 'AuditEventDirectoryServiceAccess'
include/psdk/winnt.h:3668: error: previous definition of 'AuditEventDirectoryServiceAccess' was here
ion(a)svn.reactos.org wrote:
> Author: ion
> Date: Tue Oct 24 01:19:15 2006
> New Revision: 24636
>
> URL: http://svn.reactos.org/svn/reactos?rev=24636&view=rev
> Log:
> - Add NtApphelpCacheControl, NtFilterToken (WARNING: PATENTED. TAKE CARE WHEN IMPLEMENTING).
>
I'm assuming that the warning is in reference to NtFilterToken(). If
someone other than you goes to implement this function, they probably
won't look through svn history to see this comment. Wouldn't it be best
to put a warning like this in the comments of the function source?
> - RtlCopyMemory(StateChange,
> + /* Return our wait state change structure */
> + RtlMoveMemory(StateChange,
> &WaitStateChange,
> sizeof(DBGUI_WAIT_STATE_CHANGE));
RtlMoveMemory doesn't really make sense as the destination and source
are never overlapping, resulting in unnecessary overhead.
- Thomas
Aleksey Bragin wrote:
"It should try every revision, otherwise there is no
use from it at
all. And automerge from trunk to stable branch is not
possible,
because patches usually depend on each other."
Sorry,i explained myself wrong, i was not talking
about automerging, or using the "stable branch" to
send patches. No, patches would be still sent to the
unstable branch, and no "automerging will be used", it
will be just overwriting.
The process i imagine like this:
-Unestable not working.
-Recent Stable working (1 day old).
-You dont have the skill to fix unstable.
-You download stable, work in your computer over
stable.
-Send changes to unstable (then things become
interesting).
-Check the files you are have touched. If no other
person have touched them since the stable (1 day old)
was made you can send your patches, if someone have
touched, you cant and have to wait till the stable
revision is updated.
-Once unstable boot again, stable is override by the
unstable, and now named stable.
This would alow people working, maybe in the control
panel, with little kernel or booting code knowledge,
keep working without having to stop developing for
dificult bugs in the kernel.
What do you thing? Maybe is a crazy idea cause i dont
know about the inners of SVN.
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
> +;
> +; ROSBOOT_CMD
> +;
> +; This value is the command which is executed to gain debugging data
> +; this value is mandatory
> +
> +ROSBOOT_CMD=D:\sysreg\qemu\qemu.exe -serial file:debug.log
> -boot c -m 128 -L D:\sysreg\qemu\ D:\sysreg\qemu\RosVM.vmdk
> -cdrom D:\Reactos\ReactOS-RegTest.iso
Is there scope to add vmware to the test?
Ged.
janderwald(a)svn.reactos.org wrote:
> Author: janderwald
> Date: Fri Oct 20 19:49:46 2006
> New Revision: 24584
>
> URL: http://svn.reactos.org/svn/reactos?rev=24584&view=rev
> Log:
> * beginning of a system regression tools
>
Can this be done in C? C++ only slows down the build even more.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
I hate ugly text formatting ...
Resending in a (hopefully) readable format.
Jerry wrote:
> After a team says that it has fixed the bug ...
<snip>
> Each team may have mentees associated with it. The teams would then
> help and guide their mentees in testing and coding, and these mentees
> will help with the work load that the regular testers have. The goal
> here is to guide the mentees to be regular developers and either stay
> in testing or move on to other parts of the project and have.
I'm a little confused with the idea of the testing teams fixing bugs.
Testers aren't usually coders. It's great if they are as they can fix the
bugs they find, but in general testing positions are filled by people who
want to help the project, but aren't programmers.
If a tester is a programmer too, I think you'll find that do a lot more
programming than testing, as shown by our tree instability at the moment ;)
Ged.
Jerry wrote:
> After a team says that it has fixed the bug ...
<snip>
> Each team may have mentees associated with it. The teams would then
help
> and guide their mentees in testing and coding, and these mentees
will help
> with the work load that the regular testers have. The goal here is
to guide
> the mentees to be regular developers and either stay in testing or
move on to
> other parts of the project and have.
I'm a little confused with the idea of the testing teams fixing bugs.
Testers aren't usually coders. It's great if they are as they can fix the
bugs
they find, but in general testing positions are filled by people who want to
help the project, but aren't programmers.
If a tester is a programmer too, I think you'll find that do a lot more
programming
than testing, as shown by our tree instability at the moment ;)
Ged.