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@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@gnumonks.org

http://laforge.gnumonks.org/

============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi all,

jolly has gone through the effort to rebase all his changes on top of current master. How do we proceed from here?

My understanding was so far that Ivan is maintaining the PCU and repsonsible for reviewing/merging any suggested changes.

The current 'jolly_merge' branch seems to work quite fine, especially now with the fixes of the last two days. I would appreciate if we could get that merged, _before_ any other changes happen in master and again cause fragmentation.

Alternatively, we could of course see if Jolly should be permitted to generally push directly to master, or if all patches should be sent via 'git send-email' to this list, or if Jolly (or even I, but I know the code not well and have too many other projects) should become a co-maintainer of the project.

Let's work together to find a solution for the responsibilities and workflow. Thanks!