← Back to team overview

tomdroid-dev team mailing list archive

Re: [UNSURE]Re: Looking for a driver for the next few releases / months

 

On Tue, Oct 19, 2010 at 3:13 PM, Sandy Armstrong
<sanfordarmstrong@xxxxxxxxx> wrote:
> On Tue, Oct 19, 2010 at 1:43 AM, Rodja Trappe <mail@xxxxxxxxx> wrote:
>>
>> As a driver, I would want to drastically change some things:
>>
>>      * switching from Launchpad to GitHub
>
> Is this really necessary?  Switching code/bug/wiki hosting is a giant
> pain for maintainers, developers, and users.  What if the next person
> says "hey I prefer hg and bitbucket, let's move there"?

Hey, I prefer hg and bitbucket, let's move there!

Kidding aside, I strongly agree with Sandy's points. Moreover, as much
as I love git (I use it daily at work and it's awesome once you get
used to its quirks), its learning curve is steep as hell and I swore
at it more than I would have liked to as a beginner. Tomdroid is an
awesome app to get your teeth cut on, let's not deter beginners from
contributing with a bad choice of tools.

Something that's been on my mind for some time is the fact that we're
not really welcoming to beginners. Maybe I'm using a straw-man here,
but the problem I see is that they have to figure out everything by
themselves. When you don't know anything about either bazaar,
launchpad, android, java or even the way open source works, this can
be quite an ordeal.

In order to ease this pain, we could put up a "Tomdroid bootstrapping"
guide, ie how to get the android sdk and eclipse installed, how to
clone and publish changes with bazaar, etc. This information is
already available somewhere on the net, but it would be much easier if
this info was centralized on a page in the wiki, even if it's just a
collection of links.

>>      * publishing Tomdroid on the Android Market (each release, and a
>>        separate dev-preview build for testing)
>>      * much more frequent releases (with very small change logs)
>>      * automatic code formatting

These are very good points, my personal favorite is the last one. The
code base is looking like Frankenstein atm, with tabs, spaces and
inconsistent formatting everywhere.

On the original question: I also don't have much time currently (no
wonder the project hasn't advanced as much as we all would have liked
to) and I would be dishonest if I pretended to be able to handle the
maintainer's work. I can try a little harder to step up and handle
part of the boring work but certainly not all of it.

This being said, do we really have to have only one person doing most
of the work? Can't we give the keys of the project to a team of two or
three people? I'm speaking from inexperience here and there are many
reasons this wouldn't work, I guess input from someone more
experienced in open source than us would be very welcome (wink wink
Sandy ;-) ).

Have a nice evening, afternoon, morning or whatever,
Benoit



Follow ups

References