- Ros-dev - ReactOS.org

Re: [ros-svn] [hpoussin] 18448: Big Plug-and-Play patch for ReactOS:
by Gge 21 Oct '05

21 Oct '05

hpoussin(a)svn.reactos.com wrote: > Big Plug-and-Play patch for ReactOS: > - Install drivers for devices at first boot > - Remove now useless entries in hivesys.inf > At the moment, driver installation only uses .inf files in ReactOS\Inf directory, and the needed files have to be in ReactOS\Inf or their final location (ReactOS\system32 or ReactOS\system32\drivers) + the user can't provide a custom driver > Plug-and-Plays devices are only USB controllers (OHCI and UHCI) and serial ports now. > > > Updated files: > trunk/reactos/bootdata/hivesys.inf > trunk/reactos/ntoskrnl/io/driver.c > trunk/reactos/services/umpnpmgr/umpnpmgr.c > How the nic driver ( realtek 8139 for example ) can be installed now ? Upto now , it was installed manually by adding "rtl8139 entries" in the registry ( hiveinst.inf file) as per wiki driver page. Regards Gge

3 2

RE: [ros-dev] Break, PC, Constituion and other misc issues
by Murphy, Ged (Bolton) 20 Oct '05

20 Oct '05

Aleksey Bragin wrote: > I regret really that Steven don't have time > right now, since he's best suited to this position (at least by a number of > expos he's taken part in :-)) I also wish Steven could find the time to take on this role. It's unfortunate as this role seemed to be almost written for him. ************************************************************************ 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

3 2

Re: [ros-svn] [navaraf] 18601: Fix DbgPrint calls.
by Hartmut Birr 20 Oct '05

20 Oct '05

navaraf(a)svn.reactos.com wrote: > Fix DbgPrint calls. > > > Updated files: > trunk/reactos/boot/freeldr/freeldr/arch/i386/i386disk.c > Oops, forgot to remove some of my privat debug prints. - Hartmut

2 1

Looking for a place to chekin
by Robert Köpferl 20 Oct '05

20 Oct '05

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

3 3

Visual Studio
by Jurgen Van Gael 20 Oct '05

20 Oct '05

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

3 2

top-level source header
by Ged 20 Oct '05

20 Oct '05

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 */

5 10

RE: [ros-dev] Voting system
by Murphy, Ged (Bolton) 19 Oct '05

19 Oct '05

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

7 7

Re: [ros-diffs] [cwittich] 18611: fix compile with msvc
by Alex Ionescu 19 Oct '05

19 Oct '05

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

2 1

Voting system
by Murphy, Ged (Bolton) 19 Oct '05

19 Oct '05

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

5 5

Re: [ros-svn] [cwittich] 18582: fixed compile problems with msvc 2003/2005
by Filip Navara 19 Oct '05

19 Oct '05

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

2 1

RE: [ros-dev] Voting system
by Murphy, Ged (Bolton) 19 Oct '05

19 Oct '05

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

2 1

Release Candidate, Test coordinator, ...
by Martin Fuchs 18 Oct '05

18 Oct '05

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

4 5

Break, PC, Constituion and other misc issues
by Steven Edwards 18 Oct '05

18 Oct '05

Hi, I have been away from my computer for most of the past week and will be away for another week but wanted to weigh in on some outstanding issues. 1. I like the draft constituion Casper has ripped from Debian. 2. I nominate Casper to the Project Cordinator Position (I would like the job but I have personal issues going on right now that may keep me busy for the next year or so) 3. I think the PC job should be for a 1 year term with no more than 2 consecutive terms. I don't like the idea of re-electing someone over and over again even if they are doing a good job. How do we know if someone could do a even better job? Don't bother replying directly to me unless you just want to share comments with others. I might not reply for a while. I would like to have votes for these issues as soon as possible. Thanks Steven __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/

4 6

Endianness
by Bart Grantham 18 Oct '05

18 Oct '05

Sorry to barge onto the list with what may be an offtopic post, but I am very curious about how married ReactOS is to little-endianness. Is there something intrinsic about how Windows is architected that would prevent ReactOS from being ported to a big-endian platform? I noticed that the inital work on the PPC port was done with the CPU in little-endian mode. Was this for convenience or was this a technical decision? Definitely not an important topic but if someone could satisfy my curiousity, I'd be grateful. Thanks, Bart

4 3

RE: [ros-dev] Constitution
by Murphy, Ged (Bolton) 17 Oct '05

17 Oct '05

Ge van Geldorp wrote: > > > From: Murphy, Ged (Bolton) > > > > Another quick point to say that using the voting facility on > > the board would remove the issue of giving a 'project > > secretary' power in a secret vote. The software would control > > that ..... And software doesn't lie or cheat :) > > But the database administrator (i.e.: me) could... You're just moving the > power from the project secretary to the dba. > But you would have to manually edit the database and everyone would immediately notice the change as the results are updated in real-time for everyone to see. In that respect, although the DBA has the power to change it as they see fit, it would be very silly to do so. There will always be some level at which the results could be changed. If we had a secretary, some could break into their computer and alter the results, or they could be bribed. I think we have to accept this and draw a line at what we consider an acceptable, reliable and trustworthy control system. I think using the forums is the best way of removing the power of controlling the votes from everyone. I know you can be trusted not to alter the database, in the same way I can be trusted not to break into the database and alter it myself. Using the forum voting system also removes any form of human error. > > In the way the phpbb forums voting works, each voter will > > only ever be able to make 1 vote, even if they have multiple > > usernames, as only 1 of those usernames will be in the > > 'developer' group. > > > > You can even go as far as making the forum hidden from > > everyone not in the developer group ..... Although I think > > this is wrong, and should be read only to everyone else. > > But every other developer still gets to see my vote I think? Doesn't sound > like a true secret ballot. Although everyone can see the vote status, it's not possible to see who voted for a particular option. It's only evident that 'someone' has voted. You could even go as far as setting your board preferences so that your name is not shown as being online when you logon. This will give complete anonymity. 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

4 3

RE: [ros-dev] Constitution
by Murphy, Ged (Bolton) 17 Oct '05

17 Oct '05

Ge van Geldorp wrote: > > [CSH] We haven't done secret elections before. I could go > > either way. If it's secret then you put a lot of power into > > one person, the person that collects the votes (most likely > > the Project Secretary). What procedure would you suggest? > > No, we haven't done this before, and I didn't like it... > How about the Project Secretary nominates a neutral vote counter (can be > anyone, Registered or Unregistered, including the Project Secretary himself) > which all the candidates have to affirm? Can be done in private emails > between Project Secretary and candidates. That should ensure the neutrality. > Another quick point to say that using the voting facility on the board would remove the issue of giving a 'project secretary' power in a secret vote. The software would control that ..... And software doesn't lie or cheat :) In the way the phpbb forums voting works, each voter will only ever be able to make 1 vote, even if they have multiple usernames, as only 1 of those usernames will be in the 'developer' group. You can even go as far as making the forum hidden from everyone not in the developer group ..... Although I think this is wrong, and should be read only to everyone else. Ged. -----Original Message----- From: Murphy, Ged (Bolton) [mailto:MurphyG@cmpbatteries.co.uk] Sent: 17 October 2005 09:48 To: 'ReactOS Development List' Subject: RE: [ros-dev] Constitution This sounds reasonable. Phpbb can use the feature whereby only a set group can post in a certain section of the forum, in this case, the developer group in the voting section. This also gives the added bonus of being a secret ballot, as Ge requested. Comments can be made without polluting the topic, and the results can be written to the wiki. -----Original Message----- From: Freworld [mailto:michael@freeworld.net] Sent: 17 October 2005 09:19 To: ReactOS Development List Subject: Re: [ros-dev] Constitution Perhaps we should vote on the website rather than on the mailinglist? The mailinglist could be used for the discussion about what exactly the vote will be and to make the vote public with a link (most people don't look at the website but at the mailinglist). With the new login system it would be no problem to control that only committers can vote. This way we would have a clean overlook what decisions were taken and what was decided exactly. If there is an interest in this I would implement it into the website. Greetings Michael ************************************************************************ 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

