I'm currently preparing the doc on how to publish ROS.
Since I did this a several times I made a QnD script which I want to
reference in my description. It's quite not a real solution, but better
than nothing on the way until rbuild gets that feature/target.
Where do you think I should check that in?
I think of a subdirectory at reactos/tools
thanks
Hi,
I was just fiddling around with reactos and am interested in getting
some stuff to compile with msvc. (I tried 2003 and 2005 express beta 2)
However, the sln workspace files don't seem to open properly on neither
visual studio. The vcproj do; just wondering whether you guys use other
versions of visual studio?
Jurgen
Although a standard header was drafted out for the ReactOS source code,
few people seem to use it and it doesn't seem to be in the wiki.
I would like to get something in the wiki agreed on by everyone which
should be included in our source files.
I think we firstly need have a vote to see if everyone actually wants a
standard header, but I put together some info anyway to explain my thoughts
As much of the ReactOS code is licensed under the GPL, it can be reused
by anyone under the license agreements.
As the BSD code does, I think a ReactOS copyright notice should be
placed in the header to ensure people know where the original code came
from. Our current header has no provision for this meaning anyone
reading ReactOS code away from the project won't have a return point.
I was talking this over with Alex, who suggested everyone might not want
to give copyright to the foundation. Any suggestions?
Using the existing header, I have drafted a slightly modified version
/*
1 * ReactOS <place holder>
2 * Copyright (C) 2005 ReactOS Foundation
3 *
4 * LICENCE: <place holder>
5 * PROJECT: <place holder>
6 * FILE: <place holder>
7 * PURPOSE: <place holder>
8 * PROGRAMMERS: <place holder>
9 * REVISIONS:
10 * <place holder>
11 *
*/
1. This is a quick line to state the area which the code was written
for. Examples could include:
ReactOS Executive
ReactOS Win32 Subsystem
ReactOS Win32 Applications
2. The copyright should detail a date when the copyright was initiated
along with the date when it was last modified. For example:
1999 - 2004
The proceeding date should be updated each time a revision is made.
4. This line should state the licence used and where to find the COPYING
file
5. This line should state what project / binary the code is for.
Examples could include:
ReactOS ntdll library
ReactOS ws2_32 library
ReactOS arp utility
ReactOS cache manager
ReactOS thread scheduler
6. This line should state the location of the file within the repository
7. This line should state the purpose of the project / binary the code
is intended for
8. This line should state any programmers whom have worked on the code.
The programmer can also choose to add an email address along with their
name as a point of contact
9. This line should list any revisions made to the code. The revisions
should include programmers initials, which can be linked to the
PROGRAMMERS section, the date the revision was made and a short comment
describing the revision. This is not meant for bug fixes and small
modifications, but for feature additions or substantial patches
I think we should put something in the wiki in relation to this.
Does anyone have any other suggestions, or modifications to my header.
Please see the examples below.
Examples:
/*
* ReactOS Win32 Applications
* Copyright (C) 2005 ReactOS Foundation
*
* LICENCE: GPL - See COPYING in the top level directory
* PROJECT: ReactOS arp utility
* FILE: apps/utils/net/arp/arp.c
* PURPOSE: view and manipulate the ARP cache
* PROGRAMMERS: Ged Murphy (gedmurphy(a)gmail.com)
* REVISIONS:
* GM 04/10/05 Created
*
*/
/*
* ReactOS Executive
* Copyright (C) 2005 ReactOS Foundation
*
* LICENCE: GPL - See COPYING in the top level directory
* PROJECT: ReactOS kernel
* FILE: ntoskrnl/ex/mutant.c
* PURPOSE: section of the kernel
* PROGRAMMERS: Alex Ionescu (alex(a)reactos.org)
* David Welch (welch(a)cwcom.net)
* REVISIONS:
* AI 04/10/05 Fix tab/space mismatching, tiny fixes to
query function and
* add more debug output.
*
*/
/*
* ReactOS Network Stack
* Copyright (C) 2000 - 2005 ReactOS Foundation
*
* LICENCE: GPL - See COPYING in the top level directory
* PROJECT: ReactOS TCP/IP protocol driver
* FILE: transport/tcp/tcp.c
* PURPOSE: Transmission Control Protocol
* PROGRAMMERS: Casper S. Hornstrup (chorns(a)users.sourceforge.net)
* Art Yerkes (arty(a)users.sf.net)
* REVISIONS:
* CSH 01/08-2000 Created
* AY 12/21/2004 Added accept
*/
Brandon Turner wrote:
> I _strongly_ disagree with this.
Me too. I'll just elaborate on the reasons Brandon gave
> 1) No way to make sure no one is cheating and not voting a
> bunch of times.
Developers are put into the developer group on the board. Thus, only
registered developers can vote. This will stop people from registering 50
different logins and altering the vote, which could not be controlled if
everyone was allowed to vote.
> 2) I don't think everyone voting is educated well enough on
> the topic.
This is also very true. Core design decisions cannot be made by people who
do not have a deep knowledge of the subject. Opening up voting to everyone
could possibly generate in bad results
> In the case coding questions like the macros vote we recently had, I
> didnt vote.
Me either. I didn't fully understand the repercussions, therefore my vote
should not effect the outcome.
> In the
> case of a PC, I just dont think that a user that reads the message
> boards or the general mailing list will have enough info and feel for
> who should and shouldnt be a PC. In both cases people with
> education on
> the topic will probably outnumber those who do know about it,
> and might
> skew things very badly.
This is just one of many examples. Another one would be the recent
discussions between Alex and Emmanuelle about splitting win32 the subsystem.
This isn't a decision that people not working with the code should be making
.... consider the users who come into the forums asking what version of
Linux ReactOS is based on. Should they be allowed to sway this decision.
To stop any animosity of users towards devs, the votes could be made hidden.
However I don't think this is a requirement as I think the majority of users
would understand the position on voting.
It would also be interesting for users to see the voting results, and how
ReactOS is developing.
If there is a vote where the users input is needed, then it can obviously be
placed in another section where the users have write access. This was
demonstrated recently when Alex Ionescu started the poll on feature
importance.
Ged
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
cwittich(a)svn.reactos.com wrote:
>fix compile with msvc
>
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/lib/aclui/precomp.h*
>
>--- trunk/reactos/lib/aclui/precomp.h 2005-10-19 21:46:17 UTC (rev 18610)
>+++ trunk/reactos/lib/aclui/precomp.h 2005-10-19 21:46:30 UTC (rev 18611)
>@@ -5,7 +5,9 @@
>
> #include <prsht.h>
> #include <aclui.h>
> #include <sddl.h>
>
>
>+#if defined (__GNUC__)
>
>
> #include <winternl.h>
>
>
>+#endif
>
>
> #include <ntsecapi.h>
> #if SUPPORT_UXTHEME
> #include <uxtheme.h>
>
>
These changes are really wrong! HEADERS have nothing to do with the
compiler! The HEADERS have to be fixed...you're just building with mingw
headers and msvc, and assuming the errors are because of msvc, but if
you'll try compiling with PSDK (or vice-versa), then these changes make
no sense at all.
Best regards,
Alex Ionescu
This seems to have died a death again, so I'm going to bring it back up.
So far we have 2 viable options for the new voting system:
1. Have a new section in the forums where only the developer group has write
access.
Conduct all votes in there using the forums built-in voting system and
posting mechanism for comments
Vote results are stored in the database and everything is handled by the
software
All votes are anonymous / private and each developer has only one vote.
2. Design our own voting system and integrate it into the website.
This will be controlled via the global login system and all devs will
have access to initiate, vote and comment on votes.
Vote results need to be stored in a database and everything should
handled by the software
All votes are anonymous / private and each developer has only one vote.
Any comments or additions?
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
cwittich(a)svn.reactos.com wrote:
>fixed compile problems with msvc 2003/2005
>
>
>Updated files:
>trunk/reactos/subsys/system/msconfig/msconfig.c
>trunk/reactos/subsys/system/msconfig/srvpage.c
>trunk/reactos/subsys/system/msconfig/toolspage.c
>
>
>
This and r18583 breaks PCH support for GCC.
- Filip
Magnus Olsen wrote:
> if we doing 2 we need write code for it.
That's what I was thinking. By using the forums, we are adopting something
which has already been implemented and has been tried and tested by
millions.
It seems like a good place to start. We can always move it into the website
if the need ever arises, and someone ever finds the time to code it.
Ged
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
OK, there have been a few misunderstandings, which lead to the current problems
and all this partly quite angry discussions.
Let's go on and see what to do now. I recommend the following steps:
1.) Fix the console bug in question, and put a new tested release
candidate on the web.
2.) update the release procedure
(http://www.reactos.org/wiki/index.php/Release_Management_Overview)
to include the test coordinator
Of course this includes a discussion about the new content on the
mailing list.
3.) make an official vote for the test coordinator and new release procedure.
And Alex - I hope your break period will not last too long.
Regards,
Martin
