Ros-dev

ros-dev@reactos.org

5788 discussions

Break, PC, Constituion and other misc issues

by Steven Edwards

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/

18 years, 11 months

Endianness

by Bart Grantham

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

18 years, 11 months

RE: [ros-dev] Constitution

by Murphy, Ged (Bolton)

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

18 years, 11 months

RE: [ros-dev] Constitution

by Murphy, Ged (Bolton)

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

18 years, 11 months

UI related bugs (IMO) that need followup.

by WaxDragon

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

18 years, 11 months

Release process

by Ge van Geldorp

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.

18 years, 11 months

RE: [ros-dev] Prelude to voting for the Testing Coordinator Roles andResponsibilities.

by Murphy, Ged (Bolton)

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

18 years, 11 months

Coordinators

by Rick Langschultz

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)

18 years, 11 months

ReactOS Development Coordinator

by Jason Filby

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

18 years, 11 months

RE: suggestion to close (was Re: [ros-dev] Prelude to voting for the Testing Coordinator Roles andResponsibilities.)

by Murphy, Ged (Bolton)

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

18 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev