Prioritizing and documenting libbsd development goals (was: libbsd updates)

[Sebastian Huber]

On 25.01.23 10:01, Christian MAUDERER wrote:
> On 2023-01-25 09:59, Sebastian Huber wrote:
>> On 25.01.23 09:52, Christian MAUDERER wrote:
>>> OK. Updated list based on Thomas and Sebastians feedback:
>>>
>>>  From highest to lowest priority:
>>>
>>> - Real time capabilities: No hard real time requirements for libbsd 
>>> core, but we have to make sure that it doesn't have a (relevant) 
>>> negative impact on other subsystems.
>>>
>>> - Maintainability: How easy is it for the people doing the main 
>>> maintenance tasks to do that work.
>>>
>>> - Transparency: How easy it is to understand the code? Relevant for 
>>> extending and debugging.
>>>
>>> - Code and RAM sizes (or other hardware requirements): Whether we 
>>> meet the minimum hardware requirements.
>>>
>>> - Modularity: How well and easy the system can be adapted to target 
>>> applications. Have only few official ways to enable / disable modules 
>>> in the subsystem.
>>>
>>> - Performance: Whether libbsd performs well enough in the typical use 
>>> cases.
>>>
>>> Any more suggestions for the order? Like I said, I would like to 
>>> integrate that to the libbsd documentation as goals for that 
>>> subsystem that can be used to evaluate different approaches for 
>>> implementing something. Would be good to have some more feedback from 
>>> others too.
>>>
>>> For example: I prioritized maintainability over transparency. That 
>>> means that we might choose a solution that's simpler to maintain but 
>>> makes it harder to integrate new modules. Is that OK?
>>>
>>> Similar the order of modularity and code / RAM size can be an issue: 
>>> Most of the time these should go well together. But it's quite 
>>> possible that some nice modular configuration options need extra code 
>>> compared to less nice methods. From my point of view we target 
>>> embedded systems where code and RAM size is more important. But I'm 
>>> not sure that this is the focus for everyone else too?
>>
>> I would not give the minimum RAM size such a low priority. libbsd used 
>> to work on systems with 16MiB. If you add new things which require 
>> additional 4MiB even if you don't use the stuff, then you simply kick 
>> out systems which used to work with libbsd.
>>
> 
> So no lower than modularity. Should it be higher than transparency or 
> maintainability? From the earlier comments I don't expect that it should 
> be higher than (core) real time capability.
> 
> What would be your preferred order?

Lets say you are a user of libbsd version X. Then you want to update to 
version X + 1. Version X + 1 no longer works on your system, because 
libbsd needs more RAM than you have. Would you really give this user an 
answer like this:

Sorry, maintainability and transparency is more important for us, so 
please stick to version X.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/