I decided to make this as a separate post, though it's a follow up to
the previous one.
I would like to set, officially, a couple of simple code hacking
rules, which are going to apply immediately for the NTOSKRNL module,
and to other modules after discussion/acceptance. They apply only to
committers (which commit their own or someone else's patches).
1. If you change someone's code, and believe it's a correct change -
go ahead and commit.
2. If you need to add a hack to someone's code, and:
2.1. you want to either hack or revert the offending commit which
breaks booting: This is allowed only after 24hrs after trying to
contact the author / posting to the ros-dev mailing list about the
problem.
2.2. you want to either hack or revert the offending commit which
contains a certain regression but doesn't cause important
consequences like inability to install the OS, or major loss of
functionality: This is allowed only from permission of author of the
code which you want to hack or, as alternative, from my permission.
I think this way we can get some order into the coming commits flow,
which is hard to track.
Also, please comment on this, so that we can alter those rules and
maybe accept them for all modules.
Thanks for understanding,
Aleksey Bragin.
This looks hackish
It also breaks the log as you're potentially returning something different from what the log states
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cgutman(a)svn.reactos.org
Sent: 06 July 2009 08:54
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [cgutman] 41783: - Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success
Author: cgutman
Date: Mon Jul 6 11:54:28 2009
New Revision: 41783
URL: http://svn.reactos.org/svn/reactos?rev=41783&view=rev
Log:
- Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success
Modified:
trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c
Modified: trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/ifenum_…
==============================================================================
--- trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c [iso-8859-1] Mon Jul 6 11:54:28 2009
@@ -280,7 +280,7 @@
entry->ent.if_descr);
TRACE("} status %08x\n",status);
- return status;
+ return STATUS_SUCCESS;
}
NTSTATUS tdiGetEntityIDSet( HANDLE tcpFile,
Uhm, why hack the kernel again? Testing on the buildbot was fixed to
accept this, so there is no urge. I was just trying to help RPG to
find the issue, along with vmware/vbox video drivers regression, due
to a MmMapIoSpace(128Mb) call.
Please read the next email.
WBR,
Aleksey.
On Jul 6, 2009, at 10:28 PM, dgorbachev(a)svn.reactos.org wrote:
> Author: dgorbachev
> Date: Mon Jul 6 22:28:11 2009
> New Revision: 41788
>
> URL: http://svn.reactos.org/svn/reactos?rev=41788&view=rev
> Log:
> "Fix" MDL PROBE FAILED! bug #4663.
jimtabor(a)svn.reactos.org schrieb:
> Author: jimtabor
> Date: Sun Jul 5 06:21:35 2009
> New Revision: 41776
>
> URL: http://svn.reactos.org/svn/reactos?rev=41776&view=rev
> Log:
> - Implement the client shutdown procedure. Tested with wine user32 msg undocumented 0x3B tests. Wine tests: msg: 6175 tests executed (0 marked as todo, 937 failures), 5 skipped.
> - Add missing end session types.
> - Reference: winproc.c WM_CLIENTSHUTDOWN http://wiki.winprog.org/wiki/Windows_messages
>
> [...]
>
> + List = IntWinListChildren(pWindow);
>
Oh, how I loathe this function.
It walks through the chain of windows to count them, allocates a buffer
from paged pool. Walks through the chain again, fills the buffer with
the windows' handles and returns the buffer so that the calling function
can walk through the buffer and use the handles to query the pointers to
the windows again. And this all happens while holding the global user lock.
Hint: you can remove 11 lines of code and change 2 lines and get the
same result, only faster.
Regards,
Timo
On Fri, Jul 3, 2009 at 5:53 AM, <dchapyshev(a)svn.reactos.org> wrote:
> - if (-1 == (int) Res || ! Res)
> - {
> - return Res;
> + if (-1 == (int) Res || !Res)
> + {
> + return FALSE;
I know you didn't write the check and were just changing the return
values but as a matter of style could we do something like
if (((int) Res || !Res) == -1)
or would the extra parens mess up the order of operations? Not a big
deal, its just easier on my eyes.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I think we all agree that the process of filling out a changelog is a task
we would rather avoid.
Collibri has made some efforts to alleviate this and despite getting some
good results we're also seeing a lot of information which isn't changelog
oriented. This now leaves us with a new problem of having to manually go
through data output from Collibri's tool and reformat it.
This is arguably more time consuming than the original method and isn't
working for us in its current form.
The current problem with this method is that a commit log is not a changelog
and getting something which can be classed as a changelog from this without
human intervention is an impossible task. There are also some people who
would rather write their own changelog instead of allowing a tool to
generate it for you.
The problem as I see it is two fold :
- Commit messages generally contain cryptic message, humour, idioms
and frustration
- Patches can spread over a wide range of modules making it
difficult to insert them into the correct position in the changelog.
A possible solution to this is to wrap up a changelog in XML elements. Such
a commit log would be as follows :
............................................................................
..........................
- Stop mixing unicode and ANSI strings
- Don't dereference NULL pointers
<changelog>
<notepad>Converted the application to Unicode</notepad>
<user32>Fixed a crash highlighted via adobe acrobat</user32>
</changelog>
............................................................................
..........................
This will allow anyone who wants to have a changelog autogenerated at
release time to take advantage and anyone who wants to do their own to
ignore it.
The problem with this method lies in getting the XML tags correct.
Anyone have any other ideas?
Ged.
Sorry for not deleting the post content:/
Back to sysreg... i`d issue a deadline, like 24-48h and until then i`d lock
the trunk. If this issue is not fixed until the deadline, offending revision
should be reverted and trunk unfrozen.
I can only hope we arent getting many regressions in the meantime.