Qtopia questions

[Holger Freyther]

On Saturday 26 July 2008 22:52:38 Lorn Potter wrote:

> > You should write clean code from the start. At WebKit.org we have clear
> > Coding Style Guidelines and most of it is enforced by review and
> > pre-commit scripts. Maybe adopting such things for Qtopia would make
> > sense?
>
> I wish you would stop using the word 'you' when you mean Trolltech.
> 'You' makes it seem like it is personal to me. I only work on one small
> part of Qtopia, and direct people to view your commit log.

Sorry, that is probably due my bad english. I refer to the entity that got 
bought by Nokia. I have no idea which developer is responsible for which part 
of the code or has written certain parts. I will try to improve but please be 
patient.



> Perhaps you should stop caring if the code has differing white spaces
> and get on with the real bugs.

Lorn, I don't know what makes you say that. We have almost four hundreds 
commits in our Qtopia tree and probably 5 of the fix the indenting. But yes I 
complain about the complete lack of a Coding Style in the Qtopia source base 
because for whatever upstream project I patch I try to follow the style when 
making patches. This is impossible with Qtopia.



> > Sure. this is why I write this into the commit message...
>
> and why we do not like to commit code that breaks it.

IIRC Trolltech's Qtopia engineers have had plenty of commits in Qtopia 4.3 
that broke BC. :)


> > Please reread the paragraph. As I said I made starting of timers
> > optional. So what is the default? Default is still the old and error
> > prone (from my point of view and every OpenSource/FreeSoftware engineer I
> > have talked to) behaviour.
>
> It's a fine line between whats right, what's correct, and what's reality.

The modem is a complete different system, it runs its own OS. Guessing about 
the internal state of the system is just wrong. Why? Because one has no idea 
what the modem is doing, what the network is instructing... whatever. So the 
plain Qtopia code sets a call to accepted before the "connect" command (ATA) 
gets even send and it is ignoring the result of the modem. Why do I care? 
Well, because it broke. People interested can read this code[1].

This is a basic engineering practice and if engineers do not follow this one 
will create a fragile and error prone systems. I know you don't like this 
statement but it is simply the case.


> > First of all I doubt that you need to start any timers to guess when
> > something is done. CLCC should always work (if %CPI or such vendor
> > extensions do not exist). So instead of guessing when a call might or
> > might not be missed, when all information arrived one could start your
> > missed timer and then check the state of the call... So I think the
> > "buggy modem" is just an excuse for writing fragile software.
>
> This is what I was told by the lead comms guy. He has many real world
> years experience (including large projects with large amounts of
> engineers such as Qtopia) as a software developer, including open source
> and I take his word for it.
> http://freshmeat.net/projects/pnet/

And I have serious doubts that this guessing is necessary in the first place. 
And I have stated that one shouldn't punish every modem/customer because one 
modem is really really bad. But see the below paragraph of the previous mail 
about mixing guessing (starting timers) and basing on %CPI (if it is 
available). %CPI is to be preferred, asking (CLCC) would be good as well 
(that is FSO's fallback), I could live with timers as well, but mixing all of 
these ask for trouble...

I know you don't like this but I complain about the guessing (starting timers) 
because it broke on me and QA, and I make sure that in our case no timers get 
started or nothing is guessed. And from the feedback I get callhandling feels 
more solid but there are still some bugs left.

Does this complaining mean I'm perfect and never make mistakes? Obviously I 
make mistakes like everyone else, I make plenty of them. But the things I 
complain about show something that is systematically wrong. Your developers 
in Brisbane can listen to it, discuss and learn, or they can ignore this. It 
is up to them, I encourage them to discuss in public and engage in Free 
Software projects.



> I was meaning general internal discussions. People choose to view your
> patches or not, depending on their interest. Many do not have time to
> wade through 300 patches of code clean up for those few real bugs.

haha. git-rev-list says 366 commits without merges. But please don't tell my 
manager that I just change whitespace the whole day long... If you feel 
better believing that we can declare this reality.

Imagine this would be Qt. I would sit down with Simon or such and go through 
all the patches and we would send the git commits to the right dev's. This 
would be a matter of a couple of hours. I think one of you could easily go 
through the git commit and discard or forward... we can do this remotely if 
there would be any interest....



>
> The fact is, Trolltech _is_ looking at your patches, regardless whether
> any one person chooses to discuss them.

this is not how it is working in Free Software projects and even in Qt. If you 
want people in the community to use Qtopia on devices you have to provide 
means to get their feedback. This includes discussing of patches in public, 
otherwise they will just move on to other platforms...heck even if at 
Openmoko we have this issue to a certain degree. :)


happy hacking

	z.

PS: I'm certain you don't like the statements about a unreliable and fragile 
system. The good thing is such things can be changed and I'm willing to 
update my statement then.


[1] 
http://git.openmoko.org/?p=qtopia.git;a=commit;h=f8a74033327e06818c61f4a17ec347707e506ee2