thunderbird upgrade - wtf?

[Richard Hughes]

2009/10/16 Ankur Sinha <sanjay.ankur at gmail.com>:
> Richard, I'd like to take this up. What do I need to know/learn?
> btw, I'm a sort of a newbie at application development though.

Well, the application development is perhaps 10% of the problem. 90%
of the problem is identifying the core problem, working out how users
are going to interact with this, and also how to avoid spamming the
user about test-updates they don't care about.

For instance, the way I could see this work is:

* A checkbox in gpk-update-viewer (or gpk-prefs) with [X] Install test
updates, not suitable for general users
* A GObject that is compiled into gpk-update-icon (say,
GpkTestUpdates) that monitors the software log and prompts for
feedback a week or so after updating
* A session database of software we've already prompted for, or
software we are interested in

They'rd also need to be some policy choices:

* How long do we give the user to test the software? Wait until the
software is run for the first time? The third time?
* Where do we direct the user to? NULL would need to be configured in
GConf by default, and then patched by distros. Or we use
/etc/PackageKit/vendor.conf and some clever re-writing to get the
correct URL
* Do we pop up a bubble for every bit of software (would get really
irritating after a while) or allow the user to say "never for this
package"
* Do we exclude some software? -devel? -debuginfo?

So, as soon as you start working on a complete specification, there
are lots of problems. The actual coding part would probably only take
a couple of days (few hours for someone comfortable with the PK
design), but the working-out-how-to-do-it part could take quite a few
weeks.

Join the PackageKit mailing list, and write a proposal or just an
ideas dump. Bear in mind it needs to be clear enough so the KDE guys
can re-implement it using their systems. I can discuss things on the
PK mailing list with whoever wants to contribute.

Richard.