On 2010-10-22 14:02, Aleksa Todorovic wrote:
2010/10/22 Adem<listmem...@letterboxes.org>:
Let me answer as someone who wrote several patches, and only one or
two of them were accepted.
I do appreciate you responding to these questions, but I would also like
to hear Florian's comments for his stance (whether he likes it or not)
represents a different category of multiplier.
Suppose you're the one wanting to do that work.
First, how would you prove you're worthy of the task?
Firstly, you need to understand how FPC development works, and to
accept that. Secondly, you need to show other FPC developers that you
are willing to work (continuous task) and work as part of team.
You're of course right --a team can only be a team if its members work
in sufficient unison.
But.. and there's always a 'but'..
These things usually work give'n'take fashion.
I mean, a certain amount of flexibility is required from the team too;
or else it risks becoming a cult sort of thing.
I am trying to point at being accomodating..
Second, could you really do it in small steps?
If you really want it - yes.
There's, I am sure you'll agree, a limit to 'really wanting it'.
Third, how would you feel if the /masters/ kept referring to your efforts as
'half-baked'?
How would you feel if someone came and change lot of your code? Would
you just blindly accept those changes?
Of course not. Nobody expects anyone to do that.
But, a litlle 'thank you' would go a long way --even if you don't mean it.
Fourth, how would you react if your attempts are belittled on the grounds of
them not being comliant with coding style --of all things?
I would give more importance to coding style. Personally, I change
coding style every few months, for two reasons: first, I adopt coding
style of the code I use (engines, libraries, ...), and second, I
respect my co-worker's coding style (unless it is horrible in which
case I talk to them about it).
Personally, I am far less flexible about coding style than you are. The
moment I start looking at a piece of code, I want it to be formatted the
way I am accustomed to. I suspect a great majority of Pascal people are
like that too.
While using Delphi, DelForEx did everything I wanted and was faster than
I needed.
In FPC/Lazarus world, we have JCF.
Which is sort of fine, but it is slow to begin with.
And worse, it has no guarantee to format all FPC/Lazarus code.
When it fails, it gives me fits --derails all my train of thought.
The thing is, I am (was) quite familiar with JCF [I was laterally
involved in its development], and it's not its fault that it fails at
some code. It needs to be updated.
It's true problem is speed: basically JCF needs to be re-written.
I suppose I could do it, but most of it would be a waste of time since
the stuff it needs is already (somewhere) in FPC is always up-to-date.
My aim was to come up with a code formatter in both as console app as
well as Lazarus/whatever module so that (say) when I receive/retrieve
code from some repository I'd apply MY coding style, and when it's time
to submit/upload I'd apply the receiver's coding style.
It was to be a cure for 'coding style' headaches.
Well.. it didn't quite happen.
Instead, that discussion turned into 'list noise' which resulted in the
creation of 'fpc-other'.. :)
Fifth, how would you feel if you're considered to be a wet-behind-the-ears
noob?
I actually feel like "wet-behind-the-ears noob" every time I start
working with new library/technology/problem area. But that's what we
are until we learn something :)
Yeah, I feel the same.
But, what I feel and what I am made to feel do not necessarily produce
the same psychological sensation :)
Finally, how do you suggest an understanding conducive to co-operation can
be established.
It's psychological question - how to you establish trust or love? This
is open-source project, and it's developed based on the free will to
do so. If you want to be part of that, you need to be team-worker, and
that requires not only knowledge but also team working skills. At
least, that's how I understand it.
True.
There does need to be a point of compromise/equillibrium.
If the time/effort to gain that trust/love takes too long, it may become
likely that one/both party loses interest and takes off.
We may explain those absences as 'silences' but at least some of them
are loses in the 'should have been avoided but we'll never know' category.
--
Cheers,
Adem
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-other
