[Libre-soc-bugs] [Bug 422] Migrate away from nmigen Record

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=422

--- Comment #3 from whitequark at whitequark.org ---
> awygle's comment here that Record.connect is "not used" is incorrect

Which comment? I do not see anything that says "not used" on that page.

> in the 75,000 lines of code in libre-soc, we make substantial use of
> Record (the entire codebase relies on it), and also use Record.connect
> in a number of places.

First: the amount of code relying on a bad design does not affect the fact that
a bad design should be replaced with an improved one. It only affects the
amount of effort that goes into providing compatibility with existing code, and
into making migration easier.

Second: you, personally, have been vocally opposed to the current design of the
Record and asked for several aspects of it to be changed. The future
deprecation and replacement will serve your needs as well, and has been
planned, in part, with your project in mind.

Third: if time constraints on your project prevent you from migrating off the
existing Record design, you will have:
  a) The deprecation grace period between, at least, release 0.4 (which is the
earliest release where Record may be deprecated) and release 0.5 (which is the
earliest where Record may be removed). The next release is 0.3.
  b) the ability, after Record is removed upstream, to take the removed code
and use it, unmodified other than for the imports, in your codebase
indefinitely. This is another aspect that has been planned while considering
your project.

In my view, this means that you are not materially constrained in any way
whatsoever by the upstream decisions on Record.

> any modifications to the IEEE754 FP library (45,000 lines of code)-
> which critically depends on Record existing - come with a penalty of
> requiring a *week* of 100% CPU on high-performance machines to run
> several hundreds of thousands of unit tests and regression tests.

The run-time of your test suite should become significantly lower once you
migrate to the release 0.3. This has been planned while considering your
project (in fact you paid me for it) and discussed with your team members.

> i also feel compelled to point out that it is of some significant
> concern to hear of major design decisions to remove critical functionality
> for the first time via 3rd hand notifications where none of our team have
> been involved or consulted as to the implications

I have informed the CEO of your corporation, Immanuel Yehowshua, in an email
dated 2020-06-21 that nMigen will hold bi-monthly IRC meetings that
specifically aim to coordinate with downstream projects and discuss any
concerns that may arise, and suggested he invite team members to attend. None
attended.

In my view, I have sufficiently reached out towards your team.

> the people making the analysis and
> major influential input (awygle) have clearly never looked at any of
> the 75,000 lines of code that has been developed under NLNet's funding remit.

At the moment, Andrew Wygle has no formal authority in the project (he does not
even have a commit bit), and he made this pull request specifically and only
because I asked him to work on it.

> also it would be disruptive to Minerva, where Record.connect is utilised
> for all wishbone bus communications (and we are using that code)

A Minerva stakeholder is aware of the change, has attended the last meeting,
and expressed no particular concern about it.

> it would be *significantly* disruptive to the project to be forced to
> modify and review 75,000 lines of code in order to remove Record, and
> it would be seriously problematic if Record.connect disappeared.

I must remind you that you are using a library versioned in the 0.x series that
says, in the very first sentence of README, that it is "incomplete and under
active development". In spite of that, I went above and beyond what is
typically done in open-source projects (much less young open-source projects)
to provide extensive migration assistance for user designs at every point in
the past.

In my view, your lack of effective planning and communication does not
constitute an emergency on my side.

-- 
You are receiving this mail because:
You are on the CC list for the bug.