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 Wed, 20 Jan 2016 19:37:54 GMT
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.

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