Can someone with JIRA admin privileges see if the default sorting order for
attachments be changed to be by date instead of by name?

Ordering by date helps in picking up the latest patches easily.

Thanks,
+Vinod

+1. In addition, I've found easier for identifying the right patch to use a
version suffix, like HADOOP-1234v2.patch. Maybe we should recommend
something like that as a naming convention in the HowToContribute

On Fri, Sep 9, 2011 at 2:38 AM, Vinod Kumar Vavilapalli <
[EMAIL PROTECTED]> wrote:

> Can someone with JIRA admin privileges see if the default sorting order for
> attachments be changed to be by date instead of by name?
>
> Ordering by date helps in picking up the latest patches easily.
>
> Thanks,
> +Vinod
>

+1, that is nice point.

Thanks,
Uma
----- Original Message -----
From: Vinod Kumar Vavilapalli <[EMAIL PROTECTED]>
Date: Friday, September 9, 2011 3:09 pm
Subject: JIRA attachments order
To: [EMAIL PROTECTED]

> Can someone with JIRA admin privileges see if the default sorting
> order for
> attachments be changed to be by date instead of by name?
>
> Ordering by date helps in picking up the latest patches easily.
>
> Thanks,
> +Vinod
>

+1. Changing default to 'sorted by date' helps.

John Vijoe George Edackattukudy

On Sep 9, 2011, at 9:01 AM, "Uma Maheswara Rao G 72686" <[EMAIL PROTECTED]> wrote:

>
> +1, that is nice point.
>
> Thanks,
> Uma
> ----- Original Message -----
> From: Vinod Kumar Vavilapalli <[EMAIL PROTECTED]>
> Date: Friday, September 9, 2011 3:09 pm
> Subject: JIRA attachments order
> To: [EMAIL PROTECTED]
>
>> Can someone with JIRA admin privileges see if the default sorting
>> order for
>> attachments be changed to be by date instead of by name?
>>
>> Ordering by date helps in picking up the latest patches easily.
>>
>> Thanks,
>> +Vinod
>>

If you post the same patch with the same name, JIRA helps you out by greying
all the earlier versions out.

On Fri, Sep 9, 2011 at 7:03 AM, John George <[EMAIL PROTECTED]> wrote:

> +1. Changing default to 'sorted by date' helps.
>
> John Vijoe George Edackattukudy
>
> On Sep 9, 2011, at 9:01 AM, "Uma Maheswara Rao G 72686" <
> [EMAIL PROTECTED]> wrote:
>
> >
> > +1, that is nice point.
> >
> > Thanks,
> > Uma
> > ----- Original Message -----
> > From: Vinod Kumar Vavilapalli <[EMAIL PROTECTED]>
> > Date: Friday, September 9, 2011 3:09 pm
> > Subject: JIRA attachments order
> > To: [EMAIL PROTECTED]
> >
> >> Can someone with JIRA admin privileges see if the default sorting
> >> order for
> >> attachments be changed to be by date instead of by name?
> >>
> >> Ordering by date helps in picking up the latest patches easily.
> >>
> >> Thanks,
> >> +Vinod
> >>
>

On 09/09/2011 07:27 AM, Ted Dunning wrote:
> If you post the same patch with the same name, JIRA helps you out by greying
> all the earlier versions out.

Indeed.  That's the best practice, not to add version numbers to patch
files, for this very reason.  We should perhaps note this on:

http://wiki.apache.org/hadoop/HowToContribute

I am a Jira administrator and would be happy to change the default
ordering of attachments if it were possible, however I can see no option
to do so.

Doug

Wow, I didn't know that!

Learn something new everyday, thanks guys.

Cheers,
Chris

On Sep 9, 2011, at 9:48 AM, Doug Cutting wrote:

