On Thu, Feb 20, 2014 at 8:32 PM, Tom Hacohen <tom.haco...@samsung.com> wrote: > On 20/02/14 11:23, Cedric BAIL wrote: >> On Thu, Feb 20, 2014 at 8:09 PM, Tom Hacohen <tom.haco...@samsung.com> wrote: >>> On 20/02/14 10:57, Stefan Schmidt wrote: >>>> Hello. >>>> >>>> On Thu, 2014-02-20 at 19:41, Cedric BAIL wrote: >>>>> >>>>> I agree with you here, the short summary could really get better with >>>>> some policy. Maybe we could agree on a format and make sure that git >>>>> wont accept a commit that doesn't follow those rules ? >>>> >>>> I would like to avoid such dragonic measures if possible. Especially >>>> here you could force the format but not enforce a good message. e.g. >>>> >>>> efl: Fix calculation @fix @backport >>>> >>>> Something like this would pass a fictive server hook to enforce it but >>>> would still be useless. >>>> >>>> It would be way better if people would try hard to improve their >>>> commits in this area and make a bit more social pressure like letting >>>> TAsn loose again to rant about commit messages. :) >>> >>> I'm always loose, just a bit distracted recently. :P >>> >>> Btw, @backport is implied by @fix. I.e only commits that should be >>> backported are marked as @fix. The rest should not, as it's not of >>> interest to the news file or anything, and is just "development". >>> >>> I'm with stefan though, I'm against using tech measures to solve this >>> social issue. >>> >>> The way I see it, there are 2 ways to go at it: >>> 1. Bad cop: Warn repeating offenders, and remove commit access if they >>> fail to improve. Commit messages are an important part of sw dev. If >>> people can't do that, we can't trust them with commit access. >>> 2. Good cop: You get a free pass to ignore commits that do not pass your >>> quality control when preparing the news/release info and etc. >>> Essentially making it so offenders to get credit for their fixes/features. >>> >>> I prefer the second option, but the first 1 is also valid. >> >> Automated even with a light check (enforcing length and a format that >> at least specify on what they are working) is enough to make people >> think about what they are writing. Having a human harass people to get >> it right, is just going to direct the frustration to a real human >> instead of against a stupid machine that wont mind. >> > > Yeah, but my frustration will be tunnelled back towards the offenders. > While a machine forgives and forgets, I hold grudges and will hunt them > forever. ;P
If you feel better after that, you can still do it after the machine. It's not exclusive :-) > Seriously though, a machine can only do as much. I think it's bound to > frustrate the non-offenders more than the offenders with glitches and etc. > > Also, not all commits need a proper commit message. > > "Updated TODO". release: update TODO > "Updated .gitignore" release: update .gitignore > And a lot of other cases, do not warrant a verbose commit message. No need to be really verbose, I would just enfoce something of the format (w+): .* with 80 characteres max (maybe less). -- Cedric BAIL ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
