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 > > > >
