falcon-dev mailing list archives

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

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