Mailing-List: contact dev-help@falcon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@falcon.apache.org
Message-ID: <BLU179-W78C229B8B600A5D4D552A3A4C40@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_1c94e9ed-5dc1-4882-b9be-2beed8b32bb6_"
From: Srikanth Sundarrajan <sriksun@hotmail.com>
To: "dev@falcon.apache.org" <dev@falcon.apache.org>
Subject: RE: [DISCUSS] Removing CHANGES.txt
Date: Fri, 22 Jan 2016 10:07:40 +0530
Importance: Normal
In-Reply-To: 
 <CAKCPnS46z1bam=SkiUzgst-e4jfOv+vKQSHKo1iH4mJPPnHB7w@mail.gmail.com>
References: 
 <CAKCPnS7eW=wW5n5q1cYnJffy-Nz5KzTsKL02kNucE4M2yd1ozg@mail.gmail.com>,<CAFfn_RrSS5AWCZ2f4qybxc1ongAexSetyp0x4uoW3CcaHS1AbA@mail.gmail.com>,<D2C51AFA.64624%suresh@hortonworks.com>
 <CA+4xyzmWA2yAMTZwk2ODnc0MiYRXW=jkt+feO2MGVQWAGyw_EA@mail.gmail.com>,<CA+4xyznmOV3YPABw0Gcm4ixg6eHWCcHk80vAjCFKUWEn14OL0g@mail.gmail.com>,<CAFfn_RqfyTup7_9DarhVMOgB_G2YwAB_tqjaMDGyfNA=9Lo0WA@mail.gmail.com>,<CA+4xyz=S2CNfzS-DyhVykCD1YzpYYAyeD41FBMQ0MBQdGR2BOg@mail.gmail.com>
 <CAJsPzfz8b73_ZOvx4AKtDJKzY6aruM2B7P9nfdWrwaw6dR3m-A@mail.gmail.com>,<CAKCPnS46z1bam=SkiUzgst-e4jfOv+vKQSHKo1iH4mJPPnHB7w@mail.gmail.com>
MIME-Version: 1.0

--_1c94e9ed-5dc1-4882-b9be-2beed8b32bb6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

There are three main reasons for maintaining the changes.txt in my view=20

1. Attribution of contribution to original owners
2. Live document listing changes by category (bug type) for developers' con=
venience
3. A change log to refer to for someone who downloads binary/source release=
s contained the tar ball.

@Ajay=2C It might be very helpful to call these out specifically.

Regards
Srikanth Sundarrajan

> From: ajaynsit@gmail.com
> Date: Thu=2C 21 Jan 2016 13:24:21 +0530
> Subject: Re: [DISCUSS] Removing CHANGES.txt
> To: dev@falcon.apache.org
>=20
> Thanks for your input Pavan=2C it is helpful to hear how everyone is usin=
g
> CHANGES.txt and that is the whole purpose of this discussion. For checkin=
g
> what all changes went after a JIRA=2C using git log is a better option. F=
or
> 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 a=
re
> trusting that CHANGES.txt entries were always made in correct place on th=
e
> 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.
>=20
> The whole idea is to automate the process=2C make it less error prone and=
 at
> the same time make change log available in better and more accurate forma=
t.
> If hadoop script / workflow solves it then I am very happy to discuss tha=
t
> 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 t=
he
> 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.
>=20
> If anyone has other use cases of CHANGES.txt file or any
> opinions/suggestions then please chime in. Later=2C I will send a summary=
 of
> the discussion with all the use cases and a proposal to solve all the pai=
n
> points which we can discuss further.
>=20
> *P.S.* We may be really used to the CHANGES.txt file but several apache
> projects don't maintain CHANGES.txt e.g. SPARK=2C Flink
>=20
> Cheers
> Ajay Yadava
>=20
> On Thu=2C Jan 21=2C 2016 at 10:50 AM=2C pavan kumar Kolamuri <
> pavan.kolamuri@gmail.com> wrote:
>=20
> > Not only for release notes if you just want to look what all patches we=
nt
> > after certain patch=2C it will be easy for anyone to just look into
> > changes.txt and get it. Like suresh suggested we should think of writin=
g
> > script for generating changes.txt=2C that is good option.
> >
> > On Thu=2C Jan 21=2C 2016 at 8:42 AM=2C Ajay Yadav <ajay.yadav@inmobi.co=
m> wrote:
> >
> > > Venkatesh=2C
> > >
> > > I never said to point users to JIRA=2C I just said that information i=
s
> > > available from JIRA and we don't need to maintain it in CHANGES.txt a=
lso.
> > > We can extract from JIRA and put release notes and change log  wherev=
er
> > 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 witho=
ut
> > > 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 th=
e
> > > branch with just 2 commands and no conflicts.
> > >
> > >
> > > Cheers
> > > Ajay Yadava
> > >
> > > On Thu=2C Jan 21=2C 2016 at 2:32 AM=2C Seetharam Venkatesh <
> > > venkatesh@innerzeal.com> wrote:
> > >
> > > > Ajay=2C I have made 3 releases on Apache Falcon and one in Apache A=
tlas
> > > and I
> > > > beg to differ from your opinion.
> > > >
> > > > Pointing users to use Jira or Git for looking at release notes is b=
ad
> > and
> > > > it immensely helps users to just glance at the text file to parse w=
hat
> > > has
> > > > gone into trunk.
> > > >
> > > > On Wed=2C Jan 20=2C 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 maintai=
ning
> > > > > CHANGES.txt file in the code.
> > > > >
> > > > > For example we can generate change log from JIRA(it provides rele=
ase
> > > > notes
> > > > > for a particular release) and put it on website along with releas=
e
> > > notes.
> > > > > We can also consider the Hadoop method if it doesn't involve extr=
a
> > > manual
> > > > > work for committers along with each commit.
> > > > >
> > > > >
> > > > > Cheers
> > > > > Ajay Yadava
> > > > >
> > > > > On Thu=2C Jan 21=2C 2016 at 12:58 AM=2C Ajay Yadav <ajay.yadav@in=
mobi.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 usin=
g
> > > 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 almo=
st
> > > > always
> > > > > > running in two branches and it becomes very painful to maintain=
 the
