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/osmocom-net-gprs@lists.osmocom.org/.
Alexander Chemeris alexander.chemeris at gmail.comI completely agree. That was the reason I proposed Ivan and Andreas agree on a path to merge existing work and coordinate better in future. I think that current code is not _that_ hard to merge, but it can't continue like this for a long time. On Wed, Jul 11, 2012 at 3:23 AM, Harald Welte <laforge at gnumonks.org> wrote: > Hi all! > > while reviewing the current PCU code in the git repository, it occurred > to me that somehow the jolly_new branch doesn't seem to be based on > master, and the only common ancestor is > 9b06ff0c4c49f1927b9029d38e16670a7b7301fb from June 15. > > In fact, Ivan seems to have made a number of changes concurrently with > Andreas, but not basing on each other's code. It's really a big mess, > from what I can tell. > > I'm referring to the followign commit's by Ivan: > a9e6dc5084627e7c279ba08de7a7809e97ebc539 > d78ee736239414021fde8010179f42b86464a238 > > Which are completely unrelated to the work that Andreas has been doing > at the same time (all his commit's from 2012-06-27 on, i.e. > 39621c41f303e24b7324dc4c91447a449d2a654b and later. > > I strongly recomend that you coordinate more and re-view each others' > code better. > > And regarding the messy situatin with master vs. jolly_new: I think the > only practical solution is to drop one of the two parallel and > incompatible changes regarding the RLC/MAC and TBF establishment > changes. > > Do you have any input on how to resolve this specific issue? I think > none of us can afford to waste resources on duplication of work and > creating virtually un-mergeable branches :/ > > 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) > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru