Suggestion: Please change subject of email thread when changing topic (Was: RE: [isa-dev] FP estimate functions location)

[Grant Martin]

This is a suggestion I have made before but perhaps useful to the various correspondents and readers.  When an email thread on one topic (for example, FP estimate functions locations) is re-used for a different topic (for example, code of conduct discussions), I would suggest that the subject line be changed, perhaps along the lines of what I did above.

 

For example, this new discussion could use as subject “Code of Conduct Discussion (Was:  RE: [isa-dev] FP estimate functions location)”, for example.

 

In this way, those interested in the FP estimate functions discussion would know that a new thread has been created on a different topic, and they can decide if they want to follow the new topic or not.

 

This would help all readers, especially if using a threaded email reader.

 

Thanks for your consideration

Grant

 

-------------------------------------------------------

Grant Martin      Distinguished Engineer

Tensilica R&D     Cadence Design Systems

2655 Seely Avenue, Bldg#8, San Jose

CA 95134   USA    Phone +1-408-944-7826

Mobile +1-510-703-7470

email gma...@cadence.com

 

From: lkcl <luke.l...@gmail.com>
Sent: Thursday, July 18, 2019 3:51 AM
To: RISC-V ISA Dev <isa...@groups.riscv.org>
Cc: luke.l...@gmail.com; robf...@gmail.com; con...@riscv.org; je...@linuxfoundation.org
Subject: Re: [isa-dev] FP estimate functions location

 

EXTERNAL MAIL

On Thu, Jul 18, 2019 at 9:52 AM Christian Brunschen <chri...@brunschen.com> wrote:

……………………

 

