falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srikanth Sundarrajan <srik...@hotmail.com>
Subject RE: [DISCUSS] Removing CHANGES.txt
Date Fri, 22 Jan 2016 04:37:40 GMT
There are three main reasons for maintaining the changes.txt in my view 

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

@Ajay, It might be very helpful to call these out specifically.

Regards
Srikanth Sundarrajan

> From: ajaynsit@gmail.com
> Date: Thu, 21 Jan 2016 13:24:21 +0530
> Subject: Re: [DISCUSS] Removing CHANGES.txt
> To: dev@falcon.apache.org
> 
> Thanks for your input Pavan, it is helpful to hear how everyone is using
> CHANGES.txt and that is the whole purpose of this discussion. For checking
> what all changes went after a JIRA, using git log is a better option. For
> example using CHANGES.txt you can not determine what all *features* or
> *improvements* went after this *bug fix *because there is no relative
> ordering between different types of JIRA in CHANGES.txt*.* Secondly you are
> trusting that CHANGES.txt entries were always made in correct place on the
> top. Being an active committer I can tell you this is not true and often
> during resolving conflicts etc. things get shuffled around. Also it is a
> common error to put a 0.9 change in trunk while committing to master.
> 
> The whole idea is to automate the process, make it less error prone and at
> the same time make change log available in better and more accurate format.
> If hadoop script / workflow solves it then I am very happy to discuss that
> approach as well. If someone has a use case which can be solved only by
> this workflow then I am happy to discuss how we can solve without
> sacrificing those use cases but I request all of you to be cognizant of the
> fact that as one of the most active contributors I am feeling the pain in
> this approach and we need a better solution. I am open to listening to
> better ideas to solve these problems.
> 
> If anyone has other use cases of CHANGES.txt file or any
> opinions/suggestions then please chime in. Later, I will send a summary of
> the discussion with all the use cases and a proposal to solve all the pain
> points which we can discuss further.
> 
> *P.S.* We may be really used to the CHANGES.txt file but several apache
> projects don't maintain CHANGES.txt e.g. SPARK, Flink
> 
> Cheers
> Ajay Yadava
> 
> On Thu, Jan 21, 2016 at 10:50 AM, pavan kumar Kolamuri <
> pavan.kolamuri@gmail.com> wrote:
> 
> > Not only for release notes if you just want to look what all patches went
> > after certain patch, it will be easy for anyone to just look into
> > changes.txt and get it. Like suresh suggested we should think of writing
> > script for generating changes.txt, that is good option.
> >
> > On Thu, Jan 21, 2016 at 8:42 AM, Ajay Yadav <ajay.yadav@inmobi.com> wrote:
> >
> > > Venkatesh,
> > >
> > > I never said to point users to JIRA, I just said that information is
> > > available from JIRA and we don't need to maintain it in CHANGES.txt also.
> > > We can extract from JIRA and put release notes and change log  wherever
> > we
> > > want e.g. then we can choose to put it on site and putting on site is
> > much
> > > better than putting it in the code with no pointers to users on where to
> > > see the change log.
> > >
> > > I am sure even you will agree that if we can get the change log without
> > > having to update CHANGES.txt with every commit then it will be very
> > helpful
> > > for committers. We can just apply the same patch on the master and the
> > > branch with just 2 commands and no conflicts.
> > >
> > >
> > > Cheers
> > > Ajay Yadava
> > >
> > > On Thu, Jan 21, 2016 at 2:32 AM, Seetharam Venkatesh <
> > > venkatesh@innerzeal.com> wrote:
> > >
> > > > Ajay, I have made 3 releases on Apache Falcon and one in Apache Atlas
> > > and I
> > > > beg to differ from your opinion.
> > > >
> > > > Pointing users to use Jira or Git for looking at release notes is bad
> > and
> > > > it immensely helps users to just glance at the text file to parse what
> > > has
> > > > gone into trunk.
> > > >
> > > > On Wed, Jan 20, 2016 at 11:38 AM Ajay Yadav <ajay.yadav@inmobi.com>
> > > wrote:
> > > >
> > > > > Just to clarify I am not suggesting to not provide change log to
> > > users. I
> > > > > am just suggesting to get rid of the practice of manually maintaining
> > > > > CHANGES.txt file in the code.
> > > > >
> > > > > For example we can generate change log from JIRA(it provides release
> > > > notes
> > > > > for a particular release) and put it on website along with release
> > > notes.
> > > > > We can also consider the Hadoop method if it doesn't involve extra
> > > manual
> > > > > work for committers along with each commit.
> > > > >
> > > > >
> > > > > Cheers
> > > > > Ajay Yadava
> > > > >
> > > > > On Thu, Jan 21, 2016 at 12:58 AM, Ajay Yadav <ajay.yadav@inmobi.com>
> > > > > wrote:
> > > > >
> > > > > > As I said Idea is to delete CHANGES.txt as the same information
can
> > > be
> > > > > > extracted from JIRA. We can provide change log information using
> > > JIRA.
> > > > > >
> > > > > > Maintaining CHANGES.txt file is a huge pain for the people who
have
> > > to
> > > > > > commit patches. It is also very error prone way of maintaining
> > change
> > > > > log.
> > > > > > We have a 6 weekly release cycle so that means that we are almost
> > > > always
> > > > > > running in two branches and it becomes very painful to maintain
the
> > > > > change
> > > > > > log in this fashion.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Cheers
> > > > > > Ajay Yadava
> > > > > >
> > > > > > On Thu, Jan 21, 2016 at 12:38 AM, Suresh Srinivas <
> > > > > suresh@hortonworks.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Hadoop has a script to generate CHANGES.txt. That might
be an
> > > option.
> > > > > >>
> > > > > >> Agree with Venkatesh. This is an important information and
should
> > > not
> > > > be
> > > > > >> deleted.
> > > > > >>
> > > > > >> On 1/20/16, 10:55 AM, "Seetharam Venkatesh" <
> > > venkatesh@innerzeal.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> >I think this is quite useful and AFAICT, the release
timelines
> > are
> > > > > >> >quarterly, it might be worth the extra effort to maintain
this.
> > > > > >> >
> > > > > >> >-1 from me.
> > > > > >> >
> > > > > >> >On Wed, Jan 20, 2016 at 10:52 AM Ajay Yadava <
> > > ajayyadava@apache.org>
> > > > > >> >wrote:
> > > > > >> >
> > > > > >> >> Currently we are maintaining CHANGES.txt to record
> > contributions,
> > > > > >> >>  committers of the commits and the release in which
they got
> > > > > committed.
> > > > > >> >>All
> > > > > >> >> this information is also available in JIRA and
git.
> > > > > >> >>
> > > > > >> >> However, there are certain disadvantages of CHANGES.txt,
every
> > > time
> > > > > >> >>during
> > > > > >> >> release we have to maintain different CHANGES.txt
in master and
> > > > > branch.
> > > > > >> >>We
> > > > > >> >> have to be careful with subtle details like "Proposed
release
> > > > > version"
> > > > > >> >>and
> > > > > >> >> "Released version" etc. This also creates confusion
when same
> > > > commit
> > > > > >> >>gets
> > > > > >> >> committed into master and the branch.
> > > > > >> >>
> > > > > >> >> Also, it entails committers to do some edits to
the patch
> > > submitted
> > > > > by
> > > > > >> >>the
> > > > > >> >> contributor. This is error prone and can be tedious
sometimes.
> > > > > >> >>Sometimes we
> > > > > >> >> forget to attribute contribution or spell contributor's
name
> > > > > >> >>incorrectly.
> > > > > >> >>
> > > > > >> >> Hence I propose to delete CHANGES.txt from master
(0.10
> > onward).
> > > > > Please
> > > > > >> >> provide your inputs. If everyone agrees, then I
will create a
> > > JIRA
> > > > > and
> > > > > >> >> delete CHANGES.txt from master.
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> Cheers
> > > > > >> >> Ajay Yadava
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > > --
> > > > > _____________________________________________________________
> > > > > The information contained in this communication is intended solely
> > for
> > > > the
> > > > > use of the individual or entity to whom it is addressed and others
> > > > > authorized to receive it. It may contain confidential or legally
> > > > privileged
> > > > > information. If you are not the intended recipient you are hereby
> > > > notified
> > > > > that any disclosure, copying, distribution or taking any action in
> > > > reliance
> > > > > on the contents of this information is strictly prohibited and may
be
> > > > > unlawful. If you have received this communication in error, please
> > > notify
> > > > > us immediately by responding to this email and then delete it from
> > your
> > > > > system. The firm is neither liable for the proper and complete
> > > > transmission
> > > > > of the information contained in this communication nor for any delay
> > in
> > > > its
> > > > > receipt.
> > > > >
> > > >
> > >
> > > --
> > > _____________________________________________________________
> > > The information contained in this communication is intended solely for
> > the
> > > use of the individual or entity to whom it is addressed and others
> > > authorized to receive it. It may contain confidential or legally
> > privileged
> > > information. If you are not the intended recipient you are hereby
> > notified
> > > that any disclosure, copying, distribution or taking any action in
> > reliance
> > > on the contents of this information is strictly prohibited and may be
> > > unlawful. If you have received this communication in error, please notify
> > > us immediately by responding to this email and then delete it from your
> > > system. The firm is neither liable for the proper and complete
> > transmission
> > > of the information contained in this communication nor for any delay in
> > its
> > > receipt.
> > >
> >
> >
> >
> > --
> > Regards
> > Pavan Kumar Kolamuri
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message