This bug is for demonstrating a good way to raise issues discovered within the Libre-SOC project (code, hardware, documentation, etc.). Started the wiki page section is called "How to raise issues" (2.2.1) and can be found here: https://libre-soc.org/HDL_workflow/
Forgot to include my commit on the wiki repo: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=232e3d71124c438402d791be8d024937fbf25fd3
(In reply to Andrey Miroshnikov from comment #0) > Started the wiki page section is called "How to raise issues" (2.2.1) "how" does not emphasise "why", and it is the WHY that stops resentment at being "forced" to "waste time" on "stupid project management" that alone is important enough to have its own section... *and then* under that have the "actions" (the "how"s) can you both now have a conversation on IRC (placing links back here as you do so) recounting your recollection of what i said on the conf. call today? it may take some time, it may take only minutes, but whatever happens you will see *and experience* the very issues that then need themselves to be documented.
i have added some additional advice especially "why" https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=9a7a107c95a0fddbb5209428fb1394ca706aa2a4 you (one of you) need to coordinate amongst yourselves to decide who s going to document *this* practice. see what jacob did here: https://bugs.libre-soc.org/show_bug.cgi?id=1125#c0 it is not perfect but pretty good, i much prefer the links to the diffs as it is quicker and easier to review.
After group call, Luke made useful comments on including milestones and budget information, so I included a few extra points in HDL_workflow. See commit diff: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=fccae2f02cb75bf5658bd1ae983f530df630f51c
andrey shriya: https://bugs.libre-soc.org/show_bug.cgi?id=1139#c5 needs to be in the "why" and then in the "how/what"
andrey, shriya: more to be added to the "why and how" https://libre-soc.org/irclog/%23libre-soc.2023-08-15.log.html#t2023-08-15T00:01:34 yes this is the process that i have been following for five years. i expect everyone to know it, know *why* it exists, and follow it strictly because the damage done, time wasted and jeapordy to the project by failing to meet its unwritten obligations to NLnet, is otherwise unacceptable.
(In reply to Luke Kenneth Casson Leighton from comment #5) > needs to be in the "why" and then in the "how/what" (In reply to Luke Kenneth Casson Leighton from comment #6) > andrey, shriya: more to be added to the "why and how" Added a few more lines based on your conversations: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=9b6b662d559441a2f01d1b6cfbb88b832e617f25 https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=c0b515803e2ffdb18582d9aa8336d5060fdf5526 Forgot about the two sections, so I moved the 'why' sentences to their respective place: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=70e614970fbc51691114f36961bb3a5f2cac4620
andrey, ths also needs adding, "how to do budget estimation" https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-August/005592.html it involves guestimating +/- 40% a number of days where "number" is less than appx 8, but no smaller than 1/2 a day, and the total subtasks so estimated is appx 5-25. if greater than 8 days it is REQUIRED to break it into smaller subtasks. statistically speaking the +/- 40% variance when added up over 20+ tasks gives a time estimate that is accurate to +/- 10%. ... but you have to actually have a fricking clue and a clear idea of what is actually needed, and NOT leave anything out. forget to add say "do the documentation" to the list of tasks to be estimated for funding and you just screwed the project by failing to put in the Grant Request to cover 80% more work than there is available money. or your project just has no documentation and is worthless due to noone being able to maintain it in future.
also the following need adding to the HDL_workflow along with explanations: * Liskov Substitution Principle * Principle of Least Surprise https://bugs.libre-soc.org/show_bug.cgi?id=1039#c33
always put "bug #NNN" not "#NNN". add the insight about saving time and making things easier to track in order to focus on accelerating iteration. slogging through bugs forcing developers to type "NNN" into the bug/search field (if they even know about that), rather than just clicking on a link? this is hostile to forward progress, and aggravating. https://libre-soc.org/irclog/%23libre-soc.2023-08-25.log.html#t2023-08-25T10:00:05
also need to be aware of the level of inter-dependencies, the specification being *the* absolute top priority for maintaining as "100% up-to-date", followed by a cascade of inter-dependent bugreports that trickle down from that to cover the CSV files, insndb, ISACaller, binutils, and then to TestIssuer which has its own set of dependencies especially if a new regfile or SPR is added. https://libre-soc.org/irclog/%23libre-soc.2023-09-02.log.html#t2023-09-02T08:32:23
"do not attempt to re-use bugs" section needed. rationale here: http://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005625.html
all code MUST have copyright notices license headers and an NLnet grant and EU ref number https://bugs.libre-soc.org/show_bug.cgi?id=982#c23 extremely important.
Also link #1164 into HDL_workflow and into the main front page in order to make it easy for people to find examples of other people going through onboarding, and also to find a template for the same.
another necessary task, highlighted from bug #1171: whenever new sub-tasks are added which have a sub-budget assigned from an existing Milestone, it is necessary to: * notify Michiel and the relevant NNNN-NN@nlnet.nl team of advance notice of intent to add new sub-tasks, cc'ing bob goudriaan - confirm with them that this is NOT a change in the AGREED MILESTONE BUDGETs, because it is just sub-task allocation. - confirm that they are happy to add the sub-tasks to the MoU (this needs approval of bob goudriaan) * *re-generate* the JSON file * make a DIFF against the *PREVIOUS* JSON file * create a MANUAL report/summary of "changes" that NLnet may easily action - "add the following task X to parent Y of amount W", - and if any: "change parent Z available amount to V as a WRAPUP") (this latter is because occasionally there are subtasks NOT totalling the full parent amount, usually because a summary report is needed. Michiel and I privately agreed to call this "wrapup") * obtain a confirmation that this has been actioned * DOUBLE-CHECK that the RFP database correctly matches the new bugzilla status. PLEASE NOTE: YOU CANNOT ACTION THE ABOVE UNDER THE FOLLOWING CIRCUMSTANCES 1. to make a change to the actual budgetary amounts of the Grant Milestones, without written authorization from Bob and Michiel. a DIFFERENT PROCEDURE is needed. this is because NLnet had to go through a 3rd party Verification Process with the European Union: changing the amounts without consent is therefore tantamount to fraud. 2. if there has been an RFP already submitted under a given Milestone, it becomes NO LONGER POSSIBLE to change the JSON file in NLnet's system because it is too complex. there is one Grant in this complex situation: bug #690, the crypto grant. it is made much more complex because it *pre-dates* NLnet's current RFP system, where RFPs were submitted by EMAIL and there are manual records not fully integrated into the database. also note: as the addition of sub-tasks *requires a change to the MOU* it should NOT be taken lightly, i.e. should not be arbitrarily done one by one, but only in "batches". considerable care therefore has to be taken to ensure that NLnet are not overloaded, nor that the EU Auditor is given grounds to become "suspicious" because of a dozen or more alterations to the MOU.
Created a new page which will be used to document points covered under this bug: https://libre-soc.org/libresoc_bug_process/ https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=20d7aed364a29d298af4994575be259c3491f84f https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=3e6492ea4f6b4cdc8b04bc6d8b0ea9358ac4dce8 I will be gradually adding bits over the course of today.
(In reply to Andrey Miroshnikov from comment #16) > Created a new page which will be used to document points covered under this > bug: > https://libre-soc.org/libresoc_bug_process/ (In reply to Luke Kenneth Casson Leighton from comment #15) > another necessary task, highlighted from bug #1171: > whenever new sub-tasks are added which have a sub-budget > assigned from an existing Milestone, it is necessary to: Added information from your comment Luke: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=1f2f589f6f3f73b9890bd5d0c7a4ad19de96c061 Jacob please have a good read over it to familiarise yourself (I need to do so too, as well as the rest of team).
(In reply to Andrey Miroshnikov from comment #16) > Created a new page which will be used to document points covered under this > bug: > https://libre-soc.org/libresoc_bug_process/ it goes under HDL_workflow
(In reply to Luke Kenneth Casson Leighton from comment #18) > it goes under HDL_workflow https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=f924c90239a done. TODO: link in a section in HDL_workflow
luke asked to post the "i'm thinking of doing ..." procedure: https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005678.html
(In reply to Jacob Lifshay from comment #20) > luke asked to post the "i'm thinking of doing ..." procedure: > https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005678. > html i meant, "track down the email from last week" and track down the mailing list posts on the same topic (when i first sent them, nearly a year ago), and explicitly post the copy here so that it can be put into the wiki. i am not going to repeat it or write it out again for the seventh time in one year *your* responsibility is to listen the first time.