[Cocotb] The future of Cocotb

Chris Higgs chris.higgs at potential.ventures
Mon Sep 24 12:05:47 CEST 2018


Greetings All,

TLDR; If you would like to get involved in maintaining and shaping the
future direction of Cocotb we are looking for volunteers to help run the
project - please reply on this thread if you would like to get involved!

There has been some discussion about the management of Cocotb and the lack
of input from Stu and myself over the last year or so.  The upstream repo
has languished, PRs have been open for some time, there haven’t been any
tagged releases and generally the project has not kept up the momentum
despite accumulating an ever growing user base.  Please accept our
apologies for this state of affairs - we want to fix this and find a way to
ensure that Cocotb can thrive without us getting in the way.  We used the
recent 2018 ORConf conference to announce our intention to solve this, but
there are still a lot of details to be worked out to make it happen.

We need to figure out a way to hand control of the project over to the
community and put in place structures and guidelines to facilitate
colloboration.  We need to appoint maintainers for different areas of the
project. The FOSSI foundation has helped tremendously by doing things like
setting up this mailing list and organising great conferences.  However
while they may be able to provide some resources for helping out with
regression testing, if Cocotb is going to become a community driven project
then ultimately it is down to us as a community to work out how the project
should be structured and take it forward.

Here are some initial thoughts from my perspective of things we could do to
start working towards that goal.

1. We need to figure out a process for contributing to the project and
document it.

2. We need to make it possible for more developers to get involved in
reviewing and merging code onto the upstream repository. Ideally we could
appoint maintainers for various parts of the codebase who decide if
something is ready to be merged.  If we cannot find maintainers, we could
try and achieve some degree of consensus via the review process.  For
smaller bug fixes etc if the regressions all pass anybody with permissions
should feel confortable merging so we keep a reasonable turn-around time
for getting contributions into the upstream.

3. We could create a branch on the upstream (experimental or unstable or
similar) where people felt more inclined to merge new stuff. Then things
can make it upstream and issues and wrinkles get ironed out, but there can
still be a wider discussion before a feature goes into master. That would
solve the situation we have currently where a lack of merging mean people
are often pointing at forks because upstream is moving too slowly. This
also ties into the fact that we’re not really versioning properly so most
people use a checkout and we don’t have stable releases, which means
merging to master can break things for people.

4. We should figure out a way of for extensions to functionality to be
provided without necessarily needing to go in upstream, or permit multiple
implementations to exist side-by-side. For example with coverage, there are
a few ways of doing it so arguably they should all be available as
extensions and people could use whichever is most appropriate, rather than
mandating only one way in the “official” repo.

We need extensions to be easily discoverable and there are a few options
for this - for example we could maintain a list of extensions/BFMs in the
repository itself. It would be good to define some guidelines and
discoverability mechanisms for plugin authors that help make it very simple
to find and install plugins while avoiding some of the problems that can
arise such as namespace collisions. We could use LibreCores to aid
discoverability by finding extensions that exist in Github.

To me this path seems more scalable than continually adding stuff in and
means it can evolve much faster.  In theory the “core” of cocotb that
abstracts VPI/VHPI into Python will be relatively stable.

I’m thinking something like:

pip install cocotb-coverage

Where coverage could live in an externally maintained repo... then there’s
no barrier to layering on features and multiple competing implementations
can coexist. There are plenty of examples of this style of
plugin/extensions so it’s not unusual to follow this model, we just need to
ensure we have thought through the implications of things like namespaces,
regression testing and versioning to avoid things getting broken.

5. We need to find a solution to regression testing against proprietary
simulators.  Again this is something where we might be able to enlist help
of the FOSSI foundation if there is infrastructure we need to do this in
addition to the Github/Travis services we are already using.

6. We need to start doing versioned releases and pushing them to PyPI.

There was a lot of interest at ORConf from people wanting to get involved
in Cocotb, let’s try and continue momentum!

Cheers,

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/cocotb/attachments/20180924/0c9eab87/attachment.html>


More information about the cocotb mailing list