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