This page should be removed!
Make sure that ONOS code-base(s) can be built efficiently, reliably and consistently into a small set of distributable artifacts to make it easy to distribute and deploy ONOS
Make sure that ONOS SDK can be built and released efficiently, reliably and consistently as a set of published artifacts on Maven Central and ONOS project site
Maintenance of the build and release process documentation
Maintenance of the corresponding user (network administrator) documentation
Maintenance of the corresponding developer SDK documentation
Development and maintenance of the build, test and run-time tool kits for developers, testers and users (network administrators)
Development and maintenance of the CI process and release process and supporting tools and working with the team managing the infrastructure
Integration of CI with basic functionality tests (STC) as part of the build & release processes
Maintenance and upstreaming of Gerrit plugins (Module Owner, Stats, Project Lock)
Maintenance of Shared Cells Warden
Investigation (and later execution) of how to disaggregate the ONOS code-base, while continuing the ability to build & release with regular (and frequent) cadence
Development and maintenance of the ONOS archetypes (Maven + Buck)
Deprecation and removal of the legacy build framework
Move artifacts versions to follow semantic versioning
Continue deprecation of legacy build framework
Scrub Wiki documentation
Update affected screencasts (in progress)
Prune CI jobs
Investigate code-base disaggregation
Propose workspace / workflow management tools (e.g. Repo)
Propose specific repository divisions
Propose workspace directory structure
Produce timeline for transition, solicit feedback, present to TST
Including draining or migration of existing code review backlog
Experiment with snapshot/subset of codebase for experience
Investigate build tool deficiencies
Look into Buck deficiencies and ONOS’ fork diffs
Look into build in the context of multiple/different workspaces (i.e. full code, standalone app)
Investigate other Blaze-related tools to see if they overcome limitations more easily
Produce build framework recommendation, solicit feedback, present to TST
Start developing fixes for any deficiencies or new features for proposed build tool
Experiment with snapshot/subset of codebase for experience
Fix build framework as per suggestions of investigation
Execute code-base disaggregation plan
Document workflow for development and release
Including full code (build apps, drivers, core together) and standalone (build part against release artifacts)
Complete deprecation of legacy build framework
Remove all but the top-level pom.xml files
Consider moving publish to entirely standalone Python script (away from Buck)
Begin work on distribution-specific packages (e.g. deb, RPM, Docker container, tutorial and release VMs, etc.)
platform neutral onos.tar.gz, onos-test.tar.gz
various platform specific packages and/or recipes
e.g. deb, rpm, Docker, snap, Ansible, Puppet
API jar bundles (+javadocs, +tests)
Libraries & Utilities jar bundles (+javadocs, +tests)
Java API docs on api.onosproject.org
REST API docs on rest.onosproject.org - later
Document capturing initial thoughts : https://docs.google.com/document/d/1Hdl-ZsttECXZEucskoPNghwsv_H68dtnTnRZrDWgVsg/edit
How to get involved:
contact kspviswa.github@gmail.com