@fhvyhjriur

Flashable reproducible artifacts are under https://app.circleci.com/pipelines/github/tlaurion/heads/2571/workflows/ca2d05fc-1163-41fd-a862-463e9eff49e2/jobs/46423/artifacts

closes #1672 without putting it back as maintained for now.

Could you put the T530 back as maintained? Take a look at #1682

@fhvyhjriur there is no timely testers responsive under #692 anymore :

t530 (xx30): @3hhh

Never tested rom builds for a really long while. Pending is to remove the board from having testers, not putting the board back as all other tested boards with responsive board owners interested into their board continuing to be maintained.

Would you be that new timely tester for t530? I'm not gonna repeat past experience here: boards need to be tested in a timely manner by users having external programmer and willing to use it if needed so that other less technical users don't flash something expected to work when it isn't and causing bricks for users not expected to have an external flasher because things should be tested before being merged. That's the bare minimal. If the board doesn't boot properly, you do not seem to be that technical user being able to provide patches to fix it, are you? So basically I would create more work for myself where past decision was to love the board to being unmaintained. This board needs a fairly technical person as a board owner willing to test and even fix things when they are broken, interact with coreboot community when needed, and fix those boards for themselves. I do not own the board, I repeat.

The kgpe-d16 is a different story since most known users are technical users having multiple adapters they can swap in case of something failing, and where access to the board requires swapping to original flash chip with a bigger one, not involving solderin.

The t530 is neither like the x230 where spi chips are easily accessible under the keyboard. The t530 is not properly documented either, it was supposed to be done by original port board owner which never happened, making me answer questions for a board I do not own. I will not repeat history. This is a community project where board owners should be willing testers and selfish contributionnists, not me having to poke for sometimes weeks going to a month for things to get tested before merge.

You confirming things still working is the first step. The next step is engagement of not letting PR bit rotting, which I'm sorry, happened under your own past requests before. I'm not taking maintenance engagement anymore for boards I do not own or do not have responsible nor responsive board owners as testers when Linux kernel or coreboot version are bumped. If you were not responsive in the past, this shows you might not be responsive in the future, which means this board having only one declared board owner have high probabilities to be moved back as UNMAINTAINED in next important changes targeting parts requiring per platform testing. I don't have time to poke people constantly around: this is way above my pay grade based on mostly absent donations.

Do you know more responsive t530 board owners that could enroll under #692 maybe?

Sorry but I've learned through this, which is why the board became untested first and then moved to unmaintained, which I wished didn't happen but this simply shows that board is not used widely enough to deserve free maintainership on my side anymore without high engagement of a board owner, which should have been technical enough to do himself the PR I made you test leading to you closing it and opening a new issue asking me now to rename the board, which you should be able to do yourself. This alone could convince me to bring the board back to being maintained. On which premises this board deserves my rare community time to poke unresponsive board owners not able to help me fix what is kroen which is board specific when it comes to coreboot ?

Otherwise I interpret this as a request for me to maintain boards used by one person and that person not being technical enough or kotivated enough to bring back the board himself, which is what this community project is about.

See how the only board owner assigned don't respond here anymore? The plan is not to have UNMAINTAINED nor untested boards under Circleci bukdijg roms for end users not being technical enough to unbrick their devices, causing more harm then good here.

Hope we have a common understanding here.
You should be involved enough to be able to take my PR, and move the board to tested yourself. Me doing this myself is giving unlimited supplies of fish to someone not interested in learning how to fish.

I think I understand your feelings about open source projects @tlaurion. In the beginning one usually is a very enthusiastic and positive maintainer and over time one learns that many people are just abusing open source for their own gain without giving anything back.

