falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pallavi Rao <pallavi....@inmobi.com>
Subject Re: [DISCUSS] Removing CHANGES.txt
Date Fri, 05 Feb 2016 10:04:30 GMT
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