Annotation of wikisrc/projects/project/bulktracker.mdwn, revision 1.2

1.1       dholland    1: [[!template id=project
                      2: 
1.2     ! dholland    3: title="Bulk build tracker application"
1.1       dholland    4: 
                      5: contact="""
                      6: [tech-pkg](mailto:tech-pkg@NetBSD.org)
                      7: """
                      8: 
1.2     ! dholland    9: mentors="unknown"
        !            10: 
1.1       dholland   11: category="pkgsrc"
                     12: difficulty="medium"
1.2     ! dholland   13: duration="unknown"
1.1       dholland   14: 
                     15: description="""
                     16: Currently, bulk build results are sent to the pkgsrc-bulk mailing
                     17: list. To figure out if a package is or has been building successfully,
                     18: or when it broke, one must wade through the list archives and search
                     19: the report e-mails by hand. Furthermore, to figure out what commits if
                     20: any were correlated with a breakage, one must wade through the
                     21: pkgsrc-changes archive and cross-reference manually.
                     22: 
                     23: The project is to produce a web/database application that can be run
                     24: from the pkgsrc releng website on NetBSD.org that tracks bulk build
                     25: successes and failures and provides search and crossreferencing
                     26: facilities.
                     27: 
                     28: The application should subscribe to the pkgsrc-bulk and pkgsrc-changes
                     29: mailing lists and ingest the data it finds into a SQL database. It
                     30: should track commits to each package (and possibly infrastructure
                     31: changes that might affect all packages) on both HEAD and the current
                     32: stable branch, and also all successful and failed build reports on a
                     33: per-platform (OS and/or machine type) basis.
                     34: 
                     35: The web part of the application should be able to retrieve summaries
                     36: of currently broken packages, in general or for a specific platform
                     37: and/or specific branch. It should also be able to generate a more
                     38: detailed report about a single package, containing for example which
                     39: platforms it has been built on recently and whether it succeeded or
                     40: not; also, if it is broken, how long it has been broken, and the
                     41: history of package commits and version bumps vs. build results. There
                     42: will likely be other searches/reports wanted as well.
                     43: 
                     44: The application should also have an interface for people who do
                     45: partial or individual-package check builds; that is, it should be able
                     46: to generate a list of packages that have not been built since they
                     47: were last committed, on a given platform or possibly on a per-user
                     48: basis, and accept results from attempting to build these or subsets of
                     49: these packages. It is not entirely clear what this interface should be
                     50: (and e.g. whether it should be command-line-based, web-based, or what,
                     51: and whether it should be limited to developers) and it's reasonable to
                     52: expect that some refinements or rearrangements to it will be needed
                     53: after the initial deployment.
                     54: 
                     55: The application should also be able to record cross-references to the
                     56: bug database. To begin with at least it's reasonable for this to be
                     57: handled manually.
                     58: 
                     59: This project should be a routine web/database application; there is
                     60: nothing particularly unusual about it from that standpoint. The part
                     61: that becomes somewhat less trivial is making all the data flows work:
                     62: for example, it is probably necessary to coordinate an improvement in
                     63: the way bulk build results are tagged by platform. It is also
                     64: necessary to avoid importing the reports that appear occasionally on
                     65: pkgsrc-bulk from misconfigured pbulk installs.
                     66: 
                     67: Note also that "OS" and "machine type" are not the only variables that
                     68: can affect build outcome. There are also multiple compilers on some
                     69: platforms, for which the results should be tracked separately, plus
                     70: other factors such as non-default installation paths. Part of the
                     71: planning phase for this project should be to identify all the
                     72: variables of this type that should be tracked.
                     73: 
                     74: Also remember that what constitutes a "package" is somewhat slippery
                     75: as well. The pkgsrc directory for a package is not a unique key;
                     76: multiversion packages, such as Python and Ruby extensions, generate
                     77: multiple results from a single package directory. There are also a few
                     78: packages where for whatever reason the package name does not match the
                     79: pkgsrc directory. The best key seems to be the pkgsrc directory paired
                     80: with the package-name-without-version.
                     81: """
                     82: ]]

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb