[debtags/debtagsd.git] / TODO

Patch review: show when a patch is just a patch or when it also contradicts other patches in the pool
 - if it contradicts other patches, on save the other patches are automatically amended

Milestone: moar reports!

projectb:
 binaries_metadata + metadata_keys gets the control file fields for Tag: fields in control files
 then I can do the merge with the DB taken from debtags.d.o
 then I can produce the new overrides

12:27 #debian-it < pinotree> enrico: mentre aggiungo/rimuovo tag, la lista "current tag" potrebbe rimanere in ordine alfabetico?

Show search results grouped by source package

Simpler interfaces (like card-showing, or popcon on own system driven tagging
things)
 - Mozilla openbadge API
 - "I'm a gnome tagger" / "I'm a top tagger"
 - tagging games
 - filter by section

Push for an AMQP server in Debian "bug reported" / "dak has run" / "..."


09:11 #debian-devel: #debian-devel < pabs> enrico: now sorting by distrowatch index in descending popularity 
                                           (missing distros get popularity 0): 
                                           http://dex.alioth.debian.org/census/debtags
09:13 #debian-devel: #debian-devel < pabs> enrico: btw, please ping me when you have integrated other 
                                           derivatives, so I can update 
                                           http://wiki.debian.org/Derivatives/Integration


a-x-i does not consider foo:amd64 multiarch package names as referring to the same package
22:13 #debian-devel < DonKult> enrico: you can: echo 'APT::Architectures { "amd64"; "i386"; };' > 
                               /etc/apt/apt.conf.d/00multiarch  # then apt-get update and you have an apt with amd64 and 
                               i386 packages in the cache. Just don't try to install i386 packages as dpkg will bail out 
                               (using apt from experimental would be better though, but optional)
22:31 #debian-devel < ol> enrico: there are two options - one is to ensure you add a single entry for each package, 
                          merging the arch lists if you store those, and the other is to put the package name in a 
                          document value and collapse on it
22:32 #debian-devel < ol> the former is better if it's easy to do
23:23 #debian-devel < DonKult> enrico: thinking about it, as ubuntu has already deployed multiarch for (i think) 2 
                               releases they may have already a complete patch for apt-xapian-index…
23:25 #debian-devel < DonKult> enrico: i wild-guess its that one: 
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/apt-xapian-index/precise/revision/27
23:26 #debian-devel < enrico> DonKult: it defintiely looks like it's that one
23:26 #debian-devel < DonKult> which might be wrong, as this wouldn't index foreign packages, or?




04:26 #debian-devel < pabs> enrico: once alioth comes back, this will be generated daily: 
                            http://dex.alioth.debian.org/census/debtags
04:32 #debian-devel < pabs> enrico: thats this until vasks returns: 
                            wagner.debian.org:/home/groups/dex/census/var/debtags 
http://distrowatch.com/text/fullphr-52.txt

 - Export overrides for the various distributions

 + tags in control files
    - used by maints to say "tags are good now, freeze"
    - used to sort difficult situations (renames over history)
    - how to manage one version of a package with tags from control files and
      another version with tags from overrides?
       - I can drop overrides for packages with tags in control, but that will
         drop them for all versions, and you can't add them to the control
         files of older versions
       - Or I can import tags from control files into overrides, replacing the
         stable ones from the site, but then the overrides override with the
         same tags for all versions
       - other options?

13:22 #debian-devel < enrico> zigo: uhm, I could also add a "list packages of maintainer $FOO" option to 
                              http://debtags.debian.net/edit/tags/suite::openstack
