hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yongjun Zhang <yzh...@cloudera.com>
Subject Re: a friendly suggestion for developers when uploading patches
Date Tue, 16 Dec 2014 16:24:38 GMT
Hi Konst,

Thanks for digging out this info and share!

Interesting to see that the setting is not configurable and  it is not a
simple fix.

Best,

--Yongjun




On Mon, Dec 15, 2014 at 5:43 PM, Konstantin Shvachko <shv.hadoop@gmail.com>
wrote:
>
> Did some research on changing the default order of attachments.
> It is not a configuration or INFRA issue.
> Turned out to be a controversial topic in the Jira itself, which was
> explicitly rejected by the developers. With many users unsatisfied.
>
> https://jira.atlassian.com/browse/JRA-28290
>
> I thought it should be a simple thing to fix...
> Oh well. Revision numbers is the way to go then for now.
>
> Thanks,
> --Konst
>
> On Mon, Dec 15, 2014 at 11:55 AM, Andrew Wang <andrew.wang@cloudera.com>
> wrote:
> >
> > 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