Adrian, Too true, I suspect if David was paid standard rate for all the time he's spent explaining what's wrong with patches he'd probably have retired by now!
Being thick skinned is all part of working with a disparate group of people on a very generic project. So perhaps a rejection policy also helps people to understand the type of mindset required for success! - Andrew On Tue, 2007-01-16 at 07:56 -0800, Adrian Crum wrote: > 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > >>> > >>> 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" <[EMAIL PROTECTED]> > >>>>> > >>>>> 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 <[EMAIL PROTECTED]> > >>>>> > >>>>> 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 === > >> > > -- Kind Regards Andrew Sykes <[EMAIL PROTECTED]> Sykes Development Ltd http://www.sykesdevelopment.com
