You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@falcon.apache.org by Ajay Yadava <aj...@apache.org> on 2016/01/20 19:51:30 UTC
[DISCUSS] Removing CHANGES.txt
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
Re: [DISCUSS] Removing CHANGES.txt
Posted by Ajay Yadav <aj...@gmail.com>.
Ok, the title of this thread is slightly ambiguous. I clarified it before
but once again, just to bring everyone on same page, no one is recommending
to stop keeping changelog. I think everyone is suggesting that we should
not be maintaining CHANGES.txt manually.
I haven't yet done anything on this, so if anyone has bandwidth then please
feel free to pick it up. I liked Suresh's suggestion of generating
CHANGES.txt hadoop style, so we should be able to borrow heavily from
hadoop's tools/scripts.
On Fri, Feb 5, 2016 at 3:34 PM, Pallavi Rao <pa...@inmobi.com> wrote:
> I totally see (and have experienced) the pain when independent pull
> requests need to be rebased just to update the CHANGES.txt.
>
> However, for reasons mentioned above, lets not remove CHANGES.txt. Lets
> rather automate its generation.
>
> Personally, I like the categorization in there (although not fool-proof)
> and I am using it as a reference to create release notes for the current
> 0.9 release. I also like the way I can see at one place what changes went
> into each release (as recent history is maintained). Yes. all this can be
> retrieved via a few github and JIRA commands. But, for a user, CHANGES.txt
> is the most convenient way to retrieve the info.
>
> I can volunteer to explore ways (or help Ajay with that if he already has
> some thoughts around it) to generate CHANGES.txt automatically. I don't
> want CHANGES.txt gone.
>
> So,
> -1 to removing CHANGES.txt without an alternative.
> +1 to automatically generating it.
>
> Regards,
> Pallavi
>
>
> On Fri, Feb 5, 2016 at 3:07 PM, Praveen Adlakha <
> praveen.adlakha@inmobi.com>
> wrote:
>
> > +1 we should remove CHANGES.txt.
> >
> > On Fri, Feb 5, 2016 at 3:01 PM, Deepak Kumar Barr (Tech_BLR) <
> > deepak.barr@flipkart.com> wrote:
> >
> > > 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 <aj...@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
> > > > > > >> > >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> > --
> > _____________________________________________________________
> > 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.
>
Re: [DISCUSS] Removing CHANGES.txt
Posted by Pallavi Rao <pa...@inmobi.com>.
I totally see (and have experienced) the pain when independent pull
requests need to be rebased just to update the CHANGES.txt.
However, for reasons mentioned above, lets not remove CHANGES.txt. Lets
rather automate its generation.
Personally, I like the categorization in there (although not fool-proof)
and I am using it as a reference to create release notes for the current
0.9 release. I also like the way I can see at one place what changes went
into each release (as recent history is maintained). Yes. all this can be
retrieved via a few github and JIRA commands. But, for a user, CHANGES.txt
is the most convenient way to retrieve the info.
I can volunteer to explore ways (or help Ajay with that if he already has
some thoughts around it) to generate CHANGES.txt automatically. I don't
want CHANGES.txt gone.
So,
-1 to removing CHANGES.txt without an alternative.
+1 to automatically generating it.
Regards,
Pallavi
On Fri, Feb 5, 2016 at 3:07 PM, Praveen Adlakha <pr...@inmobi.com>
wrote:
> +1 we should remove CHANGES.txt.
>
> On Fri, Feb 5, 2016 at 3:01 PM, Deepak Kumar Barr (Tech_BLR) <
> deepak.barr@flipkart.com> wrote:
>
> > I agree. +1
> >
> > Regards,
> > Deepak Kumar Barr
> > Bigfoot-Apps
> >
> > On Fri, Feb 5, 2016 at 2:59 PM, Sandeep Samudrala <sa...@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 <aj...@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
> > > > > >> > >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
> --
> _____________________________________________________________
> 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.
Re: [DISCUSS] Removing CHANGES.txt
Posted by Praveen Adlakha <pr...@inmobi.com>.
+1 we should remove CHANGES.txt.
On Fri, Feb 5, 2016 at 3:01 PM, Deepak Kumar Barr (Tech_BLR) <
deepak.barr@flipkart.com> wrote:
> I agree. +1
>
> Regards,
> Deepak Kumar Barr
> Bigfoot-Apps
>
> On Fri, Feb 5, 2016 at 2:59 PM, Sandeep Samudrala <sa...@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 <aj...@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
> > > > >> > >
> > > > >>
> > > >
> > >
> >
>
--
_____________________________________________________________
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.
Re: [DISCUSS] Removing CHANGES.txt
Posted by "Deepak Kumar Barr (Tech_BLR)" <de...@flipkart.com>.
I agree. +1
Regards,
Deepak Kumar Barr
Bigfoot-Apps
On Fri, Feb 5, 2016 at 2:59 PM, Sandeep Samudrala <sa...@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 <aj...@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" <ve...@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
> > > >> > >
> > > >>
> > >
> >
>
Re: [DISCUSS] Removing CHANGES.txt
Posted by Sandeep Samudrala <sa...@gmail.com>.
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 <aj...@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" <ve...@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
> > >> > >
> > >>
> >
>
Re: [DISCUSS] Removing CHANGES.txt
Posted by Ajay Yadav <aj...@gmail.com>.
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" <ve...@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 <aj...@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
> >> > >
> >>
>
Re: [DISCUSS] Removing CHANGES.txt
Posted by Venkat Ranganathan <vr...@hortonworks.com>.
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" <ve...@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 <sr...@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 <aj...@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
>> > >
>>
Re: [DISCUSS] Removing CHANGES.txt
Posted by Seetharam Venkatesh <ve...@innerzeal.com>.
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 <sr...@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 <aj...@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
> > >
>
RE: [DISCUSS] Removing CHANGES.txt
Posted by Srikanth Sundarrajan <sr...@hotmail.com>.
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 <aj...@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 <aj...@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 <aj...@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
> >
Re: [DISCUSS] Removing CHANGES.txt
Posted by Ajay Yadav <aj...@gmail.com>.
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 <aj...@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 <aj...@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 <aj...@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
>
Re: [DISCUSS] Removing CHANGES.txt
Posted by pavan kumar Kolamuri <pa...@gmail.com>.
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 <aj...@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 <aj...@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 <aj...@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
Re: [DISCUSS] Removing CHANGES.txt
Posted by Ajay Yadav <aj...@inmobi.com>.
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 <aj...@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 <aj...@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" <ve...@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 <aj...@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.
Re: [DISCUSS] Removing CHANGES.txt
Posted by Seetharam Venkatesh <ve...@innerzeal.com>.
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 <aj...@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 <aj...@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" <ve...@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 <aj...@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.
>
Re: [DISCUSS] Removing CHANGES.txt
Posted by Ajay Yadav <aj...@inmobi.com>.
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 <aj...@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 <su...@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" <ve...@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 <aj...@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.
Re: [DISCUSS] Removing CHANGES.txt
Posted by Ajay Yadav <aj...@inmobi.com>.
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 <su...@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" <ve...@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 <aj...@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.
Re: [DISCUSS] Removing CHANGES.txt
Posted by Suresh Srinivas <su...@hortonworks.com>.
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" <ve...@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 <aj...@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
>>
Re: [DISCUSS] Removing CHANGES.txt
Posted by Seetharam Venkatesh <ve...@innerzeal.com>.
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 <aj...@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
>