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

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

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