ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adri...@hlmksw.com>
Subject Re: OFBiz UI work
Date Tue, 16 Jan 2007 15:56:11 GMT
Wow. This subject sure took off from my original dilemma.

Actually, there's an element of truth to what Chris said. At first glance the 
policy seems mean-spirited. But as was mentioned in another reply, it's a good 
way to train the submitters.

Personally, I have a pretty thick skin, so what David proposed doesn't offend me 
or discourage me. Instead, it motivates me to take a closer look at what my IDE 
and SVN client are doing to cause these unintentional formatting changes.

I truly appreciate the time David took to address my problem. Without his 
detailed description of the problems with my patches, I wouldn't know what was 
wrong with them.


David E. Jones wrote:
> 
> I'm not sure what to say, perhaps what I originally said would be  helpful:
> 
> "People tend to slip things into patches accidentally all the time.  I'm 
> tempted to begun the voting process for a new policy that says  that if 
> there is anything in the patch file not described in the  summary of the 
> patch, then it will be rejected..."
> 
> -David
> 
> 
> On Jan 15, 2007, at 10:44 PM, Chris Howe wrote:
> 
>> Sorry, I don't know why that quote didn't hit me right
>> the first time.  My apologies to W.C. Fields. “Go
>> away, kid, you bother me”. I really butchered it. I
>> mean _really :-)
>>
>> So, if that's not the policy and procedure you're
>> looking to adopt, please elaborate on what you're
>> tempted to propose.
>>
>>
>> --- "David E. Jones" <jonesde@hotwaxmedia.com> wrote:
>>
>>>
>>> You have quite an imagination.
>>>
>>> -David
>>>
>>>
>>> On Jan 15, 2007, at 10:01 PM, Chris Howe wrote:
>>>
>>>> Being tempted to ask for a vote, insinuates that
>>>
>>> you
>>>
>>>> want to condone a practice whereby if you go to
>>>
>>> review
>>>
>>>> a patch like in Adrian's case and it has
>>>
>>> superflous
>>>
>>>> formatting changes, that you would delete it from
>>>
>>> JIRA
>>>
>>>> in a "sorry kid, you're wasting my time" dismissal
>>>> (email impressions added for levity).  Anything
>>>
>>> less
>>>
>>>> is what is currently going on and wouldn't need a
>>>> vote.  People aren't tempted to vote on the status
>>>> quo.
>>>>
>>>> --- "David E. Jones" <jonesde@hotwaxmedia.com>
>>>
>>> wrote:
>>>
>>>>
>>>>>
>>>>> Ummm... what do you think when you think of a
>>>>> rejection policy? We
>>>>> already have patch rejection policies when
>>>
>>> problems
>>>
>>>>> are found...
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jan 15, 2007, at 9:44 PM, Chris Howe wrote:
>>>>>
>>>>>> I agree.  I think it's better that we strongly
>>>>>> encourage certain practices (as we are doing
>>>
>>> now)
>>>
>>>>> and
>>>>>
>>>>>> bring people to notice when those practices
>>>
>>> could
>>>
>>>>> be
>>>>>
>>>>>> improved, but rejection policies put your _means
>>>>>> perspective ahead of your _ends.  Contributions
>>>>>
>>>>> may be
>>>>>
>>>>>> easier to review, but I can gaurantee you with
>>>>>> rejection policies, you will then have less of
>>>
>>> it
>>>
>>>>> to
>>>>>
>>>>>> review and thereby less solutions making it back
>>>>>
>>>>> into
>>>>>
>>>>>> the project.
>>>>>>
>>>>>> --- "David E. Jones" <jonesde@hotwaxmedia.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Yes, we want more people, but I don't think
>>>>>
>>>>> anyone
>>>>>
>>>>>>> wants
>>>>>>> indiscriminate changes going into SVN! I hate
>>>>>>> surprises when I check
>>>>>>> out as much as the next guy, probably more than
>>>>>
>>>>> the
>>>>>
>>>>>>> next guy in many
>>>>>>> cases.
>>>>>>>
>>>>>>> Thinking about the next guy is the real key
>>>
>>> here.
>>>
>>>>>>> You may want to get
>>>>>>> your patches in ASAP, but if your patch breaks
>>>>>>> existing code (for
>>>>>>> example), then that needs to be fixed before
>>>
>>> the
>>>
>>>>>>> commit is done
>>>>>>> (either by the committer, the contributor, or
>>>
>>> an
>>>
>>>>>>> interested third
>>>>>>> party).
>>>>>>>
>>>>>>> So, yeah, that slows things down and is
>>>>>>> inconvenient, but keep in
>>>>>>> mind that a large portion of patches that come
>>>>>
>>>>> into
>>>>>
>>>>>>> OFBiz break
>>>>>>> existing functionality. This seems to happen
>>>>>
>>>>> around
>>>>>
>>>>>>> once a week or
>>>>>>> so, at least.
>>>>>>>
>>>>>>> It's great that people want to contribute, but
>>>
>>> in
>>>
>>>>> or
>>>>>
>>>>>>> to contribute to
>>>>>>> something as large and complex as OFBiz a large
>>>>>>> amount of effort is
>>>>>>> necessary, and anyone that wants to help out
>>>
>>> will
>>>
>>>>>>> err on the side of
>>>>>>> extra effort, caution and review, and
>>>>>
>>>>> consideration
>>>>>
>>>>>>> of more general
>>>>>>> requirements and designs rather just one's own
>>>>>>> requirements.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jan 15, 2007, at 7:42 PM, Jonathon --
>>>
>>> Improov
>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Heh. True. I definitely want MORE people
>>>>>
>>>>> involved
>>>>>
>>>>>>> in OFBiz.
>>>>>>>
>>>>>>>>
>>>>>>>> But since I'm not a committer, I'd rather make
>>>>>>>
>>>>>>> things easier for
>>>>>>>
>>>>>>>> the committers. I have no control over how
>>>
>>> easy
>>>
>>>>> or
>>>>>
>>>>>>> difficult it is
>>>>>>>
>>>>>>>> to handle patches with "extra unintended
>>>>>>>
>>>>>>> footprints".
>>>>>>>
>>>>>>>>
>>>>>>>> If I were a committer, I would try to
>>>>>>>
>>>>>>> automatically filter out
>>>>>>>
>>>>>>>> formatting changes in my audit, and then
>>>
>>> INCLUDE
>>>
>>>>>>> the formatting
>>>>>>>
>>>>>>>> changes. After all, there's no harm removing
>>>>>
>>>>> some
>>>>>
>>>>>>> extra spaces at
>>>>>>>
>>>>>>>> the end of lines, part of clean up.
>>>>>>>>
>>>>>>>> We often try to make things easier for the
>>>>>
>>>>> person
>>>>>
>>>>>>> who is doing a
>>>>>>>
>>>>>>>> task that we have no control over. Eg, I'd
>>>
>>> keep
>>>
>>>>> my
>>>>>
>>>>>>> mouth really
>>>>>>>
>>>>>>>> wide open for my dentist just so his vision is
>>>>>>>
>>>>>>> 20/20, no arguments
>>>>>>>
>>>>>>>> from me; I could afford to be slack about this
>>>>>>>
>>>>>>> "mouth wide-open
>>>>>>>
>>>>>>>> policy" if I were able to do the dentistry
>>>>>
>>>>> myself.
>>>>>
>>>>>>>>
>>>>>>>> But you're certainly right that it'll exclude
>>>>>
>>>>> some
>>>>>
>>>>>>> people,
>>>>>>>
>>>>>>>> especially folks who use editors that do not
>>>>>
>>>>> give
>>>>>
>>>>>>> very much control
>>>>>>>
>>>>>>>> to users.
>>>>>>>>
>>>>>>>> Jonathon
>>>>>>>>
>>>>>>>> Chris Howe wrote:
>>>>>>>>
>>>>>>>>> I don't know that rejection policies are very
>>>>>>>>> community friendly.  Treating SVN code
>>>
>>> changes
>>>
>>>>>>> like
>>>>>>>
>>>>>>>>> the keeper of the Bridge of Death (Monty
>>>
>>> Python
>>>
>>>>>>>>> Reference, smile) may find less people
>>>
>>> willing
>>>
>>>>> to
>>>>>
>>>>>>> do
>>>>>>>
>>>>>>>>> in this do-ocracy.  Many of us rather like
>>>>>
>>>>> what's
>>>>>
>>>>>>> left
>>>>>>>
>>>>>>>>> of our anarco-sydicalist commune (oh look,
>>>>>>>
>>>>>>> there's
>>>>>>>
>>>>>>>>> another :-) ).
>>>>>>>>> --- Jonathon -- Improov <jonw@improov.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>>>>>>> David,
>>>>>>>>>>
>>>>>>>>>> I agree with the rejection policy.
>>>>>>>>>>
>>>>>>>>>> One suggestion on procedure to take when
>>>>>>>>>> self-reviewing a patch before submitting it.
>>>>>>>
>>>>>>> Look at
>>>>>>>
>>>>>>>>>> the diff to see if there are changes we
>>>
>>> cannot
>>>
>>>>>>> account
>>>>>>>
>>>>>>>>>> for. Using KDiff also makes things easier,
>>>>>
>>>>> even
>>>>>
>>>>>>> when dealing with
>>>>>>>
>>>>>>>>>> formatting changes.
>>>>>>>>>>
>>>>>>>>>> In Emacs, it's also easy to go through every
>>>>>
>>>>> set
>>>>>
>>>>>>> of
>>>>>>>
>>>>>>>>>> changes, do an interactive-search for 1st
>>>
>>>
>> === message truncated ===
>>
> 

Mime
View raw message