On Wed, Oct 2, 2013 at 6:59 AM, Tom Hacohen <tom.haco...@samsung.com> wrote: > On 02/10/13 09:16, Michael Blumenkrantz wrote: >> Since I've been contacted by a number of people recently who are wanting to >> do work on E19, here's some general rules that I'd like people to follow to >> avoid conflicts: >> >> >> * Do NOT merge commits into my branch. Ever. If you have some patches that >> you'd like merged, send me a mail about it. All other branches should be >> rebased to my branch, which will eventually be merged to master after the >> E18 release. >> >> >> * Use correct prefixing in commit messages. This IS different from efl >> prefixing! In E19, we will be doing away with all news/changelog idiocy; >> the new system is based on the first word in a commit message and works >> like this: >> - "feature" - use this when adding a new feature >> - "bugfix" - use this when you are fixing a bug >> >> I may add other prefixes to this in time, but for now this is how it works. >> Patches not conforming to this system will not be merged, and no other form >> of prefixing is necessary. > > Awesome.
I look forward the day that we will do the same for EFL (wrt news/changelog). >> >> >> * I WILL be squashing and rewriting commits as much as possible in order to >> keep the overall patchset small; it's already approaching 50 patches, and I >> don't want this to be a commit tsunami. If you fix a bug in an existing E19 >> commit, do NOT prefix the commit with "bugfix". Instead, use "squash >> <commit hash>". I will merge this with the specified commit and add your >> attribution/signoffs to that commit. > > Less awesome. There are better way of doing things. But I guess that's > the first step. The problem with signoffs is that they are not proper > attributions. That is, tools that check for authors using git will not > spot them (among other things). > >> >> >> >> I realize that this is a hassle, but the E18 release cycle is turning out >> to be about twice as long as I expected, which has caused the E19 branch to >> grow much larger than I imagined. >> > > You could just branch out e18, and make master e19. I see no problem > with that. Alternatively, you could just work on your branch as if it > was master (without any hassles). > > -- > Tom. > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rafael Antognolli ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