3 2

UI related bugs (IMO) that need followup.
by WaxDragon 17 Oct '05

17 Oct '05

This is mostly directed at mindflayer (mf). Looking over the BZ database for 0.2.8, there are several bugs I would like the UI team to look over, followup, or investigate. 448 - Message Box Icons http://www.reactos.org/bugzilla/show_bug.cgi?id=448 449 - File Format Icons http://www.reactos.org/bugzilla/show_bug.cgi?id=449 642 - Hotkeys not supported. http://www.reactos.org/bugzilla/show_bug.cgi?id=642 691 - ReactOS Explorer needs a configurable menu delay. http://www.reactos.org/bugzilla/show_bug.cgi?id=691 692 - Taskbar buttons are not centered in taskbar. http://www.reactos.org/bugzilla/show_bug.cgi?id=692 843 - The focus rectangle is sometimes on the wrong button http://www.reactos.org/bugzilla/show_bug.cgi?id=843 855 - Cannot sort by column in Task Manager http://www.reactos.org/bugzilla/show_bug.cgi?id=855 903- Detect 640x480 and adjust the resolution automatically http://www.reactos.org/bugzilla/show_bug.cgi?id=903 904 - Start, Search, search.. does nothing visible, please add messagebox http://www.reactos.org/bugzilla/show_bug.cgi?id=904 905 - Need mouse speed adjustment in mouse control panel. http://www.reactos.org/bugzilla/show_bug.cgi?id=905 906- There is a blank control panel icon, please label. http://www.reactos.org/bugzilla/show_bug.cgi?id=906 There are others, but this is a start. I don't necessarily want the UI team to code fixes, but rather provide input and try to motivate fixes. Thanks, WD -- <arty> don't question it ... it's clearly an optimization

