hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: a friendly suggestion for developers when uploading patches
Date Mon, 15 Dec 2014 19:55:09 GMT
I'm all for changing the default sort order, but it doesn't address the
point that Steve and I brought up about local downloads.

If you want to push on the INFRA JIRA though, please feel free. I'm +1 for
that.

Best,
Andrew

On Mon, Dec 15, 2014 at 11:40 AM, Konstantin Shvachko <shv.hadoop@gmail.com>
wrote:
>
> 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 <stevel@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 <yzhang@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.hadoop@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.tsuyoshi@gmail.com>
> > > > wrote:
> > > > >
> > > > > Thanks Yongjun and Harsh for updating Wiki!
> > > > >
> > > > > Thanks,
> > > > > - Tsuyoshi
> > > > >
> > > > > On Thu, Dec 4, 2014 at 9:43 AM, Yongjun Zhang <yzhang@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 <harsh@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 <
> > yzhang@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.wang@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
<
> > > > aw@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.tsuyoshi@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 <
> > > > > yzhang@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 <
> > > > > >> cmccabe@alumni.cmu.edu
> > > > > >> >> >
> > > > > >> >> > >> wrote:
> > > > > >> >> > >>
> > > > > >> >> > >>> On Wed, Nov 26, 2014 at 2:58
PM, Karthik Kambatla <
> > > > > >> >> kasha@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
> > > > > >> >> > >>> <erichadoop-1@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
<yzhang@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.wang@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 <
> > > > > harsh@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 <
> > > > > >> >> > >>> yzhang@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message