[Cocotb] The future of Cocotb
themperek at gmail.com
Tue Sep 25 12:26:21 CEST 2018
Dear Chris at.al.
Thank you for your email. This is great news.
I can definitely help with packaging/CI and testing. I will try to
- Since the project is bit larger should we use gitflow for development?
- We could introduce the rule that 2 maintainers have to review the the PR
for acceptance (especially for features) for small bug fixes 1 would be
- Make regular releases (some planning needed).
I could organize a teleconference to discuss things if you find it useful.
On Mon, Sep 24, 2018 at 12:06 PM 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!
> cocotb mailing list
> cocotb at lists.librecores.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cocotb