(contents removed as not needed for Grant Martin suggestion

 

[lkcl]

On Thursday, July 18, 2019 at 3:33:39 PM UTC+1, Grant Martin wrote:

This is a suggestion I have made before but perhaps useful to the various correspondents and readers.  When an email thread on one topic (for example, FP estimate functions locations) is re-used for a different topic (for example, code of conduct discussions), I would suggest that the subject line be changed, perhaps along the lines of what I did above.

appreciated, grant.  i do appreciate it's standard netiquette.

i think also, though, that morale is pretty low right now.  over the years (long before i joined) several people (and several entire teams) had already given up entirely of ever being considered as contributors to the RISC-V community, and it's kinda hard to face why that is, y'know?  i know i don't particularly feel like changing the topic to something that announces that the discussion is likely to not be a whole lot of fun.

still, respecting netiquette rules i do understand is important.

thank you for speaking up, grant.

l.

[Bruce Hoult]

On Thu, Jul 18, 2019 at 7:59 AM lkcl <luke.l...@gmail.com> wrote:
>
> On Thursday, July 18, 2019 at 3:33:39 PM UTC+1, Grant Martin wrote:
>>
>> This is a suggestion I have made before but perhaps useful to the various correspondents and readers. When an email thread on one topic (for example, FP estimate functions locations) is re-used for a different topic (for example, code of conduct discussions), I would suggest that the subject line be changed, perhaps along the lines of what I did above.
>
> appreciated, grant. i do appreciate it's standard netiquette.
>
> i think also, though, that morale is pretty low right now. over the years (long before i joined) several people (and several entire teams) had already given up entirely of ever being considered as contributors to the RISC-V community, and it's kinda hard to face why that is, y'know?

I'm sorry you and the unknown others you refer to feel that way Luke.

From where I stand what I see is people who are *pumped* by the
progress RISC-V is making, whether it's the first silicon from the
Shakti team, lowRISC getting funding and hiring people, RISC-V being
accepted as an official backend in LLVM and being officially supported
in musl (both of those in the last week), or the constant stream of
new cores, new design wins, new investors, new companies being
announced on a monthly basis.

The RISC-V Vector spec seems to be causing a lot of excitement. I've
pointed it out to a few people who have done a lot of HPC or
SSE/AVX/NEON work but don't know much (or anything) about RISC-V and
they are like "Wow! When can I get this?"

Other extension groups are making good progress too, with
BitManipulation being the one I'm the most familiar with. There are a
lot of papers coming through where people are basing academic research
around RISC-V, especially in the security area.

Multiple competitors with other ISAs have stopped ignoring RISC-V and
are changing their pricing structures and licensing to more closely
match what RISC-V vendors are doing. This benefits everyone in the
digital electronics industry and their customers, whether they are
currently using RISC-V or not.

Most of the frustration I see is just that potential customers want
RISC-V Raspberry Pi competitor boards, or phones or notebooks, or
chips for sale at mouser or digikey now now now, not next year or the
year after or in five years. Everyone is working flat out to make that
stuff happen.

Morale low? The opposite, I would say.

[lkcl]

(moving this to an alternative thread, as grant asked)

> when any conversation shifts away from being technical, can i please ask those 

> relying to NOT include the list in your reply-all? you’re welcome to have

> a private side conversation.... but please be aware the rest of us have no

> interest in that nontechnical content.

i appreciate you raising this, guy.  the thing is: did you mean to say "everyone", here?  can you be certain that *everyone* has no interest in this particular non-technical content? particularly when it concerns how the morale of participants has been low enough that several have given up, and leads to an opportunity to express how to fix that?

i know for example that you've given up participating and contributing - is that something that you really want?

> if you can’t do this, then I think we need a moderator for these mailing lists.

who would moderate the moderator?  both karsten and i have already raised concerns about how the RISC-V Foundation is overstepping its reach.

[EMPHASISE SEPARATE CONTEXT HERE, for karsten's benefit]

also i have researched Trademarks, and if it is the RISC-V Foundation that performs such moderation, they're likely to lose the Trademark as a result.  Trademark holders have to be extremely careful not to use the Trademark to suppress "Free Speech".

> the signal:noise ratio makes me want to unsubscribe. i’ve held on nearly as long as

> i can, but it’s getting painful. 

it already is.  i'd like to see that improve.  to have that occur, it needs the participants to be willing to face things - no matte how painful - in a mutually respectful way.

> i know that i’m not alone here, and the whole thing

>  goes downhill if we start losing contributors.

we already have, and it already is.

that provides people with an opportunity to speak up and say what they *do* want (in a positive fashion).  if that's done privately, then just as both karsten and i pointed out, it leaves everyone else going "you don't speak for me, and you definitely didn't consult me".

l.

[lkcl]

On Thursday, July 18, 2019 at 7:36:36 PM UTC+1, Bruce Hoult wrote:

 

> i think also, though, that morale is pretty low right now.  over the years (long before i joined) several people (and several entire teams) had already given up entirely of ever being considered as contributors to the RISC-V community, and it's kinda hard to face why that is, y'know?

I'm sorry you and the unknown others you refer to feel that way Luke.

much appreciated you acknowledging this, Bruce.  it helps people to feel that they're being listened to, and that their opinions, feelings and goals matter

 

From where I stand what I see is people who are *pumped* by the
progress RISC-V is making, whether it's the first silicon from the
Shakti team, lowRISC getting funding and hiring people, RISC-V being
accepted as an official backend in LLVM and being officially supported
in musl (both of those in the last week), or the constant stream of
new cores, new design wins, new investors, new companies being
announced on a monthly basis.

Bruce: I was there when the Shakti Team did the board bring-up on their Intel 22nm core.  It was truly a huge moment, incredibly inspiring.  I cannot say too much because it was private conversations, so allow me to be indirect: let's look at the external sequence of events.

* IIT Madras joins as a Founding Member

* begins an RV64G core that conforms to the UNIX Platform

* layout begins (which as anyone knows is the point of no return)

* WITH NO CONSULTATION, about 20 months ago, the UNIX Platform is changed to RV64GC

* Shakti silicon has to be taped out as-is

* Successful boot-up occurs.

* One year later, SDK is announced (RV64G - not RV64GC).

Krste's arbitrary decision - a "nod" at a conference 20 months ago - cut the Shakti Team off from Debian and Fedora (because RV64GC is incompatible with RV64G), not only isolating them from the mainstream UNIX community and relegating their otherwise perfectly functional ASIC to the far less useful "Embedded" Platform, it caused them to have to dedicate special resources to creating an alternative OS.

Now, how do you think that a team whose silicon has been made irrelevant by an arbitrary decision on which they were not properly consulted, isolating them from the *entire* Debian and Fedora resource, would feel about that?

They had *one* chance to get that 22nm ASIC done, because it was on the back of a training / mentorship deal arranged through Alumni contacts working for Intel.

Their next cores will only be in 180nm (a local University / Dept of Defense Foundry) until they get funding to upgrade it.

Krste's arbitrary decision has set India's Processor Programme back *years*, Bruce!

if you recall, i pointed out the consequences, and was shouted down (ridiculed in some cases) and ignored.  what people may not have been aware of: i was privately talking with the IIT Madras team, and relaying their concerns.

*this* is what has people concerned.  the things you describe below are fantastic.  the achievements of everyone involved likewise.  however it's where people are being side-lined and ignored, *that* is where the problems are that desperately, desperately need to be addressed.

 

The RISC-V Vector spec seems to be causing a lot of excitement. I've
pointed it out to a few people who have done a lot of HPC or
SSE/AVX/NEON work but don't know much (or anything) about RISC-V and
they are like "Wow! When can I get this?"

yes, i really like RVV. i've learned a huge amount from what i can find, and made efforts to help out where i can, by raising concerns about its design.

however, i feel like my efforts are being completely ignored, and that i am viewed as not just an outsider, but a hated, disrespected and unwelcome nuisance.  it's extremely discouraging, particularly when my contributions and insights are unpaid, and actually take up sponsorship money to write.

i'd like to see that change to become much more positive, and to be able to participate usefully.  and no, *please*, please do *not* say that i have to join the RISC-V Foundation to do so.  the Membership Agreement is akin to an NDA and, as it stands, places me under restrictions that result in a Conflict of Interest with the NLNet Privacy and Enhanced Trust Grant conditions.

btw to note: in the past you raised the issue of assignment to the RVF: that's not the problem, i have no issue with that (cf: Cygwin, FSF do the same).  it's the freedom to speak up (witness the recent imposition of the CoC which is a binding agreement... *for RVC Members only*) and the total lack of transparency that comes with the closed lists: these are flat-out incompatible with the *business* objectives of our project  - personal morals don't even enter into the equation *at all*!

in addition (continued below), note the key emphasis, "people are waiting".

 

Other extension groups are making good progress too, with
BitManipulation being the one I'm the most familiar with.

yes, this is an extremely important Extension, on which the Libre RISC-V SoC is critically dependent, as it is a hybrid CPU, GPU and VPU, so will need YuV to RGB conversion and much more.  Vulkan defines some formats that we will be required to meet, however there will be more.

in addition, where RVV has special opcodes for masks that are (in "element" form) directly analogous to xBitManip equivalents, we decided in SV instead to go with *actual* bitmasks, and consequently, xBitManip becomes an absolutely essential Extension.

... yet despite this we feel completely excluded from participation!

There are a
lot of papers coming through where people are basing academic research
around RISC-V, especially in the security area.

yes.  when i was in Chennai i talked to some of the people there, at some length.  it was fantastic to hear people talk about a "parallel memory tag" idea, which would help (in hardware) to track malloc and free (use of uninitialised or already-freed memory).  i suggested to them to consider doing a "refcount" augmentation of that, which would help track other languages that use refcounting (c++, rust, javascript, etc.)

the guy working on power side-channel analysis, his talk was *really* interesting.  the FP unit leaked information sufficient to leak Rijndael keys with 99% accuracy, even when the algorithm clearly isn't using FP!  this was eventually tracked down somewhere really unusual: something to do with the decode engine and the cache - totally unexpected and really important to know.

i *love* that these things are happening, and so much easier to do because the architecture is open, the toolchains and their installation procedures are fully documented and even automated, allowing students to usefully contribute within months if not weeks.

 

Multiple competitors with other ISAs have stopped ignoring RISC-V and
are changing their pricing structures and licensing to more closely
match what RISC-V vendors are doing. This benefits everyone in the
digital electronics industry and their customers, whether they are
currently using RISC-V or not.

this is fantastic.  it's great to see, and hear about.

 

Most of the frustration I see is just that potential customers want
RISC-V Raspberry Pi competitor boards, or phones or notebooks, or
chips for sale at mouser or digikey now now now,

i know - i've been contacted by some of them :)

 

not next year or the
year after or in five years. Everyone is working flat out to make that
stuff happen.

indeed.  our team is very specifically designing a processor that has the exact specifications to go into the SBC small form-factor.  additional sponsors and potential sponsors have stepped forward to have conversations with us about using it, and how they may help accelerate its development.

Morale low? The opposite, I would say.

in certain areas, yes you are absolutely right.

it's important to discern certain "categories".  (NOTE TO CHRISTIAN AND OTHERS: I AM GOING TO USE SPECIFIC LANGUAGE HERE WHICH SHOULD ALLEVIATE OBJECTIONS OF BEING "DEMANDING").

the way that i see it - or - the way that *i* - PERSONALLY - perceive things is as follows:

(1) i perceive that there are people here on these lists who are new and getting up-to-speed.  they need help with doing board-bring-up of *existing* designs: ariane, lowRISC, etc.

there is no problem here: there is no morale issue, at all.

(2) i also see that there are people here who implement *existing* standards.  there was the team from sri lanka a few months ago, really good to see their efforts be successful!

there is no problem here: there is no moral issue, at all.

(3) i also see that there are people who point out grammatical errors in the *existing* standards.  corrections to wording, clarification, and so on.

for the most part, these are acknowledged and actioned by (the very busy!) andrew waterman [with thanks for your efforts, andrew].  *HOWEVER*, there are several instances that have been ignored, or, in some cases, shouted down (with accusations of mental incompetence).  where i was on the receiving end: these were deeply distressing to experience, and i would like to see people take that on board and be more accommodating, particularly as i'm contributing those corrections *for other people's benefit*.

(4) i also see that there are people on this list who point out *serious limitations*, missed opportunities, or have ideas to *EXTEND* RISC-V.

THESE ARE COMPLETELY IGNORED.

i have not witnessed ONE single instance in 18 months where a contributor from this list has had a response, "that's a great idea, would you like to write it up formally" or "that's a great idea, what wording would you suggest?" or "hmm, we missed that, can you please elaborate as i agree it would be really important to investigate this further".

*EVERY SINGLE IDEA* - from EVERY external contributor - WITHOUT FAIL - has been ignored, "rationalised away" or its contributor ridiculed or made to be belittled in some fashion.  *every single one*, Bruce!

examples include:

* a russian programmer who came up with a brilliant idea of using one of the RV64 FP opcodes to load 32-bits into the "HI" word of an RV32G (yes, G, not F,  yes RV32, not RV64) 64-bit FP register (yes, 32-bit INT regfile, yes, *64* bit FP regfile).  i pointed out that his idea would actually be just as applicable to solve a similar issue for RV64Q, by utilising an analogous RV128 opcode

no response

* only last week when pointing out that LE/BE misses some really significant use-cases.

no response.

* richard herveille and others who have mentioned the missed opportunity of RV32/RV64 binary compatibility (and given up on doing so)

no positive response.

* ISAMUX/ISANS - an absolutely critical strategic scheme to alleviate pressure on RISC-V as it moves forward over the next 50 years

ironic fighting and back-stabbing like you would not believe [well-documented, for people who may take that at face value]

* RV16, XCondensed and other 16-bit schemes whose progress and adoption critically depends on ISAMUX/ISANS giving them the "room to breathe" (safely, without conflict)

no encouragement or response.

there are many more examples like this, and they add up to a not very nice and extremely consistent picture of... well... the track record speaks for itself, and it results - has resulted - in several people just simply giving up and walking away from RISC-V entirely.

*this* is what the RISC-V Founders - and the people who evangelise about RISC-V - don't want people to know.  it's what they want to hide and pretend is not happening, that there are people who *want* to contribute at the INNOVATIVE edge of RISC-V (who cannot, for whatever reason, do so from within the confines of RISC-V Membership as it currently stands), and whose CONSTRUCTIVE and valuable input is IGNORED.

that is what i meant by morale being low, Bruce.  it's amongst the INNOVATORS - not the USERS - that morale is at rock bottom, including one of the *Founding* Members of the RISC-V Foundation itself.

only once this is properly acknowledged, rather than dismissed [as an "ad hominem attack" in one instance] or simply ignored, can progress be made.

l.

[Madhu]

Luke,

yes we were pretty annoyed at the compressed instruction decision. but was one issue way, way back when the foundation was in its infancy. two points

1. please do not blow that one incident out of proportion 

2. if we have issues with the foundation, you can be rest assured that i will be creating  a ruckus! we really do not need anyone speaking on our behalf. 

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/efe7fbb5-921c-410c-937c-9eec5b382614%40groups.riscv.org.

[lkcl]

On Friday, July 19, 2019 at 4:55:20 PM UTC+1, Madhu wrote:

Luke,

yes we were pretty annoyed at the compressed instruction decision. but was one issue way, way back when the foundation was in its infancy. two points

1. please do not blow that one incident out of proportion 

2. if we have issues with the foundation, you can be rest assured that i will be creating  a ruckus! we really do not need anyone speaking on our behalf. 

appreciated you speaking up, here, madhu.  i totally get that the team has moved on, and i am aware that there's people in the team working on (completed?) C implementation.  my point is that the incident happened at all - it should never have occurred in the first place - and that it is just one of an increasingly-long list of incidents which have yet to receive *any* kind of acknowledgement or recognition - at all - that they're a problem, let alone engaging in a discussion towards a solution.

l.

 

[Neel Gala]

As a member of the SHAKTI team, I would like to clear up quite a bit of mis-information in your last mail:

1. All of our current cores support Compressed ISA.
2. Our SDK supports all currently ratified extensions. The SDK is not meant for RISECREEK (the 22nm *test*-chip). 
3. RISECREEK was a test-chip and continues to serve its purpose for us. It has had none of the grave-repurcussions you seem to claim.
4. I don't think you are part of any conversations with us to claim *ALL* our future tapeouts will be *ONLY* at 180nm. Please do not spread the same elsewhere. 
5. India's Processor Program is far ahead than what you seem to think. If anything, we would thank Krste (and team) for all his effort in introducing RISC-V.
6. Our concerns with the foundation have been resolved back then in much mature fashion. If we do have concerns, we will continue to raise them to the respective authorities directly.

To iterate what Madhu said, we are not looking for any white-knights for us. 

I would request you to consult us in future before making any claims about SHAKTI.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPb2fE_69D-%2BBSTg2Ng06Jj8GtwhWXQ3351ProNiOBT%3Dt%2B8rvQ%40mail.gmail.com.

--

Neel Gala

Senior Project Officer

RISE LAB, IIT-Madras

[lkcl]

On Friday, July 19, 2019 at 5:30:38 PM UTC+1, Neel Gala wrote:

As a member of the SHAKTI team, I would like to clear up quite a bit of mis-information in your last mail:

ah, neel, many many apologies, we haven't been keeping in touch, so i'm clearly not up to date.  

1. Our SDK supports all currently ratified extensions.

_fantastic_. 

1. India's Processor Program is far ahead than what you seem to think. If anything, we would thank Krste (and team) for all his effort in introducing RISC-V.

that's great!  it would be fantastic to hear more.  i do know that you're extremely busy, though.

1. Our concerns with the foundation have been resolved back then in much mature fashion. If we do have concerns, we will continue to raise them to the respective authorities directly.

i'm delighted to hear that you have - and are able - to do so.  by contrast: as "unwelcome outsiders", our concerns are completely ignored.

To iterate what Madhu said, we are not looking for any white-knights for us.

apologies for the misunderstanding: that was in no way the "primary purpose" of the message that i wrote.  as i wrote in the follow-up, it was to illustrate that it is one incident in a long line of incidents where people's input is being - has been - ignored.

I would request you to consult us in future before making any claims about SHAKTI.

with apologies: will do so.  good luck, and apologies for distracting you from the work that you're doing.

l.

[David Yu]

Happy to see we are back to tech discusdion.

I had asked a question about why riscv has no instruction like MTHC in MIPS.
So the issue below is the one I understand and care about.

* a russian programmer who came up with a brilliant idea of using one of the RV64 FP opcodes to load 32-bits into the "HI" word of an RV32G (yes, G, not F, yes RV32, not RV64) 64-bit FP register (yes, 32-bit INT regfile, yes, *64* bit FP regfile). i pointed out that his idea would actually be just as applicable to solve a similar issue for RV64Q, by utilising an analogous RV128 opcode

The russian programmer is Dmitri.

This is responded in github manual issue301
https://github.com/riscv/riscv-isa-manual/pull/301

Solution and suggestion are all in the thread, but I don't know when will it bring up again and add to new spec.

[lkcl]

On Saturday, July 20, 2019 at 5:19:18 PM UTC+1, David Yu wrote:

Happy to see we are back to tech discusdion.

yes, likewise.  let's change the topic to match.

that's great.  it looks like it was picked up about the analogous RV64Q issue (overload of a corresponding RV128 opcode) as well, which is great.

also that...

ah.

If both the FMVH.X.W and FMV.X.W are required

 for the same double-precision floating-point register,

 the following code sequence is recommended:

 FMVH.X.W {\em rdh, fs1}; FMV.X.W {\em rdl, fs1}

 (where {\em fs1} is the same, but {\em rdh} cannot be the same as {\em rdl}).

ok, so it looks like dmitri didn't see the comments that i made, about the recommended sequence.  also, a standard cannot and must not have *recommended* sequences, it has to be *defined* sequences.

"recommended" sequences results in chaos.  hardware that aims to do macro-op fusion for example will *have* to watch out for *BOTH* sequences, because due to the word "recommended" it is still *permitted* to use the other: thus, one compiler or assembler writer may use one sequence, whilst another will use the other.

that results in extra gates (and extra power consumption).

a "naive" implementation will work like this:

* FMVH.X.W: writes data into the *HI* 32-bit of a 64-bit FP reg...

*click*... it's the other way round, isn't it?  spec v20190621-draft, section 11.7:

FMV.X.W moves the single-precision value in floating-point register rs1 represented in IEEE 754-

2008 encoding to the lower 32 bits of integer register rd. The bits are not modified in the transfer,

and in particular, the payloads of non-canonical NaNs are preserved. For RV64, the higher 32 bits

of the destination register are filled with copies of the floating-point number's sign bit.

so FMVH.X.W will move the high 32 bits of the *floating point* register into the 32-bit regfile target.

which of course begs the question: why isn't FMVH.W.X also being proposed?

(this, accidentally, was where i raised a concern about overwriting the top 32-bits of the FP target, if FMVH.W.X was called first... *and then* FMV.W.X was called.  the second opcode *would* destroy the work that the FMVH.W.X had just done).

yes of course an FLD can be used, however these are inefficient (relatively speaking: huge amounts of power consumed just getting through the L1/L2 cache barrier).  staying in the regfile is *important*.

> it and implementing it, and although a few mentioned this issue, it

> did not raise to the level of an essential bug fix or a radical > improvement over this period. (Unlike memory-model, NaN-boxing, or > moving counters/FENCE.I out of base).

the power efficiency savings of FMVH.W.X and FMVH.X.W (as well as the reduction in instruction count) may have been missed by others when analysing the other issues.

could someone please add that to the bugreport, as i cannot use github.

or, post a cross-reference hyperlink to this thread?

many many thanks for noticing that one, david.

l.

[C.Y. Yu]

Just dig out original discussion, first proposal from Dmitri Pavlov.

For a record and reference link.

https://groups.google.com/a/groups.riscv.org/forum/m/#!topic/isa-dev/kXgfFqgBv-c

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/b684712c-03fa-49a4-baff-ce9475fb61c0%40groups.riscv.org.

[lkcl]

On Saturday, July 20, 2019 at 7:06:44 PM UTC+1, David Yu wrote:

Just dig out original discussion, first proposal from Dmitri Pavlov.

For a record and reference link.

https://groups.google.com/a/groups.riscv.org/forum/m/#!topic/isa-dev/kXgfFqgBv-c

thanks david - weirdly i can't "reply" there, the format is different. very strange.  i'll find another way.

what i meant was: whilst there are references _here_ (forward links), there's no references *to* here, from github.

for an example, see here:

http://bugs.libre-riscv.org/show_bug.cgi?id=110

that is a bugreport that cross-references to the list archives: those list archives also cross-reference back here (to isa-dev).  we do this all the time, and in fact, the bugtracker (bugzilla) has been *added* to the list, so that any modifications (not all, i switched a lot of them off) to the bug get posted to the list, automatically.

this is *not* being done for the development of RISC-V Standards, and it's causing problems.

as we are developing a privacy-respecting processor, under the NLNet's "Privacy and Enhanced Trust" Programme (https://nlnet.nl/PET/), use of a proprietary service (github) that monitors its users and sells data and information to the highest bidder would result in quite justifiable and correct accusations of total and outright hypocrisy.

it was *assumed* by the RISC-V Foundation - without a wider consultation - that the use of github would be acceptable to contributors.  it's *also* assumed - by implication and in some cases actual straight statements - that anyone *NOT* accepting github is worthless, and has nothing of value to contribute.

in the software libre world it is extremely common to see IRC gateways on commit messages, email-to-web-service gateways, and so on.  github on the other hand is a proprietary service - like slack, which has received *extremely* high criticism - that is DESIGNED to ENTRAP users onto its platform.

a simple solution therefore would be to set up a github-issue-email-gateway.  a quick search finds this:

https://fire.fundersclub.com/

here's the source code:

https://github.com/FundersClub/fire

a second one is here (i think):

https://github.com/sibson/ghinbox

it's not clearly explained in the README what that is.

the point is: there is no *TECHNICAL* reason why "outsiders" - the ones that cannot use github - need to continue to be isolated from the rest of the RISC-V Community.

l.