[Compcomm] So what's going on code-wise? Or what we're working on.

[Danny Baumann]

Hi,

> > The patch you're talking about (the fixedRGBA texture loading stuff) was
> > different to what you outlined. I was telling David that we need this
> > IMO (before I got commit access), he said "I don't really care, send me
> > a patch and I'll put it in), I sent him the patch and heard nothing for
> > multiple weeks. I misunderstood this as him just having forgotten to
> > commit it, so I commited it.
> >   
> 
> I could not remember the details til you mentioned them.  I do
> remember the email from him and thinking that there was going
> to be a misunderstanding.
> 
> > You see, the problem here was a lack of communication paired with some
> > misunderstanding. It was not because it was rejected in a nice way - I
> > think I would have understood that ;-)
> >   
> 
> Misunderstanding can only be caused by poor communication.
> 
> (IMHO you were in the right in this case, David was probably being
> over-nice which led to misunderstanding and lost time)

Yes, that's right.

> It was the same for me when writing the file notification stuff in
> ini.  The lack of documentation (poor communication) meant I wasted
> time.  We need to avoid lost time because everyone is volunteering.
> 
> We need to work on this communication thing.  I am used to David now
> so I know a few tricks to get his attention and what not to do.  Ill try
> to communicate some of them, but I have to keep some for myself ;)

Same here - but still, I don't think even needing tricks for getting his
attention is a good thing ;-)
Sometimes only a "I have no time at the moment, but will review your
patches" would be a good thing to have so everyone knows what's going
on.

> > A better example are my resize patches - David said "this and that is
> > ok, but I don't like these things", so I changed that which made the
> > code better. Obviously 'nice rejection' was a good thing here.
> >   
> 
> Yes, I think he was readjusting thats about right.
> 
> Thats not a very good example of poor communication leading
> to lost time and effort, so I did not use that as an example ;)

I think outlining _good_ communication is better than outlining bad
communication, isn't it? ;-)

> Sometimes 'hack' cannot be explained very easily.  I've seen
> examples where David says something is a hack and he knows
> the reason why, he either assumes you know too or he just
> cannot be bothered to go into the very deep reasons why.
> 
> A polite 'why is that a hack?' would not go amiss if you really
> cannot understand why or how.  I am sure someone can chip
> in.
> 
> Personally I trust him to be the final judge on these things.
> I know for a fact that he listens to other people who have more
> experience in certain fields than he does, if you can prove you
> know what you are talking about then he will listen more and
> more.  If there is an issue where you really think you are right,
> then you need to approach the problem differently or explain
> better.

Problem here is: If you write code, submit a patch and someone who might
have more clue than you about the whole thing says "That's a hack"
without comment you are left without knowing what is going on. If you
actually knew what's wrong in the code, you wouldn't have submitted it
in the first place ;-)

Regards,

Danny