qualitiy is important for tangoGPS

[Sander van Grieken]

On Sunday 11 April 2010 19:42:23 Marcus Bauer wrote:
> On Sat, 10 Apr 2010 16:29:15 +0200
> Sander van Grieken <sander at 3v8.net> wrote:
> > No. Just email your patches to Marcus Bauer. Expect no reply nor use
> > of patches.
> > 
> > But, you don't have the right to complain. You have the right to
> > fork, though.
> 
> Well, looks like you are a bit upset that your patch was not accepted

Not at all, I don't care, I build my own tangogps. I just warning people what to expect. 
It's quite different from other GPLed projects. 

> but quality is important for the longterm success of tangoGPS.

Yes that's why GPL projects usually attempt to also build a _developer_ community.

> Criteria for software quality are (amongst others):
> 
>  * correctness (i.e. bug free)
>  * maintainability
>  * robustness
> 
> Your patch about speed-up is very invasive in core parts of
> tangoGPS, was not well documented, not minimalistic and introduced
> several bugs. 

Yes all true, there were some issues still that needed attention, and I didn't expect you 
to merge it in. I expected some feedback on the direction though. Never got it (until now 
:)

> In general it falls in the category of premature
> optimisation which will cause enhancements like other map datums as
> WGS84 or other projections as Merkatoor significantly more difficult
> and error prone.

Nonsense. I mean, reloading and parsing all PNG tiles on every map drag? come on, you can 
do better than that. And other projections? BS, you're just stacking tiles.

That's not premature optimisation, that's called caching.

> There is plenty of documentation about how to contribute to open source
> projects and my advice is to check that first.

Very funny. Where is the mailing list, where's the bugtracker, where's the public tree, 
where's the *feedback*?

If you're really interested in the long-term success of TangoGPS I suggest you start 
building on the developer community aspects. I know it's hard to let other developers make 
changes to your project, but you're still the owner of your own tree, and decide what has 
high enough quality standards for you. For not-quite-ready patches (like mine), there's a 
thing called branches, which you can use to give other devs a place for their work. 
Another option is to use a bugtracker, where patches can be attached to bug descriptions. 
At least then developers don't get the impression that their hours of work fall into a 
deep black void.

If you don't set up this critical infrastructure, or even have the courtesy to give 
feedback on patches, eventually all interested developers lose interest.

grtz,
Sander