+++ /dev/null
-**********************
-Fluorine Release Goals
-**********************
-
-Purpose
-=======
-
-This document outlines OpenDaylight's project-level goals for Fluorine. It is
-meant for consumption by fellow LFN projects, the LFN TAC and the LFN Board.
-
-Goals
-=====
-
-Infrastructure Efficiency
--------------------------
-
-OpenDaylight has major infrastructure requirements that can't be mitigated due
-to the large number of tests the community has developed over time. The
-Integration/Test and RelEng/Builder projects have always strove to use
-resources efficiently, to make OpenDaylight's increasingly large test suite
-fit in the same resource allocation. However, OpenDaylight's recent move to LFN
-and the Managed Release model may have unlocked new opportunities to achieve
-equally good or better test coverage at a lower cost.
-
-A few ideas are outlined below, although it's expected others will emerge.
-
-Regular Cost Feedback
-+++++++++++++++++++++
-
-Getting feedback about the impact of efficiency efforts is critical.
-OpenDaylight has requested that LFN start sending out infrastructure spending
-reports. These will allow the community to make data-driven decisions about
-which changes have substantial impacts and which aren't a good work-vs-reward
-trade-off.
-
-Reports should be provided as frequently as possible and should include all
-available data, like per-flavor usage, to help target efforts.
-
-Other LFN projects may find it helpful to request similar reports.
-
-OpenStack Deployments via OPNFV Images
-++++++++++++++++++++++++++++++++++++++
-
-OpenDaylight currently spends significant infrastructure and developer
-resources maintaining our own Devstack-based OpenStack deployment logic. OPNFV
-installer projects already produce VM images with master branch versions of
-OpenStack and OpenDaylight installed via production tooling. OpenDaylight would
-like to move to doing our OpenStack testing using these images, updating the
-version of OpenDaylight to the build under test. Using a pre-baked OpenStack
-deployment vs deploying it ourselves in every job would result in substantial
-cost savings, and not having to maintain Devstack deployment logic would make
-our jobs much more stable and save developer time.
-
-This change wasn't possible in our previous Rackspace-hosted infrastructure,
-but we hope it will be enabled by our recent move to Vexxhost or by running
-jobs that require OpenStack on LFN-managed hardware.
-
-Audit for Unwatched CSIT
-++++++++++++++++++++++++
-
-As part of OpenDaylight's move to the Managed Release model, the Test team will
-have greater freedom to step in and directly manage project's tests. This may
-enable the Test team to disable tests that are not actively watched and make
-other jobs run less frequently.
-
-Cross-Project CI/CD
--------------------
-
-OpenDaylight pioneered Cross-Project CI/CD (XCI) in LFN with OPNFV shortly
-after that project's creation. Since then, both projects and others that have
-followed have realized major benefits from continuously integrating recent
-pre-release versions. OpenDaylight would like to continue and expand this work
-in Fluorine.
-
-OpenDaylight as Infra
----------------------
-
-OpenDaylight's cloud infrastructure runs on OpenStack. We would like to start
-using a released version of OpenDaylight NetVirt as the Neutron backend in
-this infrastructure. This "eating our own dogfood" exercise would make for a
-good production-level test and good marketing.
-
-This change wasn't possible in our previous Rackspace-hosted infrastructure,
-but we hope it will be enabled by our recent move to Vexxhost or by running
-jobs that require OpenStack on LFN-managed hardware.
-
-Expand Contribution Base
-------------------------
-
-OpenDaylight would like to continue bringing new contributors to the community.
-
-For Fluorine, OpenDaylight would like to focus on getting downstream consumers
-involved in upstream development. In an ideal Open Source world, the users of
-an Open Source projects would contribute back to the projects they consume.
-OpenDaylight would like to facilitate this by building special relationships
-between key downstream consumers and the upstream developer community. These
-downstreams could be companies, universities or Open Source projects. We hope
-for contributions in the form of code, documentation and bug reports.
-
-OpenDaylight would like to work with the LFN MAC and TAC to identify a small
-set of downstream users to pilot the program with. The users would provide
-developers with dedicated cycles and a commitment to stick around for the
-long-term. In exchange, the OpenDaylight developer community would prioritize
-training these developers, answering their questions and generally facilitate
-their bootstrapping into the upstream community.
-
-Support Kernel Projects
------------------------
-
-Companies allocating contributors to OpenDaylight tend to distribute resources
-to projects that are directly related to the usecases they are interested in,
-but neglect to give sufficient resources to the kernel projects that support
-them. OpenDaylight's kernel developers are doing a heroic job of keeping the
-platform healthy, but for the long-term health of the project special attention
-needs to be paid to sufficiently staffing these key projects.
-
-OpenDaylight requests that LFN member companies that consume OpenDaylight
-consider contributing developer resources to kernel projects. The new
-developers should be allocated for the long-term, to avoid costing cycles
-for training that aren't repaid by contributions.
-
-Improve First-Impression Documentation
---------------------------------------
-
-OpenDaylight has a tremendous amount of documentation, but much of it is
-written by experienced developers for experienced developers. As with most
-Open Source projects, the experienced developers typically don't look at
-documentation targeted at inexperienced potential contributors. This type of
-general documentation is also typically not maintained by individual projects,
-who are focused on making sure their project-specific docs are in good shape.
-
-To facilitate expanding OpenDaylight's user and contributor base, we would like
-to focus on improving this "first impression" documentation for Fluorine. Since
-it's not realistic to hope for a major improvement from the existing
-contributor base, OpenDaylight requests the LFN Board create a LF staff
-position focused on auditing and working with LFN project communities to
-improve this general, "first impression" documentation. This resource would be
-shared across all LFN projects.
-
-Improve Release Model
----------------------
-
-The OpenDaylight community has developed a new release model for Fluorine. The
-Managed Release Model will facilitate timely releases, provide a more stable
-development environment for the most active OpenDaylight projects, reduce
-process overhead for all projects, give more autonomy to Unmanged Projects and
-allow the Release and Test teams to give more support to Managed Projects.
-
-See the `Managed Release Process`_ for additional details.
-
-Resync Release Cadence
-----------------------
-
-OpenDaylight's release dates need to synchronize with a number of related Open
-Source projects. The OpenDaylight TSC will work with those projects, perhaps
-making use of the LFN TAC, to understand the best time for our releases. The
-TSC will adjust OpenDaylight's release schedule accordingly and ensure it's
-met. We anticipate that the new Managed Release Process will make it easier for
-OpenDaylight to consistently meet release date targets going forward.
-
-In-Person Developer Design Forum Per-Release
---------------------------------------------
-
-OpenDaylight would like to continue having a face-to-face Developer Design
-Forum to plan each release. The community has expressed many times that these
-events are extremely valuable, that they need to continue happening and that
-they can't be replaced by remote DDFs.
-
-OpenDaylight requests that the LFN Board allocate resources for at least one,
-ideally two, days of DDF for each OpenDaylight six-month release cycle. It has
-worked well to host these events in conjunction with other large, relevant
-events like ONS.
-
-.. _Managed Release Process: https://git.opendaylight.org/gerrit/68382/
Code Review / docs.git / commitdiff