You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Daniel John Debrunner <dj...@apache.org> on 2006/02/16 18:02:25 UTC
Jira attachments - please don't delete
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.
Re: Jira attachments - please don't delete
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Daniel John Debrunner wrote (2006-02-16 09:02:25):
>
> 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?
That depends. If old attchments are kept, it is verfy important with
names that clearly states wether
1) it is a new version of a patch (use e.g. v1 v2 etc in the
name. Especially remember to use v1 in the *first* one.)
2) it is an addition to another patch or
3) it is one of several sub-patches.
Today, very often, you have to browse through the comments to figure
this out.
Also: in the comments, we should be catious to name the patch instead
of writing "this", "new" or "latest", which after som new patches and
comments are of very little value.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: Jira attachments - please don't delete
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
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?
I think it depends.
For example, for the logo activity, I removed early web site mockups
from DERBY-747 to declutter that issue, but that might be viewed as a
special case. And, in fact, the Wiki might be a better place for
slapping up screenshots for people to comment on.
In the specific case of doc patches I think it's fine to leave old
versions if the latest version that should be committed is clearly
identified.
-jean
Re: Jira attachments - please don't delete
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I think including a date in the name is a bit much. Personally, I like
<patchname>_v<num>, and let the hover mechanism let you know the date.
As a committer it would be nice to have the bug description in the patch
name, but if necessary I can do that when I save the patch to my local
filesystem.
David
Daniel John Debrunner wrote:
> Kathey Marsden wrote:
>
>
>>Mamta Satoor wrote:
>>
>>
>>
>>>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
>>>Derby479LinkageErrorReturnNullIfNulldiff021306.txt
>>>
>>>
>>
>>I really like the issue number and date in the name as you have it. It
>>really helps me keep patches straight.
>>
>>I would add
>>- A patch number so Jira sorts in the right order.
>
>
> I'm not sure Jira guarantees any sort order.
>
> If you hover the pointer over the attachment the date it was attached
> pops up, I find that useful for confirming the latest version.
>
> Also, I think if you attach a file of the same name the older version is
> greyed out, not sure if you can still select it or not. Though I do
> recommend different names for patches, versions or dates. Dates can be
> somewhat confusing unless everyone sticks to international format of
> year followed by month followed by day.
>
> Dan.
>
Re: Jira attachments - please don't delete
Posted by Daniel John Debrunner <dj...@apache.org>.
Kathey Marsden wrote:
> Mamta Satoor wrote:
>
>
>>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
>>Derby479LinkageErrorReturnNullIfNulldiff021306.txt
>>
>>
>
> I really like the issue number and date in the name as you have it. It
> really helps me keep patches straight.
>
> I would add
> - A patch number so Jira sorts in the right order.
I'm not sure Jira guarantees any sort order.
If you hover the pointer over the attachment the date it was attached
pops up, I find that useful for confirming the latest version.
Also, I think if you attach a file of the same name the older version is
greyed out, not sure if you can still select it or not. Though I do
recommend different names for patches, versions or dates. Dates can be
somewhat confusing unless everyone sticks to international format of
year followed by month followed by day.
Dan.
Re: Jira attachments - please don't delete
Posted by Kathey Marsden <km...@sbcglobal.net>.
Mamta Satoor wrote:
>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
>Derby479LinkageErrorReturnNullIfNulldiff021306.txt
>
>
I really like the issue number and date in the name as you have it. It
really helps me keep patches straight.
I would add
- A patch number so Jira sorts in the right order.
- Move the date earlier.
Maybe
Derby<###>_patch<##>_<mmddyy>_<description>.diff
Derby479_patch01_021306_MyPatchInfo.diff.
Re: Jira attachments - please don't delete
Posted by Mamta Satoor <ms...@gmail.com>.
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
Derby479LinkageErrorReturnNullIfNulldiff021306.txt
Mamta
On 2/16/06, Satheesh Bandaram <sa...@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
>
>