Michael Niewöhner wrote: > Once again, nobody is talking about deleting the platform or make it unusable.
Moving a board to a branch includes deleting it on master. Deleting on master harms the board in two ways: * Board code loses visibility, which also harms the project as a whole. (Less discoverable outside of the project => less newcomers.) * master diverges over time, so future work on master is less likely to apply to the board code. Whether you intend it or not that de-facto deprecates the board code. Added to that is a less quantifiable organizational/psychological aspect, where a board existing only on a historical release branch is likely understood by most to mean that this board code is indeed historical within coreboot. This is "softer" than the two points above, but I believe still of consequence. > Actually, moving it to a branch is the exact opposite to that - > preserve a *hopefully* working state, That state is preserved on master too, so that's not a good argument. If you want to discuss how we can best document the collective experience and test results for all boards then I think that's great! Martin mentioned board-status and how there's room for improvement in this area. But e.g. a branch per board is not an improvement, for the reasons I give in this thread. We could consider using git tags, but they're also not a very good fit. Do you have more ideas? Maybe something concrete for how board-status could be improved? Maybe a first improvement is to split it into two; one small repo for high-level test results with metadata, another for the log files. Perhaps some compression could improve storage requirements for the latter? > while still taking maintaince work My ask is that such benefits in fact exist and are explained when proposing to delete a board from master, so *those* can be discussed - as opposed to (like in this case) speculatively proposing to delete a board on master based merely on lack of recent (define recent?) test results and development work. (At some point every board code will become complete, so no more work required.) When there is a clear benefit, such as reducing workload in other code then it's possible to have a concrete discussion and it's also possible for people to offer other ways to create the same benefit. To me, deleting from master without clear benefit is premature. I guess one could argue that master should contain as little code as possible, only whatever someone is actively working on, but that doesn't seem at all useful for those who like to use our project. > from ***VOLUNTEERS***. I wonder what the split is between paid and spare time coreboot folks. //Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