2 1

Release process
by Ge van Geldorp 17 Oct '05

17 Oct '05

I'm trying to keep this as non-personal and technical as possible. I did include names, most people will guess the names anyway. Yesterday, Robert announced on the IRC channel that he had put RC1 on SourceForge. Immediately, some people jumped on him, demanding to know why he did that without the approval of the Testing Coordinator. This surprised me very much. Not only do we all of a sudden have a TC (I'm not the only one surprised about that: http://www.reactos.org/pipermail/ros-dev/2005-October/005250.html), but it seems that the TC has veto powers over publishing as well. Please don't get me wrong, I think Andrew (WaxDragon) is doing a great job with the testing (much of the increased stability can be attributed to better testing), and I certainly would have voted for him if such a vote had taken place. But that's the problem: Alex put a page on the Wiki (http://www.reactos.org/wiki/index.php/ReactOS_Testing_Coordinator) and appointed Andrew as TC. In my book, that makes him Alex' testing coordinator, not the ReactOS project testing coordinator. Naming Andrew TC is only a minor problem as far as I'm concerned, after all, he's the right guy for the job, the only problem is the procedure followed. I do have a major problem with the role definition as presented on the Wiki though. I want to focus on "The TC can decide as his will which bugs to promote to Blocker status (thereby blocking a new release)" for now. This is simply unacceptable to me. End of 2003, beginning of 2004 we've had a long discussion about the release process. In the end, general concencus was reached on the text presented here: http://www.reactos.org/wiki/index.php/Release_Management_Overview. There was no formal vote, since we didn't do those at that time, but at the time it was very clear that everyone agreed to it. As far as I know, no ammendments to this document have been approved, so it still stands as a valid, agreed-upon process for the ReactOS project. (To make it absolutely clear: the TC Wiki page is just some text that someone wrote, it does not have the same status.) If you feel that the Release Management Overview is not up to date or otherwise needs to be changed, draft an amendment and put it to vote. Until that happens, we're all bound by the current version. At the time, we agreed we should do time-based releases, a new release every two months. Basically it would be a snapshot of the tree at that time, much like the Wine project does with its monthly releases. After branching a RC1 would be put out. Period. No mention of "we put out a RC1 when all blocker bugs have been fixed and the TC has approved the release". On the contrary, the reason to put out a RC1 was to find as much bugs as possible and hopefully fix them before the final release. The idea behind the time-based releases is "release early, release often" (see the famous Cathedral/Bazaar article, http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/), you release even if you know about some bugs. So, do I think we shouldn't have "blocker" bugs at all? Let me put it this way: if none of the 30 devs feel a bug is important enough to be fixed in the feature freeze period before a release, I do question the severity of the bug. The time-based releases started to go wrong at the end of last year. 0.3 seemed around the corner at that moment, so we decided to postpone the release a bit (we did that before with the 0.2 release, which worked out ok). But now, one thing lead to another, and we completely forgot about the release schedule. I was very pleased to see we were picking up the schedule again, with 0.2.8 being released 2-3 months after 0.2.7. I feel very strongly that we should continue this, go back to the original plan of making snapshot releases every two months. Of course, we should try to stabilize the releases as much as possible, but I would like to remind everyone of this quote from the Wine release announcements, which applies to us equally well: "This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly.". A final word of support for Robert: He did EXACTLY what he was supposed to do by placing RC1 on SourceForge and I completely back him on his decision. Gé van Geldorp.

10 16

RE: [ros-dev] Prelude to voting for the Testing Coordinator Roles andResponsibilities.
by Murphy, Ged (Bolton) 17 Oct '05

17 Oct '05

