Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mprudhomapache@gmail.com
 designates 64.233.162.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=X6Wq9u69BX4wCmitTgBYxdNTp49sRsderdoASYQnpVNgnbpcUOMRwHELgJ//u9K4qJOL64VWiJCoHiAhWaFcg8qdu5MlSxKc8zi/fktYnMkI2q7aM0qagcvee9H+LtVkoDfeVOSh8B6XGZSg9lRBiQBlKEtDtQfZB86cxuOoBZ8=
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <e9ac83540608300856l5de62c3ftf0cdef4a8118eb40@mail.gmail.com>
References: <89c0c52c0608300707m4967d028y8e0fa5eb67ff4a4c@mail.gmail.com>
 <74467F1A-31F7-4E62-80C1-195D1BD213A4@apache.org>
 <89c0c52c0608300752ocd1ee71p7c22868bffd159bd@mail.gmail.com>
 <294A96D8-7D72-44B3-845C-CC6D66E224A2@apache.org>
 <21F7E81D-9F61-4954-9748-D36A97C8232C@apache.org>
 <89c0c52c0608300851m7562b931pccea45ffdac0852b@mail.gmail.com>
 <e9ac83540608300856l5de62c3ftf0cdef4a8118eb40@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <07746DB7-B4AC-48B9-ADCD-AD17E19ACEFE@apache.org>
Content-Transfer-Encoding: 7bit
From: Marc Prud'hommeaux <mprudhom@apache.org>
Subject: Re: Process for Patch verification
Date: Wed, 30 Aug 2006 10:09:54 -0700
To: open-jpa-dev@incubator.apache.org
Sender: Marc Prud'hommeaux <mprudhomapache@gmail.com>


On Aug 30, 2006, at 8:56 AM, Eddie O'Neil wrote:

> Kevin--
>
>  Wearing my mentor hat...
>
>  I say go for it -- if you're confident in your changes, it passes
> the tests, and does right by the project, this is how community is
> built.  Occasionally, we'll break a few eggs, but this is how everyone
> learns to work together.

I'm inclined to agree ... when patches wind up breaking our BEA- 
internal tests, then that will only further encourage us to migrate  
some more of those tests into the public OpenJPA code base in a  
timely matter.

In this particular case, I had said I would test the patch, and never  
got around to doing it, and then a conflicting change got committed  
to the file by someone else that invalidated the patch file, leading  
to wasted work. Sorry about that. We hope that my negligence and  
laziness will be the exception rather than the rule going forward :)


>  Patrick, Abe, and others can certainly (and likely will!) chime in
> and provide feedback on the patch or process for testing, but your
> role as a committer means that the community trusts you to commit
> code.
>
> Cheers,
> Eddie
>
>
>
> On 8/30/06, Kevin Sutter <kwsutter@gmail.com> wrote:
>> Bill,
>> Absolutely, I am a committer.  But, I am still learning the whole  
>> code
>> base.  It's quite large...  :-)  So, I was still looking for some BEA
>> assistance with verifying the patches before committing the  
>> changes.  But,
>> like this thread is indicating, maybe I just need to verify the  
>> patch to the
>> best of my ability and go for it.  Problems will get resolved one  
>> way or the
>> other...
>>
>> I'll wait for some feedback from other participants before going that
>> route...  :-)
>>
>> Kevin
>>
>> On 8/30/06, Bill Dudney <bdudney@apache.org> wrote:
>> >
>> > Just reading over the OpenJPA-15 thread and now I understand this
>> > thread much better.
>> >
>> > Kevin, aren't you a committer? If so why not take the patch and  
>> apply
>> > it, if it works for you and passes the current test suite then it
>> > should probably be committed.
>> >
>> > If you want a second opinion I'd be glad to try out the patch this
>> > afternoon.
>> >
>> > TTFN,
>> >
>> > -bd-
>> >
>> > On Aug 30, 2006, at 8:58 AM, Bill Dudney wrote:
>> >
>> > > Hi Kevin,
>> > >
>> > > Should have known BAU - ah well, can't keep all that in my  
>> head...
>> > >
>> > > I hope and expect that patches won't be left in JIRA  
>> unresolved or
>> > > unapplied for long periods of time. That would be a major bummer,
>> > > esp for the poor folk trying to help!
>> > >
>> > > Yes forcing the hand would be a good thing IMO :-)
>> > >
>> > > TTFN,
>> > >
>> > > -bd-
>> > >
>> > > On Aug 30, 2006, at 8:52 AM, Kevin Sutter wrote:
>> > >
>> > >> Bill,
>> > >> BAU == Business As Usual
>> > >>
>> > >> I guess verifying the patch against the existing set of tests
>> > >> would be one
>> > >> way to do it.  But, knowing that there are other internal tests
>> > >> that might
>> > >> be affected seemed a little harsh.  So, I was trying to be more
>> > >> diplomatic.
>> > >> I guess it would force the hand to deliver the "failing"
>> > >> tests...  :-)
>> > >>
>> > >> Kevin
>> > >>
>> > >> On 8/30/06, Bill Dudney <bdudney@apache.org> wrote:
>> > >>>
>> > >>> Hi Kevin,
>> > >>>
>> > >>> I like the idea of raising awareness of available patches but I
>> > >>> don't
>> > >>> think we want to hold someone up that is doing a bunch of  
>> work with
>> > >>> having to verify all patches that have been submitted and  
>> how the
>> > >>> patches might effect the new work.
>> > >>>
>> > >>> One way (I think) to address the concern is to have more  
>> than one of
>> > >>> us apply the patch, run the tests and verify that all tests  
>> pass.
>> > >>> Assuming all tests pass then the patch should be OK and we  
>> put a
>> > >>> comment into the JIRA to that effect. Only problem I can see  
>> is that
>> > >>> some of the internal BEA tests would fail but these tests  
>> are on
>> > >>> their way into the OpenJPA code base correct?
>> > >>>
>> > >>> BTW - BAU == ?
>> > >>>
>> > >>> TTFN,
>> > >>>
>> > >>> -bd-
>> > >>>
>> > >>> On Aug 30, 2006, at 8:07 AM, Kevin Sutter wrote:
>> > >>>
>> > >>> > Hi,
>> > >>> > I'm looking to start a conversation on how we can coordinate
>> > >>> timely
>> > >>> > verification of patch submissions.  As you have probably  
>> noticed,
>> > >>> > Catalina
>> > >>> > and I have been working on a patch for OPENJPA-15 (
>> > >>> > http://issues.apache.org/jira/browse/OPENJPA-15).   
>> Granted, we
>> > >>> have
>> > >>> > had a
>> > >>> > couple of miscues as we continue to learn the patching and
>> > >>> > contribution
>> > >>> > processes.  But, we have also had to regenerate the patch  
>> a few
>> > >>> times
>> > >>> > because of changes being integrated into the affected  
>> files before
>> > >>> > the patch
>> > >>> > could be verified.
>> > >>> >
>> > >>> > I'm wondering if this is BAU in the open-source community, or
>> > >>> is there
>> > >>> > something we can do to help this process?
>> > >>> >
>> > >>> > I know there was a discussion about having the ability to  
>> flag a
>> > >>> > JIRA report
>> > >>> > when a patch is attached.  I don't believe I've seen  
>> resolution of
>> > >>> > that
>> > >>> > request.  Flagging a JIRA report might help some, but it  
>> still
>> > >>> > doesn't help
>> > >>> > with a timely verification of the patch.  At least it would
>> > >>> raise the
>> > >>> > awareness that patches are available for verification.   
>> And, any
>> > >>> > new change
>> > >>> > activities should check for possible patches before  
>> hitting the
>> > >>> commit
>> > >>> > button.
>> > >>> >
>> > >>> > Since this OpenJPA community is still highly reliant on the
>> > >>> > original authors
>> > >>> > of the contribution, I guess this question is mostly  
>> directed at
>> > >>> > them.  Once
>> > >>> > more of us non-BEA committers become familiar enough with  
>> the code
>> > >>> > base, we
>> > >>> > can help with this verification process to help spread the  
>> wealth.
>> > >>> > But, in
>> > >>> > the mean time, it would seem that we need to figure out some
>> > >>> > process for
>> > >>> > verifying patches before the next set of changes gets  
>> committed
>> > >>> and
>> > >>> > makes
>> > >>> > the patch null-and-void.
>> > >>> >
>> > >>> > Thoughts?
>> > >>> >
>> > >>> > Kevin
>> > >>>
>> > >>>
>> > >
>> >
>> >
>>
>>