falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajay Yadav <ajayn...@gmail.com>
Subject Re: [DISCUSS] Removing CHANGES.txt
Date Sat, 23 Jan 2016 05:26:36 GMT
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 <
vranganathan@hortonworks.com> 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" <venkatesh@innerzeal.com>
> 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 <sriksun@hotmail.com
> >
> >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: ajaynsit@gmail.com
> >> > Date: Thu, 21 Jan 2016 13:24:21 +0530
> >> > Subject: Re: [DISCUSS] Removing CHANGES.txt
> >> > To: dev@falcon.apache.org
> >> >
> >> > 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 <
> >> > pavan.kolamuri@gmail.com> 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 <ajay.yadav@inmobi.com>
> >> 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 <
> >> > > > 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.
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Regards
> >> > > Pavan Kumar Kolamuri
> >> > >
> >>
>

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