imm wrote:
> On 29 May 2007, at 18:55, matthiasm wrote:
>> On May 29, 2007, at 5:26 PM, MacArthur, Ian ((SELEX)) ((UK)) wrote:
>>> In practice, no one really sets priorities in open source projects -
>>> when the workers are volunteers, you can't tell them which bits to
>>> fix...
>> I believe it worked pretty well even without hierarchy. I can tell
>> you though that only fixing bugs form 1.1.7 to 1.1.8 and not adding
>> any features is quite nerve wrecking.
Yes, I think opening things up to 1.2.0 will let it grow again.
> I think it has worked very well. And I think that the quality of the
> code is generally enhanced by allowing "natural evolution" rather
> than by trying to enforce a specific agenda. People do a better job
> on the things they really need...
Yes, just about all open source works this way.. Linux being
the biggest. I disagree with the 'anarchy=bad' sentiments..
it has gotten us this far, as well as all software. It's not
anarchy so much as it is 'work to a common goal'. Also the
core programmers tend to be pretty well organized here, so
it's not like there's no organization and communication..
it's not 'everyone for himself', but more like 'everyone
for the common good'.
Enough of that; the dynamics of open source is well known
by most everyone here.
> Also, if we are going to break the 1.1 ABI, do we want to re-name
> some of the more inaccurately named functions and methods whilst we
> are at it?
Assuming we keep the old calls, and just mark them deprecated
in the docs, and refer to the newer functions, that's a solution.
This way old code will still compile.
My approach in my docs is to put <STRIKE> around commands
that are deprecated, but keep the docs so that people having
to read old code can still figure out what it does.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