> On 09/09/2011 07:27 AM, Ted Dunning wrote:
>> If you post the same patch with the same name, JIRA helps you out by greying
>> all the earlier versions out.
>
> Indeed.  That's the best practice, not to add version numbers to patch
> files, for this very reason.  We should perhaps note this on:
>
> http://wiki.apache.org/hadoop/HowToContribute
>
> I am a Jira administrator and would be happy to change the default
> ordering of attachments if it were possible, however I can see no option
> to do so.
>
> Doug
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: [EMAIL PROTECTED]
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Can I ask, though that we do add branch information in the patches.  Too often a patch is intended to apply to some branch other then trunk, and there is no easy way to tell what branch it was intended for.

--Bobby Evans
On 9/9/11 10:52 AM, "Mattmann, Chris A (388J)" <[EMAIL PROTECTED]> wrote:

Wow, I didn't know that!

Learn something new everyday, thanks guys.

Cheers,
Chris

On Sep 9, 2011, at 9:48 AM, Doug Cutting wrote:

> On 09/09/2011 07:27 AM, Ted Dunning wrote:
>> If you post the same patch with the same name, JIRA helps you out by greying
>> all the earlier versions out.
>
> Indeed.  That's the best practice, not to add version numbers to patch
> files, for this very reason.  We should perhaps note this on:
>
> http://wiki.apache.org/hadoop/HowToContribute
>
> I am a Jira administrator and would be happy to change the default
> ordering of attachments if it were possible, however I can see no option
> to do so.
>
> Doug
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: [EMAIL PROTECTED]
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

But what if I want to see an incremental diff between two patches? I don't
want to review the whole patch everytime. Maybe I just want to re-review the
changes made to a patch. I would then have sort the patches manually using
time. I think its better to have version numbers in that case
On Fri, Sep 9, 2011 at 10:48 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:

> On 09/09/2011 07:27 AM, Ted Dunning wrote:
> > If you post the same patch with the same name, JIRA helps you out by
> greying
> > all the earlier versions out.
>
> Indeed.  That's the best practice, not to add version numbers to patch
> files, for this very reason.  We should perhaps note this on:
>
> http://wiki.apache.org/hadoop/HowToContribute
>
> I am a Jira administrator and would be happy to change the default
> ordering of attachments if it were possible, however I can see no option
> to do so.
>
> Doug
>

How about we the how to contribute page with a simple standard?

jira-xyz.patch  # for trunk
jira-xyz-branch.patch  # for a release branch, could use a shortened
name, eg "20x" for branch-20-security and "append" for
branch-20-append.

Thanks,
Eli

On Fri, Sep 9, 2011 at 10:32 AM, Robert Evans <[EMAIL PROTECTED]> wrote:
> Can I ask, though that we do add branch information in the patches.  Too often a patch is intended to apply to some branch other then trunk, and there is no easy way to tell what branch it was intended for.
>
> --Bobby Evans
>
>
> On 9/9/11 10:52 AM, "Mattmann, Chris A (388J)" <[EMAIL PROTECTED]> wrote:
>
> Wow, I didn't know that!
>
> Learn something new everyday, thanks guys.
>
> Cheers,
> Chris
>
> On Sep 9, 2011, at 9:48 AM, Doug Cutting wrote:
>
>> On 09/09/2011 07:27 AM, Ted Dunning wrote:
>>> If you post the same patch with the same name, JIRA helps you out by greying
>>> all the earlier versions out.
>>
>> Indeed.  That's the best practice, not to add version numbers to patch
>> files, for this very reason.  We should perhaps note this on:
>>
>> http://wiki.apache.org/hadoop/HowToContribute
>>
>> I am a Jira administrator and would be happy to change the default
>> ordering of attachments if it were possible, however I can see no option
>> to do so.
>>
>> Doug
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: [EMAIL PROTECTED]
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>

Personally I like version numbers as well,  it allows me to refer to a
specific version of the patch (vs a patch on a given time of
date/date).

I also notice some people use .txt which browsers can view in place vs
.patch which will download by default unless you register a viewer.

Thanks,
Eli

