Who am I? I have been a member of the Android software team since
late 2007, but a couple of months ago I shifted over and became the
lead maintainer for the Email client. I have written or supervised
all of the post-1.0 changes. Some of these you can see as reliability
& compatibility improvements (the primary focus of the 1.1 effort, for
Email). Others changes are in the form of improved localizability,
now that Android devices are starting to ship in non-US locales.
Finally, if you look in the cupcake sources, you'll find continued
improvements in all of those areas, as well as a unit testing
framework (which was not present in the original 1.0 open source
release).
The basic question at hand is: When will K9 be bulk-merged back into
the mainline sources?
The short answer is: It will not.
The long answer is:
We are very excited about the existence of forks like K9 (and others
which might be out there). This is one of the highlights of open
source work, seeing a different group take your work and extend it to
the next level. In contrast to a comment made in the other thread, we
are quite happy to see forks, because they provide opportunities for
other developers to explore new ideas, and they contribute to a robust
market for Android applications.
But somewhere along the line there has been an impression that somehow
K9 would become the "new" platform email application, via a
large-scale merge. I'm not sure how this happened. If it was said by
Googlers, please consider this email both an apology and a correction.
If it was wishful thinking, well, I'm here to let you down a bit :(
But in any case, I want to clearly state that this is not the plan.
While I don't mean to dwell on the negative, here are a few of the
reasons why not.
1. K9 is great - I know Googlers who are quite happy using it. But
K9 is not somehow earmarked to become the new platform Email app.
What would happen if another group of coders showed up 3 months later
with another client fork? Should we merge that next? Where does it
stop?
2. K9 was developed under a very different set of constraints than we
have in the platform Email client. I must work within user interface
guidelines and remain consistent with the rest of the platform, as
well as user testing, and the requirements of carrier partners. The
K9 team has a lot more flexibility to experiment with changes to the
user interface than I do, and they have the benefit of much more
immediate feedback from their download customers.
3. When I work on the platform Email client, I get to deal with
localization, multi-carrier requirements, and a lot of testing. And
most of all, I have to work within platform release schedules, which
limits the windows in which I can add new features. Third party
application teams can work on a much more flexible release schedule.
But I'd like to cover some positive territory too.
First, the email client in cupcake is in better shape than 1.1, and
that's in better shape than 1.0. I encourage the K9 team, as well as
any other Email forks, to take as much from cupcake as possible.
You'll find a more reliable POP3 implementation, improved
interoperability (welcome back, comcast.net users!), and overall
cleanup of some of the rough edges in the client. It has a long way
to go, but it's a lot better than it was. You'll find a couple of new
features, too. And we're not done yet.
Second, I encourage & welcome patches from anybody interested in
making Email better (including the K9 team). Pushing patches upstream
is good for everybody: It improves the platform app, and it makes
life easier for everyone who is forking from it.
Here are some things that will make for successful patches.
* Good patches will make the client better for users, by fixing bugs,
improve efficiency or increasing interoperability. Or, they make the
client better for developers, by making it more extensible,
debuggable, or testable.
* Patches that make direct changes to the UI are much less likely to
be accepted. But patches that make it easier to change the UI in a
downstream fork, are fine.
* As David Turner said in the previous email, smaller really is
better. Big patches take far, far longer to approve (or may simply be
sent back.)
* Test, test, test, test. Please plan to include unit tests for your
changes. I know that some parts of the code are more testable than
others. If you can't test a piece of Email, that's a bug and we can
work together to correct that. I've been finding that fairly small
refactorization is all that's necessary to make the code testable.
I'm sure there's more to cover but this is already longer than I had
intended to write.
I look forward to discussing patches & bugs!
Andy Stadler
Google
But somewhere along the line there has been an impression that somehow
K9 would become the "new" platform email application, via a
large-scale merge. I'm not sure how this happened. If it was said by
Googlers, please consider this email both an apology and a correction.
If it was wishful thinking, well, I'm here to let you down a bit :(
But in any case, I want to clearly state that this is not the plan.
While I don't mean to dwell on the negative, here are a few of the
reasons why not.
1. K9 is great - I know Googlers who are quite happy using it. But
K9 is not somehow earmarked to become the new platform Email app.
What would happen if another group of coders showed up 3 months later
with another client fork? Should we merge that next? Where does it
stop?
2. K9 was developed under a very different set of constraints than we
have in the platform Email client. I must work within user interface
guidelines and remain consistent with the rest of the platform, as
well as user testing, and the requirements of carrier partners. The
K9 team has a lot more flexibility to experiment with changes to the
user interface than I do, and they have the benefit of much more
immediate feedback from their download customers.
3. When I work on the platform Email client, I get to deal with
localization, multi-carrier requirements, and a lot of testing. And
most of all, I have to work within platform release schedules, which
limits the windows in which I can add new features. Third party
application teams can work on a much more flexible release schedule.
There has been some discussion about K9 merging back into the platform
Email sources. I'd like to address some of the things that have come
up and try to shed some light on the situation.
<snip>
Sorry I haven't rejoined this thread more quickly - I was out of town
for most of last week, and just now catching up.
There's a lot to discuss and I'm going to take it in small pieces
(like a good patch). I'm quite sure I won't answer every question
that's been posed, or in enough depth to satisfy all. But it's good
to keep the conversation going.
Upfront: I appreciate your thoughts on the overall AOSP, but I am
only here to discuss the Email client.
Regarding statements about merging clients. I'm really not aware of
any plans between DAMail and K9, so I really don't have much to
contribute there. Regarding any statements of a complete merge of any
forked client back into the main truck, as I tried to say clearly:
"If it was said by Googlers, please consider this email both an
apology and a correction." I'm not sure if it's worth a lot of
time/effort digging through old emails, but feel free if you wish to.
Regarding pulling patches from K9: You're right, I could. I'd like
to do more of that. I'm hoping that we can do more open discussion of
bugs on this board, and move patches in either direction when we can.
But it starts with bugs filed and discussions (like a good one going
on right now about IMAP folder subscriptions).
Regarding "secret docs": Well, I didn't say that, but I'll be happy
to elaborate on the things I did say.
Regarding UI changes in patches: Let's use your example of better
handling of self-signed certificates. I actually see this one as two
or three patches. The first one or two would be the underlying
plumbing. I say two because there's work to be done in the transport
areas that will need to be implemented & tested, and there's also the
need to reliably and securely store accepted certs in the per-account
preferences. Assuming good code quality, internal documentation,
review, and sufficient unit testing, I'm sure these patches can make
it (and I am looking forward to seeing them). Obviously the final
patch would be the UI to present certificate errors, describe them to
the user, and provide options for handling them. Would it be
accepted? I hope so! But I think the important issue here is not
plumbing vs. UI, but rather that these patches would be reviewed
independently, on their own merits, and would each contribute to the
platform.
Regarding forks vs. outside contributors: I don't think I said that
forks are preferable to outside contributions. Quite simply I don't
see it as an either-or situation. I believe that forks are good
because they create choice for end users. I believe that outside
contributors are good because they improve the platform. I think it's
great that members of the K9 team are in the position to do both.
Regarding being closed to contributions: My inbox has a lot more
messages about the idea of accepting patches, than actual patches.
Hint hint :)
Andy Stadler
Google
p.s. Jesse, you have no reason to apologize for enthusiasm!
Hello all-
Sorry I haven't rejoined this thread more quickly - I was out of town
for most of last week, and just now catching up.
There's a lot to discuss and I'm going to take it in small pieces
(like a good patch). I'm quite sure I won't answer every question
that's been posed, or in enough depth to satisfy all. But it's good
to keep the conversation going.
Upfront: I appreciate your thoughts on the overall AOSP, but I am
only here to discuss the Email client.
Regarding pulling patches from K9: You're right, I could. I'd like
to do more of that.
Regarding "secret docs": Well, I didn't say that, but I'll be happy
to elaborate on the things I did say.
I must work within user interface guidelines and remain consistent with the rest of the platform, as well as user testing, and the requirements of carrier partners.
Regarding forks vs. outside contributors: I don't think I said that
forks are preferable to outside contributions. Quite simply I don't
see it as an either-or situation. I believe that forks are good
because they create choice for end users. I believe that outside
contributors are good because they improve the platform. I think it's
great that members of the K9 team are in the position to do both.
Regarding being closed to contributions: My inbox has a lot more
messages about the idea of accepting patches, than actual patches.
Hint hint :)