openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <mik...@apache.org>
Subject Re: Names of patches for jira issues
Date Sat, 11 Aug 2007 18:36:11 GMT
Adding the patch in SVN would only be possible for committers, so that would
exclude a large number of people who are submitting patches (I'm thinking of
contributors here).

Personally I'd rather not clutter up SVN with more files, especially ones
that we know we're going to delete anyway (or at least we're likely to
delete). But that's just MHO.

I think the naming conventions we have in place are fine. OPENJPA-xxx.patchor
openjpa-xxx.txt should suffice for most problems. If we end up with multiple
patches for the same issue adding a number is helpful to know which one is
the most recent.

Lets not make it any more complicated than we have to. All we really need is
a indicator as to which JIRA issue the patch is intended for, and a standard
suffix.

As an aside, I vaguely remember there being an issue with the .patch suffix
at some point. I believe the patch was being emailed around and was rejected
by a spam / virus filter. Not a big deal, but something to be aware of.

-Mike

On 8/11/07, Pinaki Poddar <ppoddar@bea.com> wrote:
>
> Hi Craig,
>   Just a thought: is it possible to add the patch itself in SVN? Then we
> do not even require a version bit in naming.
>    Also what does other Apache projects do to manage patches?
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Sent: Saturday, August 11, 2007 12:39 PM
> To: dev@openjpa.apache.org
> Subject: Re: Names of patches for jira issues
>
> Hi Pikaki,
>
> The reason I suggested using the same name is to reduce confusion when a
> patch is intended to replace a previous version. Then it makes sense to
> reuse the same name.
>
> Craig
>
> On Aug 11, 2007, at 9:33 AM, Pinaki Poddar wrote:
>
> > Hi Craig,
> > My suggestion was to add a serial version number to the patch,
> > irrespective of authorship.
> >
> > 1. Author A submits first patch: OPENJPA-123.1.patch 2. Author A
> > updates the patch  : OPENJPA-123.2.patch 3. Author B comes up with an
> > alternative patch: OPENJPA-123.3.patch
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> > Sent: Saturday, August 11, 2007 11:29 AM
> > To: dev@openjpa.apache.org
> > Subject: Re: Names of patches for jira issues
> >
> > Hi Pinaki,
> >
> > On Aug 10, 2007, at 5:47 PM, Pinaki Poddar wrote:
> >
> >> +1
> >>
> >> A small addition to Craig's proposed convention:
> >> ppenjpa-xxx.z.patch or openjpa-xxx.z.txt where xxx is the JIRA issue
> >> number and z is the patch number as often there are multiple versions
>
> >> of the patch on the same issue.
> >
> > I like this idea. Elaborating, if the patch is updated by the author,
> > the same name should be used, e.g. openjpa-158.patch is the first
> > patch.
> > If the patch is updated, openjpa-158.patch replaces the original. Jira
>
> > knows to make available for download only the latest version of a
> > patch with the same name.
> >
> > If another patch is added, to cover some additional cases,if the
> > original patch is committed, or if someone else has a different view
> > of the fix, then openjpa-158.2.patch, openjpa-158.3.patch, and
> > openjpa-158.4.patch could be used.
> >
> > Is that what you had in mind?
> >
> > Craig
> >>
> >>
> >> Pinaki Poddar
> >> 972.834.2865
> >>
> >> -----Original Message-----
> >> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> >> Sent: Friday, August 10, 2007 7:07 PM
> >> To: dev@openjpa.apache.org
> >> Subject: Names of patches for jira issues
> >>
> >> I'd like to propose an informal convention for jira patch
> >> attachments.
> >>
> >> 1. Use the name of the jira in the patch file name, and use either a
> >> .txt or .patch suffix.
> >>
> >> 2. Do the svn diff >openjpa-249.patch from trunk.
> >>
> >> These small things make it easier when downloading the patch to know
> >> where it applies and you don't have to rename the patch to remember
> >> which issue it applies to.
> >>
> >> Obviously, no one will complain about details like this when getting
> >> patches "free as in work" but it might make it a bit easier to verify
>
> >> them.
> >>
> >> What do you all think?
> >>
> >> Craig
> >>
> >> Craig Russell
> >> Architect, Sun Java Enterprise System http://java.sun.com/products/
> >> jdo
> >> 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
> >>
> >>
> >> Notice:  This email message, together with any attachments, may
> >> contain information  of  BEA Systems,  Inc.,  its subsidiaries and
> >> affiliated entities,  that may be confidential,  proprietary,
> >> copyrighted  and/or legally privileged, and is intended solely for
> >> the
> >
> >> use of the individual or entity named in this message. If you are not
>
> >> the intended recipient, and have received this message in error,
> >> please immediately return this by email and then delete it.
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
> >
> >
> > Notice:  This email message, together with any attachments, may
> > contain information  of  BEA Systems,  Inc.,  its subsidiaries
> > and  affiliated entities,  that may be confidential,  proprietary,
> > copyrighted  and/or legally privileged, and is intended solely for the
>
> > use of the individual or entity named in this message. If you are not
> > the intended recipient, and have received this message in error,
> > please immediately return this by email and then delete it.
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
>
>
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message