I try not to be that way by contributing to projects I really like (incl. this one).
However I also try not to get too involved in order not to get into the aforementioned position (personal impact outweighing personal gain from a project - especially one that I don't maintain myself).

In this particular case my personal impact of a bricked T530 currently oftentimes outweighs the gains as I need my T530s on a daily basis and have to spend 2-4 hours to bring them back in case of a brick. Actually I had even bought a third T530 on which I planned to test heads, but unfortunately bricked that one on first flash (I only managed to flash one of the chips).

So yes, tests from my end will continue to happen randomly, if at all.

Anyway I disagree with the current approach of just ditching boards that aren't regularly tested:

Just because something is not recently tested doesn't mean that heads cannot be used for that particular board - it might just be an older version of heads. People mostly don't care whether they use the latest greatest release or some older release - especially for their BIOS - as long as their system comes up.

So instead I'd suggest to keep the last tested version for a board available somewhere (some sort of downloads page or so). Only if there's some major security issue with old versions, it may make sense to remove them or at least mark them as dangerous to use.

Btw IIRC I last tested heads-UNTESTED_t530-hotp-maximized-v0.2.0-1991-g90d1c2e.rom on Jan 10 2024.

I think I understand your feelings about open source projects @tlaurion. In the beginning one usually is a very enthusiastic and positive maintainer and over time one learns that many people are just abusing open source for their own gain without giving anything back.

I try not to be that way by contributing to projects I really like (incl. this one). However I also try not to get too involved in order not to get into the aforementioned position (personal impact outweighing personal gain from a project - especially one that I don't maintain myself).

I completely get that, i do the same for other projects and can totally empathize with that. Thank you for acknowledging that and caring here. This is really appreciated.

In this particular case my personal impact of a bricked T530 currently oftentimes outweighs the gains as I need my T530s on a daily basis and have to spend 2-4 hours to bring them back in case of a brick. Actually I had even bought a third T530 on which I planned to test heads, but unfortunately bricked that one on first flash (I only managed to flash one of the chips).

So yes, tests from my end will continue to happen randomly, if at all.

That is the problem i'm talking about because as opposed to other FOSS projects where an app would just crash and burn, FOSS firmware projects don't boot when things get untested in time under Heads, will possibly create bricks which one needs to externally flash with either a fixed one or an old one, and where the t530, as opposed to other boards, requires more disassembly of the board to acccess SPI flash chips, which may cause mayhem if not tested at really important milestones, which the t530 suffered from in the past, because not massively used as opposed to other boards of the same generation which are easier to recover from testing. This is exactly why this board doesn't get the same level of testing and adoption even on the coreboot side alone. You chose them over other boards of the same generation for reasons that are yours and therefore should care about participating into the board staying maintained. This is unfortunate reality of boards which flash chips are not easily accessible unless a gadget exists that can be glued on, which hopefully I will pass second NlNet round and get funding for because this is a real problem. But not yet fixed, right? This is why it became unmaintained, right?

Anyway I disagree with the current approach of just ditching boards that aren't regularly tested:

It's not to be regularly tested. Heads evolved a lot, and most of the changes are now being tested under qemu and on boards of the same family. This results in way higher confidence that daily changes in security policies (scripts: content of heads.cpio: the main goal of Heads) won't affect any specific platform and can be tested virtually (tpm1/tmp2/hotp/no-hotp/whiptail/fbwhiptail) without causing a probability of creating bricks for untested platforms by dedicated and participating board owners. Read others arriving to heads and saying: ho! I want the t530 too! But not understanding that its untested because of board disassembly to recover from bricks, which is exactly why you didn't test the builds when needed, @3hhh. I hope you take this for what this is : a fair point against that platform, that board model specifically.

Just because something is not recently tested doesn't mean that heads cannot be used for that particular board - it might just be an older version of heads. People mostly don't care whether they use the latest greatest release or some older release - especially for their BIOS - as long as their system comes up.

And that is the issue here. The system might have not come up since it was last reported tested by you @3hhh, since it involved a coreboot version bump which could have broke libgfxinit, sysfb, suspend, tpm, acpi, video ports and a lot of other things actually. Not aiming to be an attack toward you here, but boards without testers when tagged in pull requests now fall under unmaintained category exactly for that reason. The last commit of PR when untested is to move board to untested, change CI config and move on. If boards were previously untested, then become unmaintained. Plain and simple. The fact that this board is now unmaintained shows that at least two important testing cycles required by board owners didn't happen. Other projects like skulls and libreboot here don't have that burden: its plain flat coreboot without security features baked in, relaying on seabios+grub not linux as a payload. This is what is being mostly used, and makes Heads peculiar in compatibility and testing needed so that the platform not only post, but is able to boot into another kernel with all those compatibility layers not having broke neither under coreboot nor linux it depends on. This is technical and might seem easy because it just works(tm), but it might not. And that is why testing is required when version bumps occurs. And failed. For that particular platforms as well as dgpu variants of the boards.

Solution to this would obviously be to have myself have all the boards that are brought up under Heads (its speeding up). But I will not use those platforms as board owners do. And I do not intend to each and every single one of them either because I have no use for that. Another recent example #1685 : a user bought a t420 with dgpu without knowing. Should this makes me support own not only igpu but also dgpu variants? This never ends. I say no. Why? because the motherboards themselves are not even wired up electronically the same way, the GPU doesn't even drive the outputs the same way, requiring vbt and vbios and other stuff that at least one technical board owner should be aware of to help me when coreboot+linux version bumps occur.

TLDR: This should be picked up by a technical user desiring his board to be maintained under Heads, not the other way around, otherwise each time I see a board being brought up, the quantity of work I need to do increase at each version bump, and if I don't come up with a way of maintaining only what is used out there, and I mean not just by a single non-technical user, I need to consent about the investment in time vs usefullness of that effort. And the t530 is a counter example of this winning ratio of effort/outcome.

So instead I'd suggest to keep the last tested version for a board available somewhere (some sort of downloads page or so).

Heads is a rolling release with roms being available in PR for last pushed commit for 30 days after build prior of being merged. And under master for 30 days after merge. Heads is a rolling release, aka bleeding edge. Where newcomers must be able to trust that roms built from CI were tested otherwise not merged.

As said previously, confidence is high enough that scripts changes won't affect anything once tested through qemu with all possible variants there being able to pick up problems. No problem with bumping tools version under modules/* that works for other platforms I can test against, which don't affect specifically some platforms (aka coreboot/linux changes).

Now coming back to the nature of Heads, which is to use linux as a coreboot payload (linuxboot over coreboot vs uefi), and coreboot having speeding up their release cycle to every 3 months, where Heds doesn't follow tightly: bunping coreboot alone requires timely testing from board owners, which if they cared enough about their used platform to be maintained by me, which doesn't own those boards (this is stated in PR needing testing) then those became unmaintained, plain and simple.

Only if there's some major security issue with old versions, it may make sense to remove them or at least mark them as dangerous to use.

Btw IIRC I last tested heads-UNTESTED_t530-hotp-maximized-v0.2.0-1991-g90d1c2e.rom on Jan 10 2024.

Alright: so check the changes that happened since you last tested a rom @3hhh :
90d1c2e...master

• Includes a coreboot version bump which is the one having not been tested and having led this platform that you care for but not enough to have tested in a timely manner b91eaed
• that happened under 4.22.01 fhd patch merged upstream (4.24) + bump all 4.19 boards to 4.22.01 #1604 which required testing to not avail 4.22.01 fhd patch merged upstream (4.24) + bump all 4.19 boards to 4.22.01 #1604 (comment)
• This PR was left open from feb 05th 2024 and merged on March 25th 2024 without the t530, amongst other dgpu boards which could follow the same exact requests from people waking up way too late for me to then want to go back myself and fix all those boards whose changes were not following master, bringing the cost of maintainership on my shoulder

The switch in strategy here is that since Heads is a community driven project, if a board stays untested for changes that could break a platform, it becomes untested. If board stays untested until next major changes that could break usage, it becomes unmaintained. That was also tagging board owners when that happened, directly over github which board owners should have received notifications about. Unfortunately not my problem.

now @fhvyhjriur tested this PR, so:

• its still unmaintained, but was tested. That requires moving boards names around some more requiring work, break somehow the boards git history with renaming of files and making things hard to trace for anyone interested in following changes related to a board in time. This is also not a sign of a board being used nor cared for enough.

Constructive points to challenge

• Why was the coreboot version bump untested when needed for more then a month?
• Is this acceptable on a maintainership perspective?
• How can the process be improved so that boards in tree, built by CI for each commit are only the ones being used by the community? How would I know if nobody answers calls for testing?
• What better process would you propose?
• The t530 is not a model that can be easily unbricked, which is actually the plan with all of this, where documentation is not updated either T530/w530 disassembling/flashing notes heads-wiki#83
• the t530 could have been picked up by you @3hhh and brought back to master once tested functional, with you making the board config, coreboot config and linux config tested to be par with boards of the same family and the problem would have been resolved, with you understanding the time and cost of not testing boards having led them to become untested, and then unmaintained
• The t530 is not complicated for me to move to master again, but the point is that the two declared users of the t530, not even dgpu version which is another story, cannot clearly say: I will test PR requiring board owner testing when required once or twice a year when the board is actually just having that risky change to test, and I'm willing to plan and invest 2 hours unbricking it if it happens
• Note that as opposed to Skulls or libreboot project, Heads relies on coreboot to and libgfxinit to prepare sysgfb then used by efifb linux kernel driver. Heads use case here makes it different then those pojects is one of the reason why testing from board owners is required whenever a linux kernel version bup or coreboot version bump is needed.
• When this occurs, its a call for testing for all board owners. It doesn't happen often. And when it does and board owners don't answer the call, I don't answer the call back and the burden of maintainership is then placed on the next technically advanced board owner to bring back an unmaintained platform, not me.

Based on those facts @3hhh, I hear you would want the roms to be hosted somewhere but this is not yet the case and unplanned, since OEM and organizations making money out of Heads are creating releases out of the upstream rolling release, extensively QA test it and offer support for the boards they sell, making them responsible to create issues for their users or engage with me to fix discovered issues that might already be fixed upstream (scripts) where they reuse coreboot+linux version bump normally in their releases and answer the call for testing when needed, otherwise requiring me to have all the platforms, which I won't do.

Now let's be constructive taking into consideration the perticular nature of heads project depending on coreboot and linux and so many other moving pieces, but concentrating on the most bricking possible parts being linux and coreboot version bump testing. What should I cahnge in the current process and why should I merge this PR in the current situation where doing so will only lead into making it go unmaintained soon? A coreboot version bump is needed for all other platforms since Headds is behind now. Who will test the t530 risking need to disasemble to unbrick and who will engage degugging it? I cannot even tag other board owners: there are none declared being responsibe enough to test builds in a 1 month timelapse, where if not responsive, PR bitrot and makes me work even more (rebasin because other PR were merged in that timeframe, cherry-picking of commits not applying cleanly and all the other jazz which brought me to decide that those platforms having been moved to untested first were due to be moved to unmaintained for all abovementioned reasons.

Nobody stood up yet to be a timely tester of at least coreboot+linux version bumps, nobody stood up in the recent past when it was needed. So what do I do with this PR?

@fhvyhjriur @3hhh ? Can there be engagement? if none, I close this PR and it should be brought back by one of you: look at the changes. Any of you could have done this. But after a kernel+coreboot version bump to clean kernel config and coreboot config to be par with other platforms of their generation? For free? Forever? No. It should be board owners participating when needed in PR within weeks of needed merge window, not a month, not never.

I get your perspectives, don't get me wrong, but mine is maintaining boards that I do not own because I find them impractical, and that are not even officially used by anybody, where people using them don't care enough to answer within a month of required testing window. I don't know what to do with this. If someone was selling the t530 it would be a different sotry, but it isn't so the burden of maintance is then free without any code of money compenseation, without boards ebing tested working in time.

So instead I'd suggest to keep the last tested version for a board available somewhere (some sort of downloads page or so). Only if there's some major security issue with old versions, it may make sense to remove them or at least mark them as dangerous to use.

Hm, my earlier suggestion possibly was given too hastily without knowing all the facts.

So let me try to collect these first:

What was the real reason behind the CI removal of untested boards?

Did you need to cut CI costs?

I guess it wasn't too much of a maintenance burden as the coreboot config files are relatively small (75 lines or so) and don't change that often?

Or are we really talking about the idealistic approach of only having well tested boards in the heads tree?

Also, what's the difference between "untested" and "unmaintained" now? I noticed there are still a few boards built by the CI pipeline, but flagged as "untested".

On a side note:
In my case the T530 brick happened because of some hardware issue (one of the flash chips is dead imho - probably I accidentally shorted something or whatnot) and not because of some heads software issue. I wouldn't mind sending the bricked board to you for free, but I guess it'd just end up a waste of time for you, too.

On a side note:
In my case the T530 brick happened because of some hardware issue (one of the flash chips is dead imho - probably I accidentally shorted something or whatnot) and not because of some heads software issue. I wouldn't mind sending the bricked board to you for free, but I guess it'd just end up a waste of time for you, too.

@3hhh
I'm unfortunately not a low level refurnishing guy offering electronic micro soldering services, including what @fhvyhjriur is talking a out in other issues, replacing faulty/smaller flash chips or unsoldering/soldering new resistors if they were abused by voltage.

But this is where synergies could happen with @githubisnonfree through https://minifree.org/product/installation-service/ where Leah offered in the past to flash Heads as a service and does microelectonic work by passion and need. You should contact her to repair your t530.

I repeat, the goal here is not for me to have all Heads supported platforms and then have to test them all myself, but build a community of technical enough people who self help/help others for the platforms they love, and where organisations can add Heads in their product offerings on which I can make money through profit sharing contracts and then help maintain and help those organisations into supporting their customers and then others to have Heads on coreboot supported platforms they can DIY for themselves for free, where other partners are developing coreboot on said new platforms on which I help to integrate heads on. This would help everyone, but as said if no board owner is willing to test already produced roms by ci (removing the technical part of building roms already here) then this path is void for the t530 because the barrier to entrance for unbricking the platform makes that platform undesirable for both business and DIY. Point just proven here that the t530 might not be fit for Heads maintenance because even technical users consider time investment/gains to not be a win in the t530, so why should I care more then a technical person already having a fleet of t530?

Please contact @githubisnonfree, otherwise what you proposed here is for me to give more supplies of fish, not a fishing line. To an extend, the proposition here would be for me to go alone in a fish trip, as opposed to get mindlike people coming with me on a trip to have a good time and learn some tricks along the way, tightening the bounds of what we want here: have others be able to use it because they need to, while us being technical enough being some kind of network of support.

If I accepted your t530 donation, I would then become alone supporting that platform without any other known technical user being also a board owner willing to chip in in time if not money to scratch his own itches, being able to help support it and others in case of problems through issues, documentation and other stuff related which is normally offered through business services on which people make money from.

This is why this platform went UNMAINTAINED and why I do not want to maintain platforms who has zero known board owners also on GitHub (meaning technical enough to be here at least...)

TLDR: I cannot support a platform without having at least one board owner at least willing to test coreboot version bump. I think I made my point clear here on why's and how that could change and why I took this decision as the maintainer of the project. If neither of you can offer self-support and help others, I have no more free time to deal with Heads as a pet project anymore, businesses and a lot of users depend on it nowadays, and I need other DIY users to at least test builds produced for free and easy to download to also give a hand otherwise this is no go for me.

Hope you understand and will show you care enough too.

For 250 bucks I can buy two more T530 to do it myself. Also, this was just a side note. A simple "No thanks, no interest / time." would have been sufficient.

In total I understand that users with no officially tested heads boards need to fork heads in the future to get ROMs, if they need them. Imho that's a bit of a weird way to build a community, but at least it's a clear statement.

@3hhh
What country are you from? I would fix your T530 devices for free when somehow a local meetup would be possible. I would pay on my side the shipment back to you if a second meetup wont make that much sense from the productivity view. I have unused 4 and 8MiB SPI chips after updated some boards to double 16MiB SPI chip.
Not being able to do coreboot/heads software development because of such a simple hardware issue is just insane in my eyes and that is why i make this offer to you.

@tlaurion
Those wall of text you always write. You are such a capable developer. Writing this long text here have cost you probably more time then just writing the code to bring back the T530.

I dont have all the overview of all those pages you created here in github. I just do hardware work. When i am not listed in #692 for the T530 then write me there like you seem to have done for the Thinkpad r500 (but not t400 where i have done testing and reporting here on github).

I dont know where to write it, i hope here is enough:
I am not a software developer. Please dont request from me software developer work like PR.
@tlaurion
You wrote:

But after a kernel+coreboot version bump to clean kernel config and coreboot config to be par with other platforms of their generation? For free? Forever? No."

I have spend my money and my time for this project. Bought hardware, reworked it and tested the things that had to be tested because a device is not listed in supported any more and people cant get the binaries to run them on their hardware. That was many hours of work (and money). Have i done this for me? No. I do not want to own a T530. I have done it for this project.
Please do not give me the feeling that i am requesting something from you when in reality i do just the testing work that is undone in this project.

BTW: After i have seen #1685, i got especially for the heads project a T420-dGPU version and would do the testing. Further about this topic on the page there.

Left as unmaintsined board because no board owner being able to test and improve this board if needed.