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 > entry > >> of each set, and > >>>>> see if the 2nd entry is > >>>>> highlighted similarly. Meaning, if it is > >> highlighted similarly, > >>>>> the set of changes is bogus > >>>>> (formatting only). > >>>>> > >>>>> In general, we should submit patches that are > >>>>> intentional, ie just the intended changes > only. > >> We should not > >>>>> submit patches that contain unintended > >>>>> changes that have extra unintended footprints. > >>>>> > >>>>> Jonathon > >>>>> > >>>>> David E. Jones wrote: > >>>>>> Moving this back to the mailing list... > >>>>>> > >>>>>> > >>>>>> On Jan 15, 2007, at 5:34 PM, Adrian Crum > wrote: > >>>>>> > >>>>>>> David E. Jones wrote: > >>>>>>>> When reviewing a patch lines with > formatting > >>>>> changes only are > >>>>>>>> EXTREMELY time consuming, and the patch > >>>>> attached that issue is a > >>>>>>>> good example of a painful one. For each of > >>>>> those line you have to > >>>>>>>> stare at it looking at every character > trying > >>>>> to figure out what the > >>>>>>>> point of the bloody change was, or to make > >> sure > >>>>> that the change is > >>>>>>>> "invisible"... > >>>>>>> That really puzzles me. You keep mentioning > >>>>> formatting changes when I > >>>>>>> don't see any. I didn't make any formatting > >>>>> changes when modifying the > === message truncated ===