13:23 #debian-devel < enrico> zigo: or even "I'm maintainer $FOO" in the settings, so there's no need to 
                              fill up an email address every time

 - special interest "marketing" pages
    - cloud
    - games and other go*
    - call to d-devel for more

 - Bytag editor: see more results in the search boxes
   Myon> enrico: how do I get the rest of the result? I only shows about 40 of 466 for 
         "postgresql"
   enrico> Myon: still unimplemented. It's irritating, isn't it? I'm trying to work out 
           what's a nice way to implement that right now

 - in maintenance output, divide stats of packages updated because of new
   versions and packages updated because of popcon changes

 - RSS feed with changes to tag vocabulary

 - Widgets
    - settings dialog
       + distributions of interest
       - show tag/facet names or descriptions
    - standardised package / tag presentation functions
       - customisable package widget
          - interfaces with a patchset to update its tag list as patches happen
    - floating patchset that disappears if there are no patches
    - tag chooser (all tags list in editor, packed in a reusable dialog)
       - based on a vertical tab layout?
    - tag clipboard

 - Patch review
    - when reviewing a patch, collect changes from all the other patches and
      show them all together: so there's a good overview of that package in the
      patch queue
    - when an amend is applied, it needs to be applied to ALL patch-bytag dirs
      that would require it, otherwise things resurface until this is done by
      hand
       - even more, when a patch is approved, its appropriate subset needs to
         be applied as an amend to all patches that conflict with it

 - Per-package log
    - one table (timestamp, type, json)
    - log json so it's easier to process extra info per log entry type
    - log on package updates instead of using log.info
    - log when applying patches
    - initial log entry "indexed before logging system was implemented"

 - Reports
    - plottare il numero di patch per giorno e vedere se ci son dei trend
       - table on the DB with per-day counts
       - update per-day counts based on the timestamp in patch file names,
         collected during maintenance
       - restore historical data
          - function that scans a .tar archive looking for .patch files, and
            takes note of the timestamp in the name
          - run it regularly on the backups, to correct glitches in incremental
            data collection
    - query reports dynamically via API, so that next/show more don't need a
      reload, and that new packages can be loaded after quick fixes are applied
    - 'next' or 'show more' in report pages
    - allow to apply quick fixes also in the check reports
    - pinotree> invece di una pagina con pagine per le categorie, sarebbe possibile una sola 
                pagina con i tag nelle varie categorie leggermente indentati?

 - Checks:
    - allow to apply quick fixes also in the patch reviewer

 - Send vocabulary commit emails via svn hooks to debtags-devel@l.a.d.o

 - copypaste tags
   Myon> enrico: some "copy tags from $otherpkg" facility would be helpful, e.g. for 
         postgresql-$version-somemodule
   Myon> I guess it would be useful in other cases to have in the webinterface
   Myon> (I'm pondering to make the -$version- part in PG modules go away)
   enrico> Myon: it's rather nontrivial, ui-wise, given a package, to select another one to 
           copy tags from. I can probably do some "copy tags in a cookie" / "paste tags 
           from cooke" feature, though: would that be useful?
   Myon> probably, yes
   enrico> Myon: so it's "add tags from clipboard cooke" and "replace tags with cliboard 
           cookie", right?


Milestone: distromatch interesting files

 - Data sources
    - Interesting files from distromatch
 - Show interesting files in pkginfo report
 - autotagger from interesting-files
    - if it contains [usr/]bin/* then package it role::program
    - if it contains [usr/]lib/*.so.* then package it role::shared-lib
    - if it contains [usr/]lib/*.a then package it role::devel-lib


Milestone: all the rest

 - "Press"
    - Blog the /search/ function and mention that it works also on local apt-xapian-index
    - Blog the /search/bytag/ function and mention that it works also on local apt-xapian-index
    - Ask debian-devel about the reusable bits that have been put together
       - django debian layout app
       - debdata/

 - Patch review
    - load vocabulary.js and offer tooltips like in the tag editor
    - after aggregating patches, compute a sanity index for the aggregated patch
    - patch approval
       - todo list item 'has changes needing approval'
       - backend
          - salvare una proposed-patch, testuale, per pacchetto
          - in fase di approvazione, il tagset reviewed del pacchetto è editato
            con la proposed-patch attuale
          - semplificazione-pulizia delle proposed patch all'importazione del
            nuovo set di tag stable
          - export e backup delle proposed patch del giorno
          - log delle review (chi fa cosa e quando)
            (timestamp, user, pkg, text-patch)
       - approvatore per piú pacchetti
          - autenticazione al momento su user DB custom
            (sentire come integrare in qualcosa di piú integrabile)
          - pagina con pacchetti ordinati per popcon
          - pagina con pacchetti raggruppati per sorgente, pacchetti per maintainer
          - sullo stile delle todo, ma coi widget di approvazione
          - approvazione per-submitter, aggregando con il patch tag (ordinando
            per dimensione delle patch aggregate)
          - patch queue separata coi risultati delle approvazioni
          - jquery ui widget con l'approvatore per un pacchetto binario
          - submit per pacchetto e per pagina
       - the unstable and stable DBs could go out of sync, in the sense that after
         reviewing all the patches they could still have differences. They can be
         easily fixed by turning the differences into a patch and reviewing it as
         usual.
    - bytag patch review page
       - hover on a facet shows the facet info, including the list of tags
    - Patch review
       - reverse patch review: show a tag and all packages added/removed to it
          - apply the resulting patch to the stable tag db
          - apply the resulting amend to all patches
       - have users that are only authorized to review by one or more tags (not
         really needed at this stage)


 - Autotagger
    - autotagger: xapian search tags, add those with a weight higher than $foo
    - autodebtag
       - aggiungere tag tramite il motore di tip
       - if it depends on packages in section "oldlibs", tag maint::oldlibs
         maint::transitional
       - infer implemented-in from build-deps
       - merge coi tagcheck
          - fare tagcheck che possa usare delle data source extra (per deps e arches)
          - aggiungere, oltre alla formattazione di un tagcheck, il rendering come patch
          - lanciare tutti i check sia come tips (per i manually maintained)
            che come robot patcher (per i robot-maintained)
    - do not even offer -dbg packages for tagging: just tag them
      role::debug-symbols and be done with them
       - double check the other tags in the current role::debug-symbols to see
         if there could be a reason for other tags to be there
         YES: dummy -dbg packages
    - autotagging rules for postgres
      Myon> enrico: some "copy tags from $otherpkg" facility would be helpful, e.g. for 
            postgresql-$version-somemodule
      enrico> Myon: if you give me a rule for postgres, I can automate it. I do it
              for kernels and shlibs

 - Tagging
    - tagger from the tag point of view
       - next and prev buttons to paginate the two result lists

    - package lists
       - compute and show tips on package tagsets

    - filter/format current and possible lists according to the tag patch

    - compute a per-tag list of inference rules, and load it in the per-tag
      review page to offer a list of quick fixes for every package

 - Data sources
    - Download data files keeping track of last-modified in HTTP headers
    - Also keep track of sha256sums of files at index time
    - Support more derivatives
      pabs> I saw you allow debtags for Ubuntu-only packages, how about including other derivatives? 
            you could use the sources.list snippets on http://wiki.debian.org/Derivatives/Census
      pabs> we already do that for planet.debian.org/deriv, the way it works is that the derivatives 
            census scripts generate a config for you: http://wiki.debian.org/Derivatives/Integration
      pabs> if you are just pulling package info from UDD, then I guess that can wait though
      enrico> the census git isn't that straightforward. What I need is, for each distro, a name for 
              the distro and a list of Packages files
      enrico> best points if I can avoid anonymous people add 'debian' or 'ubuntu' distros to the wiki 
              pointing to packages files containing insults

      enrico> pabs: thanks, the order of source files looks good now. Another question is the order of 
              distros
      enrico> pabs: if I use that, package info from AlienVault-OSSIM has priority over that in Ubuntu. 
              It would probably make more sense to list the most popular distros first
      enrico> pabs: although that bit might be tricky
      enrico> pabs: I can work around that by maintaining a hardcoded list of popular distributions, and 
              then import all the others in whatever order
      pabs> cool
      enrico> pabs: is there a place that says how popular a distro seem to be?
      pabs> distrowatch maybe?
      enrico> pabs: just to introduce some more fairness in the process than "Enrico heard about it"
      enrico> pabs: right, they do have some stats. I hope the distro names match
      pabs> enrico: the wiki pages have distrowatch links for most distros, perhaps I could download 
            stats using that and impose some ordering from there
      enrico> pabs: that'd be fantastic


    - Nuove info nel DB
       - info maintainer overrides sui tag
       - info subscriber nel PTS
    - per-package storage of extra data
       - use the autodebtag patch as a source of hints: for each package keep
         the generated autodebtag patch and a description of why then it can be
         picked up by a tag checker which if the patch is not applied suggests
         the given tags and picks up the description

       - same idea can be used using apriori to compute more likely tagsets for
         a given package, then stored in a per-package storage and used by the
         checker

       - store in a per-package storage also some tagging constraints for the package
         (which can be edited by the maintainer)

    - use apriori to evaluate the tagging of a package:
       - rank possible new tags by feeding it only the tagsets that are
         supersets of the package tags
       - rank possible tags to remove by looking at the frequencies of all
         tagsets that are subsets of this one
       - count the frequency of similar tagsets: a possible optimization could
         be to feed apriori with the tagset count (-w integer transaction
         weight in last field)
    - reviewer constraints added as patch lines in a package text attribute

 - Exports
    - debtags for other distros, via dde or distromatch

 - Reports
    - Wording confusion at http://debtags.debian.net/reports/maint/
      Myon> I stopped typing when it said "myon" was ok, while in fact myon@debian.org is what works
      enrico> atm I'll fix the wording, then I'll add to the todo list to also validate the 
              field contents in the background
      Myon> enrico: ok the wording make sense now, but imho it shouldn't replace EMAIL then
      Myon> enrico: it's still not clear that I need to click on some "random" link after the 
            input field
      enrico> Myon: <enter> wouldn't work if you had more than one report per maintainer, 
              which is what I had in mind
      enrico> Myon: the original idea was to have that page as a link generator for all 
              per-maintainer reports; however I can also decide to have one main 
              per-maintainer report and link to the others in the related pages box in the top 
              right

    - tag stats: all tags sorted by name, number of packages (ascending or
      descending), facet then name or number of packages (ascending or
      descending)
    - list of frequent itemsets
    - allow to filter report pages by tag, keywords, section, distribution, ...?
    - pkginfo
       - link to full file list
       - link to Homepage
       - link to Vcs browser
    - upload popcon report file and get a todo page based on it
    - enrico> buxy: make it http://debtags.debian.net/edit/{$escaped-binary-package}
      enrico> buxy: or get rid of it, as you wish. If you'd like a link to a per-source package, 
              I can create it
      enrico> s/package/page/
      pabs> enrico: a per-source package page would be nicest
      buxy> well, that would be great yes, but in the mean time we're using the per-maintainer 
            view with the correct anchor
    - RSS feed of tag changes per package or per maintainer or per tag
    - reports/health
       - age of each data source
       - time since last patch was submitted
       - time since last patch review
    - inspection pages
       - have all the various maintenance / autodebtag checks write a copy of
         their output to a pickled maintenance log, which can then be loaded by
         report pages
       - inspection/test of algorithms for tag checking and autotagging
       - inspection of all available data about a package
       - age of all input sources
       - stats, stats stats: submissions, patches approved, patches amended,
         lifetime of a tag cookie, ...
    - url with per-binary tag info / todo list
    - url with per-source tag info / todo list

 - Tag checks
    - enrico> I'd need to give it some thinking, but I'd be inclined to say that 'scope::*' 
              only makes sense for role::program packages

 - Maintenance
    - do not just remove per-package storage dirs when the package
      disappears, but move them to backup instead
      (easy to do since we have the package list in memory)

 - Things that were already broken/untested/unused in the old site
    - prod pages (servono ancora?)
    - tag QA (li usa qualcuno?)

 - Tag/check overrides
    - One patch per package that is applied to a tagset before running checks
      (it would likely trigger misleading checks that believe the wrong tag is
       there)
    - An 'enforcing' patch, which can also contain positive or negative facet
      patches, that is specially evaluated by the checks to see if they should
      silence themselves
    - Some check-specific override string, generated by the check, that can be
      used to instruct a future run to silence itself

 - Editor
    - enrico> Myon: although yes, I could highlight those facets that according to some 
              considerations could be 'more interesting' at one given moment
               - if program then suite, if gameplaying then game, if field then
                 science, ...

 - special::needs-review tag
   Myon> anyway my point was I was trying to improve by saying "please someone have a look 
         (I don't want to currently)", but there's no way to do that
   Myon> ok for the bottom line, please consider adding some way for people to make stuff 
         as "needs review"
   enrico> Myon: special::needs-review sounds good, /me adds to todo list

 - enrico> Myon: the workflow is incomplete: it misses the part where a maintainer, after 
           some way of authentication, can declare tags on a package as "finished"

 - API
    - python-piston?
       - distro object (GET packages and infos)
       - bin package object (GET info, PUT tags)
       - src package object (GET infos)

https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related (1.3 only)

09:48 #debian-devel < enrico> pabs, buxy: I'm not sure I'd like to try all per-binary package links from the 
                              PTS to see if there's work to do. Doesn't the per-maintainer link provide 
                              enough of an overview?
09:49 #debian-devel < pabs> enrico: well, say you want to debtag one of the perl team packages but not all of 
                            the hundreds of them
09:50 #debian-devel < buxy> enrico: Yes I tend to prefer it too (that's why I said "if we go that way"), but 
                            it's not really ideal. Lintian has a similar view that we use but at least it 
                            provides an anchor "#foo" to see the relevant entries immediately
09:53 #debian-devel < enrico> buxy: group by srcpackage in the per-maint page is a good idea, indeed. And 
                              with an anchor, yes
09:53 #debian-devel < pabs> for the Debian fonts review we cat all the binary package reports together
09:57 #debian-devel < buxy> pabs: so I would suggest to use the per-maint view and you add an anchor #source, and 
                            when enrico implements it we'll be good, and in the mean time people will have to search 
                            manually (in the few cases where the list is really huge)

Allow to ignore suggestions, simply through the idea of tag hints (bits of
authoritative tag patch provided by maintainers)


Site:
 - tags are attached by package version as well
 - tags automatically flow from old versions to new versions when new versions
   appear
 - tags are added to a given version, or to the newest of not specified
 - store a file in a VCS writable by all DDs with 'tag locks':
      package1: +tag1, -tag2
      package2: +tag1, -tag3
   to use to prevent some additions or removal to be done via the web interface.

Packages are linked to "suite" (lenny, testing, sid, karmic, ...)
Updates are done by sending the list of (package,version) to the "suite" data
source and retrieving a list of changes ("changed", info) or ("deleted", info)
(package,version) couples that do not exist in any suite are removed. As a
consequence, for every (package,version) it is possible to show a list of
corresponding suites.

Users are tracked by email or by cookie.
  Cookie  Name       Email
  cookie  name|NULL  email|NULL
Changes are tracked by user
History table with all the changes (package, version, add/remove, tag)

package,version,tag,user mapping tables
 - More than one (site, reviewed)
constraint tables (package, version|NULL, has/hasnt, tag, user responsible for
constraint)

--

Specialist Committees:
  > This is one of the reasons why I find working on debtags for my packages
  > rather unrewarding.  I have no real indication that the decisions I'm
  > making about what tags make sense have much in common with the decisions
  > everyone else makes and that therefore the resulting classification will
  > be consistent.  There are some that are obvious and some that the debtags
  > system provides assistance for, but there are a lot of borderline cases
  > where I question the usefulness compared to a centrally-administered
  > system with some set of people who imposes consistency.
  
  All very true.  Unfortunately, the sheer quantity of data to be edited 
  in debtags makes it rather impossible to be handled by a central
  committee that can ensure consistency.
  
  I've tried to mitigate this by experimenting with data mining algorithms
  that look for patterns and feed them back to the taggers in the form of
  suggestions, but this is still very far from achieving any sort of
  consistency.
  
  What I intend to do is to form subcommittees by broad topics: "The Gnome
  Guys", "The KDE Guys", "The Web Developers", "The Photographers" and so
  on, and give them the ultimate say on a set of tags, including being
  able to say "these packages are ok and reviewed now, disallow edits for
  all our tags on them".
  
  This needs work, and the software currently running
  debtags.alioth.debian.org can't sanely be extended to do it.  A rewrite
  is in order and planned, but it's unfortunately a one man job, and it 
  takes time.

  Russ: That would be awesome.  I'd be happy to review the Kerberos tags, for
        example, as I have time.


<!-- editor TODO:
  http://www.alistapart.com/articles/userproofingajax

  give some per-facet intro when a facet is selected

  < h01ger> and make a developer-view, with all packages per developer and show a graph per developer :)

        < h01ger> enrico, another todo-item: display (links to edit) e same source-package
        < h01ger> enrico, suite::debian-edu and all the other CDDs are missing :)

        Erich: Maybe you could add some "Loading..." display to the editor, at least for opera? I just tested with opera again, and at first thought it was still not working.
        Erich: It would be interesting to have a button "similar packages". So when you're done editing a package you can easily go to another one you might know.

        Search-as-you-type in the todo.html package list
                do it with a dom visit that gets the package name looking at the text node
                in the right place in the DOM, and sets visibility accordingly
                (this removes the need of remembering the collection)

        Get maintainer/comaintainer package list from
        http://qa.debian.org/data/ddpo/results/ddpo_maintainers, where # indicates a
        comaintained package.

        tag -> facet hints
        proper FAQ

  13:30 #debian-devel < enrico> Sesse: something else that could be done is to show 2 columns: one with the direct
                              results, one with the results coming from the server
        13:31 #debian-devel < Sesse> enrico: oh, but that was never my suggestion. my suggestion was that if I input
                                     "implemented-in::c", it would come up on top. that is, "exact or near exact matches"
        13:31 #debian-devel < enrico> Sesse: and how do I read your mind trying to understand if you're looking for an
                              exact tag match or the other complex search that won't look at tag data at all?
  13:32 #debian-devel < Sesse> enrico: if there's more than three matches, simply don't return them

-->