On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onef...@gmail.com> wrote: > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly <bdi...@profusion.mobi> > 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. >> >> Using the merge approach, in a project with so many commiters could >> lead us to a very confuse history. > > If the history is confused, then that's what it should show. I really > don't like the idea of rewriting history just to make it easier for
ahn?? nobody is talking about rewriting the history of the public repository > some people. Sometimes you just need to track down what actually > happened, not the convenient lie we tell ourselves is what happened. > > Those who don't know history are destined to repeat it. B-) /me confused and so seems you are. Lucas De Marchi ------------------------------------------------------------------------------ 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