On Fri, Sep 9, 2011 at 11:08 AM, Ravi Prakash <[EMAIL PROTECTED]> wrote:
> But what if I want to see an incremental diff between two patches? I don't
> want to review the whole patch everytime. Maybe I just want to re-review the
> changes made to a patch. I would then have sort the patches manually using
> time. I think its better to have version numbers in that case
>
>
> On Fri, Sep 9, 2011 at 10:48 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:
>
>> On 09/09/2011 07:27 AM, Ted Dunning wrote:
>> > If you post the same patch with the same name, JIRA helps you out by
>> greying
>> > all the earlier versions out.
>>
>> Indeed.  That's the best practice, not to add version numbers to patch
>> files, for this very reason.  We should perhaps note this on:
>>
>> http://wiki.apache.org/hadoop/HowToContribute
>>
>> I am a Jira administrator and would be happy to change the default
>> ordering of attachments if it were possible, however I can see no option
>> to do so.
>>
>> Doug
>>
>

On Fri, Sep 9, 2011 at 11:38 PM, Ravi Prakash <[EMAIL PROTECTED]> wrote:
> But what if I want to see an incremental diff between two patches? I don't
> want to review the whole patch everytime. Maybe I just want to re-review the
> changes made to a patch. I would then have sort the patches manually using
> time. I think its better to have version numbers in that case

One could utilize the apache reviewboard instance to do this. It
supports revisions internally so you don't have to regenerate a
secondary diff.

--
Harsh J

Agreed.  Furthermore, if I have 10+ versions of a patch, when getting
feedback knowing for with version would be handy, having a single name makes
this correlation difficult.

Thxs.

Alejandro
[PS: I know, I should code better not have to go thru several versions]

On Fri, Sep 9, 2011 at 11:08 AM, Ravi Prakash <[EMAIL PROTECTED]> wrote:

> But what if I want to see an incremental diff between two patches? I don't
> want to review the whole patch everytime. Maybe I just want to re-review
> the
> changes made to a patch. I would then have sort the patches manually using
> time. I think its better to have version numbers in that case
>
>
> On Fri, Sep 9, 2011 at 10:48 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:
>
> > On 09/09/2011 07:27 AM, Ted Dunning wrote:
> > > If you post the same patch with the same name, JIRA helps you out by
> > greying
> > > all the earlier versions out.
> >
> > Indeed.  That's the best practice, not to add version numbers to patch
> > files, for this very reason.  We should perhaps note this on:
> >
> > http://wiki.apache.org/hadoop/HowToContribute
> >
> > I am a Jira administrator and would be happy to change the default
> > ordering of attachments if it were possible, however I can see no option
> > to do so.
> >
> > Doug
> >
>

On 09/09/2011 11:12 AM, Eli Collins wrote:
> Personally I like version numbers as well,  it allows me to refer to a
> specific version of the patch (vs a patch on a given time of
> date/date).

Re-using the name doesn't hide the old versions, it just makes them
gray.  They're still listed, with date and may be sorted by date.  If
you select the "Activity>All" tab then the different versions are linked
to in the comment stream, providing context.

90+% of the time I'm interested in the most recent version of the patch,
so the value of having it highlighted is great.  Frequently when
different names are used I mistakenly download the wrong version and
waste time reviewing it, but when the same name is used I always get the
most recent.  The highlighting is very effective for me.

Doug

On Fri, Sep 9, 2011 at 12:52 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> On 09/09/2011 11:12 AM, Eli Collins wrote:
>> Personally I like version numbers as well,  it allows me to refer to a
>> specific version of the patch (vs a patch on a given time of
>> date/date).
>
> Re-using the name doesn't hide the old versions, it just makes them
> gray.  They're still listed, with date and may be sorted by date.  If
> you select the "Activity>All" tab then the different versions are linked
> to in the comment stream, providing context.
>
> 90+% of the time I'm interested in the most recent version of the patch,
> so the value of having it highlighted is great.  Frequently when
> different names are used I mistakenly download the wrong version and
> waste time reviewing it, but when the same name is used I always get the
> most recent.  The highlighting is very effective for me.
>

I'm cool w/ adopting the names w/o versions. Try to standardize on one
form would be easier for everyone, especially new contributors.

Anyone object to me updating HowToContribute with the following?

