List view
It should be possible for someone to check out the core Kythe repository, plus any additional repositories needed to obtain language support, and straightforwardly run a build, index, postprocessing, and cross-references server from end-to-end. This is partly a UI goal, in that it may entail some additional tools—but most importantly we need to ensure that all the tools are present and available, and well-enough documented to be used in isolation.
No due datePresently there are three file-based storage formats for compilation records ([indexpack][], [kindex][], and [kzip][]), and analyzer tools must explicitly support any of these they want to consume. Three formats is two too many, and it is a lot of work to add support for them in a new language. Standardize on a single storage file format, [kzip][], and obsolete and remove support for indexpack and kindex files, whose desirable properties the kzip format already subsumes. [indexpack]: http://www.kythe.io/docs/kythe-index-pack.html [kindex]: http://godoc.org/kythe.io/kythe/go/platform/kindex [kzip]: http://www.kythe.io/docs/kythe-kzip.html
No due date•6/6 issues closedWe should define and follow a reasonably-consistent release schedule for binaries and repo tags.
No due date•1/1 issues closedThe main Kythe repository has a large dependency footprint, in part because in addition to the core schema, documentation, and support libraries, we also have several indexers checked in. Partition the main repo so that it is easier to check out and work with individual components, without having to install everything. The resulting partition should make it easier for contributors to work on individual indexers, without making core development too painful.
No due date•1/1 issues closedImplement and document a postprocessing tool for cross-references based on Kythe graph artifacts. The existing tools have fallen behind changes in the API definitions.
No due date•0/1 issues closedThere are a variety of missing and incomplete aspects of the Kythe documentation. To make a stable release possible, these things need to be cleaned up and updated.
No due date•2/4 issues closedSince the loss of our managed Jenkins setup a few years ago, we have been relying on script hooks to ensure all the appropriate tests get run for changes pushed to the Kythe repository. We should have automation to ensure that commits are properly tested—ideally both pre- and post-submission.
No due date- No due date•2/2 issues closed
This milestone tracks the high-level goal of defining a 1.0 release for the Kythe project. Broadly this has two components: Defining what 1.0 means in terms of quality and stability; and also a collection of specific deliverables that must be implemented in order to satisfy that definition.
No due date•1/2 issues closed