New Contributor - Wanting to work on a feature
John Neuhaus
- The top sheets array already defines what can have its own PCB in this scheme.
- Use the boards array in the project file, which it appears is essentially unused, to store the boards. I think it's UUID and filename only right now, which I think can work given how much of the relationship is discovery driven.
- Blank array as the indicator for "legacy" and any behavior switching is the easy answer
- "Update-on-save" to populate the array and update projects. There might be backwards compatibility issues there I'm unaware of, but combining these two sub-bullets would give us "open in 11 -> convert, worst case for open in 10 -> revert, open in 11 -> back to the default" for basically free.
- Netlist export is what's used to populate the PCB, and already supports specifying a root scope, it just doesn't.
- Bonus on this, it dovetails nicely with expanding sheet-level capabilities, e.g. "Simulate sheet..." to pop open the simulator with only a subset exported, which wouldn't need to inherently care if it's top-level or not
- Update from schematic, open PCB, and all the back-annotation can rely on a combination of current active sheet and filename matching
- They already do, and it gets really squirrelly if you mess with it, e.g. by naming a PCB after the top-level sheet instead of the project. That half-works, and this scheme would/could impart better-defined behavior.
- There's almost nothing in the context menu of sheets currently, so no fight to add "Create Board...", "Associate existing board...", etc.
- Renaming sheets is a potential tricky spot
- Good spot for that "Simulate Sheet..." option.
- All the design rule stuff is already derived from board name
Seth Hillbrand
--
You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/5a49a753-a27b-4451-837b-e951e8f6db88n%40kicad.org.
Oliver
Hi beautiful KiCad dev team and Seth Hillbrand,
just a thought, i had for a long time, that might fit in this
context.
It has a deep background - to make it short, I wonder about the
long term maintainability of KiCad, since i
am mostly interested in software maintainability.
I consider, that Project became kind of difficult to maintain over
the years, and if so, I would be sad, since I consider KiCad one
of the best things out there.
When i started to "try" to contrib to KiCad by grabbing some
beginners bug to fix, I found it cumbersome to get starded,
despite the comprehensive doc.
My lag of expertise mostly, I guess. I learned already a lot in
the process.
So, I have an Idea to lower the threshold of becoming a
contributor.
What I personally started some time ago, for all my personal
software projects, is something i find an incredible useful small
thing that matters ( easter egg to Uncle Bob ) .
It is based on the Joel Test,
which i like very much.
It is very simple - I document the "how to work on this project"
and write a helper tool at the same time - very efficient.
It is an idea coming from rust, the "just" tool.
It works basically like this:
git clone any_project
just <- that shows the available commands to work on
the project
just setup <- this invokes the fetching and installing
of dependencies
just build <- runs whatever cmake command with args, and
so on
just run <- run from build environment without
installing
and so on. All from command line. IDE agnostic.
That's just an example.
So, all the "how to contribute" is encoded in the justfile,
instead of documenting all the details.
Platform aware.
Can even have args, like
just setup docker <- clone the docker script, setup the
build container, ...
or helpers like
just help <- points to contribution guideline, wiki,
policy ...
just status <- checks the current environment,
plattform, missing dependencies, whatever
or chain incvocations, like
just run <- invokes all the above as neccessary
or
just setup build run
Two more aspects on this:
1) that is just a thin wrapper, redirecting to the tools that do
these things. No intention to blow up the justfile - that is
documentation, not tooling.
2) I even found a practical way ( for a c++ project with many
targets ) to make that STATEFUL, so one could "configure" the
environment, like
just config release
just build
This came from the encounter, that cmaketools / vscode is ...
cumbersome for having many targets. For example.
Why is that adressing the joel test ? Because all that complexity
boils down to "can you make a build in one step", yes, it is
just
and everything that follows becomes self-explanatory, more or
less, ok , nothing is perfect, but if it lowered the threshold for
becoming a contributor ...
thanks for your attention.
kind regards
Oliver from Switzerland
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-pTVjjLe%2BhAM7b-bhuQ34x5vUVKpfonEjPJY_vS5S1zaA%40mail.gmail.com.
Seth Hillbrand
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/333a062b-dd1f-4db2-b095-3950e24618d9%40web.de.
Oliver
OK. I try that for myself then, and see if it would be of any
value (as a case study).
May i ask a few questions ?
- say i choose a beginenr bug to fix: How can i ensure not someone
else already work on it
- is maintainability a thing at all in kicad ?
- did maintainability got worse over time
- are you workig on it, and what exactly to you work at in that
regard
- what measures do you take to improve maintainability
( i know some industry reality like using QubeSonar on CI/CD,
or MISRA, and so on endless )
Thanks for spending time and attention to my message.
Oliver
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-rtrijJV4xr4ThASSWjfAazFMTKSKep08vmH1kVWdP_rA%40mail.gmail.com.
Seth Hillbrand
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/7afaa48e-a50f-4316-a2c7-b767a5a70562%40web.de.