Rare project developers

[mc36 <>]

hi,

On 3/30/22 17:22, Alexander Gall wrote:
[..]
> > right now the todo: is when a new line appeared in the todo.txt,
> > when one get removed then a no todo: will appear,
> > and if something happened to the test cases then a (no) qc pass:
> > will be omitted... if none of these happened, then the changelog
> > will be kept intact, so no commit message will be there...
>
> Thanks for the details. So, when something disappears from todo, it
> always means that the thing was implemented? How do you distinguish
> that from the case when you decide not to implement something that was
>   on the todo list? Maybe the difference is that there will be no test
> case?
exactly...
for anything that is relevant, a bunch of test cases appear around the no 
todo line...

> > mc36@safe:/data.pub/src$ java -jar rtr.jar test changelog since 2022-03-20
>
> That would be ok for me. The problem is a bit that the messages are
> very terse and I'm afraid that I won't understand what they mean in
> many cases. For example, I have no idea what to make of
>
> disableable door code in temper
temper is a web thermostat, a subproject under misc...
but later it got extended by a door opener, and later
by a generic relay interface... it just got a new
kind of door opening password capability, that is
not always active, just when a full one enables these...
an entrance ticket for my friends, but only when i enable:)

> or
>
> lsrp pvrp forbid remote dynamic metric
so recently i played a lot to tear down fib computations and lately
i noticed that my igp converges mostly because my mobile backup
have some wide variety of delay measurement results over time...
so for now, to not to make exception for this in my hub routers.
instead an igp peer can request that it must not be measured...

> It would also not make sense to copy this to the release notes
> verbatim. I'm still wondering how we can turn this into somehting
> that's useful for non-hardcore freeRtr hackers (of which there is a
> fairly small number close to one ;)
> We don't have to document every single change either. I'm looking more
> for a compact description of major changes so users have at least
> enough information to deceide whether it is something that could
> concern them or not.
>

agreed upon, most of these are small changes not all are easily
understandable or even not for a wider audience...
one direction could be if we grep the results to p4lang|bgp|isis|ospf...

br,
cs