whitequark: i'm adding you as a cc on this bugreport.  awygle's comment
here that Record.connect is "not used" is incorrect:
https://github.com/nmigen/nmigen/pull/368

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.

here is a count just the count of the number of base classes
(excluding inherited classes) and locations where Record is used:

soc$ find . -name "*.py" | xargs grep 'Record' | wc
    140     694   10827

we cannot make a similar cursory count for the IEEE754 FPU because the
OO inheritance and sub-object tree is 2 to 4 levels deep in places.

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.

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

(microwatt's wishbone implementation has to split incoming from outgoing
signals into separate structs and it becomes incredibly confusing:
it appears that a module using two such separate structs then has two
connections: one to a wishbone master and one to a wishbone slave,
whereas in fact it's just a single wishbone slave connection.  this
kind of confusion took over 15 minutes of detailed reading of the code
to identify).

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 bottom line is that it would be substantially detrimental to the
entire project in time and resources to deal with this, particularly
right when we have an upcoming tape-out deadline in October 2020.

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, and, on inspection
of the conversation logs to find that 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.

this is not a small project with a small impact.  Hugh, the former
Director of the OpenPOWER Foundation, informs me that it will be the
world's first new independent POWER9 design to go into silicon in
*ten years*.

i would welcome your input as to how we can move forward here in an
inclusive way.

(i've notified awygle on irc.freenode.net of the existence of this bugreport so that he does not feel excluded or being "discussed as a 3rd person")

> 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.

(In reply to whitequark from comment #3)
> > 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.

it's here:

https://github.com/nmigen/nmigen/pull/368

 awygle commented on Apr 24

Deprecate the unfortunate Record.connect method, and the Direction functionality of Record as well


> > 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.

i hear you: it's just that... hearing for the first time that Record is
going away is quite alarming.


> 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.

that's really appreciated.  it's perhaps unfortunate that i am, because of
significant heavy focus on other parts of the project, just hearing about
the intended deprecation 

> 
> 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.

interesting - and much appreciated.  i had absolutely no idea that this was
the case, that you'd been this thoughtful in the planning.  depending on
timing (0.5 pre- or post- Oct 2020) we therefore have a couple of
non-disruptive routes.

so i think we're good.  thank you for these details.  it allows us to
plan effectively.

in future, how can we ensure better communication, here?


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

ok.  that's really good to know, and a huge relief.  i was very concerned
for a while.

 
> > 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.

... bear in mind that Yehowshua is sufficiently busy that he simply does
not have time to keep me informed.

if you have had private conversations with him, then the majority of those
private discussions will in fact remain private, and you should take that
in to consideration.

also, Yehowshua is not the Technical Lead: i am the Technical Lead of the
Libre-SOC project - not Yehowshua (see more below), and Yehowshua is the CEO
(not the CTO) of a Corporation that "happens to be using Libre-SOC source code".

bottom line is that if it's not been sent to or discussed on libre-soc.org
resources (which are in absolutely no way owned or controlled by the
USA-based Corporation known as "Systemes Libre"), then you should assume
by default that it has not reached the attention of the team.

given that we (Libre-SOC) are funded by NLNet for full transparency,
private technical conversations involving the Libre-SOC codebase and
matters relating to it are a strong "red flag" anyway.


> > 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,

hang on, hang on - you're confusing the Corporation (which is yet to
be established) with Libre-SOC.  the two are completely separate entities
(a Charitable Foundation is in the process of being established for
Libre-SOC which will help make that clear).

i am directly responsible for the Libre-SOC codebase and its technical
direction.

Yehowshua is responsible for a commercial entity that *uses* Libre-SOC,
whose sole purpose and existence is to hold the Mask Rights for a taped-out
processor, with zero ownership of copyrighted code so that if it is attacked 
with back-to-back patent lawsuits, those attacks have zero impact on the
technical and strategic direction of Libre-SOC.

Yehowshua is therefore not involved in the actual technical decisions
because he is simply too busy with other matters [Masters Thesis].


> 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.

for technical matters related to Libre-SOC, the best person to raise that
with is me, directly, and the best place to raise it is the mailing list,
due to the transparency requirements (i will review the contents and
discussion and raise a bugreport to keep track of its impact).

(Yehowshua did in fact send a message to the list about the meetings).

to make it clear: for matters related to the creation and commercial sale
of ASICs paid for by Systemes Libre investors and customers, it would be
appropriate to contact Yehowshua about that.


> None attended.

i simply missed it: i watch the IRC logs, and read them - i haven't had time
yet to let you know.  it was an interesting discussion.

i have to say that when reading the messages, i didn't recall seeing anything
about Record being removed.  clearly, if i had, given the huge impact, i
would have said something.


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

to be completely open and honest with you i feel quite intimidated and not
very welcome.  i did not feel comfortable in directly participating, so
chose to review the logs after the meeting had taken place.  i meant to
let you know, i apologise.


> 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.

ok. appreciated.

> > 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.

the Minerva codebase is only 4,000 lines.  Libre-SOC's codebase is literally
20 times larger, and it will likely be 40 to 50 times larger by the time
we have full functionality.

i would therefore expect that it be fairly easy for Minerva to migrate,
which would explain why the Minerva team has no issue with the plans.


> > 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". 

i do appreciate that.  really :)

