On Thu, Feb 14, 2013 at 08:53:22AM -0200, Bruno Dilly wrote: > 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.
It's usually less work for me, because it's easier for me to reapply patches I had in my own branch and check if they still do what they did before rebase correctly, then to resolve one big merge conflict where you can get 5 different people touching the same code as what you had in branch and you have to be sure that your resolution does not only keep your change correct, but also does not break those 5 different changes. > Using the merge approach, in a project with so many commiters could > lead us to a very confuse history. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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
