[Gtkradiant] thoughts on Micheal's reply - Re: Gtkradiant Digest, Vol 22, Issue 15

[justin]

namespace wrote:
> I think there are some misunderstandings concerning the definition of a "tester".
> To me a tester does not necessarily know how to code, how to compile radiant or
> how to checkout a revision from svn. In my opinion a tester is "just" a user.
> A user who can give feedback on a new feature or something thats in
> evaluation phase. He can report if the feature works well, if it needs
> workflow-improvements, if it creates strange results with input X and so on.
>   
I agree, but surely we need to include as many contributers as we can.

For my part, I usually post stuff to bugzilla saying "this and this is
broken".  On a couple of occasions I have tracked down the source of the
problem and reported it (model name problem and linux build problems). 
What I would like to know is whether bugzilla is the correct forum for
reporting bugs AND fixes.  Also, I wouldn't mind the occasional "thank
you" for (at least) trying to help.  Just me, I suppose - I like a pat
on the back.

On that note I would like to say "THANK YOU" to SPoG for putting in all
the effort.  If there's any way I can help, you only have to ask.
> If we expect everybody who wants to help radiants development
> to make a checkout from the svn rep, patch the source, compile it and then report
> problems he may have come across, we limit ourselves to a very small group
> of "mappers who also do coding".
>   
True - true.  But we should use every resource at our disposal.  For
example, I use GtkR on Linux.  I'm not an expert in C++ (C, yes, C++,
no) or Windoze but I can generally pinpoint a problem and report back. 
AFAIK there isn't a mechanism for submitting patches - what I've done is
simply email SPoG with what I did to make it work.
> My suggestion tries to open things up by providing an unstable/testing/call it what you want-tree.
> If mappers want to give feedback on the latest development they just download
> the nighlybuild of the unstable tree and report what they did or did not like and where
> they think is room for improvements.
>   
And here, I think, is the problem.  It's not *just* the base tree, but
also the addons and tweaks that can be applied.  Obviously, it would be
impossible to try to maintain them all in the same tree.  Perhaps we
should be looking at two trees (as suggested) but the onus *must* be on
the "addon" tree keeping up with the main trunk - which will totally
ignore any activity in the addon tree.  That way we can still forge
ahead with basic GtkR functionality and not compromise the base tree. 
Naturally, there would be a need to create milestones where the two
coalesce.

  Justin.