> 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.

although you've not spelled it out, i could tell even from the initial
discussions back 2 years ago that you had this kind of appreciation and
understanding of APIs and the burden it places [on you] for maintaining
them.  although i do recall that you were quite stressed about doing so :)

without actually discussing it explicitly, i completely "got" that, with
your valuable committment to principles that were unspoken, nmigen would be
a much stronger base for us to create such a hugely ambitious commercial
ASIC on than any other HDL out there, even as nmigen progressed and
developed.

so i do "get it" - i just freaked out for a minute, given the time-pressure
and the attention that's on this project to succeed [and consequently,
logically, will also be on nmigen.  sorry about that!].


> In my view, your lack of effective planning and communication

whilst understandable i have to say that this is not very fair.
we're under huge time-constraint pressure, whitequark, and it's
a massive project.  for the Oct 2020 deadline i have over 30 *major*
tasks to keep track of... *at the first level*.

i'm barely keeping up with development, let alone external communication.
normally for a project of this size and scope there would be a full-time
Project Manager dedicated exclusively to dealing with task management and
team coordination, and that role is - because there is nobody else to do
it - my responsibility *as well* as being the key active technical developer.


> does not constitute an emergency on my side.

i agree, and on learning that you've thought significantly about a
route for us to continue to use Record (externally if necessary) is
greatly appreciated.  it means that we can plan a migration on a
suitable timescale rather than having to drop everything and scramble,
right at a critical juncture.

i won't close this bugreport, because we need something to plan the
migrations (after Oct 2020).  marking this as "Deferred" though.

thank you for taking the time to keep us informed, whitequark.

> Deprecate the unfortunate Record.connect method, and the Direction
> functionality of Record as well

There is nothing in that sentence that says "unused". If we, in fact, considered it unused, we would have removed it right away. But obviously that is not the case.

> i have to say that when reading the messages, i didn't recall seeing anything
> about Record being removed.  clearly, if i had, given the huge impact, i
> would have said something.

It was mentioned only briefly because it is not the focus of the next (0.3) release; the technical discussion related to replacing Record will happen before the 0.4 release.

Given the relatively slow (for a project in the 0.x series) release cadence and the extensive compatibility shims we provide, I decided that there is no urgent need to announce the deprecation any more loudly than that, especially since we do not have any actual design for its replacement. A design and a complete, field-tested implementation for the replacement are, of course, a prerequisite for deprecating Record, much less removing it.

> on learning that you've thought significantly about a
> route for us to continue to use Record (externally if necessary) is
> greatly appreciated.

The ability to implement something like a Record in your own codebase has been added more than a year ago (at 2019-06-11) after a discussion with you and hearing your requests, I've told you about that, and you've acknowledged that you understood you had this ability.

> to be completely open and honest with you i feel quite intimidated and not
> very welcome

This is a consequence of your own past behavior, and today, by starting with unfounded accusations instead of attempting to discover the facts or really any attempt at a productive dialogue at all, you have not shown many reasons to welcome you. I would prefer to discuss technical topics with literally any other member of your team, none of whom, to my knowledge, behave like this.

You seem to consider LibreSOC a very important project for nMigen--but this kind of behavior is in no way tolerated in the nMigen community and, frankly, over time makes your project more of a liability.

Would I recommend anyone work with you knowing that in case of a misunderstanding, you will attack them (as well as complete bystanders) first and ask questions later, such as what you did today? Absolutely not.

> in future, how can we ensure better communication, here?

