tangoGPS community development, patches (was: tangoGPS magnify patch)

[Joshua Judson Rosen]

Marcus,

Thank you for your responses today; however, I'm still not clear on
the answers to my questions. Maybe I can be more specific, below...:

Marcus Bauer <marcus.bauer at gmail.com> writes:
>
> On Sat, 10 Apr 2010 23:06:48 -0400
> Joshua Judson Rosen <rozzin at geekspace.com> wrote:
> >
> > > > I have a patch that makes it possible to scale the details on maps
> > > > (e.g.: text, icons, line-widths) and change the amount of detail
> > > > shown without zooming the map; 
> > 
> > So, when you select `fewer, bigger details', the code just decreases
> > *pixel-density* and a `zoom-level offset' adjusted accordingly.
> > The map remains at the same zoom-level; but the text and icons get
> > bigger, the streets and other lines get wider; the amount of
> > visual `clutter' decreases, and information-clarity goes up.
> > 
> > If you select `more, smaller details', the pixel-density is increased
> > and the zoom-offset adjusted in the other direction. Again, the map
> > remains at the same zoom-level; but the text and icons get smaller,
> > the streets and other lines become thinner; the amount of information
> > visible at a given zoom-level (the information-density) increases.
> 
> This patch is potentially interesting on the Freerunner due to the 3x
> higher dpi of the screen.

Also on the Nokia portables, I'd imagine--while their pixel-density is
somewhat lower than the FreeRunner's, it's still quite remarkably
high: ~225 pixels per inch, I think.

> The patch makes future extensions for layers, non-merkatoor and no
> wgs84 more error prone

Oh--now that's quite interesting: if those are lines of development
that you're currently pursuing, I look forward to reading about them--
I hope that you'll find some time to post something on your weblog.

Now, more to the point...:

> and therefore currently is not suitable for tangoGPS.

Which is fine. It doesn't matter so much to me whether other people
have a use for the features that I implement--both of the features
that I've mentioned in this thread were developed, after all,
primarily because I needed them. I'm not looking to make a name for
myself with this--I've already made a name for myself, and am quite
comfortable with my professional standing :)

I *would* like to make my patches *available* for other people to be
able to find them and use them if they like, and there are also other
functional additions that I'd like to build on top of tangoGPS--which
I'd like to develop openly and with opportunities for the community to
participate; which is why I asked where I should be posting this stuff.
As you say, tangoGPS has a much broader scope than just OpenMoko
at this point, so the `openmoko community' list is surely not
the right venue. But this is where I've posted feature-additions,
bug-fixes, etc. because it wasn't evident where else I should;
I haven't seen any evidence of an actual `tangoGPS mailing-list'.

So, how *should* I collaborate? What mailing-list should I use?
When I fix an upstream bug, in what BTS should I publish the patch?
Where can we talk on IRC about current developments in tangoGPS,
if anywhere?

Most importantly: How should I keep up with work that you're doing
upstream between releases? Maintaining the patches that I use is vital
to me, and it's harder to do that if I have no idea where you're going
upstream--if I have no idea what's going to change out from under me
with the next release. I know you can appreciate that concern, given
the recent gpsd episode.... :)

You've also mentioned some valuable functional additions that you have
scheduled for sometime in tangoGPS' future, which I'd love to help
make happen sooner; it'd be much easier to come up with patches that
were likely to be acceptable upstream if there were more transparency
in upstream development: a public (for read access) version-control
repository would be *ideal*, but I haven't been able to find one for
tangoGPS. If you're using one of the *distributed* VC tools (like Git,
Bazaar, et al.) then I'd *really* like to know the URL for your public
archive--the benefits from those systems are just huge.

As it is, I feel like I'm trying to track a moving target... with a
blindfold on. The fact that there is `source' material apparently
missing from the tangoGPS release tarballs doesn't help: it looks like
the GUI was done in Glade and C code was autogenerated from that,
but there is no glade-XML file to found in the release tarballs.
Are you even still using glade? If so, where is the `.glade' file?

That's one of the reasons (along with the others listed above) that I
keep asking if you have a public VC repository somewhere and I've just
overlooked it..., and am hoping to get a response some day :)


> However, you can ask the packagers of SHR etc. if they are
> interested in inclusion.

Certainly--and I just heard from someone today that my `detail-scaling'
patch was just the sort of thing for which he had been looking,
so maybe I will forward a copy to shr-devel in case they want it.

Though, If I was them, I'd be quite reluctant to do that: it's just
too big a job for them to concern themselves with it--managing a line
of development that runs counter to the direction of the upstream
maintainer.


If you're suggesting that I fork tangoGPS off into a separate project,
I can certainly do that. I'm very reluctant to do that, because forks
can have such a divisive effect on the community; I'd much rather just
help you with your project where possible, and have a place to share
optional add-ons and patches with others when they are not of broad-
enough applicability or appeal for them to make sense for you to
incorporate upstream. But it feels more difficult to help with tangoGPS
than it is with other FOSS projects to which I've contributed.
Yours is more of the `cathedral' method, where most take a more
`bazaar'-like approach.

If there *is* to be a fork from tangoGPS, I'd hope for it to be done
with respect and on the best possible terms--perhaps like when EGCS
forked from GCC, or when people fork the Linux kernel to work on new
subsystems: a good-natured fork to do more experimental exploration
that may not be immediately appropriate in tangoGPS proper.
tangoGPS could then (obviously) merge any changes that did turn out
to be appropriate, on whatever timeline would be appropriate.

As I said, I *do* really *like* tangoGPS--I owe you a big thanks for
giving me a good base application on which to build!

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."