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 many patches for them, now ? I don't talk about elm, or e, or > other libs. Waht you reviewed is mainly ecore mainloop stuff. > > Vincent
What 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. thomasg ------------------------------------------------------------------------------ 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
