On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann <d.willm...@samsung.com> wrote: > On 13/02/13 00:36, Bruno Dilly wrote: >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willm...@samsung.com> >> wrote: >>> >>> Topic branches: >>> * In each repository every developer with commit access will be able to >>> push/update branches in their own namespace (devs/<name>/*). These >>> branches will allow non-fastforward updates and no one should expect >>> these to be stable. >>> * This is a testing ground for developers where new features can be >>> developed, debugged and shared with fellow developers. Ideally any new >>> feature would live in its own branch until it matures and is merged >>> into master. >> >> Hey Daniel, >> >> It's a nice proposal, but what about master branch permissions ? >> Every developer would be allowed to push stuff on there (with a flow >> similar to svn) ? Or we'll try to establish some kind of policy about >> it (maintainers, review, etc) ? > > As others have already pointed out there seems to be consensus that we > don't have enough manpower to work with an integrator workflow (whether > or not that's true I don't know).
ok, I got it. > > What I want to achieve with the topic branches is that whoever wants to > can maintain an integrator-like workflow. You develop your feature in a > topic branch, then post a request for review/review and test yourself > and if everything looks good you can merge into master. > > Speaking of merging...is there any preference on merge vs. rebase? > > Lots of small merges can really pollute your history and I don't really > like them. For larger topic branches I think merging makes sense. I agree with Tom here. I'm always trying to keep a linear history, focusing on rebases instead of merges. We've used this approach on Profusion projects for years and it worked fine so far. Maybe it will give you a little bit more work, you'll have to fix conflicts in the commits it happens instead of only once in a final merge commit, but it will be nicer to review or look for issues later, imo. Using the merge approach, in a project with so many commiters could lead us to a very confuse history. > > > Regards, > Daniel > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Lead Developer ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
