[Aptitude-devel] Plans for aptitude 0.5.0 - 0.6.0.

[Daniel Burrows]

  Hello all,

  I just wanted to post what my general plans are for the aptitude 0.5.0
line and its development into 0.6.0.  For those of you who haven't been
around as long, aptitude uses old-Linux-style version numbering; 0.5.0
will be a series of unstable releases along the road to 0.6.0.  For
comparison, there have been two previous development series: 0.1.0,
circa 2001, was the rewrite to use signals, slots, and something
resembling a real widget system; 0.3.0, circa 2005, was a rewrite to
use Unicode everywhere and threading in a lot of places.

  Probably the main person who will be interested in this email is
Arthur, but of course anyone else who wants to chime in can. :-)

  So, here's what I see.

  0.5.0 -- released mid-October to experimental

    ... -- some number of interim releases

  0.6.0 -- released around Christmas (this may be too optimistic;
           perhaps more like February-March?)

  In each release, I'd like to try to maintain three invariants:

    * All the widgets the user can see will work.
    * No major known crashing bugs.
    * All documentation is up-to-date (except that we might not write
      any documentation for the GTK+ frontend until sometime after 0.5.0).

  The basic idea is that 0.5.0 should have all the core functionality
we want; the development on the way to 0.6.0 will consist of improving
UI and adding less critical features.  Also fixing bugs, should any
arise.  Estimated times are the time I think it'll take to design and
implement a basically working version of the feature without any major
bugs; one day = 8 hours.

  The following features are the ones that I think are aimed at
0.5.0 vs 0.6.0.  "For 0.5.0" means I think it absolutely should be
in the first GTK+ release.  "For 0.5.0, if possible" means I'd like
to get it into the first GTK+ release, but I think we could defer it
if it turns out to be too much difficulty.  I used this for entries
that I'm not quite sure how to implement (so they may need some
experimentation).  "For 0.6.0" means I think it should be in the first
stable release of the GTK+ frontend.  "For 0.6.0 or later" means that
I'd like to get it into the first GTK+ release, but we could also
implement it later (if, again, it turns out to be too much trouble).

  Let me know what I forgot.



  Major TODOs for 0.6.0:

    * Show dpkg interaction inside the program instead of in the
      controlling terminal.

      + For 0.5.0: pop up dpkg in a new tab.  Estimated hack time: 4-8
        hours; we just need to integrate support for libvte.

      + For 0.6.0: display a progress bar showing what dpkg is
        up to in a notification bar, with a button to open the dpkg
        output.  Estimated hack time: unknown, probably <8 hours.

    * Xapian support in search patterns.

      + I've been working on an overhaul of the search code to support
        this and the other search-related feature below.

      + For 0.5.0: support Xapian-indexed queries.  Bare strings should
        produce full-text queries against any and all relevant
        information sources (this will probably take some tweaking to
        get "just right"; e.g., do we search tags?).  Estimated hack
        time: 2-3 days.

      + For 0.6.0 or later: support highlighting matched terms,
        incremental search, sorting by relevance, and perhaps
        interactively narrowing the search.  Estimated hack time: 4-5
        days total.

        Highlighting matched terms will probably be especially tricky,
        or at least will take a lot of typing.

    * Support for interactively editing search patterns.

      + For 0.5.0, if possible: write a UI to let the user build complex
        queries.  Some sort of an "Edit..." button next to "Find" that
        causes the editor to appear; the editor will change the search
        that's being used and replace the text in the sesarch box.

        With the ground work I've done over the last few days, this is
        just a matter of converting the aptitude::matching::pattern
        class to some sort of live editing widgets (and back).  The
        harder question is figuring out what the end goal is.

        I'm not sure what the UI should be.  For displaying the editor,
        a tab doesn't feel right; maybe a dialog or a fold-out region
        in the package list?  For the editor itself, I don't know what
        works for people.  Email clients and Web browsers that I've
        used just display rows of widgets, one row per match term, but
        I think this might not work for expressions with nesting, etc.
        Another option would be some sort of tree view.

        Once we decide on a UI, I estimate that this will take 1-2 days
        to implement.  If we end up throwing the first one out, it'll
        take longer.

    * Upgrade planner.

      + For 0.5.0, if possible: design and implement a tab that brings
        together the tools that are useful in an upgrade: a list of
        upgraded packages, a dependency resolver, and changelog viewing.
        (what else / how to put them together?)

    * Dashboard.

      + For 0.5.0: The "dashboard" tab should contain some useful
        content.  Either that, or we should just hide it.  Estimated
        hack time: 1-2 hours.

      + For 0.6.0: We could use the dashboard to give the user quick
        buttons to access common stuff (a text box to search for packages,
        a button to start an upgrade), and perhaps a list of pending
        upgrades (with some text from the changelog of each one).
        Estimated hack time: 4-8 hours.

    * Dependency resolver.

      + Already implemented: basic support for displaying solutions and
        moving between them.

      + For 0.5.0: we should at least support the "accept" and "reject"
        actions.  My preferred UI is a pair of thumbs-up/thumbs-down
        icons in package rows, but I guess I could settle for check
        boxes.  Estimated hack time: 2 days, mostly spent trying to
        wrestle GtkListView into submission.

      + For 0.6.0 or later: I think there are probably more ideas to
        explore, but I haven't come up with very many clever ones.  For
        instance, displaying a list of the solutions the user has
        generated and visually indicating which ones aren't allowed by
        their current constraints.  Estimated hack time: unknown.

    * Package list.

      + For 0.5.0: there should be an easy way for users to display
        more or fewer columns (for instance, right-clicking on row
        headers?)  This of course means we'll have to generate more
        columns. ;-)  Estimated hack time: 4 hours.

      + For 0.6.0: we should investigate using a custom TreeModel so we
        don't have to instantiate the whole list at once.  For larger
        result sets, I expect this to be a major savings.  Estimated
        hack time: 1-2 days (mostly design work).

      + For 0.6.0: get some better icons.  The stock ones just don't
        cut it for package management.  (IMO)  What does an envelope
        mean?  What about a rewind button?  Estimated hack time:
        unknown, find a graphic artist or some free-as-in-speech
        clip-art.

      + For 0.6.0 or later: Support displaying popularity and sorting
        by it.  Maybe we could use something like network strength
        indicators?  i.e., up to 4 bars of increasing height.  Estimated
        hack time: 4 hours.

    * Package information.

      + Already implemented: support for displaying changelogs.

      + For 0.5.0: changelog downloads should happen in the background.

      + For 0.5.0: the "files", "popcon", and "tags" tabs need to either
        be implemented or to be hidden.  Estimated hack time: <1hr for
        "tags", 2hrs for "popcon", and 2 days for "files" (or about 5
        seconds each to hide them).

      + For 0.5.0 or later: expose the "why" information in the info tab.

      + For 0.6.0: they should really all work.  Slower tabs (like
        changelog and files) should be loaded in the background.

      + For 0.6.0 or later: use an html renderer for displaying
        descriptions and other info?  The TextView is annoying to
        work with; a real HTML renderer would get us goodies like better
        rendering of lists and indented text.

    Thanks,
  Daniel