Changes between Version 6 and Version 8 of TracPlugin

Jun 14, 2008, 11:33:02 AM (11 years ago)

Summarized and removed jml's input from the twisted discussion.


  • TracPlugin

    v6 v8  
    3333 * Should all the patch history/timeline events be shown in the normal ticket history, or should there be a separate page for detailed patch history?
    35 === #twisted discussion ===
    37 {{{
    38 <warner> after implementing a couple more status pages, I'll probably merge it to trunk
    39 <teratorn> warner: the code on seems a little out-of-date.. like before we renamed the files from "bbplugin"
    40 <warner> jml: adding builds to the trac timeline, having those link to trac pages that describe the builds (and can point at trac changeset pages)
    41 <-- cablehead has quit ()
    42 <warner> jml: secondarily, a trac page showing the most recent build of each branch/builder
    43  jml: tertiarily, adding buttons to Trac to let committers test patches that have been attached to tickets and mark their "tested good/bad" status on the ticket page
    44 <teratorn> jml: also some patch management stuff.. i.e. run the tests with this patch applied on such and such buildslaves
    45 <warner> (the latter will take a bit more work, but could be pretty cool for the whole patch-review process)
    46 <jml> for sure.
    47 <teratorn> err e.g.
    48 <warner> teratorn: ah, I forget when I last pulled from you. Have you published your tree somewhere? I'll pull from it and push to if you have.
    49 <jml> warner: what's the benefit of having builds in the timeline?
    50 <teratorn> warner: no but I'll do that shortly
    51 <warner> jml: well, so you can see them from trac without going off to a separate buildbot page
    52 <warner> I'm taking some UI cues from bitten, and they do it that way
    53 * spiv waits for what comes after "tertiarily"...
    54 <jml> warner: so, before I jump off and say a bunch of other things, all this sounds very cool and useful :)
    55 <warner> quadrilaterally? :)
    56 <spiv> Haha
    57 * warner just discovered that after quaternions and octonions there are sedonions
    58 <spiv> "This job is for the squares in the crowd!"
    59 <warner> which made my world
    60 <jml> almost all the time, I only care about the most recent build. When I care about other builds, it's almost always to find the last working build.
    61 <warner> jml: I go back and forth on whether this will all add actual new functionality (well, except for the patch-review thing, which I really think is new stuff). but people seem to want it.
    62 * warner nods
    63 <jml> the remaining fraction of concern is almost entirely made up of wanting to find the last failing build (in case of intermittent error)
    64  I imagine that most people are like me in this.
    65 <warner> yeah, I think that sort of stuff will just live in the buildbot, on some of the new status pages
    66 <jml> And I think that the timeline might not be the best way of supporting these use-cases.
    67 <warner> the trac thing is mostly so you can get from builds to other trac pages (like tickets and changesets)
    68  agreed
    69 <teratorn> jml: could I convince you to do a brain->wiki transfer? :)
    70  teratorn termie
    71  just add a new section or something "jml's crazy ideas" or something :)
    72  teratorn termie
    73  jml: note that that page is not comprehensive or even well thought out in the least
    74 <jml> sure
    75 <spiv> I think people usually want to be edge triggered when it comes to build success/failure status.
    76 * jml pastes this conversation and leaves it for the wiki fairies
    77 <warner> yeah, maybe a page that shows at most one line per build, but elides stretches of builds with the same results
    78 <spiv> "Still passing" and "Still failing" are both less interesting than a change in state.
    79  Although intermittently failing tests obviously screw with that.
    80  (But they screw with everything that's good and proper :( )
    81 }}}
     35=== jml's crazy ideas / #twisted discussion ===
     36 * The most common use cases warrant an edge-triggered display of builds
     37   * When did builds stop/start failing?
     38   * What was the last build that worked?
     39 * Tying these spans to a full diff would also be useful.