On Fri, 4 Feb 2011, Mike Blumenkrantz wrote:
> On Fri, 4 Feb 2011 16:37:59 +0100 (CET) > Vincent Torri <[email protected]> wrote: > >> >> >> On Fri, 4 Feb 2011, Mike Blumenkrantz wrote: >> >>> On Fri, 4 Feb 2011 16:17:48 +0100 (CET) >>> 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 >>> You have to keep in mind that we were in a code freeze for the past several >>> months, so feature patches could not be submitted/committed. With what you >>> are suggesting, the 5000 commits that TAsn just made would have had to pass >>> review before being committed. How many people here really know textblock >>> code as well as he does? Out of them, who has the time to do an adequate >>> review? >> >> from one of my answers: >> >> "Using that kind of policy on some specific libraries (Evas, Ecore and >> Edje as they are maybe the most important ones) could be good for code >> solidity. >> But for example, maybe we can let Tom doing his text job on evas and edje >> without such review." >> >> so read what i write. >> >> Vincent > Right, but then you're saying that certain people/libs get special privileges? > I was trying to point out that things like that can happen more than once. If > I make 30 commits to eeze with feature adds, do you really want to be > reviewing > udev/libmount code? Of course not. So then eeze is an exception. How about > cedric and eet internals? You and evil? > If you keep handing out special case exceptions, pretty soon there won't be > much code left without them. Then we're back to the same problem of people who > are forgetful continuing to be forgetful, but we also have an arbitrary review > process which makes no sense and serves no purpose. 1) for me it's strange that nobody want to do things seriously. 2) Better having a bit of seriousness than nothing. You prefer committing like a madman and breaking stuff (like *you* did with ecore main loop, ecore_con) than letting people look first at what you did ? Good. That's not the way I want to work. Vincent ------------------------------------------------------------------------------ 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
