Ros-dev October 2005

ros-dev@reactos.org

76 participants
164 discussions

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

19 years, 2 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

19 years, 2 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.

19 years, 2 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

19 years, 2 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)

19 years, 2 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

19 years, 2 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

19 years, 2 months

Prelude to voting for the Testing Coordinator Roles and Responsibilities.

by WaxDragon

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

19 years, 2 months

RE: [ros-dev] Constitution

by Murphy, Ged (Bolton)

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

19 years, 2 months

RE: [ros-dev] Constitution

by Murphy, Ged (Bolton)

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

19 years, 2 months

← Newer
1
...
5
6
7
8
9
10
11
...
17
Older →

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 October 2005