[Buildbot-devel] WebStatus ponderings

[Dustin J. Mitchell]

On Wed, Jan 6, 2010 at 4:14 AM, Marcus Lindblom <macke at yar.nu> wrote:
> 1. We need to write a testcase that does this. ;)

Anyone want to have some fun with htmlunit?

> 2. All pages that respond to parameters on the URL should have a help
> text or a form where one can enter said data. It helps quite a bit when
> testing these things. (The best way would be to handle this somehow via
> HtmlResource, so that a page could describe it's options and have the
> form be automatically generated and parsed back.)

This would be pretty cool - much better than burying that info in the
manual.  It doesn't necessarily need to be a web form, like the
waterfall help, but that seems like a pretty easy way to set it up.

> 3. Someone (myself?) should hack together a better view of all the
> changes that come in (they're only visible in waterfall, and there's no
> concise list of them anywhere). Also, the ability to link incoming
> changes/revisions to external web-views (hgwebdir.cgi, svnserve, viewvc,
> trac, etc) would be cool & integratey (;-P).

I think that's what the "links" attribute of a Change is for, but this
seems disused.  Perhaps it could be revived?

> 3b. A Repository class would propbablt be a good thing to have, and
> might suit what we're talking about with the multi-repo support. (I
> haven't looked closely at those patches yet.)

I had considered the very similar idea of a SourceManager in the
one-oh work, and it might apply here, too.  A single object that knows
everything about the source of the code.  It would provide
pre-configured Source steps for you, could tell the web status which
changes are which and what order they come in, calculate lists of
changes and blamelists given an arbitrary two sourcestamps, etc.  It's
a cool idea that just needs some further development!

> 4. Some sort of regexp->link to link "#xyz" entries in change comments
> to bug issue pages would also be nice . A new param to webstatus taking
> a regexp substitution and a jinja-filter ought to be enough
> (i.e. we just write {{ c.comments|e|issue_links }} in the template where
> issue_links is a python function applying the regex).

Jinja is going to enable all kinds of goodness, isn't it?

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com