You could start with not messaging me out of the blue with counterfactual accusations stemming from the assumption that I do not, in fact, consider it valuable to provide a smooth migration path for downstream projects when this has been the focus of the project since before it got a 0.1 release.

(In reply to whitequark from comment #5)
> > Deprecate the unfortunate Record.connect method, and the Direction
> > functionality of Record as well
> 
> There is nothing in that sentence that says "unused". If we, in fact,
> considered it unused, we would have removed it right away. But obviously
> that is not the case.
> 
> > i have to say that when reading the messages, i didn't recall seeing anything
> > about Record being removed.  clearly, if i had, given the huge impact, i
> > would have said something.
> 
> It was mentioned only briefly because it is not the focus of the next (0.3)
> release; the technical discussion related to replacing Record will happen
> before the 0.4 release.
> 
> Given the relatively slow (for a project in the 0.x series) release cadence
> and the extensive compatibility shims we provide, I decided that there is no
> urgent need to announce the deprecation any more loudly than that,
> especially since we do not have any actual design for its replacement. A
> design and a complete, field-tested implementation for the replacement are,
> of course, a prerequisite for deprecating Record, much less removing it.

yes i've seen the daily discussions.  it's unfortunate that i simply didn't
see the intent to deprecate

> 
> > on learning that you've thought significantly about a
> > route for us to continue to use Record (externally if necessary) is
> > greatly appreciated.
> 
> The ability to implement something like a Record in your own codebase has
> been added more than a year ago (at 2019-06-11) after a discussion with you
> and hearing your requests, I've told you about that, and you've acknowledged
> that you understood you had this ability.

it hadn't occurred to me to actually extract the entirety of Record from
the nmigen codebase (into nmutil, most likely) and to become its de-facto
maintainers until it's no longer needed.  it's a good idea.

as i was assuming that doing that would not be viewed favourably (because
that doubly-maintained code would then become a burden on you, for support
issues) it never occurred to me that it would be acceptable to duplicate
Record... *right now*.

consequently, the classes that i wrote (RecordObject, Object) derived
*from* Record rather than duplicated it.

consequently, removal of Record would seriously adversely impact the code
that relied on it.

now, of course, if the Record class is *removed* from nmigen then that's
an entirely different (and very good) proposition, as the responsibility
for its maintenance and support is no longer duplicated.


> > to be completely open and honest with you i feel quite intimidated and not
> > very welcome
> 
> This is a consequence of your own past behavior, 

this... i am... should everyone be so judged on the past?  in light of
the fact that our Charter *requires* - not optionally - *REQUIRES* that
contributors take into consideration external constructive feedback,
judging someone based on the *past* is hugely unfair.

it says - very loudly - "you as a human being are completely pathologically
incapable of adaptation".

that's not a very nice thing to say, is it?


> and today, by starting with unfounded accusations 

whoa whoa who there were no *accusations* whitequark.  i simply pointed
out that there is a lack of communication and that i felt considerable
alarm at the implications of the removal of something that we're critically
dependent on.

you then very kindly pointed out things that i haven't looked at for
several months going on a couple of years, that you've taken them into
consideration, and been supporting us - unknowingly as it turns out -
all this time.


> instead of attempting to discover the facts or really
> any attempt at a productive dialogue at all,

whitequark: please understand, we're *required* to discuss things
publicly - problems and all - when it affects the technical direction
of the project.

normally, in order to preserve a "positive image" of a project, things
are hidden from public view.  discussed privately, and only brought
to light when they are resolved (if at all).

under the NLNet funding remit, for Privacy and Enhanced Trust, *we cannot
work that way*.

we're required to hold technical discussions - even if there are
misunderstandings - entirely in the public light, for independent auditing.



> you have not shown many reasons
> to welcome you. I would prefer to discuss technical topics with literally
> any other member of your team, none of whom, to my knowledge, behave like
> this.
> 
> You seem to consider LibreSOC a very important project for nMigen--but this
> kind of behavior is in no way tolerated in the nMigen community and,

*what* "behaviour"??  am i not "permitted" publicly to say "i'm really
freaked out that because of things i don't know about, because i'm simply
too busy and simply haven't had time to keep fully up-to-date, that we
might miss a critical deadline and the entire EUR 400,000 funded
project will fail as a result?"

let me ask that another way.

how would _you_ have put it?  bear in mind that it has to be a public
communication (libre-soc mailing list, libre-soc bugtracker), what words
would you have used in order to convey what was needed?

then - bear in mind that i have Asperger's so "by default" i will simply
speak my mind - i can use that as a "template" for future communication
on a similar topic.

remember: normally there would be a "full time Project Manager" in place
to help with these kinds of things.  there isn't one, so it's down to
us, directly.

basically, you'll need to teach me what i need to say, ok?

because *i literally do not know*.


> frankly, over time makes your project more of a liability.

i appreciate your honesty, here.

if i can: my feeling is that if we, as project leaders, don't make a
positive effort here, it's going to reflect badly for both our respective
projects.


> Would I recommend anyone work with you knowing that in case of a
> misunderstanding, you will attack them (as well as complete bystanders)
> first and ask questions later, such as what you did today? Absolutely not.

i'm *not* going to attack people, whitequark.  what the hell would be
achieved by that??  make myself "look good"?  try to "win points by denigrating
others??"  make other people look "more stupid than me by comparison"?

those are the kinds of things that really nasty people do, and if they
tried it in this project they'd be in flagrant violation of the Libre-SOC
Charter and would be taken to task on it, because it would be significantly
detrimental to the project's goals.

now, from a combination of Asperger's complete lack of emotional (personal)
empathy combined with the mandatory requirements of full transparency, i
do appreciate that it might *LOOK* like an "attack" - a deliberate hostile
intent to denigrate the work that you're doing, and trying to "bring down
others".

except: this is so completely against *everything we believe in* that the 
discussion here is reaching "Kafka-esque" proportions, the mis-match is
that stark.


> > in future, how can we ensure better communication, here?
> 
> You could start with not messaging me out of the blue with counterfactual
> accusations stemming from the assumption that I do not, in fact, consider it
> valuable to provide a smooth migration path for downstream projects when
> this has been the focus of the project since before it got a 0.1 release.

whitequark: *i didn't know that* - not in real concrete terms.  it's one
thing to know it in the "abstract", and it's another to actually have
a real example thrown at us when there's a critical deadline coming up.

one that came up from there not being proper communication channels, based,
i believe, on misunderstanding compounded on misunderstanding on 
misunderstanding.  which, although it might not be appropriate to say,
i do find... some level of ironic/amusement in observing it.  the appropriate
japanese word would be "o-ka-shii-neeh" meaning (loosely), "funny / strange".


please: you're jumping at shadows and believing that you're being accused
of things that *haven't actually happened* and are simply the product of 
miscommunications.  or, the *perception* is one of accusation which you
know - logically with a little thought and reflection - cannot be true
because it would be so severely detrimental to both our projects if such
accusations were actually and intentionally being made.

let me ask you: did you *genuinely* think that, when i wrote what i did,
that my first active thought was, "I MUST ACCUSE WHITEQUARK AND EVERYONE HAR
HAR MAKE THEM LOOK LIKE TOTAL IDIOTS"??

you can't possibly think that that was my very first thought, can you?

i'm asking that genuinely, because i really don't know the answer.


i've already said thank you for your efforts in pointing out the migration
path (that you'd planned such a long time ago).

what else do you need me to say that would help reassure you?
(because - remember: with Asperger's *i simply don't know*)


there's a lot for both of us to learn, here, and given that the assumption
has been that i am "accusing" you of things has happened more than once,
i feel that it's our responsibility - both of us - to really get to the
bottom of this, properly.

but please - please - do not ever forget that with Asperger's i simply *do not
see things the same way as other people*.  i do not have the same kind of
emotional responses or modelling of others that everyone else has.

yes there are assholes and vicious and spiteful people with Asperger's out
there, just as there are kind, conscientious and thoughtful people without.

please understand that it is absolutely anathemic to me to be a "spiteful
vicious person, actively hell-bent intent on harming others".

this is an *ethical* project, and that's taken very seriously.

bottom line:

causing harm is an *extremely serious* violation of the Charter!


fundamentally, then, *you'll need to teach me* what kind of responses you
would like to see, and i can put them into the "mental database" and use
them as templates.  this is "standard practice" for people with Asperger's
(there are now books by respected authors on the subject)

this _will_ appear "awkward".  you'll know - ultimately - that the responses
that i make are "canned".  however this is just how it is with people with
Asperger's.  they *never* properly fit in with the rest of humanity, and
i believe you may have picked up on that but potentially not really
understood the full ramifications.


now, if i was not willing to do this, then you would be perfectly within
your rights to say that the entire project is pathologically managed.

as this is not the case (it is in direct violation of the Libre-SOC
Charter to be pathological), we can conclude that something else is
going on.

exactly what that is, i have no idea, and i'd welcome honest
and open discussion to work things out.

> basically, you'll need to teach me what i need to say, ok?

> how would _you_ have put it?

Sure, I can work with that. Suppose I am responsible for an important project and the upstream of a dependency is doing something I don't understand or appreciate. I've been in that position before.

I understand several things about it:
  a) Nothing prevents me from continuing to use the existing codebase of a dependency that currently works fine for my project. My tests presumably all pass, I do not have any bugs that need to be urgently fixed or features that need to be urgently introduced.
  b) I have no authority over the developers working on my dependency. It is an open-source project that operates primarily or entirely on goodwill, and, unless otherwise agreed upon, its developers have no obligation to me at all.
  c) The fact that I am under serious pressure is the result of my own decisions, and my own decisions alone.
  d) The project has so far been managed so well that I heavily depend on it.

