Allow me to present a small sub-project Gabriel and I are working on. We did
a small scale consulting, but its the time to present it on a more wider
scale.
As a comment, specifically to Timo's post: 2nd class tags should not be
conflicting with Component field when possible. In case of Kernel and
win32k, a submodule should be used instead of module name: for example in
case of kernel bugs, Components should be set to Kernel, whereas 2nd class
tag should be pointing to kernel submodule, like iomgr:, ob:, mm: etc.
All opinions are most welcome
Best regards
Hi
I'd like to propose an overhaul of our bugzilla interface. The reason is
that the current interface is ugly and confusing and I think we can make
filing and handling bugs less unenjoyable ;-)
First I think it would be very useful, if we could edit the description
field of the bugs. This way we don't need to browse through dozens of
comments to find all neccessary info, while the description only
contains useless stuff. This should be restricted to the original
reporter and testers / developers.
Then when filing a new bug or looking at a bug that is already filed,
the layout is horrible. I'm not a webdesigner, so it's hard for me to
say how it should look like, but definately not the way it is. This
might be appropriate for projects whose website look like
http://www.gnu.org/software/binutils/ but I'm sure, we can do better.
Then when filing a bug there are the following fields:
- reporter - I know who I am, so why show it to me? Unneccessary
- Component: I don't think this field is really useful as it is. First:
Patches are definately not a component. Then it's often hard to tell
where the bug is. for example, if rapps doesn't download anything, is
that related to network or is it a kernel bug or win32 or rapps or is
only the server down? You often don't know it when filing a bug. Also
win32 covers a lot from win32k to shell32, but are these more closely
related than drivers and networking?
- Severity: while I think this field is useful and important, it should
only be editable by testers and developers and should not appear when a
bug is filed.
- Platform: should be removed
- OS: should be removed
- AssignTo, Cc: rarely used on first filing, should IMO only be editable
by testers / developers
- URL: While we use this field from time to time, I think the URL could
as well, if neccessary be put into the description field (provided, it
was editable). This versatile field should imo change it's purpose from
URL to TAG. So we can add different tags, like REGRESSION, PATCH, HACK,
that are currently put into the summery field. It could also contain the
regression range or guilty version
- Alias: we don't use this, or rather currently only misuse this for the
guilty version, which is problematic, as soon as 2 bugs have the same
guilty version, IMO unneccessary
- Summery: should be as wide as the description field
- Description: To get better bugreports, I suggest dividing this field
into "Steps to reproduce:" "Experienced behaviour:" "Remarks"
These fields can very well be automatically merged into one field, It's
just to show people that they must provide steps to reproduce, instead
of writing dozens of lines about their hardware configuration and how
they feel about the bug.
Regards,
Timo
Hello,
Many thanks for fixing this idiotic oversight of mine. I apologies for the long hours of debugging I must have caused.
This fix is somewhat incomplete/at the wrong place; could this be marked as such in the code, perhaps with a FIXME under my name, so that I may fix this correctly upon my return to the US?
Much obliged!
-r
Author: mjmartin
Date: Sat Aug 28 00:26:02 2010
New Revision: 48632
URL: http://svn.reactos.org/svn/reactos?rev=48632&view=rev
Log:
[ntoskrnl/ps]
- When deleting a Process remove the Process from the MmProcessList. Fixes random NonPaged Pool corruptions. Thanks aicom for assistance.
Modified:
trunk/reactos/ntoskrnl/ps/kill.c
Modified: trunk/reactos/ntoskrnl/ps/kill.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/kill.c?rev=486…
==============================================================================
--- trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] Sat Aug 28 00:26:02 2010
@@ -300,6 +300,8 @@
/* Detach */
KeUnstackDetachProcess(&ApcState);
+
+ RemoveEntryList(&Process->MmProcessLinks);
/* Completely delete the Address Space */
MmDeleteProcessAddressSpace(Process);
I ran into this on Fedora 13,
[HOST-CC] tools/cabman/cabinet.cxx
tools/cabman/cabinet.cxx: In member function ‘bool
CCabinet::CreateSimpleCabinet()’:
tools/cabman/cabinet.cxx:2177: error: no matching function for call to
‘stat::stat(char [260], stat*)’
/usr/include/bits/stat.h:40: note: candidates are: stat::stat()
/usr/include/bits/stat.h:40: note: stat::stat(const stat&)
from http://code.google.com/p/libproxy/issues/detail?id=122 the patch
is based on this;
http://code.google.com/p/libproxy/issues/attachmentText?id=122&aid=20023750…
Index: tools/cabman/cabinet.cxx
===================================================================
--- tools/cabman/cabinet.cxx (revision 48297)
+++ tools/cabman/cabinet.cxx (working copy)
@@ -21,7 +21,8 @@
#if !defined(WIN32)
# include <dirent.h>
#endif
-#if defined(__FreeBSD__) || defined(__APPLE__)
+#if !defined(WIN32) || defined(__FreeBSD__) || defined(__APPLE__)
+# include <sys/types.h>
# include <sys/stat.h>
#endif // __FreeBSD__
#include "cabinet.h"
Not sure this is right, so~ posted here for fast review and fix,
James
akhaldi(a)svn.reactos.org wrote:
> +++ branches/cmake-bringup/base/applications/calc/CMakeLists.txt
> [...]
>
> +file(GLOB_RECURSE SOURCE *.c)
> +list(REMOVE_ITEM SOURCE
> + ${CMAKE_CURRENT_SOURCE_DIR}/fun_mpfr.c
> + ${CMAKE_CURRENT_SOURCE_DIR}/rpn_mpfr.c
> + ${CMAKE_CURRENT_SOURCE_DIR}/utl_mpfr.c)
Should GLOB_RECURSE and later removing unwanted source files really be
the way to go?
The only advantage I see are smaller CMakeLists files.
On the contrary, it is quite an uncommon way and just adding a single
unrelated file into an application's directory could render it unbuildable.
Additionally, please take a look at
http://public.kitware.com/pipermail/cmake/2010-July/037833.html.
According to this user, CMake cannot automatically detect added files
when using GLOB_RECURSE.
In my opinion, we should list every source file to be included to
prevent unexpected side effects.
Cheers,
Colin
Hi everybody,
Looking at
http://www.reactos.org/pipermail/ros-diffs/2010-August/038197.html and
the same message in Thunderbird, I now see a need to automatically
truncate all subject lines in ros-diffs' mails to 200 characters. I
don't think that anybody reads the full commit messages through subject
lines, so 200 characters should be enough to identify a commit easily.
If there are no objections, I'll try to change this in the next few days.
Cheers,
Colin
Hello everyone!
In the latest 6 months, Niski and I have been working on a testing ground/proof of concept of a ReactOS community site, currently called the ReactOS Portal.
The idea of a ReactOS community site has been floating around for years due to the fact that our followers (Users and Non-Users) keep expecting more info and more features.
For this purpose, and having in mind that a ReactOS community site needs to focus on the followers' needs, we've created a light, eyecandy, easy to maintain Drupal-based site, to serve as a testing ground, and also as a proof of concept for the ReactOS Community idea.
Despite the fact that the community site is mainly targeted towards the project followers, we didn't forget our developers and official testers needs. We've already included some (hopefully) useful features, and we welcome ideas and suggestions.
The community site is made for everyone, by everyone.
To avoid quite a lengthy email, we'll enumerate the Top Features we've added. We've also prepared a PDF and a Video, that you can download from this URL:
http://download.myreactos.com/?dir=Vicmarcal )
************ALL+IN+1***********
All the info in ONE click (latest blog posts, forum replies, commits, ML posts and wiki activity)
******Multiblogging System*****
Several blogs, managed from just one Blogging System. Easy to post and maintain.
***********IRC-CHAT************
An integrated IRC client for the ReactOS communiy.
*********Contact Page**********
Redesigned, full of info.
**************FAQ*************
A much more user oriented FAQ with new Tester and Translator sections.
************RosKarma***********
A new forum module : "More Karma an User has, more reliable he is" and a new Autobanning System : "Bye,bye Trolls".
*********Answered Post*********
Another new forum module : Answered topics turn Green(easy to spot) and get locked ("No more Necromancy").
***********Rosquests***********
Another new Forum module : "Use Forum Users skills for ReactOS project".
How? Read the PDF or watch the video for more details.
**********MultivideoBox********
"An image is worth than thousand words".
Videotutorials, ReactOS presentations... and much more.
*******Social Networking*******
"Facebook, Vimeo, Youtube, and Tweeter integration".
And after getting some feedback we've added more features :
***Unlimited/Free FTP account***
Now Official Developers/Testers can have FTP accounts to easily and conveniently share ReactOS ISOs (or any other files).
We're also considering integrating the Software Compatibility Database into the Portal.
We hope you like it, your feedback is very important, so that we can create a comfortable, highly efficient Community Site.
More info in the Video+PDF: http://download.myreactos.com/?dir=Vicmarcal
Thanks to all the ReactOS members that are joining, posting and translating. Thanks to everyone involved ;)
Victor Martinez Calvo
Maciej Bialas
www.myreactos.com