falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepak Kumar Barr (Tech_BLR)" <deepak.b...@flipkart.com>
Subject Re: [DISCUSS] Removing CHANGES.txt
Date Fri, 05 Feb 2016 09:31:01 GMT
I agree. +1

Regards,
Deepak Kumar Barr
Bigfoot-Apps

On Fri, Feb 5, 2016 at 2:59 PM, Sandeep Samudrala <sandysmdl@gmail.com>
wrote:

> Now by moving to Github Pull request model in Apache Falcon, it creates a
> lot of pain as to each pull request merged would create a conflict in
> changes.txt for rest of the pull requests.
> Now considering this issue, the option of having the CHANGES.txt might have
> to be reconsidered.
>
>
> On Sat, Jan 23, 2016 at 10:56 AM, Ajay Yadav <ajaynsit@gmail.com> wrote:
>
> > I agree with you Venkat, mentioning in commit message is better than
> > mentioning in CHANGES.txt. Actually, in Apache Falcon we do both, hence
> > this is even more redundant for this use case. Although in my opinion
> even
> > mentioning contributor in commit message is weak form of attribution
> > compared to making the contributor the author of the commit. Attribution
> > use case will be perfectly solved with the github pull request model.
> >
> > It will also solve my biggest complaint about maintaining change log in
> > CHANGES.txt like this. The responsibility of maintaining the CHANGES.txt
> > will be shifted on multiple contributors rather than lesser number of
> > committers and active committers will not feel the pain.
> >
> > I have already created a JIRA to track this shift and work is already in
> > progress.
> >
> >
> >
> > On Sat, Jan 23, 2016 at 4:13 AM, Venkat Ranganathan <
> > vranganathan@hortonworks.com> wrote:
> >
> > > The maintenance of attribution is a valid thought, but different
> projects
> > > have handled it differently.  For example, in Sqoop, it is written in
> the
> > > git commit message and the changes.list only lists the fixed JIRAs.
> >  There
> > > are good things in both styles, but I prefer the Sqoop style for
> > > contributor information to be maintained in the Git repo as a comment.
> > > That makes the changes.txt easily readable for changes.
> > >
> > > That said, it is a preference set forth by the project team  as
> Venkatesh
> > > Seetharam said.
> > >
> > > Thanks
> > >
> > > Venkat
> > >
> > >
> > >
> > > On 1/21/16, 10:35 PM, "Seetharam Venkatesh" <venkatesh@innerzeal.com>
> > > wrote:
> > >
> > > >One more is to highlight incompatible changes which is very critical.
> > > >
> > > >We as PMC had decided to maintain this and I still think its very
> useful
> > > to
> > > >preserve it here. I do not want to use git to lookup.
> > > >
> > > >On Thu, Jan 21, 2016 at 8:38 PM Srikanth Sundarrajan <
> > sriksun@hotmail.com
> > > >
> > > >wrote:
> > > >
> > > >> There are three main reasons for maintaining the changes.txt in my
> > view
> > > >>
> > > >> 1. Attribution of contribution to original owners
> > > >> 2. Live document listing changes by category (bug type) for
> > developers'
> > > >> convenience
> > > >> 3. A change log to refer to for someone who downloads binary/source
> > > >> releases contained the tar ball.
> > > >>
> > > >> @Ajay, It might be very helpful to call these out specifically.
> > > >>
> > > >> Regards
> > > >> Srikanth Sundarrajan
> > > >>
> > > >> > From: ajaynsit@gmail.com
> > > >> > Date: Thu, 21 Jan 2016 13:24:21 +0530
> > > >> > Subject: Re: [DISCUSS] Removing CHANGES.txt
> > > >> > To: dev@falcon.apache.org
> > > >> >
> > > >> > Thanks for your input Pavan, it is helpful to hear how everyone
is
> > > using
> > > >> > CHANGES.txt and that is the whole purpose of this discussion.
For
> > > >> checking
> > > >> > what all changes went after a JIRA, using git log is a better
> > option.
> > > For
> > > >> > example using CHANGES.txt you can not determine what all
> *features*
> > or
> > > >> > *improvements* went after this *bug fix *because there is no
> > relative
> > > >> > ordering between different types of JIRA in CHANGES.txt*.*
> Secondly
> > > you
> > > >> are
> > > >> > trusting that CHANGES.txt entries were always made in correct
> place
> > on
> > > >> the
> > > >> > top. Being an active committer I can tell you this is not true
and
> > > often
> > > >> > during resolving conflicts etc. things get shuffled around. Also
> it
> > > is a
> > > >> > common error to put a 0.9 change in trunk while committing to
> > master.
> > > >> >
> > > >> > The whole idea is to automate the process, make it less error
> prone
> > > and
> > > >> at
> > > >> > the same time make change log available in better and more
> accurate
> > > >> format.
> > > >> > If hadoop script / workflow solves it then I am very happy to
> > discuss
> > > >> that
> > > >> > approach as well. If someone has a use case which can be solved
> only
> > > by
> > > >> > this workflow then I am happy to discuss how we can solve without
> > > >> > sacrificing those use cases but I request all of you to be
> cognizant
> > > of
> > > >> the
> > > >> > fact that as one of the most active contributors I am feeling
the
> > > pain in
> > > >> > this approach and we need a better solution. I am open to
> listening
> > to
> > > >> > better ideas to solve these problems.
> > > >> >
> > > >> > If anyone has other use cases of CHANGES.txt file or any
> > > >> > opinions/suggestions then please chime in. Later, I will send
a
> > > summary
> > > >> of
> > > >> > the discussion with all the use cases and a proposal to solve
all
> > the
> > > >> pain
> > > >> > points which we can discuss further.
> > > >> >
> > > >> > *P.S.* We may be really used to the CHANGES.txt file but several
> > > apache
> > > >> > projects don't maintain CHANGES.txt e.g. SPARK, Flink
> > > >> >
> > > >> > Cheers
> > > >> > Ajay Yadava
> > > >> >
> > > >> > On Thu, Jan 21, 2016 at 10:50 AM, pavan kumar Kolamuri <
> > > >> > pavan.kolamuri@gmail.com> wrote:
> > > >> >
> > > >> > > Not only for release notes if you just want to look what
all
> > patches
> > > >> went
> > > >> > > after certain patch, it will be easy for anyone to just
look
> into
> > > >> > > changes.txt and get it. Like suresh suggested we should
think of
> > > >> writing
> > > >> > > script for generating changes.txt, that is good option.
> > > >> > >
> > > >> > > On Thu, Jan 21, 2016 at 8:42 AM, Ajay Yadav <
> > ajay.yadav@inmobi.com>
> > > >> wrote:
> > > >> > >
> > > >> > > > Venkatesh,
> > > >> > > >
> > > >> > > > I never said to point users to JIRA, I just said that
> > information
> > > is
> > > >> > > > available from JIRA and we don't need to maintain it
in
> > > CHANGES.txt
> > > >> also.
> > > >> > > > We can extract from JIRA and put release notes and
change log
> > > >> wherever
> > > >> > > we
> > > >> > > > want e.g. then we can choose to put it on site and
putting on
> > > site is
> > > >> > > much
> > > >> > > > better than putting it in the code with no pointers
to users
> on
> > > >> where to
> > > >> > > > see the change log.
> > > >> > > >
> > > >> > > > I am sure even you will agree that if we can get the
change
> log
> > > >> without
> > > >> > > > having to update CHANGES.txt with every commit then
it will be
> > > very
> > > >> > > helpful
> > > >> > > > for committers. We can just apply the same patch on
the master
> > and
> > > >> the
> > > >> > > > branch with just 2 commands and no conflicts.
> > > >> > > >
> > > >> > > >
> > > >> > > > Cheers
> > > >> > > > Ajay Yadava
> > > >> > > >
> > > >> > > > On Thu, Jan 21, 2016 at 2:32 AM, Seetharam Venkatesh
<
> > > >> > > > venkatesh@innerzeal.com> wrote:
> > > >> > > >
> > > >> > > > > Ajay, I have made 3 releases on Apache Falcon
and one in
> > Apache
> > > >> Atlas
> > > >> > > > and I
> > > >> > > > > beg to differ from your opinion.
> > > >> > > > >
> > > >> > > > > Pointing users to use Jira or Git for looking
at release
> notes
> > > is
> > > >> bad
> > > >> > > and
> > > >> > > > > it immensely helps users to just glance at the
text file to
> > > parse
> > > >> what
> > > >> > > > has
> > > >> > > > > gone into trunk.
> > > >> > > > >
> > > >> > > > > On Wed, Jan 20, 2016 at 11:38 AM Ajay Yadav <
> > > ajay.yadav@inmobi.com
> > > >> >
> > > >> > > > wrote:
> > > >> > > > >
> > > >> > > > > > Just to clarify I am not suggesting to not
provide change
> > log
> > > to
> > > >> > > > users. I
> > > >> > > > > > am just suggesting to get rid of the practice
of manually
> > > >> maintaining
> > > >> > > > > > CHANGES.txt file in the code.
> > > >> > > > > >
> > > >> > > > > > For example we can generate change log from
JIRA(it
> provides
> > > >> release
> > > >> > > > > notes
> > > >> > > > > > for a particular release) and put it on website
along with
> > > >> release
> > > >> > > > notes.
> > > >> > > > > > We can also consider the Hadoop method if
it doesn't
> involve
> > > >> extra
> > > >> > > > manual
> > > >> > > > > > work for committers along with each commit.
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > Cheers
> > > >> > > > > > Ajay Yadava
> > > >> > > > > >
> > > >> > > > > > On Thu, Jan 21, 2016 at 12:58 AM, Ajay Yadav
<
> > > >> ajay.yadav@inmobi.com>
> > > >> > > > > > wrote:
> > > >> > > > > >
> > > >> > > > > > > As I said Idea is to delete CHANGES.txt
as the same
> > > >> information can
> > > >> > > > be
> > > >> > > > > > > extracted from JIRA. We can provide
change log
> information
> > > >> using
> > > >> > > > JIRA.
> > > >> > > > > > >
> > > >> > > > > > > Maintaining CHANGES.txt file is a huge
pain for the
> people
> > > who
> > > >> have
> > > >> > > > to
> > > >> > > > > > > commit patches. It is also very error
prone way of
> > > maintaining
> > > >> > > change
> > > >> > > > > > log.
> > > >> > > > > > > We have a 6 weekly release cycle so
that means that we
> are
> > > >> almost
> > > >> > > > > always
> > > >> > > > > > > running in two branches and it becomes
very painful to
> > > >> maintain the
> > > >> > > > > > change
> > > >> > > > > > > log in this fashion.
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > Cheers
> > > >> > > > > > > Ajay Yadava
> > > >> > > > > > >
> > > >> > > > > > > On Thu, Jan 21, 2016 at 12:38 AM, Suresh
Srinivas <
> > > >> > > > > > suresh@hortonworks.com>
> > > >> > > > > > > wrote:
> > > >> > > > > > >
> > > >> > > > > > >> Hadoop has a script to generate
CHANGES.txt. That might
> > be
> > > an
> > > >> > > > option.
> > > >> > > > > > >>
> > > >> > > > > > >> Agree with Venkatesh. This is an
important information
> > and
> > > >> should
> > > >> > > > not
> > > >> > > > > be
> > > >> > > > > > >> deleted.
> > > >> > > > > > >>
> > > >> > > > > > >> On 1/20/16, 10:55 AM, "Seetharam
Venkatesh" <
> > > >> > > > venkatesh@innerzeal.com>
> > > >> > > > > > >> wrote:
> > > >> > > > > > >>
> > > >> > > > > > >> >I think this is quite useful
and AFAICT, the release
> > > >> timelines
> > > >> > > are
> > > >> > > > > > >> >quarterly, it might be worth
the extra effort to
> > maintain
> > > >> this.
> > > >> > > > > > >> >
> > > >> > > > > > >> >-1 from me.
> > > >> > > > > > >> >
> > > >> > > > > > >> >On Wed, Jan 20, 2016 at 10:52
AM Ajay Yadava <
> > > >> > > > ajayyadava@apache.org>
> > > >> > > > > > >> >wrote:
> > > >> > > > > > >> >
> > > >> > > > > > >> >> Currently we are maintaining
CHANGES.txt to record
> > > >> > > contributions,
> > > >> > > > > > >> >>  committers of the commits
and the release in which
> > they
> > > >> got
> > > >> > > > > > committed.
> > > >> > > > > > >> >>All
> > > >> > > > > > >> >> this information is also
available in JIRA and git.
> > > >> > > > > > >> >>
> > > >> > > > > > >> >> However, there are certain
disadvantages of
> > CHANGES.txt,
> > > >> every
> > > >> > > > time
> > > >> > > > > > >> >>during
> > > >> > > > > > >> >> release we have to maintain
different CHANGES.txt in
> > > >> master and
> > > >> > > > > > branch.
> > > >> > > > > > >> >>We
> > > >> > > > > > >> >> have to be careful with
subtle details like
> "Proposed
> > > >> release
> > > >> > > > > > version"
> > > >> > > > > > >> >>and
> > > >> > > > > > >> >> "Released version" etc.
This also creates confusion
> > when
> > > >> same
> > > >> > > > > commit
> > > >> > > > > > >> >>gets
> > > >> > > > > > >> >> committed into master and
the branch.
> > > >> > > > > > >> >>
> > > >> > > > > > >> >> Also, it entails committers
to do some edits to the
> > > patch
> > > >> > > > submitted
> > > >> > > > > > by
> > > >> > > > > > >> >>the
> > > >> > > > > > >> >> contributor. This is error
prone and can be tedious
> > > >> sometimes.
> > > >> > > > > > >> >>Sometimes we
> > > >> > > > > > >> >> forget to attribute contribution
or spell
> > contributor's
> > > >> name
> > > >> > > > > > >> >>incorrectly.
> > > >> > > > > > >> >>
> > > >> > > > > > >> >> Hence I propose to delete
CHANGES.txt from master
> > (0.10
> > > >> > > onward).
> > > >> > > > > > Please
> > > >> > > > > > >> >> provide your inputs. If
everyone agrees, then I will
> > > >> create a
> > > >> > > > JIRA
> > > >> > > > > > and
> > > >> > > > > > >> >> delete CHANGES.txt from
master.
> > > >> > > > > > >> >>
> > > >> > > > > > >> >>
> > > >> > > > > > >> >> Cheers
> > > >> > > > > > >> >> Ajay Yadava
> > > >> > > > > > >> >>
> > > >> > > > > > >>
> > > >> > > > > > >>
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > --
> > > >> > > > > >
> > _____________________________________________________________
> > > >> > > > > > The information contained in this communication
is
> intended
> > > >> solely
> > > >> > > for
> > > >> > > > > the
> > > >> > > > > > use of the individual or entity to whom it
is addressed
> and
> > > >> others
> > > >> > > > > > authorized to receive it. It may contain
confidential or
> > > legally
> > > >> > > > > privileged
> > > >> > > > > > information. If you are not the intended
recipient you are
> > > hereby
> > > >> > > > > notified
> > > >> > > > > > that any disclosure, copying, distribution
or taking any
> > > action
> > > >> in
> > > >> > > > > reliance
> > > >> > > > > > on the contents of this information is strictly
prohibited
> > and
> > > >> may be
> > > >> > > > > > unlawful. If you have received this communication
in
> error,
> > > >> please
> > > >> > > > notify
> > > >> > > > > > us immediately by responding to this email
and then delete
> > it
> > > >> from
> > > >> > > your
> > > >> > > > > > system. The firm is neither liable for the
proper and
> > complete
> > > >> > > > > transmission
> > > >> > > > > > of the information contained in this communication
nor for
> > any
> > > >> delay
> > > >> > > in
> > > >> > > > > its
> > > >> > > > > > receipt.
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > _____________________________________________________________
> > > >> > > > The information contained in this communication is
intended
> > solely
> > > >> for
> > > >> > > the
> > > >> > > > use of the individual or entity to whom it is addressed
and
> > others
> > > >> > > > authorized to receive it. It may contain confidential
or
> legally
> > > >> > > privileged
> > > >> > > > information. If you are not the intended recipient
you are
> > hereby
> > > >> > > notified
> > > >> > > > that any disclosure, copying, distribution or taking
any
> action
> > in
> > > >> > > reliance
> > > >> > > > on the contents of this information is strictly prohibited
and
> > > may be
> > > >> > > > unlawful. If you have received this communication in
error,
> > please
> > > >> notify
> > > >> > > > us immediately by responding to this email and then
delete it
> > from
> > > >> your
> > > >> > > > system. The firm is neither liable for the proper and
complete
> > > >> > > transmission
> > > >> > > > of the information contained in this communication
nor for any
> > > delay
> > > >> in
> > > >> > > its
> > > >> > > > receipt.
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Regards
> > > >> > > Pavan Kumar Kolamuri
> > > >> > >
> > > >>
> > >
> >
>

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