On Fri, 4 Feb 2011 17:50:24 +0100 (CET) Vincent Torri <[email protected]> wrote:
> > > 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 r56706-56707. Everyone breaks things, it's a fact of life. We can either deal with it and move forward with the code or we can keep arguing pointlessly here on the mailing list. I'm done with the latter, feel free to continue at your own pace. -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! ------------------------------------------------------------------------------ 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
