Hi everybody,
As promised, here are the status updates of several ReactOS people based
on the texts I received after our failed meeting a week ago.
Thomas Faber has reported that the Kernel-Mode Test Framework is pretty
much standing, together with extensive tests for Spin Locks, Executive
Resources and IRQ-Level functions. Additional "comfort" functions might
be added as the need arises.
Basic tests also exist for Singly and Doubly Linked Lists, Hard Error
Messages, Deferred Procedure Calls and Asynchronous Procedure Call
Disabling. Furthermore, applicable tests have been ported from the old
"kmtests" module.
Thomas is currently working on tests for Events, Fast and Guarded
Mutexes as well as basic I/O functionality (Driver/Device Objects,
app-driver communication). Latter ones are partly based on the
"not-applicable" old tests. More tests concerning Object Referencing,
Singly and Doubly Linked Lists and Sequenced lists are going to follow.
Even more may follow afterwards based on his personal function list or
current requirements. Finally, the integration with our automated
testing tools has to be tested.
Colin Finck did not have much time for ReactOS in the last month, so he
could just assist Pierre Schweitzer with setting up the Icinga
monitoring solution.
Claudiu Mihail has integrated lwIP into the tcpip.sys driver. The
library has also been updated to the most recent version (1.40), which
required no changes to the interface code. On top of this, the speed
issue has been resolved, so the performance of our lwIP-based stack is
on par with our existing OSKitTCP-based stack now.
The new network stack has been tested by replacing the tcpip.sys of a
regular Trunk build with the lwIP-based one. This posed no problems, so
merging the new stack back to Trunk should work nicely. According to
Claudiu, initial testing using applications such as Opera, Firefox and
BitTorrent shows very promising results in terms of stability and
performance.
In the short term future, he plans to conduct more testing to fix any
outstanding bugs in the implementation. Besides, he plans to optimize
some aspects of the implementation, especially regarding memory usage,
together with Art Yerkes and Cameron Gutman.
For the long-term future, which also includes the time after GSoC, he
thinks about moving more TCP/IP functionality to lwIP such as UDP.
Pierre Schweitzer has been setting up an Icinga solution for monitoring
all our physical servers and VMs, including the services running on
them. This will allow the project to have a higher quality of service,
and let ReactOS sysadmins be aware quicker about issues raising on the
servers.
He also announced that he is leaving ReactOS development and only
focuses on sysadmin work for the project.
- Colin
Hello all,
Today's planned meeting has been postponed to the 25th August (the time
of the next regular meeting) based on a voting of the participants
present at 19:39 UTC. These were:
* Giannis Adamopoulos
* Javier Agustìn Fernàndez Arroyo
* Maciej Bialas
* Thomas Faber
* Colin Finck
* Ziliang Guo
* Cameron Gutman
* Rafal Harabien
* Timo Kreuzer
* Matthias Kupfer
* Igor Paliychuk
* Sylvain Petreolle
* Daniel Reimer
* Pierre Schweitzer
* Samuel Serapion
* Olaf Siejka
○ Result:
[19:44] <VoteBot> Question: Please vote for a date for postponing
this meeting.
[19:44] <VoteBot> Answers:
[19:44] <VoteBot> Abstention - 7 votes
[19:44] <VoteBot> 11th August (in 2 weeks) - 3 votes
[19:44] <VoteBot> 25th August (in 4 weeks, regular next meeting) -
6 votes
[19:44] <VoteBot> Total number of votes: 16
○ Main reasons were that the following people were still not present
at the time of voting:
* Aleksey Bragin (supposed meeting leader and key person in the
Arwinss and Release preparation agenda points)
* Amine Khaldi (supposed backup meeting leader and key person in the
CMake agenda point)
* Ged Murphy (key person in the GSoC and Driver Signing agenda
points)
○ Unfortunately, nobody has been prepared for this kind of situation,
so a lot of time has been wasted and confusing decisions might have
been made.
○ Postponing the points also gives Aleksey time to prepare a new
Arwinss build and the Build Environment guys (Daniel, me, anybody
wants to join?) time to prepare a final CMake version of RosBE, which
might be a factor when deciding about doing the migration to CMake.
○ The IRC Server has been closed at 20:03 UTC.
To allow the participants to get an unbiased idea about today's meeting,
I will post the original IRC log by the server to ros-priv. Would
actually like to make it public on ros-dev as well, but will abstain
from doing so until Ged's confusion about the openness of our meetings
is cleared.
If people have already prepared texts for this meeting (status updates,
whatever else you wanted to say), please send them to my E-Mail address
within the next 3 days and I'll compose a summary out of them, which I
will send to ros-dev.
If you think that these texts don't just deserve a simple summary, keep
them for the next meeting or do whatever you want about them.
And finally a personal note: Please keep in mind that it was not an easy
decision for me to just close the IRC Server after I believed that main
discussions were over. If I had left it running, it would have
invalidated the voting (again) and participants would have treated the
meeting even more as a joke. By closing it, I obviously received
complaints from people who had prepared stuff for this meeting and
wanted to revive it.
In good hopes,
Colin
Hello,
Let me invite you to the monthly status meeting taking place last thursday
of this month, 28th of July, 19:00 UTC.
The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the
channel #meeting. Note that the IRC service will only be started shortly
before the meeting. Everyone is invited to listen, and active community
members have their passwords so that they can participate in the discussion.
If someone doesn't have a password - please don't hesitate to email Colin to
get one. Colin - would you publish the most up-to-date list of participants?
Proposed agenda for the meeting:
1. Arwinss adoption voting.
2. CMake status report?. (Do we need to decide anything? If not, then let's
move discussion to the mailing list)
3. Release preparation status report. (Decide when to do winesyncs and
branch off the release)
More suggestions are welcome.
With the best regards,
Aleksey Bragin.
Hi,
Several times now cmake build has been broken. Time for some action!
Last meeting I asked everyone to test/use cmake. It was also mentioned
that if questions arise, we (Amine and me) would be happy to help out. I
can't remember anyone has asked how it works, so I assume noone had any
problems. There's also a pretty good wiki entry describing the whole
procedure for n00bs.
Now people tell me it's complicated, people are complaining that its
ridiculous to have 2 build systems, etc.
And probably noone has ever tried it.
We really need to move on.
I don't like having 2 build systems as well.
Current blocker is the debugging which has some issues, Arty is working
on that. Another problem is a boot problem on real hardware, but no I
don't know on which configuration it doesn't work, so we need more
people testing it on their real hardware setup and report any issues.
Here's a list with current issues:
http://www.reactos.org/wiki/CMake_Todo
So please:
If you are missing something, let us know.
If you like to make it better, make suggestions.
But stop ignoring cmake!
If noone cares and everyone just thinks he can give a s^Z damn until we
officially switch, then we can as well delete all cmake stuff and keep
rbuild. It has a lot of awesome advantages, like you only have to type
one command to build everything and you don't need to install cmake and
you can export whatever you want from kernel32 even if the functions
don't exist. Also you can enjoy the rbuild-loop again and again.
Or we can do it the hard way and delete rbuild, so people are forced to
use cmake. I'm sure this approach would be *really* appreaciated.
Thanks,
Timo