about merging deletion of checking-value-strings script from libosmocore
I would have welcomed more patience in merging https://gerrit.osmocom.org/3685, "Use value string check from osmo-ci" in libosmocore. (the commit log of which fails to indicate removal of the script, btw) Moving to the new repositories, I have enough loose ends flapping in the wind, and dropping the script from libosmocore has added yet another distraction, while not being necessary to start using the one from osmo-ci. Max clearly posted "N. B: this should be merged last, after all the repos converted to check script from osmo-ci." -- which is not the case for the new repositores split from openbsc.git. In osmo-msc I have >50 patches waiting to be merged. The timing could hardly have been worse, luckily only a few gerrit builds are affected. Will try to sort out merging of the patches without needing a rebase and >50 rebuilds. Thanks for you attention :) ~N
Hi Neels, On Sat, Aug 26, 2017 at 08:23:05PM +0200, Neels Hofmeyr wrote:
I would have welcomed more patience in merging https://gerrit.osmocom.org/3685, "Use value string check from osmo-ci" in libosmocore. (the commit log of which fails to indicate removal of the script, btw)
My apologies. I'm absolutely *not* in favor of quite a number of the recent changes that affect the build dependencies, including the introduction of the bumpversion dependency, the move of the value string script, etc. 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. Also, if anyone else is planning changes to the build systems / infrastructure / build-time dependencies / ...: Please discuss *before* you invest time in doing something that will then rather likely be rejected. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
participants (2)
-
Harald Welte -
Neels Hofmeyr