> Let me make it clear that the vote is about wether or not to allow
> a particular type of branch which have some bad consequences. Not
> branches in general. See
> http://reactos.com:8080/archives/public/ros-dev/2005-March/002083.html
> for a description of the common branch types.
I did read it (otherwise I wouldnt vote)
"Bugs that that could have been fixed on trunk are annoying to trunk
developers. The bugfixes that go only to the branch are not in trunk (until
merged there from the branch"
=> trunk developers are free to ask for a merge or use ros-diffs to speed up the merge process.
"* Risk of duplicating work. We'll have more branches to track bugfixes on
so it's harder to know which bugs has been fixed and which hasn't."
you can use ros-svn to track it. And you can fix bugs in bugzilla too.
"Fixed in branch my_branch, feel free to merge."
>
> Do you have commit access?
>
> Casper
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
If all legal conditions are fulfilled :
- give link to the source
- (alex's idea) provide md5sum of the file(s)
As some people already said, 3d point cant exist.
(ros is a LGPL system, some magazines already distribute it, etc.)
> [ ] Yes, allow 3rd-party distribution of the OS through the #ros-xdcc
> channel and ROS-XDCC-001 bot. (support and encourage this distribution)
>
> [X] Yes, allow 3rd-party distribution of the OS, but it must clearly
> distance itself from officially supported releases (tolerate but do not
> support this distribution)
>
> [ ] No, only sourceforge and other official ReactOS distribution points
> should be used.
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Hi!
hbirr(a)svn.reactos.com wrote:
> Added a keep-alive reference to each key object.
> Lock the registry while accessing sub keys of a key object.
> Implemented a worker thread which removes all unused key objects.
> Fixed a bug which shows keys twice if a key is already opened.
>
>
>
> Updated files:
> trunk/reactos/ntoskrnl/cm/cm.h
> trunk/reactos/ntoskrnl/cm/ntfunc.c
> trunk/reactos/ntoskrnl/cm/registry.c
> trunk/reactos/ntoskrnl/cm/regobj.c
>
ntoskrnl: [CC] cm/regobj.c
cm/regobj.c: In function `CmiObjectParse':
cm/regobj.c:244: error: parse error before '<<' token
cm/regobj.c:763: error: parse error at end of input
cm/regobj.c:23: warning: `CmiGetLinkTarget' declared `static' but never defined
make[1]: *** [cm/regobj.o] Error 1
make: *** [ntoskrnl] Error 2
8^),
James
--- Casper Hornstrup <ch(a)csh-consult.dk> wrote:
> I'd like to close this discussion with a vote.
>
> Should we allow branches (other than trunk) with mixed new development and bugfixes
> unrelated to the new development that is on the branch (miscelanea branches) ?
>
> [X] Yes, do allow miscelanea branches
>
> [ ] No, don't allow miscelanea branches
>
> Casper
>
Have an svn branch gives a nice way to revert/update
and permits others to work with a different POV on the project.
Even if only some are using it, it can help ros a lot.
(look at the xmlbuildsystem branch that speeds up the compilation a lot)
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
I don't think we've ever formalised our voting procedures.
All I seem to remember about this is that committers can vote.
I've drafted an initial version here:
http://reactos.com/wiki/index.php/Voting
Please comment on that.
Casper
--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
> [ ] Yes, allow 3rd-party distribution of the OS through the #ros-xdcc
> channel and ROS-XDCC-001 bot. (support and encourage this distribution)
>
> [X] Yes, allow 3rd-party distribution of the OS, but it must clearly
> distance itself from officially supported releases (tolerate but do not
> support this distribution)
Yes but only if they are using a binary published by reactos.org or a core ReactOS developer such
as Thomas's nightly builds. If they are not doing so then my vote is no. At the first offence we
should warn them and then at the 2nd offence we should deny the use of the ReactOS name
> [ ] No, only sourceforge and other official ReactOS distribution points
> should be used.
We cannot stop distrabution of the OS. Only the use of the name.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
Hi Royce,
royce(a)svn.reactos.com wrote:
> -Wall -Werror and fix warnings
>
>
> Updated files:
> trunk/reactos/tools/widl/Makefile
> trunk/reactos/tools/widl/hash.c
> trunk/reactos/tools/widl/write_msft.c
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
More crazy Linux port problems, in /reactos/tools/widl,
write_msft.c: In function `ctl2_write_chunk':
write_msft.c:2189: warning: implicit declaration of function `write'
write_msft.c:2190: warning: implicit declaration of function `close'
write_msft.c: In function `save_all_changes':
write_msft.c:2284: warning: implicit declaration of function `creat'
make: *** [write_msft.o] Error 1
It works when removing -Werror -Wall from the Makefile. BTW io.h
is in the /usr/mingw32/include directory.
Thanks,
James
hbirr(a)svn.reactos.com wrote:
>Use only one access to the spinlock in the assertion, because the value may change between two access' on smp machines.
>
>
You implementation is better, no doubt, but it wouldn't have mattered to
read it twice or more. I mean, it's re-read again down in the
InterlockedExchange call, there's a possibility it might have been
changed in the meantime as well. But it really wouldn't matter ;)
Best Regards,
Thomas
Hello,
Retransmission of this message sent to Harmut , to Ros-Dev list
following error in the mail address of Ros list
---------------------------------------------
Harmut ,
I do not know if this commit is related to the Bug #512 ( Colinux fails
to load in MM/MDL ) but more debug messages are displayed now.
I have updated Bugzilla with these debug messages.
Best regards
Gerard
Subject:
[ros-svn] [hbirr] 13963: Lock the kernel address space instead the
process' one, if the pages are located in kernel space.
From:
<hbirr(a)svn.reactos.com>
Date:
Sat, 12 Mar 2005 10:14:38 +0100
To:
<ros-svn(a)reactos.com>
Lock the kernel address space instead the process' one, if the pages are
located in kernel space.
Unlock the address space on error.