Hi all,
A first release candidate of RosBE-Unix 2.0 is now available on
http://svn.reactos.org/RosBE-Temp/. Compared to 1.5, it finally includes
CMake 2.8.5 (with Jerome's patches), an updated GNU Make and new GMP and
MPFR libraries. For the latter ones, I've added a patch to fix building
under Mac OS X 10.7.
Please try it out and tell me about your results. If there's anything
that needs to be fixed before the release, please tell me in a reply to
this mail.
For the reference, the current CMake building commands in a ReactOS
checkout are as follows:
- ./configure.sh
- cd output-i386-MinGW/host-tools
- makex
- cd ../reactos
- makex bootcd
I'll also set up this Build Environment on the Debug Buildslave as soon
as possible.
Happy building,
Colin
Hi,
at present I work for mid-sized company for ticketing, parking and mobile
solutions in Germany (and Great Britain). I personally work in a project for
railway services (using gsm-r network). To understand the tools given below I
want to figure out our target and environment in short. We develop for
embedded Linux systems with ARM-CPU and Qt-Framework. Therefore C++ was and
is used as programming language.
Apart from he usual tools like
- make-alike build tools (written in perl - a project specific one)
- regular make files for some special targets
- SVN for source code management
we use some interesting tools to keep the source readable and to preserve a
minimum of source quality automatically (bear in mind we use C++ instead of
C, for our purpose we need to alter some tools for our needs):
- Hudson for automatic build and checking the source (see below)
- cpplint.py (by Google) for some checking the source
- cppcheck for another check of the source
- doxygen for checking the missing documentation (in that special case check
only by tricky configuration instead of costly generating all documentation
files)
- format the source code (after agreement of all devs) in a uniform style with
astyle before commit (for ReactOS better as commit hook)
- finally we gather all check results in one table and mark the results for
hudson as stable (if no errors), failed (in case of any errors), unstable (in
case of some low-prio warnings)
Maybe we can think about some of them, because even if some problems of
development remains, it might give us some edge and may also attract some
devs. I don't make any suggestions, but I want to tell you how others work.
Matthias
PS: We are the first project in the company going that way and other project
groups would like to adapt the way, because they see the benefit for
their/other/future projects.
--
Matthias Kupfer phone +49 371 236 46 52
Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54
09122 Chemnitz, Germany
Hi,
due to a HDD failure in one of our major servers, you've been
encountering services interruptions (mail, svn, web, mainly) this
afternoon and tonight. The issue has been successfully addressed right
now, and the server is back online with its new hard-drive.
Regards,
The ReactOS sysadmins.
Hi,
this is a reminder about the Status meeting, which is to happen
tomorrow, 29th of September at 19:00 UTC. Please don't miss it. The
meeting is declared private. I will lead the meeting, as usual.
Proposed agenda for the meeting:
1. CMake adoption progress.
2. Release preparation status report, deciding on the release date.
3. Webportal upgrade plans.
4. ReactOS target version: strict sticking to it or hybrid.
List of participants:
- Giannis Adamopoulos (smiley1_)
- Johannes Anderwald (janderwald)
- Javier Agustìn Fernàndez Arroyo (elhoir)
- Maciej Bialas (niski)
- Jan Blomqvist-Kinander (JaixBly)
- Aleksey Bragin (abragin)
- Thomas Faber (ThFabba)
- Colin Finck (Colin_Finck)
- Jérôme Gardou (zefklop)
- Danny Götte (dangerground)
- Cameron Gutman (aicom)
- Ziliang Guo (ZWabbit)
- Rafal Harabien (rafalh)
- Andrew Hill (ash77)
- Kamil Hornicek (Pigglesworth)
- Gabriel Ilardi (gabriel_it)
- Alex Ionescu (Alex_Ionescu)
- Amine Khaldi (AmineKhaldi)
- Igor Koshpaev (tower)
- Timo Kreuzer (tkreuzer)
- Matthias Kupfer (Collibri)
- Michael Martin (mjmartin)
- Victor Martinez (vicmarcal)
- Roel Messiant (Mephisto)
- Claudiu Mihail (KlausM)
- Andrew Munger (WaxDragon)
- Ged Murphy (GedMurphy)
- Igor Paliychuk (igorko)
- Sylvain Petreolle (Usurp)
- Hervé Poussineau (hpoussin)
- Daniel Reimer (dreimer)
- Pierre Schweitzer (HeisSpiter)
- Samuel Serapion (encoded)
- Olaf Siejka (Caemyr)
- James Tabor (jimtabor)
- Christoph von Wittich (Christoph_vW)
- Art Yerkes (arty)
WBR,
Aleksey Bragin.
FYI:
This is Linus' interview. http://h30565.www3.hp.com/t5/Feature-
Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/
ba-p/440
He very correctly outlines many things. One of the most important:
"The other thing—and it's kind of related—that people seem to get
wrong is to think that the code they write is what matters. No, even
if you wrote 100% of the code, and even if you are the best
programmer in the world and will never need any help with the project
at all, the thing that really matters is the users of the code. The
code itself is unimportant; the project is only as useful as people
actually find it.”
And this:
"Way too many projects seem to think that the code is more important
than the user, and they break things left and right, and they don't
apologize for it, because they feel that they are ‘fixing’ the code
and doing the right thing.”
WBR,
Aleksey Bragin.
Hi all,
Just for your information, I have enabled ACPI for the KVM machine used
by the Linux Testslave today.
For reference, the full VM configuration is like this:
* QEMU/KVM-based i686 ACPI machine
* 256MB of RAM
* 512MB HDD on IDE Primary Master
* ReactOS ISO on IDE Secondary Master
* AMD PCNet-compatible Network Adapter
* COM1 port redirected to a virtual Linux terminal device
* PS/2 mouse
* Tablet pointing device on USB
Usually useful if any KVM machine is controlled over VNC, but probably
not relevant for ReactOS yet.
As you see, there is no virtual sound card (disabled as of 2011-06-07
due to r52098 according to my notes). Is this still correct?
- Colin
Wont be that usual. Happened twice today, still broken atm. I`m not a dev, hence i have no idea how the devs commit stuff works and all the problems you guys have to overcome...
I suppose it is too difficult for you simply to visit http://build.reactos.org/waterfall and just check if its all green (yes, no need to check stdio, just noticing the color). Your time is probably too precious to wait up to 5 bloody minutes, to see if previous build was ok...
I`m not even talking about runtime regressions. Its understandable, that 45 minutes is often too much to wait, but 5??
I`m not even talking about patchbot, why should I? Already did, already tried, to no effect.
If you really care about ROS, then by commiting on a broken trunk, you are practically shooting yourself in your foot. Trunk will be most likely not fixed until several other commits, sometimes a day or so. ISO will not be build. Commits will not be tested, neither by automation, nor by community, bugs will not be reported and regressions will only be found in more distant future. Then, you will ask for regtesting.
You should better start doing it yourself, because you guys too often are not doing even the simplest things to keep trunk clean and working, making development harder for everyone around!
--
With best regards
Caemyr