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