From bogus@does.not.exist.com  Sun Jan  9 16:47:06 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:47:06 -0000
Subject: No subject
Message-ID: <mailman.0.1641746834.43024.osmocom-net-gprs@lists.osmocom.org>

bug fixes. Ideally I'd love to see Andreas developing them on top of
the current 'master' and submitting them to the mailing list as soon
as he push them. This way Ivan (and everyone else) would be able to
review them and merge as soon as possible. I hate the situation when
fixes are stored in a private branch and are not merged into mainline.

On Mon, Nov 26, 2012 at 5:02 PM, Ivan Kluchnikov
<Ivan.Kluchnikov at fairwaves.ru> wrote:
> Hi, all!
>
> I absolutely agree with Harald and I am ready to use described life-cycle
> model for osmo-pcu.
> Before that time I merged  branch 'jolly', when the differences between
> master and jolly become critical.
> I didn't coordinate merges with Andreas and jolly branch wasn't rebased
> before merges. I think, it was my mistake.
> Now I am ready to merge jolly branch at any time, when Andreas indicates
> that his branch is ready for merge.
>
>
> 2012/11/25 Harald Welte <laforge at gnumonks.org>
>>
>> Dear all,
>>
>> it is a pity to see that since many weeks there has been no progress on
>> merging any of Andreas' work.  I think everyone involved is to be
>> blamed to some extent.  Andreas because the provided branches are not
>> kept clean, Ivan probably for lack of time, and me for not paying more
>> attention and helping this process along.
>>
>> The general life-cycle in any project, including osmo-pcu, should be as
>> follows:
>>
>> * contributor starts on some improvements, creates private branch
>> * master advances meanwhile
>> * contributor rebases (not merges!) his changes on top of more recent
>>   master
>> * contributor indicates that his branch is ready for merge
>> * maintainer merges (some of?) the commits of the contributor branch
>> * contributor re-bases remaining commits on new master
>> * contributor requests merge of remaing patches
>> ...
>>
>> If I open 'gitk' on any of the branches (master / jolly / jolly_dsp) I
>> get grey hair (to say the least).  One would normally expect:
>>
>> 1) 'jolly' to be based on some (maybe not current) master
>>
>> 2) 'jolly_dsp' to be based on 'jolly'
>>
>> Neither of the two is the case.  I've tried to
>> * rebase jolly on top of master
>> as well as
>> * rebase jolly_dsp on top of jolly
>>
>> and both are impossible due to the series of merges and the unclear
>> ancestry / relationship of the branches.  Or, just for fun, try 'git
>> diff origin/jolly..origin/jolly_dsp.  It shows you anything else but
>> what one would expect
>>
>> Andreas: Please take some time to clean up the mess.  Your 'jolly'
>> branch should contain a series of clean per-feature commit's on top of
>> current master, and 'jolly_dsp' should be a set of few patches on top of
>> 'jolly'.
>>
>> This way there is always a clean queue of changesets that Ivan can merge
>> (or cherry-pick).  I can understand that if I was in Ivan's place, I
>> would not really know where to even start merging some of those
>> contributions.
>>
>> Thanks for everyone's attention.  Please take some time to get this
>> resolved.  Let me know if you have some questions.  There are plenty of
>> people with lots of git experience around (Holger, Pablo, myself) who
>> can help if something is unclear.
>>
>> Regards,
>>         Harald
>>
>> --
>> - Harald Welte <laforge at gnumonks.org>
>> http://laforge.gnumonks.org/
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>> "Privacy in residential applications is a desirable marketing option."
>>                                                   (ETSI EN 300 175-7 Ch.
>> A6)
>>
>
>
>
> --
> Regards,
> Ivan Kluchnikov.
> http://fairwaves.ru
>



--=20
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=
=B8=D0=BE
http://fairwaves.ru



From bogus@does.not.exist.com  Sun Jan  9 16:47:06 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:47:06 -0000
Subject: No subject
Message-ID: <mailman.1.1641746834.43024.osmocom-net-gprs@lists.osmocom.org>

if we should use more C++ features (I am not talking STL, operator
overloading)?

Any opinions?

	holger

PS: I think we should find a more nice solution to extern "C".. I
spent various minutes trying to figure out which parts of the pcu
have C linkage and which C++.. For things from libosmocore it is
obvious.. but then we have the vty_info...

-- 
- Holger Freyther <hfreyther at sysmocom.de>       http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte




From bogus@does.not.exist.com  Sun Jan  9 16:47:06 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:47:06 -0000
Subject: No subject
Message-ID: <mailman.2.1641746835.43024.osmocom-net-gprs@lists.osmocom.org>

* With multiple TBF assignment the tbf_by_tlli will return a list
  anyway.
* For the multiple RACH cases we could it probably handle it more
  nicely.


E.g. avoid this:
<0005> bts.cpp:1035 Got RACH from TLLI=0xcf7611f6 while TBF(TFI=0 TLLI=0xcf7611f6 DIR=DL) still exists. Killing pending DL TBF
<0002> bts.cpp:359 Got IMM.ASS confirm, but TLLI=cf7611f6 does not exit



-- 
- Holger Freyther <hfreyther at sysmocom.de>       http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte




From bogus@does.not.exist.com  Sun Jan  9 16:47:06 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:47:06 -0000
Subject: No subject
Message-ID: <mailman.3.1641746835.43024.osmocom-net-gprs@lists.osmocom.org>

<br>
* With multiple TBF assignment the tbf_by_tlli will return a list<br>
=A0 anyway.<br>
* For the multiple RACH cases we could it probably handle it more<br>
=A0 nicely.<br>
<br>
<br>
E.g. avoid this:<br>
&lt;0005&gt; bts.cpp:1035 Got RACH from TLLI=3D0xcf7611f6 while TBF(TFI=3D0=
 TLLI=3D0xcf7611f6 DIR=3DDL) still exists. Killing pending DL TBF<br>
&lt;0002&gt; bts.cpp:359 Got IMM.ASS confirm, but TLLI=3Dcf7611f6 does not =
exit<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
--<br>
- Holger Freyther &lt;<a href=3D"mailto:hfreyther at sysmocom.de">hfreyther at sy=
smocom.de</a>&gt; =A0 =A0 =A0 <a href=3D"http://www.sysmocom.de/" target=3D=
"_blank">http://www.sysmocom.de/</a><br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
* sysmocom - systems for mobile communications GmbH<br>
* Schivelbeiner Str. 5<br>
* 10439 Berlin, Germany<br>
* Sitz / Registered office: Berlin, HRB 134158 B<br>
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte<br>
<br>
</font></span></blockquote></div><br></div>

--20cf301d42625eb38c04ea05cbef--



From bogus@does.not.exist.com  Sun Jan  9 16:47:06 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:47:06 -0000
Subject: No subject
Message-ID: <mailman.4.1641746835.43024.osmocom-net-gprs@lists.osmocom.org>

RLC/MAC layer in real networks is always used in acknowledged/reliable
mode, and LLC is always only used in unreliable (UI) mode.  The reason
for this is that TCP cannot deal with the enormous packet loss that GPRS
or similar radio links pose.  If TCP would be exposed to the real packet
loss, it would stall way too much.

So my rationale was to use the same while creating osmo-sgsn.  We use
LLC in UI mode.

Or are we talking about something completely else?

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)