falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajay Yadav <ajay.ya...@inmobi.com>
Subject Re: [DISCUSS] Removing CHANGES.txt
Date Thu, 21 Jan 2016 03:12:19 GMT
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.

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