On Mon, Jun 9, 2008 at 4:57 PM, <tkreuzer(a)svn.reactos.org> wrote:
> See issue #2142 for more details.
Is there anyway we can add a macro so that when the commit message see's
"See issue #### for more details."
It will auto magically link to bugzilla? I would look at more bugs as
the patches come in but I am too lazy to manually open another tab and
copy/paste the bug number. I could set a macro in firefox where I do
"bug ####' but that means I still have to manually open a new tab and
copy and paste, like I said I am lazy.
--
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
HI
I am been rethinking over some thing in ReactOS
mean while I will not be avail coding on ReactOS at all
or do any commit or helping people as I use to.
I am still piss over some matter betwin me and Alesky
this matter is betwin us two. What happen betwin us
is betwin us. That is all I have say for now. about
that matter.
And I am rethinking over a sugestions I got from a old
freind maybe start working for him. I do not known
if I do i can not be coding on any opensource project
the contract is for long terms contract and will need
all skill I have. I got this offer for long time ago
and I did say no to it, but it still stand,
reason I did say no to it was I did not want coding behine dorrs or
come up new ideas that being use behine dorrs and u are not avail
to talk about them. I see allot of my life works are being using of
all people that own a laptop or cellphone today.
But one can backtrace the techlogic to me. what I done.
That is how I did want thing be when I was younger.
it is some background info what I did before 2003
after I join ReactOS most people I known ask me if I can quit
from ReactOS and start working for them. One video card manufactor
did contact me when I join ReactOS I can not tell which one.
I solv the main issue I and the manufactor did have.
it was how to open directx hal for the graphic card.
next issue I solv was how to create a surface and access all other
part of directx hal. Next issue we got was DirectX DdBlt it did not
work direcly it took me and the manufactor around 2 days figout
how to use DdBlt so it was avail to blit and see it on the screen.
This informations did not exstis at all in MSDN. after I told open
how it was done and start implemeted it in reactos MS did update the
doc how to optain DirectX HAL. See GdiEntry1-16
This does not mean I am leving ReactOS
it mean I need rethink what I want todo
the options I got is very good one. I like
the offer I got. and I do not known if I will say yes or no
I am not a person say direcly no to money but none can buy me
for money. I choice what I want todo. even it is bad payment.
I have say no to many good deal and work in pass.
Steven
what I told u before, I stand with my word, and waiting on
you mail about the details.
To reash me is not via irc any longer
it is on icq / skype or my mail address.
Bestregards
Magnus Olsen
Hi,
this question seems to arise periodically, so let's have a
constructive discussion again about the issue once again.
The issue is being that a lot of people have direct commit access to
the repository, and sooner or later some of them commit patches which
introduce a regress in functionality.
I will use Magnus (GreatLord) again as an example. He was doing a
good thing (as usual), but then somehow lost focus, and along with
good fixes committed a breakage for FF2.0 installer (and all other
apps using PatBlt functions). I had to (as usual!) spend the whole
morning reviewing all his diffs, then regress-testing by bisection to
find the guilty revision, then work out a better solution with him,
and then come to agreement that the guilty commit could be just
reverted for now, since it partly works anyway.
This takes up significant amount of my time, which could go into
something more productive than just testing patches, finding way to
unregress, and so on.
Especially I'm angry about this happening right when approaching
0.3.5 release.
Ideally (as I explained in #reactos today to blight_), I want the
trunk itself be directly committable only by a very limited number of
persons, and all developers should be committing to "some other
place" at first, and then their patches merged by reviewers/testers
(yes, manually, sometimes just reviewing may be enough to commit/
reject the patch, sometimes a thorough testing must be involved,
maybe additional devs asked for a review).
blight_ called this as a "linux development model" with an
intermediate branch - yes, maybe, why not?.
What I definately don't want to do is to scare developers away and
make their life more complicated by need of sending text patches
(this is just not convinient, and as seen on the example of Wine
makes a lot of possible contributors going away).
I remember what Alex proposed (those who don't, may look up ros-dev
ML archives with a similar topic).
Would there be any new prepositions? Maybe someone discovered a new
CIS for SVN, or a decentralized VCS for patch submission and usual
SVN for maintaining HEAD?
With time, developers number is only going to increase, so this
problem will become more and more annoying.
With the best regards,
Aleksey Bragin.
Hi,
I'm going to explain this ONCE:
1st: The move was to conserve and reduce space and size of the current
structure.
Writing a floating point package could be hard to do or just copyleft
one off the net.... Problem is if we do the later it will most likely
not be compatible with M$ SFPP. BTW, M$ did patent their strange and
unusual floating point package. Which means I can not write one! Just
writing the storage emulation is almost a problem too... But due to US
patent law I can just do what I did, to "Talk to the Interface" with
the storage emulation.
Keeping the current state of ReactOS FP is my first choice. We use the
speed of the FPU which is part of the main processor and reduce the
size of the source. (Two pluses so far, Speed and Small Size.) The
storage emulation for gdi32 is important for compatibility and with
ReactOS concept of drop in replacement and play.
Thanks,
my 1EU
References:
Fast floating-point truncation to integer form - US Patent 6535898:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6535898&F=0
Use of indices for queries with comparisons based on a function:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1193619&F=0
System and method for fast and smooth rendering of lit, textured spheres:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1227443&F=0
John R. Hauser SoftFloat package :
http://www.jhauser.us/arithmetic/SoftFloat.html
IEEE 754 floating-point test software:
http://www.math.utah.edu/~beebe/software/ieee/
Hi,
I experience a hang of FF 1.5 installation app at "0% Extracting".
Sometimes hangs completely (even mouse doesn't move), sometimes I'm
able to click "X" and choose yes to cancel.
It started happening at least since yesterday.
WBR,
Aleksey Bragin.
Hi,
I like to start testing FF again on hardware but this bug is still open.
http://www.reactos.org/bugzilla/show_bug.cgi?id=2987
I've copied most of the netamd.inf from Ros to match with the inf for
the driver. But still the same crash.
Please let me know,
James
Hi!
There was a reason for doing what I commit'ed,,,, since you are
looking at it can you please fix this.
8^)
James
gdi32_winetest pen
ExFreePool of already freed address 80e8ba78
KeBugCheck at ntoskrnl/mm/npool.c:1566
*** Fatal System Error: 0x00000000
(0x00000000,0x00000000,0x00000000,0x00000000)
Entered debugger on embedded INT3 at 0x0008:0x808ac7d8.
kdb:> bt
Eip:
<NTOSKRNL.EXE:ac7d9 (lib/rtl/i386/debug_asm.S:42
(RtlpBreakWithStatusInstruction))>
Frames:
<NTOSKRNL.EXE:29a2 (ntoskrnl/ke/bug.c:1100 (KeBugCheckWithTf@24))>
<NTOSKRNL.EXE:2aac (ntoskrnl/ke/bug.c:1364 (KeBugCheck@4))>
<NTOSKRNL.EXE:5f00c (ntoskrnl/mm/npool.c:1567 (ExFreeNonPagedPool@4))>
<NTOSKRNL.EXE:61e64 (ntoskrnl/mm/pool.c:238 (ExFreePool@4))>
<win32k.sys:967ff (subsystems/win32/win32k/objects/pen.c:344
(NtGdiExtCreatePen@44))>
<NTOSKRNL.EXE:96eda (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:5dda>
<gdi32_winetest.EXE:3b497>
<gdi32_winetest.EXE:3d605>
<gdi32_winetest.EXE:3d78d>
<gdi32_winetest.EXE:3dc3d>
<gdi32_winetest.EXE:3dc6a>
<kernel32.dll:21610>
<00000000>