Patches for trunk should be named:   jira-xyz.patch
eg hdfs-123.patch

Patches for a specific branch should be named:  jira-xyz-branch.patch
where "branch" may be abbreviated, eg hdfs-123-security.patch

I'll indicate the rationale wrt jira so people know why it's this way.

Thanks,
Eli

On Sep 9, 2011, at 12:57 PM, Eli Collins wrote:
>
> Patches for trunk should be named:   jira-xyz.patch
> eg hdfs-123.patch

s,patch,txt, since jira doesn't appear to pass a content-type to indicate it is readable by the browser (as you mentioned earlier).

On 09/09/2011 01:08 PM, Allen Wittenauer wrote:
> s,patch,txt, since jira doesn't appear to pass a content-type to indicate it is readable by the browser (as you mentioned earlier).

I think Jira uses the content-type that the browser posts with.  My
browser (Chrome on Ubuntu) posts .patch files as text/plain.

Doug

On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins <[EMAIL PROTECTED]> wrote:

> Patches for a specific branch should be named:  jira-xyz-branch.patch
> where "branch" may be abbreviated, eg hdfs-123-security.patch
>

+1, if we ever hope to implement HADOOP-7435 [1], it will be necessary to
standardize the branch-name-in-patch-name scheme.

--
Aaron T. Myers
Software Engineer, Cloudera

[1] https://issues.apache.org/jira/browse/HADOOP-7435

On Fri, Sep 9, 2011 at 3:15 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
>
>> Patches for a specific branch should be named:  jira-xyz-branch.patch
>> where "branch" may be abbreviated, eg hdfs-123-security.patch
>>
>
> +1, if we ever hope to implement HADOOP-7435 [1], it will be necessary to
> standardize the branch-name-in-patch-name scheme.
>

Coming out of lurker mode...

Someday I wish Apache would find/adopt a distributed version control
system (I know about git.apache.org, but I mean pushing that further),
and use something like gerrit or review board.  So if you have a
patch, or a series of patches, you'd just use a version control
system.  Make it such that when you submit to review system you have
to log in and say "Yes, I want contribute this under to the ASF under
an Apache 2.0 license".  Make me use my JIRA/Apache credentials to
submit reviews directly from my version control, and force the commit
message to be properly formatted to tie it to a JIRA issue.  Make the
patch submission have a link right next to it to take me to the review
system, where it can be +1/0/-1'ed with commentary in line.

I mean this as nicely as possible, but generating patches and
uploading them feels like you're stuck in the stone age (also known as
the mid 1990s).  95% of the problems being discussed in this thread
are irrelevant if the tools chosen matched up with the problems.  This
whole discussion feels like discussing the merits of using the butt
end of a screw driver or a monkey wrench to drive nails.  Why not just
pick the nice hammer lying over there (even if it requires some
assembly).  Even if you don't feel like moving completely away from
SVN and JIRA (which I understand the stability of the technical and
legal aspects are important to the heavy lifting Apache does to ensure
everything is on the up and up), if you decided that you would support
git or mercurial (or DVCS of choice), along with a web based code
review integration (what ever one you like), could do the work of
submitting patches and labeling revisions for you.

I think that'd be the path of least resistance, and you'd see
developers migrate rapidly to using that workflow, and this whole
thing is mostly moot.  At least IMHO.

... Back to lurking mode...   Thanks for all the great code.

Kirby

> --
> Aaron T. Myers
> Software Engineer, Cloudera
>
> [1] https://issues.apache.org/jira/browse/HADOOP-7435
>

On 09/09/2011 01:38 PM, Kirby Bohling wrote:
> Someday I wish Apache would find/adopt a distributed version control
> system (I know about git.apache.org, but I mean pushing that further),
> and use something like gerrit or review board.  So if you have a
> patch, or a series of patches, you'd just use a version control
> system.  Make it such that when you submit to review system you have
> to log in and say "Yes, I want contribute this under to the ASF under
> an Apache 2.0 license".  Make me use my JIRA/Apache credentials to
> submit reviews directly from my version control, and force the commit
> message to be properly formatted to tie it to a JIRA issue.  Make the
> patch submission have a link right next to it to take me to the review
> system, where it can be +1/0/-1'ed with commentary in line.

