Re: [ros-dev] Registry and ObjectManager (was FreeLdr Part II)

[Steven Edwards]

Hi,

--- Alex Ionescu [e-mail] wrote:
> Once again, I hope nobody takes this personally, but I wanted to clear 
> up the situation.

Also I would like everyone to note that I was not trying to be critical of Alex for maintaining
his branch. There was a miscommunication about the merge -> branch for 0.2.6 and I should have
sent another note to Alex about it before posting here. The lack of merges is in part because of
stablity testing and our miscommuication about when would be the best time.

Thanks
Steven

__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

[Hartmut Birr]

Steven Edwards schrieb:
> Hi,
>
> --- Alex Ionescu [e-mail] wrote:
> > Once again, I hope nobody takes this personally, but I wanted to clear 
> > up the situation.
>
> Also I would like everyone to note that I was not trying to be critical of Alex for maintaining
> his branch. There was a miscommunication about the merge -> branch for 0.2.6 and I should have
> sent another note to Alex about it before posting here. The lack of merges is in part because of
> stablity testing and our miscommuication about when would be the best time.
>
> Thanks
> Steven

Hi,

sorry for my next lines,

I'm strictly against to merging Alex branch into our trunk. If I look to
the commit comments, I see one, two or three lines of comments like
'Merge with blight 's rewrite' or 'My kernel fixes, new...' and always
there are changed ten, twenty or more files. In the past there was
always a description about the improvement of our development. I would
like it if we can go back to this policity. I does know, that some of my
commits are in conflict with this rules.

- Hartmut

[Alex Ionescu]

Hartmut Birr wrote:
> Hi,
>
> sorry for my next lines,
>
> I'm strictly against to merging Alex branch into our trunk. If I look to
> the commit comments, I see one, two or three lines of comments like
> 'Merge with blight 's rewrite' or 'My kernel fixes, new...' and always
> there are changed ten, twenty or more files. In the past there was
> always a description about the improvement of our development. I would
> like it if we can go back to this policity. I does know, that some of my
> commits are in conflict with this rules.
> Hartmut

My comments have always been restrictive. Yes, "merge with blight's 
rewrite" has 20 changed files. It's a *merge*. It means that the files 
which Blight has changed have now been changed into my branch. It's my 
job to describe blight's patch? I don't think so!.

Your comments refer to the fact I've always merged with head and lots of 
files seem changed, it's unfair to blame me for not describing what each 
merge does... it's up to others to see what the merge merges, and look 
at that changelog instead.

If you care to look at a patch without merging:

"

Move Win32K callbacks to Win32K where they belong. Registrationis done with Ps function just like on XP+. Also allows non-win32k stuff to manage their own desktops and Window stations"

pdated files:
branches/alex_devel_branch/reactos/include/ddk/defines.h
branches/alex_devel_branch/reactos/include/ddk/psfuncs.h
branches/alex_devel_branch/reactos/include/ddk/pstypes.h
branches/alex_devel_branch/reactos/ntoskrnl/ex/win32k.c
branches/alex_devel_branch/reactos/ntoskrnl/ps/win32.c
branches/alex_devel_branch/reactos/subsys/win32k/include/desktop.h
branches/alex_devel_branch/reactos/subsys/win32k/include/winsta.h
branches/alex_devel_branch/reactos/subsys/win32k/main/dllmain.c
branches/alex_devel_branch/reactos/subsys/win32k/ntuser/desktop.c
branches/alex_devel_branch/reactos/subsys/win32k/ntuser/winsta.c

The patch explains clearly what's changed, and it's easy to follow.

Let's look at another:

"
Fix bugcheck code and make debugging easier for unhandled exceptions/spinlocks. fixg a race condition with tab+b, fix irql to be high_level, fix calling unsafe function by caching bugcode data, fix support for smp by using IPI, fix not-breakpointing when no debugger is there, implement KeBugCheck callbacks with Reason, fix callbacks not being called, fix proper breakpoint during bugcheck, fix errenous assert, "

Those are line by line the bugs it fixes...how much clearer can I get?

Every other patch was accompagnied by a merge and that's why there are many changed files. This is not my fault, you and casper have done the same in your branches as well, and it's perfectly normal:

"
Merge 13511:13830 from trunk

Added files:

... a list of 500 files follows...
"

And in your case,

"
Merge 13543:13754 from trunk."

and over 50 files follow.

Best regards,
Alex Ionescu

[Hartmut Birr]

Hi,

I haven't exactly said, why I'm against to merging Alex branch into the
trunk. Usually I try to review all commits which goes to kernel
components (except win32k and network drivers) and to some of the user
mode dlls (ntdll, crt, msvcrt, kernel32). Alex' commits are often a mix
from many changes, improvements and merges from trunk. It is not
possible, to review a single change or improvement. I'm not against the
changes, but I need (and some other people also) a way to understand
what is changed.

- Hartmut

Hartmut Birr schrieb:
> Hi,
>
> sorry for my next lines,
>
> I'm strictly against to merging Alex branch into our trunk. If I look to
> the commit comments, I see one, two or three lines of comments like
> 'Merge with blight 's rewrite' or 'My kernel fixes, new...' and always
> there are changed ten, twenty or more files. In the past there was
> always a description about the improvement of our development. I would
> like it if we can go back to this policity. I does know, that some of my
> commits are in conflict with this rules.
> Hartmut
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev