Change in osmo-mgw[master]: vty: Allow enabling Osmux

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/gerrit-log@lists.osmocom.org/.

Harald Welte gerrit-no-reply at lists.osmocom.org
Tue May 14 10:03:34 UTC 2019


Harald Welte has posted comments on this change. ( https://gerrit.osmocom.org/14021 )

Change subject: vty: Allow enabling Osmux
......................................................................


Patch Set 1:

> > will this commit alone make it work?  If yes, we can merge the
 > > patch as-is.  If not (which I suspect), then this patch should
 > > either be the very last patch in the series, or it should at
 > least
 > > for now still have an "#if 1" -> print error message like now.
 > 
 > Well it makes sense from chronological and development point of
 > view to have this first, since you want to build the new code using
 > the pre-existing logic of enabling it from a VTY cmd, so I first
 > need to enable it to test it. Once the whole set of patches in this
 > patchset is merged (they can be merged together), then Osmux works
 > again, at least for the most common cases I tested.
 > 
 > Since it's quite a lot of work, my plan is to have this patchset
 > merged providing initial support and once merged provide TTCN3
 > tests on osmo-bsc/osmo-msc/osmo-mgw. Later on features/special
 > cases can be improved, otherwise the amount of patches I need to
 > maintain in my branch is quite big.

In the end, our software is difficult enough to use as-is.  We shouldn't confuse the user with options that can be enabled and imply something is working, while it absolutely isn't.  I'm sure we have already some of these, but we shouldn't add more to it.

If you first enable some VTY option, commit that and then only later actually fix/implement it, then there's also the danger that we might tag a release in between.  The VTY commands then get listed in the manuals, etc.

So in summary, I think it's not too much to ask to keep the vty/config options in a private branch until the functionality is actually known wokring.


-- 
To view, visit https://gerrit.osmocom.org/14021
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ica2f82473bf1934502444be2325ee2049d938781
Gerrit-Change-Number: 14021
Gerrit-PatchSet: 1
Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-CC: Harald Welte <laforge at gnumonks.org>
Gerrit-Comment-Date: Tue, 14 May 2019 10:03:34 +0000
Gerrit-HasComments: No
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190514/9a9807cd/attachment.htm>


More information about the gerrit-log mailing list