On Friday, February 4, 2011, Thomas Gstädtner <[email protected]> wrote: > On Fri, Feb 4, 2011 at 16:17, Vincent Torri <[email protected]> wrote: >> On Fri, 4 Feb 2011, Mike Blumenkrantz wrote: >> >>> On Fri, 4 Feb 2011 15:58:13 +0100 >>> Leif Middelschulte <[email protected]> wrote: >>> >>>> 2011/2/4 Vincent Torri <[email protected]>: >>>>> >>>>> >>>>> On Fri, 4 Feb 2011, Mike Blumenkrantz wrote: >>>>> >>>>>> On Fri, 4 Feb 2011 14:31:12 +0100 >>>>>> Cedric BAIL <[email protected]> wrote: >>>>>> >>>>>>> On Fri, Feb 4, 2011 at 2:25 PM, Raphael Kubo da Costa >>>>>>> <[email protected]> wrote: >>>>>>>> Rui Miguel Silva Seabra <[email protected]> writes: >>>>>>>>> Em 04-02-2011 11:34, Leif Middelschulte escreveu: >>>>>>>>>> Hey guys, >>>>>>>>>> >>>>>>>>>> a couple of days ago I proposed a tag within commit message, which >>>>>>>>>> can >>>>>>>>>> be used later on to generate the changelog (over interval or check >>>>>>>>>> per >>>>>>>>>> commit). >>>>>>>>>> >>>>>>>>>> e.g.: >>>>>>>>>> CHANGELOG: added foo to bar >>>>>>>>> >>>>>>>>> This seems pretty reasonable! >>>>>>>> >>>>>>>> Do people not write the appropriate ChangeLog entries with their >>>>>>>> commits >>>>>>>> because they are too lazy or because they just forget to do so? >>>>>>>> >>>>>>>> If they are too lazy, the CHANGELOG: thing might help; OTOH, if they >>>>>>>> just forget to do that, why would they remember to add the CHANGELOG: >>>>>>>> tag? >>>>>>> >>>>>>> Agreed, I tend to forget, not a lazyness issue. At least for me. >>>>>> +1 forgetting >>>> They wouldn't forget, as one could provide a commit template (if there >>>> is such thing) for efl that includes a line like >>>> CHANGELOG: >>>> That line can be lefally commented out in cases where it just isn't >>>> necessary. So forgetting to modify that line alltogether (whether >>>> comment out, nor give a changelog summary) would be as bad as >>>> forgetting to give a description/summary for the entire commit. Plus >>>> it would be compatible to all git/svn/whatever people use and >>>> changelog items would be automatically removed when the commit is >>>> reverted. As of now, changelog commits are sometimes forgotten and get >>>> seperated by using an extra commit for the textfile. >>>> >>>>> even if i said a lot of stuff about ChangeLog, my mail was not only for >>>>> that. For me, it's about better code committed. That's exactly what raster >>>>> does with most of the patches by samsung, btw. He looks at them and commit >>>>> them with changes, fixes, improvements, etc... >>>> >>>> I don't want to object to what vincent says. I'll leave this topic to >>>> developers with more experience in concurrent development of a new >>>> version and maintaining of an old one. >>>> >>>> BR, >>>> >>>> Leif >>>> >>>>> Vincent >>> mmm I've only been here a short time but I'm not sure we have the manpower >>> to >>> do what samsung does. We have very few active developers and even fewer who >>> would actively review/commit patches. As it is now, the vast majority of >>> patches that get sent to the list get reviewed+committed by either raster, >>> devilhorns, or me. Increasing the workload for us just to avoid people >>> forgetting changelog updates isn't a fix for the problem imo, it's a >>> workaround. >> >> well, again (maybe you forgot), i talked only about the core EFL. Are >> there so manWhat about using Leif's suggestion to include a CHANGELOG: line, > together with a pre-commit hook that checks if that line exists when > you commit into one of the release branches? > This way you make sure nobody forgets, because there's a warning > (yes/no dialog, whatever) if one does forget, and also you have very > little work to do which makes people not hate it so much :) > Also, while making clear that a Changlog entry is wanted, it does not > force one to do it if the change is minor (e.g. "remove trailing > whitespace"...). > To repeat myself: This hook should probably not apply on trunk where > it actually would annoy people needlessly.
That sounds definitivly like the right tool to help my brain ! I am all for it, how do we setup this ? -- Cedric BAIL ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
