90adcef9ca6b26c9d508664c633223ad1a47444e
[debtags/debtagsd.git] / TODO
1 Patch review: show when a patch is just a patch or when it also contradicts other patches in the pool
2  - if it contradicts other patches, on save the other patches are automatically amended
3
4 Milestone: moar reports!
5
6 projectb:
7  binaries_metadata + metadata_keys gets the control file fields for Tag: fields in control files
8  then I can do the merge with the DB taken from debtags.d.o
9  then I can produce the new overrides
10
11 12:27 #debian-it < pinotree> enrico: mentre aggiungo/rimuovo tag, la lista "current tag" potrebbe rimanere in ordine alfabetico?
12
13 Show search results grouped by source package
14
15 Simpler interfaces (like card-showing, or popcon on own system driven tagging
16 things)
17  - Mozilla openbadge API
18  - "I'm a gnome tagger" / "I'm a top tagger"
19  - tagging games
20  - filter by section
21
22 Push for an AMQP server in Debian "bug reported" / "dak has run" / "..."
23
24
25 09:11 #debian-devel: #debian-devel < pabs> enrico: now sorting by distrowatch index in descending popularity 
26                                            (missing distros get popularity 0): 
27                                            http://dex.alioth.debian.org/census/debtags
28 09:13 #debian-devel: #debian-devel < pabs> enrico: btw, please ping me when you have integrated other 
29                                            derivatives, so I can update 
30                                            http://wiki.debian.org/Derivatives/Integration
31
32
33 a-x-i does not consider foo:amd64 multiarch package names as referring to the same package
34 22:13 #debian-devel < DonKult> enrico: you can: echo 'APT::Architectures { "amd64"; "i386"; };' > 
35                                /etc/apt/apt.conf.d/00multiarch  # then apt-get update and you have an apt with amd64 and 
36                                i386 packages in the cache. Just don't try to install i386 packages as dpkg will bail out 
37                                (using apt from experimental would be better though, but optional)
38 22:31 #debian-devel < ol> enrico: there are two options - one is to ensure you add a single entry for each package, 
39                           merging the arch lists if you store those, and the other is to put the package name in a 
40                           document value and collapse on it
41 22:32 #debian-devel < ol> the former is better if it's easy to do
42 23:23 #debian-devel < DonKult> enrico: thinking about it, as ubuntu has already deployed multiarch for (i think) 2 
43                                releases they may have already a complete patch for apt-xapian-index…
44 23:25 #debian-devel < DonKult> enrico: i wild-guess its that one: 
45 http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/apt-xapian-index/precise/revision/27
46 23:26 #debian-devel < enrico> DonKult: it defintiely looks like it's that one
47 23:26 #debian-devel < DonKult> which might be wrong, as this wouldn't index foreign packages, or?
48
49
50
51
52 04:26 #debian-devel < pabs> enrico: once alioth comes back, this will be generated daily: 
53                             http://dex.alioth.debian.org/census/debtags
54 04:32 #debian-devel < pabs> enrico: thats this until vasks returns: 
55                             wagner.debian.org:/home/groups/dex/census/var/debtags 
56 http://distrowatch.com/text/fullphr-52.txt
57
58  - Export overrides for the various distributions
59
60  + tags in control files
61     - used by maints to say "tags are good now, freeze"
62     - used to sort difficult situations (renames over history)
63     - how to manage one version of a package with tags from control files and
64       another version with tags from overrides?
65        - I can drop overrides for packages with tags in control, but that will
66          drop them for all versions, and you can't add them to the control
67          files of older versions
68        - Or I can import tags from control files into overrides, replacing the
69          stable ones from the site, but then the overrides override with the
70          same tags for all versions
71        - other options?
72
73 13:22 #debian-devel < enrico> zigo: uhm, I could also add a "list packages of maintainer $FOO" option to 
74                               http://debtags.debian.net/edit/tags/suite::openstack
75 13:23 #debian-devel < enrico> zigo: or even "I'm maintainer $FOO" in the settings, so there's no need to 
76                               fill up an email address every time
77
78  - special interest "marketing" pages
79     - cloud
80     - games and other go*
81     - call to d-devel for more
82
83  - Bytag editor: see more results in the search boxes
84    Myon> enrico: how do I get the rest of the result? I only shows about 40 of 466 for 
85          "postgresql"
86    enrico> Myon: still unimplemented. It's irritating, isn't it? I'm trying to work out 
87            what's a nice way to implement that right now
88
89  - in maintenance output, divide stats of packages updated because of new
90    versions and packages updated because of popcon changes
91
92  - RSS feed with changes to tag vocabulary
93
94  - Widgets
95     - settings dialog
96        + distributions of interest
97        - show tag/facet names or descriptions
98     - standardised package / tag presentation functions
99        - customisable package widget
100           - interfaces with a patchset to update its tag list as patches happen
101     - floating patchset that disappears if there are no patches
102     - tag chooser (all tags list in editor, packed in a reusable dialog)
103        - based on a vertical tab layout?
104     - tag clipboard
105
106  - Patch review
107     - when reviewing a patch, collect changes from all the other patches and
108       show them all together: so there's a good overview of that package in the
109       patch queue
110     - when an amend is applied, it needs to be applied to ALL patch-bytag dirs
111       that would require it, otherwise things resurface until this is done by
112       hand
113        - even more, when a patch is approved, its appropriate subset needs to
114          be applied as an amend to all patches that conflict with it
115
116  - Per-package log
117     - one table (timestamp, type, json)
118     - log json so it's easier to process extra info per log entry type
119     - log on package updates instead of using log.info
120     - log when applying patches
121     - initial log entry "indexed before logging system was implemented"
122
123  - Reports
124     - plottare il numero di patch per giorno e vedere se ci son dei trend
125        - table on the DB with per-day counts
126        - update per-day counts based on the timestamp in patch file names,
127          collected during maintenance
128        - restore historical data
129           - function that scans a .tar archive looking for .patch files, and
130             takes note of the timestamp in the name
131           - run it regularly on the backups, to correct glitches in incremental
132             data collection
133     - query reports dynamically via API, so that next/show more don't need a
134       reload, and that new packages can be loaded after quick fixes are applied
135     - 'next' or 'show more' in report pages
136     - allow to apply quick fixes also in the check reports
137     - pinotree> invece di una pagina con pagine per le categorie, sarebbe possibile una sola 
138                 pagina con i tag nelle varie categorie leggermente indentati?
139
140  - Checks:
141     - allow to apply quick fixes also in the patch reviewer
142
143  - Send vocabulary commit emails via svn hooks to debtags-devel@l.a.d.o
144
145  - copypaste tags
146    Myon> enrico: some "copy tags from $otherpkg" facility would be helpful, e.g. for 
147          postgresql-$version-somemodule
148    Myon> I guess it would be useful in other cases to have in the webinterface
149    Myon> (I'm pondering to make the -$version- part in PG modules go away)
150    enrico> Myon: it's rather nontrivial, ui-wise, given a package, to select another one to 
151            copy tags from. I can probably do some "copy tags in a cookie" / "paste tags 
152            from cooke" feature, though: would that be useful?
153    Myon> probably, yes
154    enrico> Myon: so it's "add tags from clipboard cooke" and "replace tags with cliboard 
155            cookie", right?
156
157
158 Milestone: distromatch interesting files
159
160  - Data sources
161     - Interesting files from distromatch
162  - Show interesting files in pkginfo report
163  - autotagger from interesting-files
164     - if it contains [usr/]bin/* then package it role::program
165     - if it contains [usr/]lib/*.so.* then package it role::shared-lib
166     - if it contains [usr/]lib/*.a then package it role::devel-lib
167
168
169 Milestone: all the rest
170
171  - "Press"
172     - Blog the /search/ function and mention that it works also on local apt-xapian-index
173     - Blog the /search/bytag/ function and mention that it works also on local apt-xapian-index
174     - Ask debian-devel about the reusable bits that have been put together
175        - django debian layout app
176        - debdata/
177
178  - Patch review
179     - load vocabulary.js and offer tooltips like in the tag editor
180     - after aggregating patches, compute a sanity index for the aggregated patch
181     - patch approval
182        - todo list item 'has changes needing approval'
183        - backend
184           - salvare una proposed-patch, testuale, per pacchetto
185           - in fase di approvazione, il tagset reviewed del pacchetto è editato
186             con la proposed-patch attuale
187           - semplificazione-pulizia delle proposed patch all'importazione del
188             nuovo set di tag stable
189           - export e backup delle proposed patch del giorno
190           - log delle review (chi fa cosa e quando)
191             (timestamp, user, pkg, text-patch)
192        - approvatore per piú pacchetti
193           - autenticazione al momento su user DB custom
194             (sentire come integrare in qualcosa di piú integrabile)
195           - pagina con pacchetti ordinati per popcon
196           - pagina con pacchetti raggruppati per sorgente, pacchetti per maintainer
197           - sullo stile delle todo, ma coi widget di approvazione
198           - approvazione per-submitter, aggregando con il patch tag (ordinando
199             per dimensione delle patch aggregate)
200           - patch queue separata coi risultati delle approvazioni
201           - jquery ui widget con l'approvatore per un pacchetto binario
202           - submit per pacchetto e per pagina
203        - the unstable and stable DBs could go out of sync, in the sense that after
204          reviewing all the patches they could still have differences. They can be
205          easily fixed by turning the differences into a patch and reviewing it as
206          usual.
207     - bytag patch review page
208        - hover on a facet shows the facet info, including the list of tags
209     - Patch review
210        - reverse patch review: show a tag and all packages added/removed to it
211           - apply the resulting patch to the stable tag db
212           - apply the resulting amend to all patches
213        - have users that are only authorized to review by one or more tags (not
214          really needed at this stage)
215
216
217  - Autotagger
218     - autotagger: xapian search tags, add those with a weight higher than $foo
219     - autodebtag
220        - aggiungere tag tramite il motore di tip
221        - if it depends on packages in section "oldlibs", tag maint::oldlibs
222          maint::transitional
223        - infer implemented-in from build-deps
224        - merge coi tagcheck
225           - fare tagcheck che possa usare delle data source extra (per deps e arches)
226           - aggiungere, oltre alla formattazione di un tagcheck, il rendering come patch
227           - lanciare tutti i check sia come tips (per i manually maintained)
228             che come robot patcher (per i robot-maintained)
229     - do not even offer -dbg packages for tagging: just tag them
230       role::debug-symbols and be done with them
231        - double check the other tags in the current role::debug-symbols to see
232          if there could be a reason for other tags to be there
233          YES: dummy -dbg packages
234     - autotagging rules for postgres
235       Myon> enrico: some "copy tags from $otherpkg" facility would be helpful, e.g. for 
236             postgresql-$version-somemodule
237       enrico> Myon: if you give me a rule for postgres, I can automate it. I do it
238               for kernels and shlibs
239
240  - Tagging
241     - tagger from the tag point of view
242        - next and prev buttons to paginate the two result lists
243
244     - package lists
245        - compute and show tips on package tagsets
246
247     - filter/format current and possible lists according to the tag patch
248
249     - compute a per-tag list of inference rules, and load it in the per-tag
250       review page to offer a list of quick fixes for every package
251
252  - Data sources
253     - Download data files keeping track of last-modified in HTTP headers
254     - Also keep track of sha256sums of files at index time
255     - Support more derivatives
256       pabs> I saw you allow debtags for Ubuntu-only packages, how about including other derivatives? 
257             you could use the sources.list snippets on http://wiki.debian.org/Derivatives/Census
258       pabs> we already do that for planet.debian.org/deriv, the way it works is that the derivatives 
259             census scripts generate a config for you: http://wiki.debian.org/Derivatives/Integration
260       pabs> if you are just pulling package info from UDD, then I guess that can wait though
261       enrico> the census git isn't that straightforward. What I need is, for each distro, a name for 
262               the distro and a list of Packages files
263       enrico> best points if I can avoid anonymous people add 'debian' or 'ubuntu' distros to the wiki 
264               pointing to packages files containing insults
265
266       enrico> pabs: thanks, the order of source files looks good now. Another question is the order of 
267               distros
268       enrico> pabs: if I use that, package info from AlienVault-OSSIM has priority over that in Ubuntu. 
269               It would probably make more sense to list the most popular distros first
270       enrico> pabs: although that bit might be tricky
271       enrico> pabs: I can work around that by maintaining a hardcoded list of popular distributions, and 
272               then import all the others in whatever order
273       pabs> cool
274       enrico> pabs: is there a place that says how popular a distro seem to be?
275       pabs> distrowatch maybe?
276       enrico> pabs: just to introduce some more fairness in the process than "Enrico heard about it"
277       enrico> pabs: right, they do have some stats. I hope the distro names match
278       pabs> enrico: the wiki pages have distrowatch links for most distros, perhaps I could download 
279             stats using that and impose some ordering from there
280       enrico> pabs: that'd be fantastic
281
282
283     - Nuove info nel DB
284        - info maintainer overrides sui tag
285        - info subscriber nel PTS
286     - per-package storage of extra data
287        - use the autodebtag patch as a source of hints: for each package keep
288          the generated autodebtag patch and a description of why then it can be
289          picked up by a tag checker which if the patch is not applied suggests
290          the given tags and picks up the description
291
292        - same idea can be used using apriori to compute more likely tagsets for
293          a given package, then stored in a per-package storage and used by the
294          checker
295
296        - store in a per-package storage also some tagging constraints for the package
297          (which can be edited by the maintainer)
298
299     - use apriori to evaluate the tagging of a package:
300        - rank possible new tags by feeding it only the tagsets that are
301          supersets of the package tags
302        - rank possible tags to remove by looking at the frequencies of all
303          tagsets that are subsets of this one
304        - count the frequency of similar tagsets: a possible optimization could
305          be to feed apriori with the tagset count (-w integer transaction
306          weight in last field)
307     - reviewer constraints added as patch lines in a package text attribute
308
309  - Exports
310     - debtags for other distros, via dde or distromatch
311
312  - Reports
313     - Wording confusion at http://debtags.debian.net/reports/maint/
314       Myon> I stopped typing when it said "myon" was ok, while in fact myon@debian.org is what works
315       enrico> atm I'll fix the wording, then I'll add to the todo list to also validate the 
316               field contents in the background
317       Myon> enrico: ok the wording make sense now, but imho it shouldn't replace EMAIL then
318       Myon> enrico: it's still not clear that I need to click on some "random" link after the 
319             input field
320       enrico> Myon: <enter> wouldn't work if you had more than one report per maintainer, 
321               which is what I had in mind
322       enrico> Myon: the original idea was to have that page as a link generator for all 
323               per-maintainer reports; however I can also decide to have one main 
324               per-maintainer report and link to the others in the related pages box in the top 
325               right
326
327     - tag stats: all tags sorted by name, number of packages (ascending or
328       descending), facet then name or number of packages (ascending or
329       descending)
330     - list of frequent itemsets
331     - allow to filter report pages by tag, keywords, section, distribution, ...?
332     - pkginfo
333        - link to full file list
334        - link to Homepage
335        - link to Vcs browser
336     - upload popcon report file and get a todo page based on it
337     - enrico> buxy: make it http://debtags.debian.net/edit/{$escaped-binary-package}
338       enrico> buxy: or get rid of it, as you wish. If you'd like a link to a per-source package, 
339               I can create it
340       enrico> s/package/page/
341       pabs> enrico: a per-source package page would be nicest
342       buxy> well, that would be great yes, but in the mean time we're using the per-maintainer 
343             view with the correct anchor
344     - RSS feed of tag changes per package or per maintainer or per tag
345     - reports/health
346        - age of each data source
347        - time since last patch was submitted
348        - time since last patch review
349     - inspection pages
350        - have all the various maintenance / autodebtag checks write a copy of
351          their output to a pickled maintenance log, which can then be loaded by
352          report pages
353        - inspection/test of algorithms for tag checking and autotagging
354        - inspection of all available data about a package
355        - age of all input sources
356        - stats, stats stats: submissions, patches approved, patches amended,
357          lifetime of a tag cookie, ...
358     - url with per-binary tag info / todo list
359     - url with per-source tag info / todo list
360
361  - Tag checks
362     - enrico> I'd need to give it some thinking, but I'd be inclined to say that 'scope::*' 
363               only makes sense for role::program packages
364
365  - Maintenance
366     - do not just remove per-package storage dirs when the package
367       disappears, but move them to backup instead
368       (easy to do since we have the package list in memory)
369
370  - Things that were already broken/untested/unused in the old site
371     - prod pages (servono ancora?)
372     - tag QA (li usa qualcuno?)
373
374  - Tag/check overrides
375     - One patch per package that is applied to a tagset before running checks
376       (it would likely trigger misleading checks that believe the wrong tag is
377        there)
378     - An 'enforcing' patch, which can also contain positive or negative facet
379       patches, that is specially evaluated by the checks to see if they should
380       silence themselves
381     - Some check-specific override string, generated by the check, that can be
382       used to instruct a future run to silence itself
383
384  - Editor
385     - enrico> Myon: although yes, I could highlight those facets that according to some 
386               considerations could be 'more interesting' at one given moment
387                - if program then suite, if gameplaying then game, if field then
388                  science, ...
389
390  - special::needs-review tag
391    Myon> anyway my point was I was trying to improve by saying "please someone have a look 
392          (I don't want to currently)", but there's no way to do that
393    Myon> ok for the bottom line, please consider adding some way for people to make stuff 
394          as "needs review"
395    enrico> Myon: special::needs-review sounds good, /me adds to todo list
396
397  - enrico> Myon: the workflow is incomplete: it misses the part where a maintainer, after 
398            some way of authentication, can declare tags on a package as "finished"
399
400  - API
401     - python-piston?
402        - distro object (GET packages and infos)
403        - bin package object (GET info, PUT tags)
404        - src package object (GET infos)
405
406 https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related (1.3 only)
407
408 09:48 #debian-devel < enrico> pabs, buxy: I'm not sure I'd like to try all per-binary package links from the 
409                               PTS to see if there's work to do. Doesn't the per-maintainer link provide 
410                               enough of an overview?
411 09:49 #debian-devel < pabs> enrico: well, say you want to debtag one of the perl team packages but not all of 
412                             the hundreds of them
413 09:50 #debian-devel < buxy> enrico: Yes I tend to prefer it too (that's why I said "if we go that way"), but 
414                             it's not really ideal. Lintian has a similar view that we use but at least it 
415                             provides an anchor "#foo" to see the relevant entries immediately
416 09:53 #debian-devel < enrico> buxy: group by srcpackage in the per-maint page is a good idea, indeed. And 
417                               with an anchor, yes
418 09:53 #debian-devel < pabs> for the Debian fonts review we cat all the binary package reports together
419 09:57 #debian-devel < buxy> pabs: so I would suggest to use the per-maint view and you add an anchor #source, and 
420                             when enrico implements it we'll be good, and in the mean time people will have to search 
421                             manually (in the few cases where the list is really huge)
422
423 Allow to ignore suggestions, simply through the idea of tag hints (bits of
424 authoritative tag patch provided by maintainers)
425
426
427 Site:
428  - tags are attached by package version as well
429  - tags automatically flow from old versions to new versions when new versions
430    appear
431  - tags are added to a given version, or to the newest of not specified
432  - store a file in a VCS writable by all DDs with 'tag locks':
433       package1: +tag1, -tag2
434       package2: +tag1, -tag3
435    to use to prevent some additions or removal to be done via the web interface.
436
437 Packages are linked to "suite" (lenny, testing, sid, karmic, ...)
438 Updates are done by sending the list of (package,version) to the "suite" data
439 source and retrieving a list of changes ("changed", info) or ("deleted", info)
440 (package,version) couples that do not exist in any suite are removed. As a
441 consequence, for every (package,version) it is possible to show a list of
442 corresponding suites.
443
444 Users are tracked by email or by cookie.
445   Cookie  Name       Email
446   cookie  name|NULL  email|NULL
447 Changes are tracked by user
448 History table with all the changes (package, version, add/remove, tag)
449
450 package,version,tag,user mapping tables
451  - More than one (site, reviewed)
452 constraint tables (package, version|NULL, has/hasnt, tag, user responsible for
453 constraint)
454
455 --
456
457 Specialist Committees:
458   > This is one of the reasons why I find working on debtags for my packages
459   > rather unrewarding.  I have no real indication that the decisions I'm
460   > making about what tags make sense have much in common with the decisions
461   > everyone else makes and that therefore the resulting classification will
462   > be consistent.  There are some that are obvious and some that the debtags
463   > system provides assistance for, but there are a lot of borderline cases
464   > where I question the usefulness compared to a centrally-administered
465   > system with some set of people who imposes consistency.
466   
467   All very true.  Unfortunately, the sheer quantity of data to be edited 
468   in debtags makes it rather impossible to be handled by a central
469   committee that can ensure consistency.
470   
471   I've tried to mitigate this by experimenting with data mining algorithms
472   that look for patterns and feed them back to the taggers in the form of
473   suggestions, but this is still very far from achieving any sort of
474   consistency.
475   
476   What I intend to do is to form subcommittees by broad topics: "The Gnome
477   Guys", "The KDE Guys", "The Web Developers", "The Photographers" and so
478   on, and give them the ultimate say on a set of tags, including being
479   able to say "these packages are ok and reviewed now, disallow edits for
480   all our tags on them".
481   
482   This needs work, and the software currently running
483   debtags.alioth.debian.org can't sanely be extended to do it.  A rewrite
484   is in order and planned, but it's unfortunately a one man job, and it 
485   takes time.
486
487   Russ: That would be awesome.  I'd be happy to review the Kerberos tags, for
488         example, as I have time.
489
490
491 <!-- editor TODO:
492   http://www.alistapart.com/articles/userproofingajax
493
494   give some per-facet intro when a facet is selected
495
496   < h01ger> and make a developer-view, with all packages per developer and show a graph per developer :)
497
498         < h01ger> enrico, another todo-item: display (links to edit) e same source-package
499         < h01ger> enrico, suite::debian-edu and all the other CDDs are missing :)
500
501         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.
502         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.
503
504         Search-as-you-type in the todo.html package list
505                 do it with a dom visit that gets the package name looking at the text node
506                 in the right place in the DOM, and sets visibility accordingly
507                 (this removes the need of remembering the collection)
508
509         Get maintainer/comaintainer package list from
510         http://qa.debian.org/data/ddpo/results/ddpo_maintainers, where # indicates a
511         comaintained package.
512
513         tag -> facet hints
514         proper FAQ
515
516   13:30 #debian-devel < enrico> Sesse: something else that could be done is to show 2 columns: one with the direct
517                               results, one with the results coming from the server
518         13:31 #debian-devel < Sesse> enrico: oh, but that was never my suggestion. my suggestion was that if I input
519                                      "implemented-in::c", it would come up on top. that is, "exact or near exact matches"
520         13:31 #debian-devel < enrico> Sesse: and how do I read your mind trying to understand if you're looking for an
521                               exact tag match or the other complex search that won't look at tag data at all?
522   13:32 #debian-devel < Sesse> enrico: if there's more than three matches, simply don't return them
523
524 -->