> > > > > change
> > > > > > log in this fashion.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Cheers
> > > > > > Ajay Yadava
> > > > > >
> > > > > > On Thu=2C Jan 21=2C 2016 at 12:38 AM=2C 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 sho=
uld
> > > not
> > > > be
> > > > > >> deleted.
> > > > > >>
> > > > > >> On 1/20/16=2C 10:55 AM=2C "Seetharam Venkatesh" <
> > > venkatesh@innerzeal.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> >I think this is quite useful and AFAICT=2C the release timeli=
nes
> > are
> > > > > >> >quarterly=2C it might be worth the extra effort to maintain t=
his.
> > > > > >> >
> > > > > >> >-1 from me.
> > > > > >> >
> > > > > >> >On Wed=2C Jan 20=2C 2016 at 10:52 AM Ajay Yadava <
> > > ajayyadava@apache.org>
> > > > > >> >wrote:
> > > > > >> >
> > > > > >> >> Currently we are maintaining CHANGES.txt to record
> > contributions=2C
> > > > > >> >>  committers of the commits and the release in which they go=
t
> > > > > committed.
> > > > > >> >>All
> > > > > >> >> this information is also available in JIRA and git.
> > > > > >> >>
> > > > > >> >> However=2C there are certain disadvantages of CHANGES.txt=
=2C 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 relea=
se
> > > > > version"
> > > > > >> >>and
> > > > > >> >> "Released version" etc. This also creates confusion when sa=
me
> > > > commit
> > > > > >> >>gets
> > > > > >> >> committed into master and the branch.
> > > > > >> >>
> > > > > >> >> Also=2C it entails committers to do some edits to the patch
> > > submitted
> > > > > by
> > > > > >> >>the
> > > > > >> >> contributor. This is error prone and can be tedious sometim=
es.
> > > > > >> >>Sometimes we
> > > > > >> >> forget to attribute contribution or spell contributor's nam=
e
> > > > > >> >>incorrectly.
> > > > > >> >>
> > > > > >> >> Hence I propose to delete CHANGES.txt from master (0.10
> > onward).
> > > > > Please
> > > > > >> >> provide your inputs. If everyone agrees=2C then I will crea=
te a
> > > JIRA
> > > > > and
> > > > > >> >> delete CHANGES.txt from master.
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> Cheers
> > > > > >> >> Ajay Yadava
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > > --
> > > > > _____________________________________________________________
> > > > > The information contained in this communication is intended solel=
y
> > for
> > > > the
> > > > > use of the individual or entity to whom it is addressed and other=
s
> > > > > 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=2C copying=2C distribution or taking any acti=
on in
> > > > reliance
> > > > > on the contents of this information is strictly prohibited and ma=
y be
> > > > > unlawful. If you have received this communication in error=2C ple=
ase
> > > notify
> > > > > us immediately by responding to this email and then delete it fro=
m
> > your
> > > > > system. The firm is neither liable for the proper and complete
> > > > transmission
> > > > > of the information contained in this communication nor for any de=
lay
> > in
> > > > its
> > > > > receipt.
> > > > >
> > > >
> > >
> > > --
> > > _____________________________________________________________
> > > The information contained in this communication is intended solely fo=
r
> > 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=2C copying=2C distribution or taking any action i=
n
> > reliance
> > > on the contents of this information is strictly prohibited and may be
> > > unlawful. If you have received this communication in error=2C please =
notify
> > > us immediately by responding to this email and then delete it from yo=
ur
> > > 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
> >
 		 	   		  =

--_1c94e9ed-5dc1-4882-b9be-2beed8b32bb6_--