The appropriate forum to discuss that is infrastructure-dev@a.o.

http://www.apache.org/dev/infra-mail.html

In the meantime, we should use the tools we have as best we can.

Doug

On Fri, Sep 9, 2011 at 4:04 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> On 09/09/2011 01:38 PM, Kirby Bohling wrote:
>> Someday I wish Apache would find/adopt a distributed version control
>> system (I know about git.apache.org, but I mean pushing that further),
>> and use something like gerrit or review board.  So if you have a
>> patch, or a series of patches, you'd just use a version control
>> system.  Make it such that when you submit to review system you have
>> to log in and say "Yes, I want contribute this under to the ASF under
>> an Apache 2.0 license".  Make me use my JIRA/Apache credentials to
>> submit reviews directly from my version control, and force the commit
>> message to be properly formatted to tie it to a JIRA issue.  Make the
>> patch submission have a link right next to it to take me to the review
>> system, where it can be +1/0/-1'ed with commentary in line.
>
> The appropriate forum to discuss that is infrastructure-dev@a.o.
>
> http://www.apache.org/dev/infra-mail.html
>
> In the meantime, we should use the tools we have as best we can.
>
> Doug
>

Fair enough Doug.  Somebody else will have to do that, I don't have
commit access (a pre-requisite for access to the private lists).  I'd
make the suggestion there, but I literally can't.

Not trying to veer the discussion off course, just observations about
how much tedium is left to the contributors.

Kirby

On 09/09/2011 02:15 PM, Kirby Bohling wrote:
> Fair enough Doug.  Somebody else will have to do that, I don't have
> commit access (a pre-requisite for access to the private lists).  I'd
> make the suggestion there, but I literally can't.

Such suggestions have been made before.  What's lacking are volunteers
who're able to implement it and integrate it into Apache's
infrastructure.  I presently am not able to work on that, so I won't
raise it there now.

Doug

Review board already works.  Hbase uses it extensively.

On Fri, Sep 9, 2011 at 2:15 PM, Kirby Bohling <[EMAIL PROTECTED]>wrote:

> On Fri, Sep 9, 2011 at 4:04 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> > On 09/09/2011 01:38 PM, Kirby Bohling wrote:
> >> Someday I wish Apache would find/adopt a distributed version control
> >> system (I know about git.apache.org, but I mean pushing that further),
> >> and use something like gerrit or review board.  So if you have a
> >> patch, or a series of patches, you'd just use a version control
> >> system.  Make it such that when you submit to review system you have
> >> to log in and say "Yes, I want contribute this under to the ASF under
> >> an Apache 2.0 license".  Make me use my JIRA/Apache credentials to
> >> submit reviews directly from my version control, and force the commit
> >> message to be properly formatted to tie it to a JIRA issue.  Make the
> >> patch submission have a link right next to it to take me to the review
> >> system, where it can be +1/0/-1'ed with commentary in line.
> >
> > The appropriate forum to discuss that is infrastructure-dev@a.o.
> >
> > http://www.apache.org/dev/infra-mail.html
> >
> > In the meantime, we should use the tools we have as best we can.
> >
> > Doug
> >
>
> Fair enough Doug.  Somebody else will have to do that, I don't have
> commit access (a pre-requisite for access to the private lists).  I'd
> make the suggestion there, but I literally can't.
>
> Not trying to veer the discussion off course, just observations about
> how much tedium is left to the contributors.
>
> Kirby
>

On Fri, Sep 9, 2011 at 1:15 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
>
>> Patches for a specific branch should be named:  jira-xyz-branch.patch
>> where "branch" may be abbreviated, eg hdfs-123-security.patch
>>
>
> +1, if we ever hope to implement HADOOP-7435 [1], it will be necessary to
> standardize the branch-name-in-patch-name scheme.
>