So what I do is I assume that the project leadership knows what they're doing and I'm probably missing something important, and first ensure that I got the details right by asking. Something like:

> Can you tell me the rationale and roadmap for deprecating Record, as well as the proposed migration path?

That's it. One sentence. Once you know you got the facts right, feel free to express any significant concerns you have, how disruptive it would (or would not) be, and so on. Just... don't jump to conclusions, especially when you admit it yourself that you had no reason to do so.

If you're frustrated? Find someone to vent on how much of a disruptive idiot I am, *then* write that one sentence. I am not responsible, and will not be made responsible, for managing your emotional state.

Aside: I don't know how are we having this conversation at all. I've never heard of an ASIC project three months before tapeout that did not freeze, at least, the toolchain completely, much less one upgrading the toolchain to a new major version. By all accounts, nothing I can possibly do ought to be able to affect your tapeout schedule at all, even in principle.

(In reply to whitequark from comment #7)

> So what I do is I assume that the project leadership knows what they're
> doing and I'm probably missing something important, and first ensure that I
> got the details right by asking. Something like:

ha.  that's funny.  this is exactly what i advise people regarding google
searches.  "assume that what you want to know can be found".  except the
irony is that i treat it as an "object" - no people involved - despite
the fact that there were clearly people who wrote the google search engine
code.

ok.

thank you.

> > Can you tell me the rationale and roadmap for deprecating Record, as well as the proposed migration path?
> 
> That's it. One sentence. Once you know you got the facts right, feel free to
> express any significant concerns you have, how disruptive it would (or would
> not) be, and so on. Just... don't jump to conclusions, especially when you
> admit it yourself that you had no reason to do so.

so i think we have identified the issue.

* i looked at the bugreport
* it said "Record is being deprecated"
* i saw no indication of a migration plan

expected behaviour:

* ask questions

actual behaviour:

* go "argh Record is going away because that's what the bugreport says is happening"

now that we've identified the source of the discrepancy, can i make the
suggestion that, for *other people* who may see that same bugreport, so
that they do not take up your time with the exact same mistake that i
did...

... or, worse, *not use nmigen at all and not contact you because they
assume that Record is being removed and there is absolutely no replacement*...

... to add a very short sentence, "plan and advice needed to be written here
to help people migrate from Record in existing designs"

something to that effect

> If you're frustrated? Find someone to vent on how much of a disruptive idiot
> I am, 

except i don't view you as being a "disruptive idiot".  now, it may be
the case that you *think* i think that - i simply don't.  and for that
i can only apologise that it looked that way.


> Aside: I don't know how are we having this conversation at all. I've never
> heard of an ASIC project three months before tapeout that did not freeze, at
> least, the toolchain completely, much less one upgrading the toolchain to a
> new major version. By all accounts, nothing I can possibly do ought to be
> able to affect your tapeout schedule at all, even in principle.

i know.  it's completely mental.  we lost several months (a "friend"
needed my help and it cost me, personally, around USD $7k - around 1/2
my yearly income) i won't go into details.

it is what it is.

the idea of freezing the toolchain is a good one (inexperience, there)
although the possible burden of having to maintain a hard fork if bugs
are found is not something i want to add to the list unless absolutely
necessary, and this possibility i view as a minus.

when we have an actual completed design then yes we'll freeze all tools.

i think we've diverged sufficiently from the topic to warrant closing
this bugreport and re-opening a new one.