Ok, the title of this thread is slightly ambiguous. I clarified it before but once again, just to bring everyone on same page, no one is recommending to stop keeping changelog. I think everyone is suggesting that we should not be maintaining CHANGES.txt manually.
I haven't yet done anything on this, so if anyone has bandwidth then please feel free to pick it up. I liked Suresh's suggestion of generating CHANGES.txt hadoop style, so we should be able to borrow heavily from hadoop's tools/scripts. On Fri, Feb 5, 2016 at 3:34 PM, Pallavi Rao <[email protected]> wrote: > 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 < > [email protected]> > wrote: > > > +1 we should remove CHANGES.txt. > > > > On Fri, Feb 5, 2016 at 3:01 PM, Deepak Kumar Barr (Tech_BLR) < > > [email protected]> wrote: > > > > > I agree. +1 > > > > > > Regards, > > > Deepak Kumar Barr > > > Bigfoot-Apps > > > > > > On Fri, Feb 5, 2016 at 2:59 PM, Sandeep Samudrala <[email protected] > > > > > 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 <[email protected]> > > 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 < > > > > > [email protected]> 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" < > > [email protected] > > > > > > > > > > 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 < > > > > > [email protected] > > > > > > > > > > > > > >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: [email protected] > > > > > > >> > Date: Thu, 21 Jan 2016 13:24:21 +0530 > > > > > > >> > Subject: Re: [DISCUSS] Removing CHANGES.txt > > > > > > >> > To: [email protected] > > > > > > >> > > > > > > > >> > 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 < > > > > > > >> > [email protected]> 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 < > > > > > [email protected]> > > > > > > >> 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 < > > > > > > >> > > > [email protected]> 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 < > > > > > > [email protected] > > > > > > >> > > > > > > > >> > > > 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 < > > > > > > >> [email protected]> > > > > > > >> > > > > > 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 > < > > > > > > >> > > > > > [email protected]> > > > > > > >> > > > > > > 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" < > > > > > > >> > > > [email protected]> > > > > > > >> > > > > > >> 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 < > > > > > > >> > > > [email protected]> > > > > > > >> > > > > > >> >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. >
