Guys,

I agree that revision numbers are useful if you need to reference a
particular attachment. As well as with all your other arguments.
My general point is that the infrastructure we use should be convenient for
the users to do such simple things automatically. Rather than us
introducing rules to overcome certain shortcomings of the tool. I think if
the Attachments list was
1. ordered by date rather than by name, and
2. enumerated, like subtasks are
then it would have solved the issue discussed here.

I did communicate changing the default ordering for attachments with INFRA
some time ago. Don't remember if I created a jira. Should we open one now?

Thanks,
--Konst

On Sun, Dec 14, 2014 at 6:44 AM, Steve Loughran <ste...@hortonworks.com>
wrote:
>
> a couple more benefits
>
> 1. when you post a patch you can add a comment like "patch 003 killed NPE
> in auth", and the comment history then integrations with the revisions. You
> can also do this in your private git repository, so correlate commits there
> with patch versions.
>
> 2. they list in creation order in a directory.
>
> #2 matters for me as when I create patches I stick them in a dir specific
> to that JIRA; I can work out what the highest number is and increment it by
> one for creating a new one...yet retain the whole patch history locally.
>
> I also download external patches to review & apply to an incoming/ dir;
> numbering helps me manage that & to verify that I really am applying the
> relevant patch.
>
> Doesn't mean we should change the order though. I don't think that is
> something you can do on a per-project basis, so take it to infrastructure@
>
>
> On 14 December 2014 at 01:33, Yongjun Zhang <yzh...@cloudera.com> wrote:
>
> > Hi Konst,
> >
> > Thanks for the good suggestion, certainly that would help.
> >
> > Here are the advantages to include revision number in the patch name:
> >
> >    - we would have the same ordering by name or by date
> >    - it would be easier to refer to individual patch, say, when we need
> to
> >    refer to multiple patches when making a comment (e.g,, "comparing revX
> > with
> >    revY, here are the pros and cons ...").
> >    - when we create a new rev patch file before submitting, if we use the
> >    same name as previous one, it would overwrite the previous one
> >    - when we download patch files to the same directory, depending on the
> >    order of downloading, the patches would possibly not appear in the
> order
> >    that they were submitted.
> >
> > Best regards,
> >
> > --Yongjun
> >
> > On Sat, Dec 13, 2014 at 10:54 AM, Konstantin Shvachko <
> > shv.had...@gmail.com>
> > wrote:
> > >
> > > Hello guys,
> > >
> > > The problem here is not in a patch naming conventions, but in the jira
> > > default ordering schema for attachments.
> > > Mentioned it on several occasions. Currently attachments use "sort by
> > name"
> > > sorting as the default. And it should be changed to "sort by date".
> Then
> > > you don't need any naming conventions to "adjust" to current sorting
> > > settings. You just see them in the order submitted and choose the last
> > for
> > > a review or a commit.
> > >
> > > Does anybody have permissions & skills to change the default order type
> > for
> > > attachments in the Jira?
> > >
> > > Thanks,
> > > --Konst
> > >
> > > On Thu, Dec 4, 2014 at 10:18 AM, Tsuyoshi OZAWA <
> > ozawa.tsuyo...@gmail.com>
> > > wrote:
> > > >
> > > > Thanks Yongjun and Harsh for updating Wiki!
> > > >
> > > > Thanks,
> > > > - Tsuyoshi
> > > >
> > > > On Thu, Dec 4, 2014 at 9:43 AM, Yongjun Zhang <yzh...@cloudera.com>
> > > wrote:
> > > > > Thanks Harsh, I just made a change in
> > > > >
> > > > > https://wiki.apache.org/hadoop/HowToContribute#Naming_your_patch
> > > > >
> > > > > based on the discussion in this thread.
> > > > >
> > > > > --Yongjun
> > > > >
> > > > > On Wed, Dec 3, 2014 at 2:20 PM, Harsh J <ha...@cloudera.com>
> wrote:
> > > > >
> > > > >> I've added you in as YongjunZhang. Please let me know if you are
> > still
> > > > >> unable to edit after a relogin.
> > > > >>
> > > > >> On Wed, Dec 3, 2014 at 1:43 AM, Yongjun Zhang <
> yzh...@cloudera.com>
> > > > wrote:
> > > > >> > Thanks Allen, Andrew and Tsuyoshi.
> > > > >> >
> > > > >> > My wiki user name is YongjunZhang, I will appreciate it very
> much
> > if
> > > > >> > someone can give me the permission to edit the wiki pages.
> Thanks.
> > > > >> >
> > > > >> > --Yongjun
> > > > >> >
> > > > >> > On Tue, Dec 2, 2014 at 11:04 AM, Andrew Wang <
> > > > andrew.w...@cloudera.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> I just updated the wiki to say that the version number format
> is
> > > > >> preferred.
> > > > >> >> Yongjun, if you email out your wiki username, someone (?) can
> > give
> > > > you
> > > > >> >> privs.
> > > > >> >>
> > > > >> >> On Tue, Dec 2, 2014 at 10:16 AM, Allen Wittenauer <
> > > a...@altiscale.com>
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >> > I think people forget we have a wiki that documents this and
> > > other
> > > > >> things
> > > > >> >> > ...
> > > > >> >> >
> > > > >> >> >
> > https://wiki.apache.org/hadoop/HowToContribute#Naming_your_patch
> > > > >> >> >
> > > > >> >> > On Dec 2, 2014, at 10:01 AM, Tsuyoshi OZAWA <
> > > > ozawa.tsuyo...@gmail.com
> > > > >> >
> > > > >> >> > wrote:
> > > > >> >> >
> > > > >> >> > >> <jiraNameId>.[branchName.]<revisionNum>.patch*
> > > > >> >> > >
> > > > >> >> > > +1 for this format. Thanks for starting the discussion,
> > > Yongjun.
> > > > >> >> > >
> > > > >> >> > > - Tsuyoshi
> > > > >> >> > >
> > > > >> >> > > On Tue, Dec 2, 2014 at 9:34 AM, Yongjun Zhang <
> > > > yzh...@cloudera.com>
> > > > >> >> > wrote:
> > > > >> >> > >> Thank you all for the feedback.
> > > > >> >> > >>
> > > > >> >> > >> About how many digits to use, I personally find it's not
> > > > annoying
> > > > >> to
> > > > >> >> > type
> > > > >> >> > >> one extra digit, but as long as we have the rev number, it
> > > > achieves
> > > > >> >> the
> > > > >> >> > >> goal of identifying individual patch.
> > > > >> >> > >>
> > > > >> >> > >> About the rest of the name, as long as we keep it the same
> > for
> > > > the
> > > > >> >> same
> > > > >> >> > >> patch, it would work fine.
> > > > >> >> > >>
> > > > >> >> > >> This boils down to patch naming guideline:
> > > > >> >> > >>
> > > > >> >> > >> *    <jiraNameId>.[branchName.]<revisionNum>.patch*
> > > > >> >> > >>
> > > > >> >> > >>     - Example jiraNameId: HADOOP-1234, HDFS-4321
> > > > >> >> > >>     - When the patch is targeted for trunk, then there is
> no
> > > > need
> > > > >> for
> > > > >> >> > the
> > > > >> >> > >> branchName portion, otherwise, specify the branchName
> > > > accordingly.
> > > > >> >> > Example:
> > > > >> >> > >> branch1, branch2.
> > > > >> >> > >>     - It's recommended to use three digits for
> <revisionNum>
> > > for
> > > > >> >> better
> > > > >> >> > >> sorting of different versions of patches.
> > > > >> >> > >>
> > > > >> >> > >> Would anyone who has the privilege please help to modify
> the
> > > > >> following
> > > > >> >> > page
> > > > >> >> > >>
> > > > >> >> > >>
> > > http://wiki.apache.org/hadoop/HowToContribute#Naming_your_patch
> > > > >> >> > >>
> > > > >> >> > >> accordingly?
> > > > >> >> > >>
> > > > >> >> > >> Thanks a lot.
> > > > >> >> > >>
> > > > >> >> > >> --Yongjun
> > > > >> >> > >>
> > > > >> >> > >> On Mon, Dec 1, 2014 at 10:22 AM, Colin McCabe <
> > > > >> cmcc...@alumni.cmu.edu
> > > > >> >> >
> > > > >> >> > >> wrote:
> > > > >> >> > >>
> > > > >> >> > >>> On Wed, Nov 26, 2014 at 2:58 PM, Karthik Kambatla <
> > > > >> >> ka...@cloudera.com>
> > > > >> >> > >>> wrote:
> > > > >> >> > >>>
> > > > >> >> > >>>> Yongjun, thanks for starting this thread. I personally
> > like
> > > > >> Steve's
> > > > >> >> > >>>> suggestions, but think two digits should be enough.
> > > > >> >> > >>>>
> > > > >> >> > >>>> I propose we limit the restrictions to versioning the
> > > patches
> > > > >> with
> > > > >> >> > >>> version
> > > > >> >> > >>>> numbers and .patch extension. People have their own
> > > > preferences
> > > > >> for
> > > > >> >> > the
> > > > >> >> > >>>> rest of the name (e.g. MAPREDUCE, MapReduce, MR, mr,
> > mapred)
> > > > and
> > > > >> I
> > > > >> >> > don't
> > > > >> >> > >>>> see a gain in forcing everyone to use one.
> > > > >> >> > >>>>
> > > > >> >> > >>>> Putting the suggestions (tight and loose) on the wiki
> > would
> > > > help
> > > > >> new
> > > > >> >> > >>>> contributors as well.
> > > > >> >> > >>>>
> > > > >> >> > >>>>
> > > > >> >> > >>> +1
> > > > >> >> > >>>
> > > > >> >> > >>> best,
> > > > >> >> > >>> Colin
> > > > >> >> > >>>
> > > > >> >> > >>>
> > > > >> >> > >>>> On Wed, Nov 26, 2014 at 2:43 PM, Eric Payne
> > > > >> >> > >>> <erichadoo...@yahoo.com.invalid
> > > > >> >> > >>>>>
> > > > >> >> > >>>> wrote:
> > > > >> >> > >>>>
> > > > >> >> > >>>>> +1.The "different color for newest patch" doesn't work
> > very
> > > > >> well if
> > > > >> >> > you
> > > > >> >> > >>>>> are color blind, so I do appreciate a revision number
> in
> > > the
> > > > >> name.
> > > > >> >> > >>>>>
> > > > >> >> > >>>>>      From: Yongjun Zhang <yzh...@cloudera.com>
> > > > >> >> > >>>>> To: common-dev@hadoop.apache.org
> > > > >> >> > >>>>> Sent: Tuesday, November 25, 2014 11:37 PM
> > > > >> >> > >>>>> Subject: Re: a friendly suggestion for developers when
> > > > uploading
> > > > >> >> > >>> patches
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> Thanks Harsh for the info and Andrew for sharing the
> > > script.
> > > > It
> > > > >> >> looks
> > > > >> >> > >>>> that
> > > > >> >> > >>>>> the script is intelligent enough to pick the latest
> > > > attachment
> > > > >> even
> > > > >> >> > if
> > > > >> >> > >>>> all
> > > > >> >> > >>>>> attachments have the same name.
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> Yet, I hope we use the following as the guideline for
> > patch
> > > > >> names:
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> <*projectName*>-<*jiraNum*>-<*revNum*>.patch
> > > > >> >> > >>>>>
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> So we can easily identify individual patch revs.
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> Thanks.
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> --Yongjun
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> On Tue, Nov 25, 2014 at 5:54 PM, Andrew Wang <
> > > > >> >> > andrew.w...@cloudera.com
> > > > >> >> > >>>>
> > > > >> >> > >>>>> wrote:
> > > > >> >> > >>>>>
> > > > >> >> > >>>>>> This might be a good time to mention my fetch-patch
> > > script,
> > > > I
> > > > >> use
> > > > >> >> it
> > > > >> >> > >>> to
> > > > >> >> > >>>>>> easily download the latest attachment on a jira:
> > > > >> >> > >>>>>>
> > > > >> >> > >>>>>>
> > > > >> https://github.com/umbrant/dotfiles/blob/master/bin/fetch-patch
> > > > >> >> > >>>>>>
> > > > >> >> > >>>>>> On Tue, Nov 25, 2014 at 5:44 PM, Harsh J <
> > > > ha...@cloudera.com>
> > > > >> >> > wrote:
> > > > >> >> > >>>>>>
> > > > >> >> > >>>>>>> For the same filename, you can observe also that the
> > JIRA
> > > > >> colors
> > > > >> >> > >>> the
> > > > >> >> > >>>>>>> latest one to be different than the older ones
> > > > automatically -
> > > > >> >> this
> > > > >> >> > >>>> is
> > > > >> >> > >>>>>>> what I rely on.
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>> On Sat, Nov 22, 2014 at 12:36 AM, Yongjun Zhang <
> > > > >> >> > >>> yzh...@cloudera.com
> > > > >> >> > >>>>>
> > > > >> >> > >>>>>>> wrote:
> > > > >> >> > >>>>>>>> Hi,
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> When I look at patches uploaded to jiras, from time
> to
> > > > time I
> > > > >> >> > >>>> notice
> > > > >> >> > >>>>>> that
> > > > >> >> > >>>>>>>> different revisions of the patch is uploaded with
> the
> > > same
> > > > >> patch
> > > > >> >> > >>>> file
> > > > >> >> > >>>>>>> name,
> > > > >> >> > >>>>>>>> some time for quite a few times. It's confusing
> which
> > is
> > > > >> which.
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> I'd suggest that as a guideline, we do the following
> > > when
> > > > >> >> > >>>> uploading a
> > > > >> >> > >>>>>>> patch:
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>>   - include a revision number in the patch file
> name.A
> > > > >> >> > >>>>>>>>   - include a comment, stating that a new patch is
> > > > uploaded,
> > > > >> >> > >>>>> including
> > > > >> >> > >>>>>>> the
> > > > >> >> > >>>>>>>>   revision number of the patch in the comment.
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> This way, it's easier to refer to a specific version
> > of
> > > a
> > > > >> patch,
> > > > >> >> > >>>> and
> > > > >> >> > >>>>> to
> > > > >> >> > >>>>>>>> know which patch a comment is made about.
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> Hope that makes sense to you.
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> Thanks.
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> --Yongjun
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>> --
> > > > >> >> > >>>>>>> Harsh J
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>
> > > > >> >> > >>>>>
> > > > >> >> > >>>>>
> > > > >> >> > >>>>>
> > > > >> >> > >>>>>
> > > > >> >> > >>>>
> > > > >> >> > >>>
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > --
> > > > >> >> > > - Tsuyoshi
> > > > >> >> >
> > > > >> >> >
> > > > >> >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Harsh J
> > > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > - Tsuyoshi
> > > >
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Reply via email to