request for gerrit votes to fix debian packages

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Sep 21 04:49:13 UTC 2017


Hi Neels,

On Thu, Sep 21, 2017 at 12:48:28AM +0200, Neels Hofmeyr wrote:
> To fix the osmo-msc preliminary debian package build of osmo-msc, I need these
> patches in osmo-mgw to be merged:
> 
> [...]
> https://gerrit.osmocom.org/4003

I'm surprised about this.  Why would an entirely new osmo-mgw
implementation be needed to build debian packages, if that
implementation is not yet reviewed and not yet used from either osmo-bsc
or osmo-msc master?

> If review takes too long I am tempted to just merge it ahead to fix the state
> of osmo-msc.deb in
> https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly

Please don't.  I've just spent a long time and have lots of review
comments on 4003 alone.  There's nothing wrong at all with the work
being done so far, to the contrary.  I just think it is not ready yet.
In fact, it has never gone through any review, and your commit above has
been the first time this went into gerrit at all.

> If I do, it means that I would like to fix and improve those patches later, not
> that I want to smuggle them past review. I just want to finally get the debian
> builds working and off my mind again.

I don't think debian package builds should depend on significant new
code that is not in master yet.

> The osmo-msc currently fails because it needs a header file not included in
> libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers,
> which are of course not included in the libosmo-mgcp-client deb. I want them to
> be separated completely to save us this kind of cumbersomeness in the future.

I'm not following.

> Only one of the above commits unties libosmo-mgcp-client from the other libs,
> but small bits here and there make the change depend on the others in that
> bunch. I could re-arrange, but that would take time. I'd rather just keep them
> in that order, we want them merged anyway.

The design/architecture of the new osmo-mgw needs to be done right
before we merge it.  Related code has not been subject to review so far,
and I think it will still take quite a bit.  There's no point in rushing
this now, then make osmo-{bsc,msc} use that and then do another
iteration of changes which will very likely affeect the protocol and
thus interoperability with osmo-{bsc,msc}.

I'm all in favor of efficiency and not spending time on re-arranging
patches.  The question to me is rather why were the untangling patches
developed based on a non-master branch of very large ongoing development
work, rather than on master?  AFAICT, this is the reason we now need to
spend extra time to re-order the patches.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list