[Cocotb] The future of Cocotb

Paebbels paebbels at gmail.com
Tue Sep 25 21:51:35 CEST 2018


Hello Chris,

nice to see some movement in Cocotb again. But actually, your email is very
similar to what Stuart posted
1.5 years ago on GitHub:
https://github.com/potentialventures/cocotb/issues/513#issuecomment-280936149
I hope this time, we'll see a change, so cocotb can develop further without
waiting months for PR accepts.

Currently, my open source time is a bit limited, but I still like to help
out in topics related to GHDL.

Going forward with the Cocotb repository:
1. Create labels and start to classify all issues and PRs in the system to
get an idea what content was created
    by the community in the last years.
2. Create a block diagram of Cocotb to describe that parts are interacting
how, so you can defined maintainable
    islands.
3. Prefer issues and PR that fix bugs in cocotb to allow e.g.
interaperation with state-of-the-art Python versions
    or ModelSim versions.


Kind regards
    Patrick


Am Mo., 24. Sep. 2018 um 12:06 Uhr schrieb Chris Higgs
<chris.higgs at potential.ventures>:

> 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
>
> _______________________________________________
> cocotb mailing list
> cocotb at lists.librecores.org
> https://lists.librecores.org/listinfo/cocotb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/cocotb/attachments/20180925/8d744081/attachment-0001.html>


More information about the cocotb mailing list