I am sharing the whole conversation with Luiz. 1. The "What's in my mind?" part is the relevant part.
2. Also "official busybox" is also another relevant part. The #1 is about a zero-trust world, the #2 is about accountability. In the middle, there is "official" but "parent" project ulti a "fork" get more visibility, that is Gitthub: accountability by forking, there are many clones (but a single platform). Another relevant term is "trust" which connects the #1 and #2, and trust can be "accountability" or "transparency". Where is the transparency in Busybox development? Open Source is about the source code, not HOW that source code reaches the "official" release. Transparency is about the process, otherwise it is just documentation. Moreover, busybox.net can be compromised -- just for a little while -- the time needed to inject a specific insecurity into a specific vendor supply chain. Paradoxically, what said above is the reason why "github" is not "trustable" because it is "Microsoft" and "we are the good guys of GPLv2". Microsoft is accountable, in many ways, in many jurisdictions. Can the Busybox maintainer offer/sustain such a level of accountability? If the answer is no, THEN s/he should adopt a world-wide transparent process of development to share accountability and gain trust. Let me explain this in very crystal clear terms: Germany chose the Open Format Documentation by law and it is a great victory for the "good guy of the sw libre". That's the political choice. Same people that shutdown their last three nuclear reactors, decided to adopt the OFD by law. Can you see the analogy? green-free washing? In the past projects like Busybox could have been a political flagship. At the same time Hikvision and TP-Link are forbidden to sell in the US/EU and India but China is another story. What if the problem of that system would be "busybox"? Suddenly the "I am the official maintainer of busybox" started to be a "delivery issue" not a political flagship boat. Political victories are like sales celebrations. They finally made someone sign a piece of paper somewhere and someone else abided by those "promises". Whatever, just because I have my own "operative system recipe", I took the precaution of having a frozen repo (CodeBerg) and transparent dev-repo (GitHub). Me, the idiot of the village. As a precautionary first step I created trust and accountability across the US/EU ocean by transparency and redundancy for my personal project. Me, the idiot of the village. What about you? A question reported here not to answer to me, indeed -- because the green-washing costed almost WW3, the free-washing? LOL I waited to answer publicly because it was 1st April when Luiz wrote to me. Enjoy the day after 1st April 2026... ---------- Forwarded message --------- From: Roberto A. Foglietta <[email protected]> Date: Wed, 1 Apr 2026 at 02:17 Subject: Re: [PATCH v2] ash: fix wait -n behavior for multiple PIDs and pipe jobs To: Luiz Angelo Daros de Luca <[email protected]> On Wed, 1 Apr 2026 at 01:29, Luiz Angelo Daros de Luca <[email protected]> wrote: > > > Please, create a patch file (otherwise space and tab can mixup) on the > > top of the HEAD of this branch: > > > > - https://github.com/robang74/busybox/tree/bugfixes > > > > and I am going to transfer your patch to that branch as well. > > Contributions of others before your patch (especially when already > > tested) are not going to be removed but integrated unless your patch > > provides sensitive benefits like a relevant size reduction or > > complexity. > > > > Best regards, R- > > Hi Roberto, > > At this moment, my main goal is to have this patch reviewed and merged > directly into the official BusyBox upstream. Since the patch was > developed and tested against the official master branch, I would > prefer to keep the focus there for now. https://github.com/robang74/busybox/tree/ashfix2 > > If you'd like to integrate my patch into your tree for testing > purposes, I'm attaching it as well. However, if you mix multiple wait > -n fixes, they will conflict. > In applying your patch on "bugfixes" HEAD branch conflicts can be almost-brainless solved and the result is quite interesting, in particular the transformation of a function that was reporting information by a structure pointer used with NULL and returning an integer value which is check in a single place for error but usually busybox deal with error as exception (aka xmalloc) not by return value (printf problem recently passed in this ML, write around). > To help me understand how I can best contribute, could you please > clarify the purpose of your personal branch? Are you aggregating these > fixes to prepare a consolidated submission for the main maintainer, or > is this for a specific fork? Using a github for sharing development, comment, pull request is a modern way that can upset some people but my comment above would have been much clearer once read into the code and not polluting a m-list that would be better used for general discussion and not patches collector. IMHO. Clone a repository, apply your patch, see the impact on different branches, help and help a lot those who are doing that for work thus are more keen to share contribs (even if the media is not the barrier but usually the company policy for some people). That's the reason for GitHub success. A official master git can stay on CodeBerg, instead. > > To help me understand how I can best contribute, could you please > clarify the purpose of your personal branch? Are you aggregating these > fixes to prepare a consolidated submission for the main maintainer, or > is this for a specific fork? On GitHub forking is a common action. What's in my mind? Self-explanatory for everyone to use busybox at a reliable-level. Everything else is noise or none of your business. Just note that "What's in your mind?" (even politely asked implies trust and truth, both aren't cheap nor frequent, aren't asking too much in a zero-trust world?). Best regards, R- -- Roberto A. Foglietta +49.176.274.75.661 +39.349.33.30.697 _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
