The discussion is located here:
http://www.reactos.org/archives/public/ros-dev/2005-October/005671.html
I will create a vote with the options below.
Proposal A from Ged Murphy:
/* * ReactOS <place holder> * Copyright (C) 2005 ReactOS Foundation * * LICENCE: <place holder> * PROJECT: <place holder> * FILE: <place holder> * PURPOSE: <place holder> * PROGRAMMERS: <place holder> * REVISIONS: * <place holder> * */
Proposal B from Alex Ionescu:
/* * PROJECT: ReactOS Kernel * LICENSE: GPL - See COPYING in the top level directory * FILE: ntoskrnl/ex/mutant.c * PURPOSE: section of the kernel * PROGRAMMERS: Alex Ionescu (alex at reactos.org) * David Welch (welch at cwcom.net) */
Proposal C from Casper Hornstrup/Gé van Geldorp:
/* * PROJECT: ReactOS Kernel * LICENSE: GPL - See COPYING in the top level directory * COPYRIGHT: Copyright 2004-2005 John Doe * Copyright 2005 Jane Doe */
I've seen a disturbing increase of arguments in ros-dev over the last year on various issues such as this one, and the direction we're heading really has me concerned.
This proposal won't even work for vendor drops, but I'm more concerned with the larger picture.
Every time we have a disagreement, we put up a vote so the group can decide "this is how it's going to be". What I fear is going to happen is the next time someone oversteps something we've voted on, now people have an excuse to publically lampoon that person. This is only going to drive away developers. ReactOS is still a hobby OS. It's an open source project that most of us do because we love the vision of ReactOS and mostly because it's fun and rewarding to make it better.
Today, we're voting the exact allowed format of headers - for which somebody is going to have the excruciatingly boring job of changing all the headers that are non-compliant. What if a year from now we have 30 more developers and enough are dissatisfied with the header and a new vote is taken that changes the format. We're wasting a lot of time and energy over something that really doesn't matter! Who cares what the format of the header is, really? As long as it conveys the necessary copyright information, the rest is fluff. What if someone *wants* or feels the need to put more? Now he's going to be penalized because he added something unofficial to the official header. This is foolishness.
I'll give a good example of what I'm talking about. We've had various heated discussions in the past regarding the subject of code styling. Some have proposed to vote on an official style. I and a couple others have fought vehemently against setting a hard standard. We all use different editors that we're comfortable and most efficient in. And each editor has different weaknesses regarding certain code styles. The most often proposed code style is poorly handled by the editor I use by default, for example.
I think this vote should be cancelled. It has no place in our policies and guidelines. Now, if someone wants to step up and pay me for my time to develop ReactOS, then I'll happily submit to all the coding strictures they feel are necessary. It'd be my place to interject where I think they are wrong, but as a paid employee it wouldn't be my place to ignore or rebel against them. Until that day, we need to keep ReactOS a fun project to work - we've got too much work to do for it to be any other way.
I say it again, I think this vote is wrong, and should be cancelled and rethought.
Peace,
Royce
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Royce Mitchell III Sent: 27. november 2005 18:35 To: ReactOS Development List Subject: Re: [ros-dev] [Vote] Top-level source header
Every time we have a disagreement, we put up a vote so the group can decide "this is how it's going to be". What I fear is going to happen is the next time someone oversteps something we've voted on, now people have an excuse to publically lampoon that person. This is only going to drive away developers. ReactOS is still a hobby OS. It's an open source project that most of us do because we love the vision of ReactOS and mostly because it's fun and rewarding to make it better.
A project rule doesn't give you the right to ridicule people. It merely says "this it the way we do it" until such time that the rule is changed. It's a fact of life that within a group of people there will be disputes, so we need a way to resolve these disputes and currently we have voting to do that. If you know of a more effective method than voting then feel free to share it.
By making project rules we can better avoid the "I'll rewrite it this way because my way is better" class of changes. Without project rules, it is the last one to commit that "wins".
Today, we're voting the exact allowed format of headers - for which somebody is going to have the excruciatingly boring job of changing all the headers that are non-compliant. What if a year from now we have 30 more developers and enough are dissatisfied with the header and a new vote is taken that changes the format. We're wasting a lot of time and energy over something that really doesn't matter! Who cares what the format of the header is, really? As long as it conveys the necessary copyright information, the rest is fluff.
Apparently you do as you just stated that there should be copyright information in the header.
What if someone *wants* or feels the need to put more? Now he's going to be penalized because he added something unofficial to the official header. This is foolishness.
That's what comments are for.
I'll give a good example of what I'm talking about. We've had various heated discussions in the past regarding the subject of code styling. Some have proposed to vote on an official style. I and a couple others have fought vehemently against setting a hard standard. We all use different editors that we're comfortable and most efficient in. And each editor has different weaknesses regarding certain code styles. The most often proposed code style is poorly handled by the editor I use by default, for example.
That you or someone else don't like a change shouldn't prevent someone else from trying to make that change. Which person or persons should decide which changes shouldn't be allowed to be proposed? If you don't like what someone else proposes, then you can use your right to vote to stop that change within the project.
I think this vote should be cancelled. It has no place in our policies and guidelines. Now, if someone wants to step up and pay me for my time to develop ReactOS, then I'll happily submit to all the coding strictures they feel are necessary. It'd be my place to interject where I think they are wrong, but as a paid employee it wouldn't be my place to ignore or rebel against them. Until that day, we need to keep ReactOS a fun project to work - we've got too much work to do for it to be any other way.
I say it again, I think this vote is wrong, and should be cancelled and rethought.
Peace,
Royce
Sorry, I can't do that. Feel free to vote Further Discussion though and/or put up a new vote with a proposal to "let the developer choose/change/remove the contents of the headers at his will".
Casper
Casper Hornstrup wrote:
A project rule doesn't give you the right to ridicule people. It merely says "this it the way we do it" until such time that the rule is changed. It's a fact of life that within a group of people there will be disputes, so we need a way to resolve these disputes and currently we have voting to do that. If you know of a more effective method than voting then feel free to share it.
By making project rules we can better avoid the "I'll rewrite it this way because my way is better" class of changes. Without project rules, it is the last one to commit that "wins".
I don't disagree with this, but as I stated before this is an open source unpaid project, so we should only have so many rules as are strictly necessary. We should take great care about the rules we create. Too many rules - especially frivolous ones, and we'll drive potential developers and even existing developers away.
Apparently you do as you just stated that there should be copyright information in the header.
I stated that copyright information is important. What I did not state was the exact formatting. I'll give the benefit of the doubt that you're not intending the exact indentation and order of parameters to be specified by the vote, but that's not made clear.
Furthermore, this vote seems to have started in part because you complained that a header copied from another file didn't get updated properly. I can only assume that means you intend to have removed parts of the headers that are in excess of the agreed-upon header in the vote.
That's what comments are for.
As I just stated, you were complaining about comments in the header about the name of the file that you felt shouldn't be there. Where do we draw this line of what's an allowed comment?
That you or someone else don't like a change shouldn't prevent someone else from trying to make that change. Which person or persons should decide which changes shouldn't be allowed to be proposed? If you don't like what someone else proposes, then you can use your right to vote to stop that change within the project.
Even this is a gray area, because if someone is making changes to an area nobody else wants to touch... well... maybe I don't like it, but if I'm not willing to fix a perceived problem but someone else is, then how much right do I have to complain.... it's like the story of the little red hen: nobody wanted to help her bake the bread, but they all wanted to eat it. All I'm saying is that we should try to limit our complaints about other people's changes just because we don't "like" them. We're never going to all agree completely on how things should be done. We need to agree to disagree and only invoke this kind of policy-setting when it's really important. I think at a minimum we need to more carefully word the proposals for the top-level source header issue here - in order to solve the problem without unnecessarily constraining freedom to develop in each of our own styles.
Sorry, I can't do that. Feel free to vote Further Discussion though and/or put up a new vote with a proposal to "let the developer choose/change/remove the contents of the headers at his will".
I went ahead and selected further discussion, as it seems the most prudent way to pursue my feelings on the issue. If not enough people feel as I do, there's no point wasting effort creating another vote.
Thanks!
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Royce Mitchell III Sent: 27. november 2005 20:02 To: ReactOS Development List Subject: Re: [ros-dev] [Vote] Top-level source header
Casper Hornstrup wrote:
By making project rules we can better avoid the "I'll rewrite it this way because my way is better" class of changes. Without project rules, it is the last one to commit that "wins".
I don't disagree with this, but as I stated before this is an open source unpaid project, so we should only have so many rules as are strictly necessary. We should take great care about the rules we create.
I agree, but I trust people to use their best judgement. If 90% vote for something which I think is crazy, who am I to say this shouldn't be how the project will do it?
Too many rules - especially frivolous ones, and we'll drive potential developers and even existing developers away.
I could say the same about too few rules. Remember that what one person does, affects the other persons on the project. I suppose I would like ReactOS to be somewhere on the middle of this line.
No rules Many rules <-----------------------------------------------------------> Chaos/inconsistency order/consistency
E.g. having order/consistency where is helps the group function well and help the group create a better product. I know ReactOS is about having fun, but I don't think that not being able to do whatever you feel like with regard to the project implies no fun. Certainly being in the chaos/inconsistency state (we've been there) won't create a happy team. I remember times when ReactOS often couldn't be built or booted for weeks at a time. In the early days, I just spent my time elsewhere when that happened. ReactOS wasn't useful anyway.
I recently joined a 15 person team who were working on some project. This project was close to the no rules/chaos end of that line. Of course the project was more than 100% over budget and half of the team worked 60-70 hours/week for two months. They were of course unhappy about that, but they really wanted to have this product ready for their customer. Nobody likes to fail. For those of you who are interested in numbers, that is a burn-rate of approx. 700 hours/week. I'll leave it as an exercise to the reader to calculate their salary per week ;-) Hint: additional hours over 37 hours/week pays 100% extra.
I see similarity in the ReactOS project. I see many desperately waiting for that 1.0 release. Now since nobody is paid to work on ReactOS, the project can't go 100% over budget. We can however spend twice or more as many hours getting there, depending on how we choose to develop ReactOS. So instead of reaching 1.0 in 2010 we have to wait until 2022. I'm not a patient person.
Furthermore, this vote seems to have started in part because you complained that a header copied from another file didn't get updated properly. I can only assume that means you intend to have removed parts of the headers that are in excess of the agreed-upon header in the vote.
Well, the voting is about what the standard should be (e.g. for new files). It doesn't specify anything about what to do with the existing headers. They could be replaced over time for instance.
That's what comments are for.
As I just stated, you were complaining about comments in the header about the name of the file that you felt shouldn't be there. Where do we draw this line of what's an allowed comment?
I argumented that the contents of the FILE fields in the headers tend to become wrong and thus useless over time. I can point you to at least four new files added this week for which this is true. I can point you to another set of files where the PURPOSE and PROGRAMMER fields states "Unknown" just because "something should be there". The vote is about how the header should look like and there were three suggestions. We have no rules for comments so you can put anything you feel like in a comment below the header. If you put the name of the file in a comment in the file, then fine. I will however still argument that they become wrong over time.
That you or someone else don't like a change shouldn't prevent someone else from trying to make that change. Which person or persons should decide which changes shouldn't be allowed to be proposed? If you don't like what someone else proposes, then you can use your right to vote to stop that change within the project.
Even this is a gray area, because if someone is making changes to an area nobody else wants to touch... well... maybe I don't like it, but if I'm not willing to fix a perceived problem but someone else is, then how much right do I have to complain.... it's like the story of the little red hen: nobody wanted to help her bake the bread, but they all wanted to eat it. All I'm saying is that we should try to limit our complaints about other people's changes just because we don't "like" them. We're never going to all agree completely on how things should be done. We need to agree to disagree and only invoke this kind of policy-setting when it's really important. I think at a minimum we need to more carefully word the proposals for the top-level source header issue here
- in order to solve the problem without unnecessarily constraining
freedom to develop in each of our own styles.
He has every right. If not, who decides that he hasn't the right? He may not have good reasons to complain, and may just be annoying to other people, but that's another issue.
Casper
Hi,
On 11/27/05, Casper Hornstrup ch@csh-consult.dk wrote:
Well, the voting is about what the standard should be (e.g. for new files). It doesn't specify anything about what to do with the existing headers. They could be replaced over time for instance.
This is fine with me. I will be voting for C. Once we have a standard I am sure we can find some Janitor that would love to help out by standardising the source headers for all of the ReactOS code. As long as this would not effect code we regularly import from other projects its fine with me. Adding this to the code we have already forked and or will not be trying to re-sync with seems like a good idea. However we should not replace the existing license header in any third party code we fork, we should append our header if we make major additions.
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Hmm, can't we put the license in a svn property, too? The project should be clear from the directory it is, and the copyright should be clear from the SVN-History, if not, e.g. imports/vendor drops from another projects, we could add a COPYRIGHT-file in these directories.
So we wouldn't need a header at all... Or the header could be autogenerated on commit or on a checkout...
I would vote for d (further discussion), too.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Royce Mitchell III Sent: 27. november 2005 20:02 To: ReactOS Development List Subject: Re: [ros-dev] [Vote] Top-level source header
Casper Hornstrup wrote:
By making project rules we can better avoid the "I'll rewrite it this
way
because my way is better" class of changes. Without project rules, it
is
the last one to commit that "wins".
I don't disagree with this, but as I stated before this is an open source unpaid project, so we should only have so many rules as are strictly necessary. We should take great care about the rules we create.
I agree, but I trust people to use their best judgement. If 90% vote for something which I think is crazy, who am I to say this shouldn't be how the project will do it?
Too many rules - especially frivolous ones, and we'll drive potential developers and even existing developers away.
I could say the same about too few rules. Remember that what one person does, affects the other persons on the project. I suppose I would like ReactOS to be somewhere on the middle of this line.
No rules Many rules <-----------------------------------------------------------> Chaos/inconsistency order/consistency
E.g. having order/consistency where is helps the group function well and help the group create a better product. I know ReactOS is about having fun, but I don't think that not being able to do whatever you feel like with regard to the project implies no fun. Certainly being in the chaos/inconsistency state (we've been there) won't create a happy team. I remember times when ReactOS often couldn't be built or booted for weeks at a time. In the early days, I just spent my time elsewhere when that happened. ReactOS wasn't useful anyway.
I recently joined a 15 person team who were working on some project. This project was close to the no rules/chaos end of that line. Of course the project was more than 100% over budget and half of the team worked 60-70 hours/week for two months. They were of course unhappy about that, but they really wanted to have this product ready for their customer. Nobody likes to fail. For those of you who are interested in numbers, that is a burn-rate of approx. 700 hours/week. I'll leave it as an exercise to the reader to calculate their salary per week ;-) Hint: additional hours over 37 hours/week pays 100% extra.
I see similarity in the ReactOS project. I see many desperately waiting for that 1.0 release. Now since nobody is paid to work on ReactOS, the project can't go 100% over budget. We can however spend twice or more as many hours getting there, depending on how we choose to develop ReactOS. So instead of reaching 1.0 in 2010 we have to wait until 2022. I'm not a patient person.
Furthermore, this vote seems to have started in part because you complained that a header copied from another file didn't get updated properly. I can only assume that means you intend to have removed parts of the headers that are in excess of the agreed-upon header in the vote.
Well, the voting is about what the standard should be (e.g. for new files). It doesn't specify anything about what to do with the existing headers. They could be replaced over time for instance.
That's what comments are for.
As I just stated, you were complaining about comments in the header about the name of the file that you felt shouldn't be there. Where do we draw this line of what's an allowed comment?
I argumented that the contents of the FILE fields in the headers tend to become wrong and thus useless over time. I can point you to at least four new files added this week for which this is true. I can point you to another set of files where the PURPOSE and PROGRAMMER fields states "Unknown" just because "something should be there". The vote is about how the header should look like and there were three suggestions. We have no rules for comments so you can put anything you feel like in a comment below the header. If you put the name of the file in a comment in the file, then fine. I will however still argument that they become wrong over time.
That you or someone else don't like a change shouldn't prevent someone else from trying to make that change. Which person or persons should decide which changes shouldn't be allowed to be proposed? If you don't like what someone else proposes, then you can use your right to vote to stop that change within the project.
Even this is a gray area, because if someone is making changes to an area nobody else wants to touch... well... maybe I don't like it, but if I'm not willing to fix a perceived problem but someone else is, then how much right do I have to complain.... it's like the story of the little red hen: nobody wanted to help her bake the bread, but they all wanted to eat it. All I'm saying is that we should try to limit our complaints about other people's changes just because we don't "like" them. We're never going to all agree completely on how things should be done. We need to agree to disagree and only invoke this kind of policy-setting when it's really important. I think at a minimum we need to more carefully word the proposals for the top-level source header issue here
- in order to solve the problem without unnecessarily constraining
freedom to develop in each of our own styles.
He has every right. If not, who decides that he hasn't the right? He may not have good reasons to complain, and may just be annoying to other people, but that's another issue.
Casper
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Seeing some of the comments in this thread, I think it might be wise to have rules/standards for stuff that really matter and classify the rest as something like recommendations. In the end, if you don't have 100% agreement on how something should be done (including when new people join the dev team) it won't get done that way all of the time - and even with 100% agreement, I would bet things like this get ignored any time someone is in a hurry. I've been watching the current commercial project I'm working on bypass the way stuff is supposed to be done time and time again just to get things done faster. And in the end, it only gets fixed if it's going to save time in the future and/or it really annoys one of the developers.
Dennis
Frank, you'll need to unsubscribe from the mailing list, to not receieve messages.
On 11/30/05, frank.marx@t-online.de frank.marx@t-online.de wrote:
Please dont send me further emails !
Frank Marx
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- "I had a handle on life, but then it broke"
Casper Hornstrup wrote:
The discussion is located here:
http://www.reactos.org/archives/public/ros-dev/2005-October/005671.html
The voting period is now over. Proposal B from Alex Ionescu is the winner:
Proposal B from Alex Ionescu:
/* * PROJECT: ReactOS Kernel * LICENSE: GPL - See COPYING in the top level directory * FILE: ntoskrnl/ex/mutant.c * PURPOSE: Manages the Kernel-Mode Implementation of Fast Mutex. * See /hal/halx86/generic/fmutex.c for the HAL implementation. * PROGRAMMERS: Alex Ionescu (alex@reactos.org) * Filip Navara (navaraf@reactos.org) */
Best regards, Alex Ionescu
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: 5. december 2005 19:45 To: ReactOS Development List Subject: Re: [ros-dev] [Vote] Top-level source header
The voting period is now over. Proposal B from Alex Ionescu is the winner:
Proposal B from Alex Ionescu:
/*
- PROJECT: ReactOS Kernel
- LICENSE: GPL - See COPYING in the top level directory
- FILE: ntoskrnl/ex/mutant.c
- PURPOSE: Manages the Kernel-Mode Implementation of Fast Mutex.
See /hal/halx86/generic/fmutex.c for the HAL implementation.- PROGRAMMERS: Alex Ionescu (alex@reactos.org)
Filip Navara (navaraf@reactos.org)*/
Best regards, Alex Ionescu
Documented here: http://www.reactos.org/wiki/index.php/Voting/Top-level_source_header
Casper
From: Alex Ionescu
The voting period is now over. Proposal B from Alex Ionescu is the winner:
/*
- PROJECT: ReactOS Kernel
- LICENSE: GPL - See COPYING in the top level directory
- FILE: ntoskrnl/ex/mutant.c
- PURPOSE: Manages the Kernel-Mode Implementation of Fast Mutex.
See /hal/halx86/generic/fmutex.c for the HAL
implementation.
- PROGRAMMERS: Alex Ionescu (alex@reactos.org)
Filip Navara (navaraf@reactos.org)*/
Sorry to keep on rambling about this, I know the vote is over and of course I accept the outcome, but the simple fact is that this header does not contain valid copyright notices. It lists the license (telling you what the copyright holders allow you to do with the work), it lists the programmers (who most probably are the copyright holders) but it does not contain valid copyright notices, which (according to the US Copyright Office http://www.copyright.gov/circs/circ1.html#noc) should have the following form:
[begin quote] The notice for visually perceptible copies should contain all the following three elements:
1. The symbol C (the letter C in a circle), or the word "Copyright," or the abbreviation "Copr."; and
2. The year of first publication of the work. In the case of compilations or derivative works incorporating previously published material, the year date of first publication of the compilation or derivative work is sufficient. The year date may be omitted where a pictorial, graphic, or sculptural work, with accompanying textual matter, if any, is reproduced in or on greeting cards, postcards, stationery, jewelry, dolls, toys, or any useful article; and
3. The name of the owner of copyright in the work, or an abbreviation by which the name can be recognized, or a generally known alternative designation of the owner. [end quote]
So in our case something like
/* * COPYRIGHT: Copyright 2005 Alex Ionescu (alex@reactos.org) * Copyright 2005 Filip Navara (navaraf@reactos.org) */
The GPL says you can't remove an appropriate copyright notice, it says nothing about not removing a PROGRAMMERS line. It would be very rude to remove a PROGRAMMERS line, but not against the GPL.
GvG
Hi, Ge van Geldorp wrote:
So in our case something like
/*
- COPYRIGHT: Copyright 2005 Alex Ionescu (alex@reactos.org)
Copyright 2005 Filip Navara (navaraf@reactos.org)*/
The GPL says you can't remove an appropriate copyright notice, it says nothing about not removing a PROGRAMMERS line. It would be very rude to remove a PROGRAMMERS line, but not against the GPL.
GvG
In this case I will and the other developers will have to put a copyright in every file! Thanks, James
James Tabor wrote:
In this case I will and the other developers will have to put a copyright in every file! Thanks, James
What's wrong with that? Considering the amount of work that has gone into this project, the code should be correctly copyrighted.
I think the copyright line for the source files of ReactOS should go somthing like this:
Copyright (C) 2005 ReactOS Delopement Team Parts Copyright (C) 2005 ReactOS Foundation
Then list contibuters somewhere else.
On 12/9/05, Ged Murphy gedmurphy@gmail.com wrote:
James Tabor wrote:
In this case I will and the other developers will have to put a copyright in every file! Thanks, James
What's wrong with that? Considering the amount of work that has gone into this project, the code should be correctly copyrighted.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- My DeviantArt.com page: http://crashfourit.deviantart.com/ My FanFiction.net bio page: http://www.fanfiction.net/u/726606/ My Blog: http://crashfourit.blogspot.com/ America's Debate: http://www.americasdebate.com/
From: crashfourit
I think the copyright line for the source files of ReactOS should go
somthing like this:
Copyright (C) 2005 ReactOS Delopement Team Parts Copyright (C) 2005 ReactOS Foundation
Then list contibuters somewhere else.
We've been over this before. The developers individually hold the copyright, not the ReactOS foundation (and "ReactOS Development Team" isn't a legal entity). So the individual developers claiming copyright must be named.
GvG
ReactOS Development Team isn't a legal entity and ReactOS Foundation don't get copyright until the copyright holder signs over the copyright to the foundation.
Casper
_____
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of crashfourit Sent: 9. december 2005 20:40 To: ReactOS Development List Subject: Re: [ros-dev] Top-level source header
I think the copyright line for the source files of ReactOS should go somthing like this:
Copyright (C) 2005 ReactOS Delopement Team
Parts Copyright (C) 2005 ReactOS Foundation
Then list contibuters somewhere else.
On 12/9/05, Ged Murphy gedmurphy@gmail.com wrote:
James Tabor wrote:
In this case I will and the other developers will have to put a copyright in every file! Thanks, James
What's wrong with that? Considering the amount of work that has gone into this project, the code should be correctly copyrighted.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Alex Ionescu -
Casper Hornstrup -
crashfourit -
Dennis - Guardian -
frank.marx＠t-online.de -
Ge van Geldorp -
Ged Murphy -
James Tabor -
michael＠fritscher.net -
Royce Mitchell III -
Steven Edwards -
TwoTailedFox