TonyMac32 Posted April 3, 2019 Posted April 3, 2019 A thought occurred to me while watching my machine sync a bunch of repos while running the Armbian build script, and I couldn't help wondering: Could we put the board support patches into their own repo separate from the build scripts themselves? More specifically: board support for "Boards of Interest" to the Armbian maintainers would be in whatever "official" repos we dedicate, I recommend separating per board family or SoC board support for CSC goes into, predictably, a CSC repo board support for EOL boards can be spun off into their own repo TV boxes go into a TV box repo Advantages: Supporting every pet project wont result in build system bloat as it does today. Users of the script can maintain a csc board support repo with the required structure without hacking on the build script itself, making adding such a board to the "supported" repo much easier, if even necessary. While I don't "tiptoe through the tulips" with CSC boards, I do go to some effort not to break them with changes. Those boards won't be interacting with the others anymore, they'll have their own space. Cons: Perceived fragmentation of support. In reality this is a good way to disengage the build script from pet projects and focus on the boards we as a team care about. Some work to implement (although I think the biggest part can be laced into the menu where you choose the board (CSC/WIP vs supported) @lanefu, @Igor, Could we add an "RFC" tag? would be useful, and consistent with linux terminology.
Igor Posted April 3, 2019 Posted April 3, 2019 2 minutes ago, TonyMac32 said: A thought occurred to me while watching my machine sync a bunch of repos while running the Armbian build script, and I couldn't help wondering: Could we put the board support patches into their own repo separate from the build scripts themselves? I had similar though but not fragmenting to CSC/EOL/TVBOXES. Only moving patches section to the separate repository? Both "cons" goes away
TonyMac32 Posted April 3, 2019 Author Posted April 3, 2019 1 minute ago, Igor said: I had similar though but not fragmenting to CSC/EOL/TVBOXES. Only moving patches section to the separate repository? Both "cons" goes away I think this could also be handled in stages, patches first. One of the things I see when we get a "variety show" going in a family is that the u-boot and family tweaking scripts go absolutely off the rails as far as complexity is concerned.
Igor Posted April 3, 2019 Posted April 3, 2019 1 minute ago, TonyMac32 said: I think this could also be handled in stages, patches first. Finished this and moved patches to separate repository. 4 minutes ago, TonyMac32 said: One of the things I see when we get a "variety show" going in a family is that the u-boot and family tweaking scripts go absolutely off the rails as far as complexity is concerned. Agree. This was designed to be able to handle rare exceptions which are sadly not that rare.
TonyMac32 Posted April 3, 2019 Author Posted April 3, 2019 10 minutes ago, Igor said: sadly not that rare Well, look at Amlogic, every single flavor of every SoC family has a different proprietary blob and different offsets for where it goes, it's a mess.
lanefu Posted April 3, 2019 Posted April 3, 2019 Well im a big fan of git submodules in general... it would be nice to be able to version the build and configs separately. Build scripts could pull latest submodule by default, but would def need an option flag to leave things alone when desired. Maybe even a param to specify a tag for config repo A repo per soc would make it super lean, by only initializing a submodule on demand..... but thats probably uneeded complexity 🙄
lanefu Posted April 3, 2019 Posted April 3, 2019 8 hours ago, TonyMac32 said: Could we add an "RFC" tag? would be useful, and consistent with linux terminology. wow i'm struggling to figure out how to add it
lanefu Posted July 4, 2019 Posted July 4, 2019 On 4/3/2019 at 12:44 AM, TonyMac32 said: @lanefu, @Igor, Could we add an "RFC" tag? would be useful, and consistent with linux terminology. I finally made rfc tags work better
chwe Posted July 4, 2019 Posted July 4, 2019 On 4/3/2019 at 6:44 AM, TonyMac32 said: board support for CSC goes into, predictably, a CSC repo board support for EOL boards can be spun off into their own repo well.. problem if csc is out of the normal pipe.. if kernelpatches are needed.. they probably break with every update.. :s I know csc are csc for a reason.. but, explaining this again and again.. will be a pain.. I would be in favor of moving csc into a subfolder of the patching.. and have some sort of a bot.. once recognized that a csc patch doesn't apply properly, it gets automatic disabled (for sure.. complains will still come, but at least we would have something which is explainable, eos related patches could sit in the same subfolder), documented that those patches are not maintained anymore by the core project...
TonyMac32 Posted July 5, 2019 Author Posted July 5, 2019 I think you misunderstood, I am proposing making each board family a self-contained unit, no patches exist at all in the build system itself, so the CSC stuff can do whatever it likes. The mechanism is to support users having their own boards without having to glue them into the other code.Sent from my Pixel using Tapatalk
chwe Posted July 5, 2019 Posted July 5, 2019 42 minutes ago, TonyMac32 said: I think you misunderstood, I am proposing making each board family a self-contained unit, Maybe.. but if you separate patches in their own repo they still break from time to time.. and then? if csc patches are separate from official patches how to deal with it? the kernel will still be 'per boardfamily' means needed for csc as well to work properly.
TonyMac32 Posted July 5, 2019 Author Posted July 5, 2019 Maybe.. but if you separate patches in their own repo they still break from time to time.. and then? if csc patches are separate from official patches how to deal with it? the kernel will still be 'per boardfamily' means needed for csc as well to work properly.The *C*ommunity will have to *S*upport. Sent from my Pixel using Tapatalk
chwe Posted July 5, 2019 Posted July 5, 2019 and the moderators have to explain again and again.. and again.. That's why csc patches should have a 'tag' (could be subfolder or csc_random_feature.patch) and a bot disables them automatically in case they break. first we would know soon which csc boards get community support and those who don't can be moved to eos, second as long as the patches apply properly they don't harm us (only if it's a 'bad' one which modifies stuff it shouldn't) so those boards get a decent support even when we don't invest much work into them. Otherwise I only see freeze kernel by default for csc as a sane option. constantly explaining our users that their csc board breaks cause we dropped their DTS and it messes around is kind of boring, including the 'armbian is not stable on my board blabla..
Recommended Posts