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/.
Ivan Kluchnikov Ivan.Kluchnikov at fairwaves.ruHi, 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/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121126/22ff9123/attachment.htm>