You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Yonik Seeley <yo...@apache.org> on 2007/02/21 21:04:01 UTC

removal of JIRA attachments

As a general rule, I don't think we should be removing attachments (of
code) on JIRA issues.

- it represents a loss of code... it's not like subversion where you
can go back in time.  earlier patches can also sometimes be simpler in
places, or can take a different approach, and there can be value in
keeping them around.
- it makes earlier comments in a JIRA issue harder to follow (the
comments now refer to something that is no longer accessible)
- If people submit single patches for an issue, it's easy to tell
which is the latest... no need to remove earlier ones.  Even if they
are named differently, it's still relatively easy to tell what was
added latest.  Confusion happens because people add multiple separate
files.

When a user requests that all patches except the latest be removed
(just for the purpose of clarity), we should educate them.  If they
have multiple versions of multiple files, we should ask them to submit
a single patch for clarity rather than removing outdated stuff for
clarity.

Thoughts?

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: removal of JIRA attachments

Posted by Doug Cutting <cu...@apache.org>.
+1 We should not generally remove obsolete attachments in Jira.

Doug

Yonik Seeley wrote:
> As a general rule, I don't think we should be removing attachments (of
> code) on JIRA issues.
> 
> - it represents a loss of code... it's not like subversion where you
> can go back in time.  earlier patches can also sometimes be simpler in
> places, or can take a different approach, and there can be value in
> keeping them around.
> - it makes earlier comments in a JIRA issue harder to follow (the
> comments now refer to something that is no longer accessible)
> - If people submit single patches for an issue, it's easy to tell
> which is the latest... no need to remove earlier ones.  Even if they
> are named differently, it's still relatively easy to tell what was
> added latest.  Confusion happens because people add multiple separate
> files.
> 
> When a user requests that all patches except the latest be removed
> (just for the purpose of clarity), we should educate them.  If they
> have multiple versions of multiple files, we should ask them to submit
> a single patch for clarity rather than removing outdated stuff for
> clarity.
> 
> Thoughts?
> 
> -Yonik
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: removal of JIRA attachments

Posted by Yonik Seeley <yo...@apache.org>.
And another reason I just thought of... it provides better tracking of IP.
Once something goes in JIRA, multiple people might start contributing
ideas.  If you remove all previous versions, there is no record of the
original submission, or who contributed what to the final.

-Yonik

On 2/21/07, Yonik Seeley <yo...@apache.org> wrote:
> As a general rule, I don't think we should be removing attachments (of
> code) on JIRA issues.
>
> - it represents a loss of code... it's not like subversion where you
> can go back in time.  earlier patches can also sometimes be simpler in
> places, or can take a different approach, and there can be value in
> keeping them around.
> - it makes earlier comments in a JIRA issue harder to follow (the
> comments now refer to something that is no longer accessible)
> - If people submit single patches for an issue, it's easy to tell
> which is the latest... no need to remove earlier ones.  Even if they
> are named differently, it's still relatively easy to tell what was
> added latest.  Confusion happens because people add multiple separate
> files.
>
> When a user requests that all patches except the latest be removed
> (just for the purpose of clarity), we should educate them.  If they
> have multiple versions of multiple files, we should ask them to submit
> a single patch for clarity rather than removing outdated stuff for
> clarity.
>
> Thoughts?
>
> -Yonik
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: removal of JIRA attachments

Posted by Doug Cutting <cu...@apache.org>.
Yonik Seeley wrote:
> I don't think most of us can see JIRA roles, so I don't know how they
> map to the groups like lucene-developer, but I think committers (or
> the lucene-developers JIRA group) still need removal privs (to remove
> spam, IP issues, *real* removal requests, etc).

Sorry.  For Lucene Java, the Contributor role is defined as members of 
the lucene-developer group.

> Do non-members of the lucene-developers JIRA group currently have the
> ability to delete their own attachments?

No.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: removal of JIRA attachments

Posted by Yonik Seeley <yo...@apache.org>.
On 2/21/07, Doug Cutting <cu...@apache.org> wrote:
> Michael McCandless wrote:
> > Is this (ability to delete patches) something we can disable in Jira?
>
> Yes.  It is controlled by the "Delete Issues" permission: "Ability to
> delete issues, comments and attachments."  Lucene Java uses Jira's
> Standard Permissions, and under those, the Contributor role has this
> permission.  We can switch Lucene Java to use a clone of Standard
> Permissions called "Lucene Java Permissions" and remove this permission
> from that.  Should we do that?

I don't think most of us can see JIRA roles, so I don't know how they
map to the groups like lucene-developer, but I think committers (or
the lucene-developers JIRA group) still need removal privs (to remove
spam, IP issues, *real* removal requests, etc).

Do non-members of the lucene-developers JIRA group currently have the
ability to delete their own attachments?

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: removal of JIRA attachments

Posted by Doug Cutting <cu...@apache.org>.
Chris Hostetter wrote:
> ... if because of jira settings we are forced to choose between:
>    1) deletes are completely impossible
>    2) only members of "lucene-developers" jira group can delete
>    3) people can delete their own attachments
> 
> ...i would choose #1 for safety (better to have a ton of crap we can't get
> rid of them to lose 1 thing of value)

We could also do something like: (4) only committers can delete, a 
subset of lucene-developers.  Or, we could even add a new admin 
group/role, a subset of committers, that's permitted to delete.

(2) is the status quo.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: removal of JIRA attachments

Posted by Chris Hostetter <ho...@fucit.org>.
: Yes.  It is controlled by the "Delete Issues" permission: "Ability to
: delete issues, comments and attachments."  Lucene Java uses Jira's
: Standard Permissions, and under those, the Contributor role has this
: permission.  We can switch Lucene Java to use a clone of Standard
: Permissions called "Lucene Java Permissions" and remove this permission
: from that.  Should we do that?

+1

... if because of jira settings we are forced to choose between:
   1) deletes are completely impossible
   2) only members of "lucene-developers" jira group can delete
   3) people can delete their own attachments

...i would choose #1 for safety (better to have a ton of crap we can't get
rid of them to lose 1 thing of value)


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: removal of JIRA attachments

Posted by Doug Cutting <cu...@apache.org>.
Michael McCandless wrote:
> Is this (ability to delete patches) something we can disable in Jira?

Yes.  It is controlled by the "Delete Issues" permission: "Ability to 
delete issues, comments and attachments."  Lucene Java uses Jira's 
Standard Permissions, and under those, the Contributor role has this 
permission.  We can switch Lucene Java to use a clone of Standard 
Permissions called "Lucene Java Permissions" and remove this permission 
from that.  Should we do that?

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: removal of JIRA attachments

Posted by Michael McCandless <lu...@mikemccandless.com>.
On Wed, 21 Feb 2007 15:04:01 -0500, "Yonik Seeley" <yo...@apache.org>
said:
> As a general rule, I don't think we should be removing attachments (of
> code) on JIRA issues.

+1

I've been hit by this in the past when I had wanted to diff the original
patch against the new one to see details on what had changed.

Is this (ability to delete patches) something we can disable in Jira?

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org