Good point.  One way to enforce this is for Jenkins to only run tests
against patches that follow this naming scheme, and to put the actual
branch name in the patch (where no branch means trunk). Ie
xyz-123.patch will run against trunk, xyz-123-branchx.patch will run
against branch x and all other patches will be ignored by Jenkins.
Someone tedious eg for "branch-20-security" but means we dont have to
maintain a mapping.

Thanks,
Eli

> --
> Aaron T. Myers
> Software Engineer, Cloudera
>
> [1] https://issues.apache.org/jira/browse/HADOOP-7435
>

I updated HowToContribute, it people like this prose I'll advertise
the change to *-dev.

Thanks,
Eli

On Fri, Sep 9, 2011 at 2:53 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 9, 2011 at 1:15 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
>> On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
>>
>>> Patches for a specific branch should be named:  jira-xyz-branch.patch
>>> where "branch" may be abbreviated, eg hdfs-123-security.patch
>>>
>>
>> +1, if we ever hope to implement HADOOP-7435 [1], it will be necessary to
>> standardize the branch-name-in-patch-name scheme.
>>
>
> Good point.  One way to enforce this is for Jenkins to only run tests
> against patches that follow this naming scheme, and to put the actual
> branch name in the patch (where no branch means trunk). Ie
> xyz-123.patch will run against trunk, xyz-123-branchx.patch will run
> against branch x and all other patches will be ignored by Jenkins.
> Someone tedious eg for "branch-20-security" but means we dont have to
> maintain a mapping.
>
> Thanks,
> Eli
>
>
>
>> --
>> Aaron T. Myers
>> Software Engineer, Cloudera
>>
>> [1] https://issues.apache.org/jira/browse/HADOOP-7435
>>
>

Alas, my original request about changing the default sort order to be by
date doesn't seem to be satisfiable as Doug mentioned. I also searched
around on Atlassian forums and JIRA tracker for the JIRA project itself,
seems like an issue that isn't fixed yet.

Regarding patch names, I too agree with Allen that extension should be .txt.
I do run into patches every now and then which aren't interpreted as text
files, so there are people out there using browsers that don't properly set
the content-type.

Thanks,
+Vinod
On Sat, Sep 10, 2011 at 3:30 AM, Eli Collins <[EMAIL PROTECTED]> wrote:

> I updated HowToContribute, it people like this prose I'll advertise
> the change to *-dev.
>
> Thanks,
> Eli
>
> On Fri, Sep 9, 2011 at 2:53 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
> > On Fri, Sep 9, 2011 at 1:15 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
> >> On Fri, Sep 9, 2011 at 12:57 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
> >>
> >>> Patches for a specific branch should be named:  jira-xyz-branch.patch
> >>> where "branch" may be abbreviated, eg hdfs-123-security.patch
> >>>
> >>
> >> +1, if we ever hope to implement HADOOP-7435 [1], it will be necessary
> to
> >> standardize the branch-name-in-patch-name scheme.
> >>
> >
> > Good point.  One way to enforce this is for Jenkins to only run tests
> > against patches that follow this naming scheme, and to put the actual
> > branch name in the patch (where no branch means trunk). Ie
> > xyz-123.patch will run against trunk, xyz-123-branchx.patch will run
> > against branch x and all other patches will be ignored by Jenkins.
> > Someone tedious eg for "branch-20-security" but means we dont have to
> > maintain a mapping.
> >
> > Thanks,
> > Eli
> >
> >
> >
> >> --
> >> Aaron T. Myers
> >> Software Engineer, Cloudera
> >>
> >> [1] https://issues.apache.org/jira/browse/HADOOP-7435
> >>
> >
>

On 09/10/2011 01:32 AM, Vinod Kumar Vavilapalli wrote:
> Regarding patch names, I too agree with Allen that extension should be .txt.
> I do run into patches every now and then which aren't interpreted as text
> files, so there are people out there using browsers that don't properly set
> the content-type.

