quickly-talk team mailing list archive

[Michael Terry <michael.terry@xxxxxxxxxxxxx>]

Hello!

I just wanted to do a bit of a write-up about proposed directions and
where we are today.


Work we've done so far this cycle:
(https://blueprints.launchpad.net/ubuntu/+spec/appdevs-desktop-n-quickly)

 * Alpha 1 work items were all done in time!  Yay!

 * Alpha 2 work items look like they are mostly plugin related, which
may be a problem again this cycle.  We should talk about delaying yet
again any work items based on libpeas plugins.  It's not clear that
gedit for GNOME 3.0 will be in Natty.  We'll know more after next week.
So let's not decide anything now, but just keep that in mind.

 * /opt support is going well.  Didier pushed the first cut at a
submitubuntu plugin and some changes to support /opt in the python
toolchain.  And I recently filed a merge request to add the required
bits of metadata to the debian/control file.


Policies we've tried recently:

 * Shook up team structure.  This seemed to have gone OK, and we already
have grown the committers team by one -- Hi Tony! :)

 * Release a new quickly every alpha/beta.  We made the first one, but
no reports back about its usefulness or bugs reported about it.  I guess
no news is good news.

 * Code reviews.  This has bogged down a bit, as Didier and Rick have
been so busy.  I have several reviews pending, and Tony usually has to
wait for my slow butt.


Proposed changes:
(this thread probably isn't the best place to discuss these though, keep
that to the other ones -- I'm just trying to provide an overview of the
current discussions we're having)

 1. Promises of project upgrade support.  It seems we agree that the
basic idea is:
   * Project-level features (like /opt and appindicators) will be added
by upgrades.
   * Refactoring will not be guaranteed to be upgradeable.
   * Severe bugs will be fixed by upgrades.

 2. Reducing maintenance burden from project-root churn by refactoring
it into a user-touchable 'python' module and a non-user-touchable
'python_quickly' module.  This has gotten some approval, but isn't done
being discussed.

 3. As we talk about adding new templates, it's obvious that writing a
template is a lot of work and potentially a lot of duplication.  We've
talked about ways to fix that, but haven't yet settled on anything.

   a) We could lower the size and complexity of templates by reducing
them to mere integration points for code that lives in the system
quickly library.  This makes it easier to fork and subclass templates
because templates wouldn't hold much logic.

   b) We could use template inheritance much more than we are, with a
gtk-, gnome-, and ubuntu-application hierarchy.  Have them differ
largely in packaging details and what code they use for project-root.

-- 
mterry