Hi everyone, and in this particular case Sylvain,
I know I'm hogging osmo-msc.git and I don't intend to hinder everyone else's
work, but I doubt that it was really necessary to merge the silent call channel
types patch to master right now. I'm really overloaded with doing the inter-MSC
handover work, I'm again postponing my well earned leave that I would have
liked to have started two months ago, and I don't want to be burdened with also
resolving everyone else's merge conflicts. You all know that pretty much
everything changes in osmo-msc, even if only slightly. As a rule of thumb, if
you see a 'ran_conn', 'vlr_subscr_get()', a Paging callback function or a
'gsm_trans' in a bit of code, likely there will be merge conflicts with my
current branch. Most should be trivial, but they will be stones put in my way.
So please, before you merge onto master, consider doing the same work on the
tip of my branch 'neels/ho' in osmo-msc, rather than on current master. That
would be the ideal situation for me, because then you also test my patches.
There still is ongoing work at the tip of neels/ho, if you want a more stable
point to apply modifications to, look at the commit 'add LOG_TRANS, proper
context for all transactions' and rebase your changes onto that.
If you push those changes onto a private branch, I will even see them in tig
and can simply incorporate them in by branch, carrying them along until we're
ready to merge.
If you prefer working on master, still do me a favor: just try to rebase the
patch onto neels/ho. All the conflicts that you see in such a rebase will end
up on my table and stop me from going forward until I have resolved them.
Consider that before you hit that "Submit" button on gerrit in the osmo-msc.git
repository.
Plus, if I resolve conflicts with *your* code, likely I won't grok some minor
detail and introduce bugs.
So let's work together on this. Thanks!
Working on osmo-msc.git neels/ho branch also needs various patches in other
repositories; all these branches are kept up-to-date every day and all the
time:
libosmocore neels/misc
libosmo-sccp neels/conn_id
osmo-mgw neels/endpoint_fsm
osmo-msc neels/ho
Thanks again!
~N
Show replies by date
Hi Sylvain,
in this particular patch I ended up not having the patience to understand
enough details right now to carry out the rebase. I think likewise you might
need a moment to understand the new osmo-msc code. So I guess we should discuss
what should happen in prose and I hopefully can help you translate into code.
But right now I'm reluctant to get distracted at all, so now I actually start
my neels/ho branch with a revert of the osmo-msc 'Allow different channel types
to be requested as silent calls' patch -- the intention is not to undo your
work, but instead to not lose my focus on inter-MSC handover until we can
figure it out.
I realize I should have raised these issues on gerrit before merging, but for
obvious reasons I'm also currently avoiding hours of gerrit review that I would
normally do...
Sorry about that; let's see how we can resolve.
I suspect there is a more trivial solution than deferring; after all, getting
into the COMMUNICATING state should happen by event dispatch and should be
possible any number of times, in particular fired whenever a valid transaction
gets started (on neels/ho by sending the event MSC_A_EV_TRANSACTION_ACCEPTED to
msc_a). There is no onenter action, so I'm quite sure the COMMUNICATING state
is not a reason to defer anything. If entering COMMUNICATING more than once
triggers bugs, then we should guard that events get triggered only on first
entering the COMMUNICATING state -- but I don't see anything being triggered at
all anyway. The sole purpose of the COMMUNICATING state is to remove the FSM
timeout.
On the neels/ho branch, you will now find MSC_A_ST_COMMUNICATING in msc_a.c,
not in ran_conn.c.
~N