On Thu, Aug 31, 2017 at 01:36:19PM +0200, Harald Welte wrote:
The big problem is that such changes are often done
*before* there is any discussion
about whether the community actually thinks this is a good change, and hence
I'm facing the decision: "Get over my reservations and make use of the
work that has been done" vs. "reject more of those changes".
I think in hindsight, I have regretted a lot of those instances where I
merged them despite my reservations. Your experience with fall-out from
this particular change is one more reason to lean more on the "reject"
side from now on.
I agree.
A practical problem can be that individuals may be too busy to read all the
patches pending on gerrit. Meaning that problems one of us would notice can
easily slip by. It doesn't necessarily help to wait more...
Seems that the only way is to tend to be dismissive. In the recent past I've
caused annoyance by being too dismissive / criticizing. But I see it as a
normal and necessary process, and ideally it shouldn't discourage/annoy anyone.
In this instance I was not aware of the change until it was already merged, and
I would have voted for keeping the value string checking script in libosmocore,
close to where the struct value_string originates. I placed it there on
purpose. Any job building code with value_strings in it by definition has a
libosmocore close by, be it in our
jenkins.osmocom.org builds *or anywhere
else*. osmo-ci is especially for our own jenkins; other entities wanting to
check value strings now would need osmo-ci in addition to libosmocore.
Admittedly I'm not aware of any such other entities, so it's not a practical
problem to have it in osmo-ci and, now that it's done, probably not worth it to
move it back ... unfortunately ;)
~N