db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: Jira attachments - please don't delete
Date Thu, 16 Feb 2006 18:22:48 GMT
What I have been doing with my patches is to keep all the revisions in JIRA
but try to name such that (hopefully) it is easier for the reviewers to see
what is the latest patch. The naming convention I use has bug number, little
info about bug and date it was created. for eg


On 2/16/06, Satheesh Bandaram <satheesh@sourcery.org> wrote:
> Daniel John Debrunner wrote:
> I notice that some folks are deleting jira attachements when they attach
> a new version of a patch or functional/design spec. I personally think
> this should not be encouraged, it's sometimes helpful to have the
> history of the patch and especially helpful to have the history of a spec.
> Does anyone think it's a good idea to delete old attachements?
> Dan.
> I can see arguments either way... Last time I thought this was discussed,
> the consensus was to delete previous patch/spec if the new one completely
> replaces the old one. Here is the link to previous discussion.
> http://www.nabble.com/what-is-minimum-correct-protocol-for-posting-patch-to-list--t65135.html#a177731
> Part of the message from there:
> Mike Matrigali wrote:
> > what is the minimum correct protocol when submitting patches:
> > attach to jira
> > attach to mail on list
> > send in line on list
> >
> ....
> DERBY-332 is a poster child for confusion. I applied a *patch* on May 5
> that was submitted on May 4. The issue was opened for it on June 1 and
> the April 27 *patch* uploaded. In the meantime I had even forgotten that I
> had applied a *patch* back in May. It got untangled yesterday.
> If I remember right, it was just a month ago that we were discovering
> that we had so many patches posted to derby-dev that we were starting to
> lose track of them, especially when new patches were replacing *old* ones.
> *If it's in Jira and a new patch supercedes an old patch, it's easy to
> remove that old patch so it doesn't get applied by mistake. Or if the
> old patch should be left for some reason, it's easy to see that there
> are multiple patches and judge which one should be applied. *
>   -jean

View raw message