26 Aug
2017
26 Aug
'17
8:23 p.m.
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
31 Aug
31 Aug
1:36 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2 Sep
2 Sep
12:45 a.m.
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
2451
days inactive
2457
days old
2 comments
2 participants
participants (2)
-
Harald Welte -
Neels Hofmeyr