[Cocotb] The future of Cocotb

David Stanford david.stanford at gmail.com
Wed Sep 26 12:21:59 CEST 2018


I'd also be interested in helping out.

There's a lot you guys want to get done, so it'll be hard to coordinate all
of that in this email thread, but I agree with Luke that a key starting
place is working through outstanding issues on GitHub keeping this list of
goals in mind. Even without any permissions changes on GitHub, folks can
take initiative to comment review and talk about if changes seem
appropriate for mainline, experimental, or extensions integration branches.

On Tue, Sep 25, 2018, 22:13 Luke Darnell <luke.darnell at broadcom.com> wrote:

> This is great to hear Chris.
>
> I'd love to get involved.
>
> Stemming the continual flow of unresolved issues and open pull requests
> seems like a good place to start.
>
> As of today (26th September, 2018) we have 145 open issues and 36 pending
> pull requests.
> Would be great to see this number starting to go down (or at least not
> going up).
>
> Seems like at a minimum people can start reviewing any pending pull
> requests on github.
>
> For issues, as we discussed at Orconf, github comments aren't the greatest
> place for a discussion.
> Can I suggest for any non-trivial issues, we start a thread on the mailing
> list?
>
> Perhaps we can do the same for pull requests that implement a major new
> feature or that might break backwards compatibility?
>
> I can start doing this and see how it works out.
>
> Luke
>
>
> On Mon, Sep 24, 2018 at 8:06 PM Chris Higgs <chris.higgs at potential.ventures>
> wrote:
>
>> 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
>>
> _______________________________________________
> 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/20180926/bf2a828b/attachment.html>


More information about the cocotb mailing list