On Wed, 7 Jul 2004, Arkady V.Belousov wrote:
Hello,
7-���-2004 19:54 [EMAIL PROTECTED] (tom ehlert) wrote to "Arkady V.Belousov" <[EMAIL PROTECTED]>:
Because I prefer to ask mantainer(s) instead make other fork for another application.te> in an open source world, you SHOULD compile and test yourself.
This is wrong. In "open source world" (unlike "proprietary software") we _may_ compile and test ouselves, but this is not neccesarily, especially if mantainer prefer to keep more tight control on his branch _and_ remain it best.
te> if works - fine, tell the maintainers. this way this is plain noise.
I would say you both have a point:
a) pro Tom: when you (as a maintainer) get plenty of patches, that 1) are not documented (what the patch does, why it is submitted, why to change/add/remove etc) or 2) look "suspicious" (e.g. doesn't even compile, conflicts with the doc by first sign), you have to spent a lot of time to verify the requirement and/or correctness of the patch. When the accompanied doc is present and useable, it's often easier to re-code from the scratch.
b) pro Arkady: the maintainer should control the branch, in order to ensure stability and correctness of the whole branch. And when too many sub-variants of the same project become birth, the project gets down and the man power available for the project is lost by dividing it into too many places - it don't serve much good unless one re-joins the branches again.
Summary: When the maintainer is to ensure correctness of the whole branch, e.g. must decide that a patch does not compromise it or conflicts with other portions of the branch (latter is often not so easy, when you look into the single place the patch is changing), s/he must understand it. And the willing to understand it will for no doubt lower the more time is consumed, the more untrustworthy the patch looks.
So Tom's point, that any submitted patch should (I would actually use MUST, and leave the "have not" variant for very few special cases) at least be tested for correctness, that involves to compile the source and pass some specially made test cases through it, simply means that one
need not spent much time looking at the patch itself, but focusing on
how does it fit into the whole branch.
===
Personally, I would also prefer communicating first, e.g.
a) when a bug is detected and fixed. OK. No further discussion needed.
b) when a feature is implemented, say you want to have SET to get input from the user, it would be nice to ask about it and coordinate the guideline, instead of sending in a patch and to hear that in order to be compatible with XYZ (say CMD.EXE on NT) to prompt the user has to be go this way (say SET /P VAR=prompt string).
c) when code change is sent in, that does not fix obvious bugs or adds required features, it would be nice to communicate before, e.g. I will turn down any pure code size optimization for FreeCOM, because too many stuff gets changed before it reaches a state, in which one should spend time for optimizations without wasting it.
d) there is different feeling about "readable" code. So when code does not fix nothing, does not add required features, why applying it and _possibly_ introduce a new bug? This restraint grows the more unreadable, the more untested a patch looks.
To summarize; I think: + a patch must be tested before submission. + two branches are better than twenty. + one good bugreport is better than ten bad patches.
Bye,
--
Steffen Kaiser