I have seen .txt attachments that were not uploaded as text.  A better
thing might be to ask folks to check the mime type they've uploaded, as
displayed in Jira, to make sure it's text.  What I do to remove
variability is not click on the patch directly, but always use
right-click and choose "Save Link As" (or your browser's equivalent).

Doug

> If you post the same patch with the same name, JIRA helps you out by greying
> all the earlier versions out.

Hmm. Except this is a bit of a hassle for folks like me with vision issues and color blindness.
-Eric Payne

-----Original Message-----
From: Doug Cutting [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 09, 2011 10:48 AM
To: [EMAIL PROTECTED]
Subject: Re: JIRA attachments order

On 09/09/2011 07:27 AM, Ted Dunning wrote:
> If you post the same patch with the same name, JIRA helps you out by greying
> all the earlier versions out.

Indeed.  That's the best practice, not to add version numbers to patch
files, for this very reason.  We should perhaps note this on:

http://wiki.apache.org/hadoop/HowToContribute

I am a Jira administrator and would be happy to change the default
ordering of attachments if it were possible, however I can see no option
to do so.

Doug

So, if a patch is the same for trunk plus one or more branches, would we need to upload multiple patches?

Thanks,
-Eric Payne

-----Original Message-----
From: Eli Collins [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 09, 2011 1:11 PM
To: [EMAIL PROTECTED]
Subject: Re: JIRA attachments order

How about we the how to contribute page with a simple standard?

jira-xyz.patch  # for trunk
jira-xyz-branch.patch  # for a release branch, could use a shortened
name, eg "20x" for branch-20-security and "append" for
branch-20-append.

Thanks,
Eli

On Fri, Sep 9, 2011 at 10:32 AM, Robert Evans <[EMAIL PROTECTED]> wrote:
> Can I ask, though that we do add branch information in the patches.  Too often a patch is intended to apply to some branch other then trunk, and there is no easy way to tell what branch it was intended for.
>
> --Bobby Evans
>
>
> On 9/9/11 10:52 AM, "Mattmann, Chris A (388J)" <[EMAIL PROTECTED]> wrote:
>
> Wow, I didn't know that!
>
> Learn something new everyday, thanks guys.
>
> Cheers,
> Chris
>
> On Sep 9, 2011, at 9:48 AM, Doug Cutting wrote:
>
>> On 09/09/2011 07:27 AM, Ted Dunning wrote:
>>> If you post the same patch with the same name, JIRA helps you out by greying
>>> all the earlier versions out.
>>
>> Indeed.  That's the best practice, not to add version numbers to patch
>> files, for this very reason.  We should perhaps note this on:
>>
>> http://wiki.apache.org/hadoop/HowToContribute
>>
>> I am a Jira administrator and would be happy to change the default
>> ordering of attachments if it were possible, however I can see no option
>> to do so.
>>
>> Doug
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: [EMAIL PROTECTED]
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>

On Mon, Sep 12, 2011 at 10:03 PM, Eric Payne <[EMAIL PROTECTED]> wrote:
> So, if a patch is the same for trunk plus one or more branches, would we need to upload multiple patches?
>
> Thanks,
> -Eric Payne

I for one would like it that way - easier for me to grab, apply and
test against my chosen branch/tag. Besides, a cp shouldn't be that
hard, and with sorting on, they arrange nicely on JIRA as well :-)

> -----Original Message-----
> From: Eli Collins [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 09, 2011 1:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: JIRA attachments order
>
> How about we the how to contribute page with a simple standard?
>
> jira-xyz.patch  # for trunk
> jira-xyz-branch.patch  # for a release branch, could use a shortened
> name, eg "20x" for branch-20-security and "append" for
> branch-20-append.
>
> Thanks,
> Eli

--
Harsh J

On Mon, Sep 12, 2011 at 9:33 AM, Eric Payne <[EMAIL PROTECTED]> wrote:
> So, if a patch is the same for trunk plus one or more branches, would we need to upload multiple patches?
>

Correct.  In my experience its been very rare that one patch applies
to trunk and a stable branch, and trunk to a feature branch is
normally done by a merge.

Thanks,
Eli