Re: [E-devel] commits policy

[Vincent T. <vt...@un...>]

On Fri, 4 Feb 2011, Mike Blumenkrantz wrote:

> On Fri, 4 Feb 2011 16:17:48 +0100 (CET)
> Vincent Torri <vt...@un...> wrote:
>
>>
>>
>> On Fri, 4 Feb 2011, Mike Blumenkrantz wrote:
>>
>>> On Fri, 4 Feb 2011 15:58:13 +0100
>>> Leif Middelschulte <lei...@gm...> wrote:
>>>
>>>> 2011/2/4 Vincent Torri <vt...@un...>:
>>>>>
>>>>>
>>>>> On Fri, 4 Feb 2011, Mike Blumenkrantz wrote:
>>>>>
>>>>>> On Fri, 4 Feb 2011 14:31:12 +0100
>>>>>> Cedric BAIL <ced...@fr...> wrote:
>>>>>>
>>>>>>> On Fri, Feb 4, 2011 at 2:25 PM, Raphael Kubo da Costa
>>>>>>> <ku...@pr...> wrote:
>>>>>>>> Rui Miguel Silva Seabra <rm...@14...> 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

>
> My point is just that unlike other developer groups, we have a very very small
> number of people (and an even smaller number of ACTIVE people). Many of these
> people specialize in specific areas of EFL: there are maybe 5 people with
> commit access who can actually say that they know every part of the codebase
> and can seriously manage to review feature adds, and forcing them to do so
> reduces the time that they're able to work on other things.
>
> I don't think it's the best option, but we're a community so I'll go with
> whatever the majority (aka raster) decides.
> -- 
> Mike Blumenkrantz
> Zentific: NULL pointer dereferences now 50% off!
>
>