Ge van Geldorp wrote: > > Yes, that is what RC1 is for. It is supposed to be made immediately after > branching, when entering feature freeze. It's status is basically no more > than that of a random svn version. Perhaps "RC1" is a misnomer. <snip> > Perhaps we should call > it "FF" (Feature Freeze) instead and rename RC2 to "CF" (Code Freeze)? My understanding of RC in the software world is a Release Candidate, meaning we have removed every bug we could find and we think this software is now ready for release. Therefore I think RC gives out the wrong impression and should not be used. Code Freeze or Preview Release sounds good to me. > > However, I have decided to no longer > > continue as TC, if I was even TC to start with. > > I am really sorry to hear this and hope you will reconsider. I also hope you will reconsider. IMO, the assignment of a TC has proven to be one of the most successful ideas I've seen since I started following the project. The work you have done so far has been fantastic and I would like to see it continue. 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

3 2

Coordinators
by Rick Langschultz 17 Oct '05

17 Oct '05

There has been a great deal of talk lately about coordinators. In my opinion there should be: kernel coordinator - controls the development of the kernel. device driver coordinator - makes sure device drivers are written and code managed. network coordinator - makes sure networking is complete before 0.3.0 or other release. User interface coordinator - enables the UI is stable and allows users to get a great ReactOS experience. testing coordinator - this team will test reactos on various hardware bits. They will keep a log of what hardware bits work and those that need support - for instance on Virtual PC (latest Mac OS X) enabling USB support makes ReactOS crash. A list of that hardware needs to be supported -- eventually. release coordinator - Once a release is scheduled this team makes sure releases are released on time. web coordinator - this team managers the web aspects of ReactOS. This team is pretty much complete. and IRC coordinator - this coordinator will keep logs of what has been discussed on the IRC channels. A daily list of main topics will be available on the wiki. This will keep developers up to speed on what is happening on IRC if they are away, or if someone has a quick message for other teams. These are suggested teams. Each team should have a coordinator and keep a log of information for each team. The coordinators should be able to communicate with other coordinators of other teams. Once weekly they should have a personal chat on IRC or email discussing the next release or feature addition. This is the way my company operates and it is very efficient. Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

3 3

ReactOS Development Coordinator
by Jason Filby 17 Oct '05

17 Oct '05

Hi all Before anyone else slips this through (I kid, I kid!), I would like us to move to vote on a ReactOS Development Coordinator. Before we vote, anyone that wants to run, please step up. The DC would really have the responsibility of facilitating developers. I don't know if we already have a page on this, but I would say this means helping other developers reach their potential in contributing to ReactOS through development. This also entails facilitating communication within the team and with other teams (testing, UI, translation). I'd like some discussion on this thread as to the role of the DC to prevent future confusion. Regards Jason

7 8

RE: suggestion to close (was Re: [ros-dev] Prelude to voting for the Testing Coordinator Roles andResponsibilities.)
by Murphy, Ged (Bolton) 17 Oct '05

17 Oct '05

I like and agree with all 4 of your suggestions. -----Original Message----- From: Royce Mitchell III [mailto:royce3@ev1.net] Sent: 17 October 2005 13:32 To: ReactOS Development List Subject: suggestion to close (was Re: [ros-dev] Prelude to voting for the Testing Coordinator Roles andResponsibilities.) Here's a combination of various suggestions to hopefully begin to close this matter: 1) Go with Gé's suggestion and rename our candidates to x.x.x-FF and x.x.x-CF respectively. 2) TC has no power to block FF - doesn't make sense to do so. 3) TC has power to block CF, subject to be overruled by a vote should a majority feel it is not critical enough. 4) No matter which way we enter CF, it takes an informal vote on the ML to drop back to FF for major discovered bugs - but any single developer can request and be granted a formal vote. Andrew, would you still be willing to run for TC and continue the absolutely fantastic work you've done there given these, assuming everybody would agree to them? ************************************************************************ 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

1 0

Prelude to voting for the Testing Coordinator Roles and Responsibilities.
by WaxDragon 17 Oct '05

17 Oct '05

Hello everyone. I think there is alot of time and energy being wasted regarding the Testing Coordinator role, and it's responsibilities. First the responsibilites need to be solidified. When I started acting in the TC role, this was the outline I was shown by Alex, and agreed to perform: http://www.reactos.org/wiki/index.php/ReactOS_Testing_Coordinator I am pretty pleased with the description, and have managed to balace performing these responsibilities with having a real life, wife and child included. Seems everyone agrees I am doing acceptably. I've tried to review the stability of ReactOS about once a week, since it takes about 4 to 5 solid hours to build debug and release builds, install them, load test applications and check out regressions, bugs, and newly working features. I've tried to keep the bugzilla database up to date, and filled with "Good Bugs", and I even wrote up a wiki article on how to do so. http://www.reactos.org/wiki/index.php/File_Bugs. I have tried to steer people away from reporting bugs in the IRC channel and the forums. I am usually available on IRC, and occationally surf the forums for bug reports and reminders. The last part of the obligations of the TC is the working applicaitons list, and when Alex and I discussed this, he came up with the example listed, but it was understood that the format of list was flexible. This is sort of what the "State of the Repository" emails have been about. I am collecting notes on a testing method than can be applied by our more inclined users, and a way to integrate a "testing database" that can show the status of apps using reports submitted by users or a testing team. I am also working on updating the parts of the wiki that involves testing in some manner, including building the source (and setting up the environment), using virtual machines to test, debugging, filing bugs and so on.. Please review and discuss. I would like to have the vote as soon as possible. Thanks for everyone's support, WD -- <arty> don't question it ... it's clearly an optimization

7 11

RE: [ros-dev] Constitution
by Murphy, Ged (Bolton) 17 Oct '05

17 Oct '05

Freworld wrote wrote: > If the forum is not the form you like I could include another form of > website voting. You could also peculate voting mails on the mailing > list. This project stands on a certain factor of trust. I personally think we should open up a new section in the forums entitled 'Voting' Everyone with commit access should be placed in the 'developer' group and the developer group should be given write access to this section. Polls should be made using the built in voting system. Should the 'voting' section should be made read only, or invisible to other users? Results should be posted onto the wiki > Perhaps we should make a vote which voting system is preferred? :) Although ironic, I think this is the only way. We will need a few more suggestions first of how the voting system should work. 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

1 0

RE: [ros-dev] Constitution
by Murphy, Ged (Bolton) 17 Oct '05

17 Oct '05

This sounds reasonable. Phpbb can use the feature whereby only a set group can post in a certain section of the forum, in this case, the developer group in the voting section. This also gives the added bonus of being a secret ballot, as Ge requested. Comments can be made without polluting the topic, and the results can be written to the wiki. -----Original Message----- From: Freworld [mailto:michael@freeworld.net] Sent: 17 October 2005 09:19 To: ReactOS Development List Subject: Re: [ros-dev] Constitution Perhaps we should vote on the website rather than on the mailinglist? The mailinglist could be used for the discussion about what exactly the vote will be and to make the vote public with a link (most people don't look at the website but at the mailinglist). With the new login system it would be no problem to control that only committers can vote. This way we would have a clean overlook what decisions were taken and what was decided exactly. If there is an interest in this I would implement it into the website. Greetings Michael Casper Hornstrup wrote: > > >>-----Original Message----- >>From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Ge van Geldorp >>Sent: 16. oktober 2005 23:56 >>To: 'ReactOS Development List' >>Subject: RE: [ros-dev] Constitution >> >>Looks good. A few comments: >> >>The Registered Project Members can (by General Resolution) override any >>decision made by the Project Coordinator or the Area Coordinators. However, >>the Repository Coordinator and Project Secretary can make decisions >>"preferably consistent with the consensus of the Project Members". It seems >>to me that Registered Project Members should be able to override their >>decisions too. >> >> > >[CSH] Right. How about changing: >* Override any decision made by the Project Coordinator or Area Coordinator. >* Appoint or dismiss the Project Coordinator or Area Coordinator. > >to >* Override any decision made by the Project Secretary or any Coordinator. >* Appoint or dismiss the Project Secretary or any Coordinator. > > > >>There is a mandatory 1 week discussion period and 1 week voting period for >>each vote, with no escape clause. For some votes (whether to release or not >>comes to mind) 2 weeks seems a bit long. Can we change it so that the >>proposer can ask for shorter periods, with a safeguard that the shorter >>periods will be denied if a single Registered Project Member objects? >> >> > >[CSH] I thought of having a "quick vote" for decisions which are needed here >and now (like whether or not to release now) and not necessarily need to be >documented anywhere else than the mailing lists for future reference, but how >would you define the two? >Maybe we could allow the Registered Project Member that calls for the vote to >choose any number of days of voting period less than 7 days, but at least 2? >days and no discussion period? Any Registered Project Member already has the >right to demand a revote at any time (maybe there should be some protection >from abuse of that right? One could spam until he/she gets what he/she wants). > > > >>I really would like Coordinator Elections to be secret (or private, not sure >>what the correct English term is). I should be able to cast my vote without >>the candidates knowing on who (or even if) I voted. I believe this should be >>explicitly mentioned in the Coordinator Elections voting procedure. >> >>Ge van Geldorp. >> >> >[CSH] We haven't done secret elections before. I could go either way. If it's >secret then you put a lot of power into one person, the person that collects >the votes (most likely the Project Secretary). What procedure would you suggest? > >Casper > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ************************************************************************ 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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev