You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by Jungtaek Lim <ka...@gmail.com> on 2017/08/01 21:41:09 UTC
Re: [DISCUSS] Remove CHANGELOG file
Forgot to say, +1 on Stig's explanation. I don't see critical issue from
locating release note (previously CHANGELOG) file.
After releasing, release note on website will also have static
representation (string content) of CHANGELOG so we will provide CHANGELOG
at least two places.
I'll bring several pull requests on removing CHANGELOG.md at all active
version lines soon. I also feel we all agree to do it, but just to leave a
history. I'll also modify DEVELOPER.md to remove 4. of "Merge a pull
request or patch" on pull requests.
2017년 8월 1일 (화) 오전 7:02, Jungtaek Lim <ka...@gmail.com>님이 작성:
> I'm seeing several voices worrying about JIRA update.
>
> I think the main reason to miss to update is that we're doing it manually.
> If you remember the PR about adopting Kafka merge script, it also updates
> corresponding JIRA issue at the end of merge. If you're not aware of,
> please refer https://github.com/apache/storm/pull/1468 to see long
> explanation and discussion.
>
> Our main concern to adopt Spark/Kafka merge script was squashing commits
> (and also no merge commit, maybe), while I still personally see the huge
> benefit (commit list itself becomes CHANGELOG) and I see some others fan of
> squashed commit, but we still modify the script to do the merge commit like
> what we're doing. That's what we can discuss and decide, not the blocker
> for merge script I think.
>
> Let's suppose we get rid of commit for updating CHANGELOG, and we still
> rely on merge commit. Could we determine which JIRA issue is addressed only
> from merge commit's commit title? Yes or no, depending on how contributor
> names their branch, and we can't force that (and forcing even their branch
> is going to be really annoying). So commit title of the merge commit should
> be conform to the formal format (say, contains JIRA title or so), or just
> leave squashed commit. Refining the title of merge commit manually will be
> going to another pain for merger, so should be automated as well.
>
> tl;dr. This is the time to reconsider merge script, maybe modify
> Spark/Kafka merge script to conform to Storm project. This helps squashing
> commits (only if we decide to go on), or set informative title to the merge
> commit if we reside on merge commit. This also helps on resolving
> corresponding JIRA issue as well.
>
> Thanks,
> Jungtaek Lim (HeartSaVioR)
>
> 2017년 8월 1일 (화) 오전 5:48, Stig Rohde Døssing <st...@gmail.com>님이 작성:
>
>> Would it fit alongside the other release artifacts in e.g.
>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.1.1-rc2/?
>> That
>> seems to be what Kafka is doing as well
>> https://dist.apache.org/repos/dist/release/kafka/0.11.0.0/.
>>
>> If we could put the change log up along the other artifacts, we could
>> probably get away with not having it included in the src/bin
>> distributions,
>> because people could get the change log from the same mirrors they got the
>> distributions from.
>>
>> 2017-07-31 22:37 GMT+02:00 P. Taylor Goetz <pt...@gmail.com>:
>>
>> > A couple thoughts/questions regarding the mechanics of publishing the
>> > resulting HTML file.
>> >
>> > When voting on release candidates, in the past we point to the CHANGELOG
>> > file in git. What would we do in this case?
>> >
>> > My assumption is the release manager would generate the file and post it
>> > to their account on people.apache.org. After a successful vote, the
>> > change log would be published to the storm.a.o website, presumably in a
>> > /changelogs/${version}.html file.
>> >
>> > One could argue we could simply link to a JIRA filter for that release,
>> > but I don’t like the idea of linking to something inherently mutable as
>> a
>> > release artifact.
>> >
>> > Would we include the file in the source and/or binary distributions? If
>> > so, where, and what would be the process?
>> >
>> > I’m interested in hearing others’ thoughts.
>> >
>> > -Taylor
>> >
>> >
>> > > On Jul 31, 2017, at 3:50 PM, Stig Rohde Døssing <
>> stigdoessing@gmail.com>
>> > wrote:
>> > >
>> > > Opened JIRA here https://issues.apache.org/jira/browse/STORM-2665 and
>> > took
>> > > a look at adjusting Kafka's script here
>> > > https://github.com/apache/storm/pull/2250
>> > >
>> > > 2017-07-31 21:02 GMT+02:00 Bobby Evans <ev...@yahoo-inc.com.invalid>:
>> > >
>> > >> So it looks like we all agree, now we just need someone to file a
>> JIRA
>> > and
>> > >> a corresponding pull request. The kafka script looks like a good
>> place
>> > to
>> > >> start, but we can iterate on it in the pull request to try and
>> address
>> > >> Taylor's concern about JIRA not being up to date. I would love to do
>> > it,
>> > >> but I am really overloaded right now so if someone else wants to take
>> > lead
>> > >> on it that would be great.
>> > >>
>> > >>
>> > >> - Bobby
>> > >>
>> > >>
>> > >> On Monday, July 31, 2017, 1:45:14 PM CDT, P. Taylor Goetz <
>> > >> ptgoetz@gmail.com> wrote:
>> > >>
>> > >> I’m all for getting rid of the current process for CHANGELOG. My only
>> > >> concern with any JIRA-based solution is that we would need to be very
>> > good
>> > >> about setting the “Fix Version” field properly when merging a patch
>> and
>> > >> updating the associated ticket. In the past I’ve seen a lot of
>> patches
>> > >> merged without the associated JIRA updated. If we’re going to rely on
>> > JIRA
>> > >> as the source of truth for change logs, we need to be very
>> conscientious
>> > >> about updating JIRA as necessary.
>> > >>
>> > >> -Taylor
>> > >>
>> > >>> On Jul 31, 2017, at 10:06 AM, Bobby Evans
>> <evans@yahoo-inc.com.INVALID
>> > >
>> > >> wrote:
>> > >>>
>> > >>> I am happy to switch as soon as someone has a working alternative.
>> The
>> > >> big thing in my opinion is giving end users a clear list of all of
>> the
>> > >> changes that went into a release so they can review it for
>> themselves.
>> > >> However we do it is fine with me as the current changelog file
>> leaves a
>> > lot
>> > >> to be desired. I personally would be fine with us updating the web
>> > >> page/release notes to have a link to a JIRA query in it as a starting
>> > point.
>> > >>>
>> > >>> https://issues.apache.org/jira/issues/?jql=project%20%
>> > >> 3D%20STORM%20AND%20fixVersion%20in%20(1.0.4)%20ORDER%20BY%
>> > >> 20priority%20DESC
>> > >>> or
>> > >>> https://issues.apache.org/jira/issues/?jql=project%20%
>> > >> 3D%20STORM%20AND%20fixVersion%20in%20(1.1.1)%20ORDER%20BY%
>> > >> 20priority%20DESC
>> > >>> for example.
>> > >>> Later on we can start looking at more complex alternatives that run
>> the
>> > >> above query and join it with the git revision history and possibly
>> pull
>> > >> requests to give a more complete view for what has happened.
>> > >>>
>> > >>> - Bobby
>> > >>>
>> > >>>
>> > >>> On Monday, July 31, 2017, 1:42:11 AM CDT, Jungtaek Lim <
>> > >> kabhwan@gmail.com> wrote:
>> > >>>
>> > >>> Let me also put long ago discussion about this:
>> > >>>
>> > >>> http://search-hadoop.com/m/Storm/8gnYyUdhVp1eajp31?subj=+
>> > >> DISCUSSION+More+convenient+way+to+maintain+committer+
>> > contributor+list+and+
>> > >> changelogs
>> > >>>
>> > >>>
>> > >>> In my view, from long ago discussion, Haohui and Bobby agreed to not
>> > >>> maintain CHANGELOG by hand. Haohui also suggested how to get them
>> > >>> automatically, whereas I just would want to remove it, but that's
>> also
>> > >> OK)
>> > >>> We didn’t get agreement clearly about removing CHANGELOG but at
>> least
>> > saw
>> > >>> our needs to automate it.
>> > >>>
>> > >>>
>> > >>> And in current discussion, again in my view, Roshan, Hugo, Stig
>> agree
>> > to
>> > >>> remove CHANGELOG. I’ve been continuously claiming to remove
>> CHANGELOG,
>> > >> so 3
>> > >>> PMC members and 1 contributor seem to agree on removing CHANGELOG,
>> and
>> > at
>> > >>> least 2 more PMC members to not maintain CHANGELOG manually.
>> > >>>
>> > >>>
>> > >>> I will initiate a VOTE thread if we need to. Again, release managers
>> > >> would
>> > >>> be affected by this change so I would want to hear Taylor’s opinion
>> > >> before
>> > >>> going forward, but this is clear pain point for mergers so will
>> > initiate
>> > >> a
>> > >>> VOTE thread in several days (at least in this week) if Taylor
>> doesn’t
>> > put
>> > >>> opinion on this or misses this discussion.
>> > >>>
>> > >>>
>> > >>> Thanks,
>> > >>>
>> > >>> Jungtaek Lim (HeartSaVioR)
>> > >>>
>> > >>> 2017년 7월 28일 (금) 오전 10:53, Jungtaek Lim <ka...@gmail.com>님이 작성:
>> > >>>
>> > >>>> correction: other projects -> *some* other projects, though they're
>> > >>>> popular projects (including in competition)
>> > >>>>
>> > >>>> 2017년 7월 28일 (금) 오전 10:51, Jungtaek Lim <ka...@gmail.com>님이 작성:
>> > >>>>
>> > >>>>> I'm happy that there're other guys having same difficult and
>> sharing
>> > >> same
>> > >>>>> feeling.
>> > >>>>>
>> > >>>>> This discussion has been initiating several times (from me) and
>> > getting
>> > >>>>> some +1s for each thread but didn't reach to actual work.
>> > >>>>>
>> > >>>>> We already utilize JIRA, and I'm subscribing issues@ and taking
>> care
>> > >> of
>> > >>>>> issues forgot to mark resolve and/or labeling fixed versions.
>> > >>>>> It may sounds ideal for us to let reporters caring about their
>> > issues,
>> > >>>>> but committers can also help that, and in fact merger is in
>> > >> responsible to
>> > >>>>> take care of resolving the issue, so irrelevant to contributor for
>> > this
>> > >>>>> side.
>> > >>>>>
>> > >>>>> My other consideration is that which thing is convenient for
>> release
>> > >>>>> manager. Taylor took the release manager all the time (thanks for
>> the
>> > >> great
>> > >>>>> work!) and it is directly related to release announcement so would
>> > >> like to
>> > >>>>> hear his opinion. If it is more convenient or he think he can
>> > tolerate
>> > >>>>> that, we can just go on.
>> > >>>>>
>> > >>>>> Please note that other projects don't use merge commit. Most of
>> the
>> > >> time
>> > >>>>> they squash commits in PR into one, labeling commit title as JIRA
>> > >> issue,
>> > >>>>> making commit list just as CHANGELOG. That's another thing we
>> > discussed
>> > >>>>> earlier and I think we need to discuss again, but that can be
>> > discussed
>> > >>>>> from another thread.
>> > >>>>>
>> > >>>>> Regarding maintaining contributors: easy to explain. Just take a
>> look
>> > >> at
>> > >>>>> what Spark has been doing. Some other projects follow the
>> approach as
>> > >> well.
>> > >>>>>
>> > >>>>> We can run the script to extract authors of git commits, and just
>> " |
>> > >>>>> sort | uniq", and done. Pulling assigner from JIRA issue may be
>> more
>> > >>>>> accurate, since it requires actual account whereas author
>> information
>> > >> in
>> > >>>>> commit is not strictly required to identify them. We can apply
>> hybrid
>> > >>>>> approach as well, but for starter just following git commits
>> looks OK
>> > >> to me.
>> > >>>>>
>> > >>>>> IMHO they don't feel proud strongly only they're listed in
>> > >> contributors.
>> > >>>>> Looking at contribution graph works better in this case, given
>> that
>> > it
>> > >> also
>> > >>>>> shows commit count and lines of change. (regardless of accuracy)
>> > >>>>> It may give more proud to mention them as release announce. It
>> will
>> > >> lead
>> > >>>>> contributors to play consistently, trying to participate and be
>> > >> mentioned
>> > >>>>> for releases as many as possible. IMO Spark built a great strategy
>> > for
>> > >> this
>> > >>>>> side, and if we all think it is great, why not follow?
>> > >>>>>
>> > >>>>> Thanks,
>> > >>>>> Jungtaek Lim (HeartSaVioR)
>> > >>>>>
>> > >>>>> 2017년 7월 28일 (금) 오전 6:58, Stig Rohde Døssing <
>> stigdoessing@gmail.com
>> > >>> 님이
>> > >>>>> 작성:
>> > >>>>>
>> > >>>>>> We already have to keep JIRA updated, and keeping JIRA
>> consistent is
>> > >>>>>> easier
>> > >>>>>> since there isn't one view of the resolved issues for each git
>> > branch
>> > >>>>>> like
>> > >>>>>> we have with CHANGELOG, so there's no worry about e.g. master
>> > having a
>> > >>>>>> different opinion on solved issues in 1.2.0 than 1.x-branch has.
>> > >>>>>>
>> > >>>>>> I think we already have the guideline that only small (e.g. typo)
>> > >> changes
>> > >>>>>> are okay without a JIRA issue. We're already encouraging one
>> commit
>> > >> per
>> > >>>>>> issue, most of the PRs I've seen recently have been squashing
>> before
>> > >>>>>> merge.
>> > >>>>>> Is this not your experience?
>> > >>>>>>
>> > >>>>>> I think we have the contributors/committers lists on SVN as well
>> for
>> > >>>>>> generating http://storm.apache.org/contribute/People.html at
>> > >>>>>> https://svn.apache.org/repos/asf/storm/site/_data/. I think
>> > Jungtaek
>> > >> was
>> > >>>>>> suggesting keeping the committers list, and generating the
>> > >> contributors
>> > >>>>>> list for each release by either commit authors or JIRA assignees,
>> > but
>> > >> he
>> > >>>>>> can probably elaborate better.
>> > >>>>>>
>> > >>>>>> 2017-07-27 23:06 GMT+02:00 Hugo Da Cruz Louro <
>> > hlouro@hortonworks.com
>> > >>> :
>> > >>>>>>
>> > >>>>>>> I am +1 for discontinuing CHANGELOG. However, using JIRA to
>> compile
>> > >>>>>> this
>> > >>>>>>> info will only work if contributors are very disciplined and
>> > >> consistent
>> > >>>>>>> updating JIRA. That leads to the question, is it any easier to
>> > >> maintain
>> > >>>>>>> JIRA consistent then it is to keep CHANGELOG consistent? A clean
>> > and
>> > >>>>>>> consistent JIRA is ideal, as it will also make it easy to create
>> > >>>>>> reports
>> > >>>>>>> for individual components, etc.
>> > >>>>>>>
>> > >>>>>>> This discussion touches a proposal I suggested awhile ago, that
>> > Storm
>> > >>>>>>> community should have a more strict and consistent Git log
>> > guideline.
>> > >>>>>> In
>> > >>>>>>> short, besides very trivial changes, like typos, or one or two
>> line
>> > >>>>>>> changes, every feature or bug should be associated with a JIRA.
>> > >>>>>>> Furthermore, one commit should correspond to one JIRA, and one
>> JIRA
>> > >>>>>> should
>> > >>>>>>> be solved by one commit. That means, we should focus on assuring
>> > that
>> > >>>>>>> commits are squashed, and their titles really reflect the issue
>> > they
>> > >>>>>>> address, etc.
>> > >>>>>>>
>> > >>>>>>> Af for the contributors and committers list. If we remove those
>> > >> lists,
>> > >>>>>>> where will this information be kept ?
>> > >>>>>>>
>> > >>>>>>> Hugo
>> > >>>>>>>
>> > >>>>>>>> On Jul 27, 2017, at 1:44 PM, Stig Rohde Døssing <
>> > >>>>>> stigdoessing@gmail.com>
>> > >>>>>>> wrote:
>> > >>>>>>>>
>> > >>>>>>>> Sorry to necro this thread, but I think it's worth bringing
>> this
>> > >>>>>> issue up
>> > >>>>>>>> again. As Jungtaek mentioned a manual changelog is easy to
>> break,
>> > >>>>>> and it
>> > >>>>>>>> looks like some issues are listed wrong on master and missing
>> from
>> > >>>>>> 1.x (
>> > >>>>>>>> https://github.com/apache/storm/pull/2245)
>> > >>>>>>>>
>> > >>>>>>>> I think dropping CHANGELOG is a great idea, and we might use
>> Kafka
>> > >>>>>> as an
>> > >>>>>>>> example for how to do release notes. They have JIRA generate
>> the
>> > >>>>>> notes
>> > >>>>>>> and
>> > >>>>>>>> put them up alongside each release, for instance
>> > >>>>>>>>
>> https://archive.apache.org/dist/kafka/0.11.0.0/RELEASE_NOTES.html
>> > .
>> > >>>>>> It's
>> > >>>>>>> a
>> > >>>>>>>> much nicer overview of changes than what we have in CHANGELOG
>> > where
>> > >>>>>> the
>> > >>>>>>>> issue types are mixed, and a manual changelog is easier to get
>> out
>> > >> of
>> > >>>>>>> sync
>> > >>>>>>>> with JIRA. We could probably configure JIRA to generate
>> something
>> > >>>>>> similar
>> > >>>>>>>> with a template (guide:
>> > >>>>>>>> https://confluence.atlassian.com/adminjiraserver073/
>> > >>>>>>> creating-release-notes-861253367.html
>> > >>>>>>>> ).
>> > >>>>>>>>
>> > >>>>>>>> 2017-03-10 8:31 GMT+01:00 Jungtaek Lim <ka...@gmail.com>:
>> > >>>>>>>>
>> > >>>>>>>>> This propose will make merge process simpler, so I guess
>> > >>>>>> committers/PMCs
>> > >>>>>>>>> might not have strong opinions about this. I'm concerning
>> mainly
>> > >>>>>> about
>> > >>>>>>> how
>> > >>>>>>>>> it will affect release process.
>> > >>>>>>>>>
>> > >>>>>>>>> Taylor, I guess you're busy, but could you give your opinion
>> > about
>> > >>>>>> this
>> > >>>>>>> as
>> > >>>>>>>>> a release manager? Would removing CHANGELOG hurt or break
>> release
>> > >>>>>>> process?
>> > >>>>>>>>>
>> > >>>>>>>>> And do we need to vote to make progress?
>> > >>>>>>>>>
>> > >>>>>>>>> Thanks,
>> > >>>>>>>>> Jungtaek Lim (HeartSaVioR)
>> > >>>>>>>>>
>> > >>>>>>>>> 2017년 3월 10일 (금) 오후 3:08, Xin Wang <da...@gmail.com>님이
>> > 작성:
>> > >>>>>>>>>
>> > >>>>>>>>>> LGTM. I give a +1 for the idea.
>> > >>>>>>>>>>
>> > >>>>>>>>>> 2017-03-07 9:29 GMT+08:00 Jungtaek Lim <ka...@gmail.com>:
>> > >>>>>>>>>>
>> > >>>>>>>>>>> Bump. I think it's not that trivial for code merger and
>> release
>> > >>>>>>>>> manager,
>> > >>>>>>>>>>> and even contributors (how to represent their
>> contributions.)
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> 2017년 2월 24일 (금) 오전 9:43, Roshan Naik <
>> roshan@hortonworks.com
>> > >님이
>> > >>>>>> 작성:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>> Sounds like a good idea to me.
>> > >>>>>>>>>>>> -roshan
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> On 2/23/17, 4:41 PM, "Jungtaek Lim" <ka...@gmail.com>
>> > wrote:
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> Hi devs,
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> I guess we discussed about this before, but didn't move
>> to
>> > >>>>>> actual
>> > >>>>>>>>>>> work.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> I'd like to propose again removing CHANGELOG file in
>> > >>>>>> repository,
>> > >>>>>>>>>> and
>> > >>>>>>>>>>>> use
>> > >>>>>>>>>>>> JIRA issue's fixed version(s).
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> Maintaining CHANGELOG to file is really easy to break.
>> I've
>> > >>>>>> seen
>> > >>>>>>>>>>>> several
>> > >>>>>>>>>>>> times and most of them is about backport. CHANGELOG file
>> > >>>>>> between
>> > >>>>>>>>>>>> branches
>> > >>>>>>>>>>>> are inconsistent.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> Suppose we would like to backport the issue to 1.0.x
>> which
>> > is
>> > >>>>>>>>> only
>> > >>>>>>>>>>>> applied
>> > >>>>>>>>>>>> to 2.0.0, then we should fix CHANGELOG from three
>> branches.
>> > >>>>>> Easy
>> > >>>>>>>>> to
>> > >>>>>>>>>>>> miss
>> > >>>>>>>>>>>> and redundant.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> I'd also like to remove Project leads / Committers /
>> > >>>>>> Contributors
>> > >>>>>>>>>> in
>> > >>>>>>>>>>>> README
>> > >>>>>>>>>>>> (at least Contributors) since it's also easy to break.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> For PMC members we're maintaining it to website and I
>> think
>> > >>>>>>>>> that's
>> > >>>>>>>>>>>> enough.
>> > >>>>>>>>>>>> For contributors I love what other projects are doing:
>> > >> extract
>> > >>>>>>>>>> unique
>> > >>>>>>>>>>>> contributors name from commits or JIRA issues of release
>> > >>>>>> version
>> > >>>>>>>>>> and
>> > >>>>>>>>>>>> mention them from release announce note.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> What do you think?
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> Thanks,
>> > >>>>>>>>>>>> Jungtaek Lim (HeartSaVioR)
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>
>> >
>> >
>>
>
Re: [DISCUSS] Remove CHANGELOG file
Posted by Jungtaek Lim <ka...@gmail.com>.
FYI: Just created PR around master branch:
https://github.com/apache/storm/pull/2253
I'll apply this to other version line branches as well, so please take a
look at this and comment. I'll just apply this in tomorrow if no
outstanding comment is seen.
2017년 8월 2일 (수) 오전 6:41, Jungtaek Lim <ka...@gmail.com>님이 작성:
> Forgot to say, +1 on Stig's explanation. I don't see critical issue from
> locating release note (previously CHANGELOG) file.
> After releasing, release note on website will also have static
> representation (string content) of CHANGELOG so we will provide CHANGELOG
> at least two places.
>
> I'll bring several pull requests on removing CHANGELOG.md at all active
> version lines soon. I also feel we all agree to do it, but just to leave a
> history. I'll also modify DEVELOPER.md to remove 4. of "Merge a pull
> request or patch" on pull requests.
>
> 2017년 8월 1일 (화) 오전 7:02, Jungtaek Lim <ka...@gmail.com>님이 작성:
>
>> I'm seeing several voices worrying about JIRA update.
>>
>> I think the main reason to miss to update is that we're doing it
>> manually. If you remember the PR about adopting Kafka merge script, it also
>> updates corresponding JIRA issue at the end of merge. If you're not aware
>> of, please refer https://github.com/apache/storm/pull/1468 to see long
>> explanation and discussion.
>>
>> Our main concern to adopt Spark/Kafka merge script was squashing commits
>> (and also no merge commit, maybe), while I still personally see the huge
>> benefit (commit list itself becomes CHANGELOG) and I see some others fan of
>> squashed commit, but we still modify the script to do the merge commit like
>> what we're doing. That's what we can discuss and decide, not the blocker
>> for merge script I think.
>>
>> Let's suppose we get rid of commit for updating CHANGELOG, and we still
>> rely on merge commit. Could we determine which JIRA issue is addressed only
>> from merge commit's commit title? Yes or no, depending on how contributor
>> names their branch, and we can't force that (and forcing even their branch
>> is going to be really annoying). So commit title of the merge commit should
>> be conform to the formal format (say, contains JIRA title or so), or just
>> leave squashed commit. Refining the title of merge commit manually will be
>> going to another pain for merger, so should be automated as well.
>>
>> tl;dr. This is the time to reconsider merge script, maybe modify
>> Spark/Kafka merge script to conform to Storm project. This helps squashing
>> commits (only if we decide to go on), or set informative title to the merge
>> commit if we reside on merge commit. This also helps on resolving
>> corresponding JIRA issue as well.
>>
>> Thanks,
>> Jungtaek Lim (HeartSaVioR)
>>
>> 2017년 8월 1일 (화) 오전 5:48, Stig Rohde Døssing <st...@gmail.com>님이
>> 작성:
>>
>>> Would it fit alongside the other release artifacts in e.g.
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.1.1-rc2/?
>>> That
>>> seems to be what Kafka is doing as well
>>> https://dist.apache.org/repos/dist/release/kafka/0.11.0.0/.
>>>
>>> If we could put the change log up along the other artifacts, we could
>>> probably get away with not having it included in the src/bin
>>> distributions,
>>> because people could get the change log from the same mirrors they got
>>> the
>>> distributions from.
>>>
>>> 2017-07-31 22:37 GMT+02:00 P. Taylor Goetz <pt...@gmail.com>:
>>>
>>> > A couple thoughts/questions regarding the mechanics of publishing the
>>> > resulting HTML file.
>>> >
>>> > When voting on release candidates, in the past we point to the
>>> CHANGELOG
>>> > file in git. What would we do in this case?
>>> >
>>> > My assumption is the release manager would generate the file and post
>>> it
>>> > to their account on people.apache.org. After a successful vote, the
>>> > change log would be published to the storm.a.o website, presumably in a
>>> > /changelogs/${version}.html file.
>>> >
>>> > One could argue we could simply link to a JIRA filter for that release,
>>> > but I don’t like the idea of linking to something inherently mutable
>>> as a
>>> > release artifact.
>>> >
>>> > Would we include the file in the source and/or binary distributions? If
>>> > so, where, and what would be the process?
>>> >
>>> > I’m interested in hearing others’ thoughts.
>>> >
>>> > -Taylor
>>> >
>>> >
>>> > > On Jul 31, 2017, at 3:50 PM, Stig Rohde Døssing <
>>> stigdoessing@gmail.com>
>>> > wrote:
>>> > >
>>> > > Opened JIRA here https://issues.apache.org/jira/browse/STORM-2665
>>> and
>>> > took
>>> > > a look at adjusting Kafka's script here
>>> > > https://github.com/apache/storm/pull/2250
>>> > >
>>> > > 2017-07-31 21:02 GMT+02:00 Bobby Evans <evans@yahoo-inc.com.invalid
>>> >:
>>> > >
>>> > >> So it looks like we all agree, now we just need someone to file a
>>> JIRA
>>> > and
>>> > >> a corresponding pull request. The kafka script looks like a good
>>> place
>>> > to
>>> > >> start, but we can iterate on it in the pull request to try and
>>> address
>>> > >> Taylor's concern about JIRA not being up to date. I would love to
>>> do
>>> > it,
>>> > >> but I am really overloaded right now so if someone else wants to
>>> take
>>> > lead
>>> > >> on it that would be great.
>>> > >>
>>> > >>
>>> > >> - Bobby
>>> > >>
>>> > >>
>>> > >> On Monday, July 31, 2017, 1:45:14 PM CDT, P. Taylor Goetz <
>>> > >> ptgoetz@gmail.com> wrote:
>>> > >>
>>> > >> I’m all for getting rid of the current process for CHANGELOG. My
>>> only
>>> > >> concern with any JIRA-based solution is that we would need to be
>>> very
>>> > good
>>> > >> about setting the “Fix Version” field properly when merging a patch
>>> and
>>> > >> updating the associated ticket. In the past I’ve seen a lot of
>>> patches
>>> > >> merged without the associated JIRA updated. If we’re going to rely
>>> on
>>> > JIRA
>>> > >> as the source of truth for change logs, we need to be very
>>> conscientious
>>> > >> about updating JIRA as necessary.
>>> > >>
>>> > >> -Taylor
>>> > >>
>>> > >>> On Jul 31, 2017, at 10:06 AM, Bobby Evans
>>> <evans@yahoo-inc.com.INVALID
>>> > >
>>> > >> wrote:
>>> > >>>
>>> > >>> I am happy to switch as soon as someone has a working
>>> alternative. The
>>> > >> big thing in my opinion is giving end users a clear list of all of
>>> the
>>> > >> changes that went into a release so they can review it for
>>> themselves.
>>> > >> However we do it is fine with me as the current changelog file
>>> leaves a
>>> > lot
>>> > >> to be desired. I personally would be fine with us updating the web
>>> > >> page/release notes to have a link to a JIRA query in it as a
>>> starting
>>> > point.
>>> > >>>
>>> > >>> https://issues.apache.org/jira/issues/?jql=project%20%
>>> > >> 3D%20STORM%20AND%20fixVersion%20in%20(1.0.4)%20ORDER%20BY%
>>> > >> 20priority%20DESC
>>> > >>> or
>>> > >>> https://issues.apache.org/jira/issues/?jql=project%20%
>>> > >> 3D%20STORM%20AND%20fixVersion%20in%20(1.1.1)%20ORDER%20BY%
>>> > >> 20priority%20DESC
>>> > >>> for example.
>>> > >>> Later on we can start looking at more complex alternatives that
>>> run the
>>> > >> above query and join it with the git revision history and possibly
>>> pull
>>> > >> requests to give a more complete view for what has happened.
>>> > >>>
>>> > >>> - Bobby
>>> > >>>
>>> > >>>
>>> > >>> On Monday, July 31, 2017, 1:42:11 AM CDT, Jungtaek Lim <
>>> > >> kabhwan@gmail.com> wrote:
>>> > >>>
>>> > >>> Let me also put long ago discussion about this:
>>> > >>>
>>> > >>> http://search-hadoop.com/m/Storm/8gnYyUdhVp1eajp31?subj=+
>>> > >> DISCUSSION+More+convenient+way+to+maintain+committer+
>>> > contributor+list+and+
>>> > >> changelogs
>>> > >>>
>>> > >>>
>>> > >>> In my view, from long ago discussion, Haohui and Bobby agreed to
>>> not
>>> > >>> maintain CHANGELOG by hand. Haohui also suggested how to get them
>>> > >>> automatically, whereas I just would want to remove it, but that's
>>> also
>>> > >> OK)
>>> > >>> We didn’t get agreement clearly about removing CHANGELOG but at
>>> least
>>> > saw
>>> > >>> our needs to automate it.
>>> > >>>
>>> > >>>
>>> > >>> And in current discussion, again in my view, Roshan, Hugo, Stig
>>> agree
>>> > to
>>> > >>> remove CHANGELOG. I’ve been continuously claiming to remove
>>> CHANGELOG,
>>> > >> so 3
>>> > >>> PMC members and 1 contributor seem to agree on removing CHANGELOG,
>>> and
>>> > at
>>> > >>> least 2 more PMC members to not maintain CHANGELOG manually.
>>> > >>>
>>> > >>>
>>> > >>> I will initiate a VOTE thread if we need to. Again, release
>>> managers
>>> > >> would
>>> > >>> be affected by this change so I would want to hear Taylor’s opinion
>>> > >> before
>>> > >>> going forward, but this is clear pain point for mergers so will
>>> > initiate
>>> > >> a
>>> > >>> VOTE thread in several days (at least in this week) if Taylor
>>> doesn’t
>>> > put
>>> > >>> opinion on this or misses this discussion.
>>> > >>>
>>> > >>>
>>> > >>> Thanks,
>>> > >>>
>>> > >>> Jungtaek Lim (HeartSaVioR)
>>> > >>>
>>> > >>> 2017년 7월 28일 (금) 오전 10:53, Jungtaek Lim <ka...@gmail.com>님이 작성:
>>> > >>>
>>> > >>>> correction: other projects -> *some* other projects, though
>>> they're
>>> > >>>> popular projects (including in competition)
>>> > >>>>
>>> > >>>> 2017년 7월 28일 (금) 오전 10:51, Jungtaek Lim <ka...@gmail.com>님이 작성:
>>> > >>>>
>>> > >>>>> I'm happy that there're other guys having same difficult and
>>> sharing
>>> > >> same
>>> > >>>>> feeling.
>>> > >>>>>
>>> > >>>>> This discussion has been initiating several times (from me) and
>>> > getting
>>> > >>>>> some +1s for each thread but didn't reach to actual work.
>>> > >>>>>
>>> > >>>>> We already utilize JIRA, and I'm subscribing issues@ and taking
>>> care
>>> > >> of
>>> > >>>>> issues forgot to mark resolve and/or labeling fixed versions.
>>> > >>>>> It may sounds ideal for us to let reporters caring about their
>>> > issues,
>>> > >>>>> but committers can also help that, and in fact merger is in
>>> > >> responsible to
>>> > >>>>> take care of resolving the issue, so irrelevant to contributor
>>> for
>>> > this
>>> > >>>>> side.
>>> > >>>>>
>>> > >>>>> My other consideration is that which thing is convenient for
>>> release
>>> > >>>>> manager. Taylor took the release manager all the time (thanks
>>> for the
>>> > >> great
>>> > >>>>> work!) and it is directly related to release announcement so
>>> would
>>> > >> like to
>>> > >>>>> hear his opinion. If it is more convenient or he think he can
>>> > tolerate
>>> > >>>>> that, we can just go on.
>>> > >>>>>
>>> > >>>>> Please note that other projects don't use merge commit. Most of
>>> the
>>> > >> time
>>> > >>>>> they squash commits in PR into one, labeling commit title as JIRA
>>> > >> issue,
>>> > >>>>> making commit list just as CHANGELOG. That's another thing we
>>> > discussed
>>> > >>>>> earlier and I think we need to discuss again, but that can be
>>> > discussed
>>> > >>>>> from another thread.
>>> > >>>>>
>>> > >>>>> Regarding maintaining contributors: easy to explain. Just take a
>>> look
>>> > >> at
>>> > >>>>> what Spark has been doing. Some other projects follow the
>>> approach as
>>> > >> well.
>>> > >>>>>
>>> > >>>>> We can run the script to extract authors of git commits, and
>>> just " |
>>> > >>>>> sort | uniq", and done. Pulling assigner from JIRA issue may be
>>> more
>>> > >>>>> accurate, since it requires actual account whereas author
>>> information
>>> > >> in
>>> > >>>>> commit is not strictly required to identify them. We can apply
>>> hybrid
>>> > >>>>> approach as well, but for starter just following git commits
>>> looks OK
>>> > >> to me.
>>> > >>>>>
>>> > >>>>> IMHO they don't feel proud strongly only they're listed in
>>> > >> contributors.
>>> > >>>>> Looking at contribution graph works better in this case, given
>>> that
>>> > it
>>> > >> also
>>> > >>>>> shows commit count and lines of change. (regardless of accuracy)
>>> > >>>>> It may give more proud to mention them as release announce. It
>>> will
>>> > >> lead
>>> > >>>>> contributors to play consistently, trying to participate and be
>>> > >> mentioned
>>> > >>>>> for releases as many as possible. IMO Spark built a great
>>> strategy
>>> > for
>>> > >> this
>>> > >>>>> side, and if we all think it is great, why not follow?
>>> > >>>>>
>>> > >>>>> Thanks,
>>> > >>>>> Jungtaek Lim (HeartSaVioR)
>>> > >>>>>
>>> > >>>>> 2017년 7월 28일 (금) 오전 6:58, Stig Rohde Døssing <
>>> stigdoessing@gmail.com
>>> > >>> 님이
>>> > >>>>> 작성:
>>> > >>>>>
>>> > >>>>>> We already have to keep JIRA updated, and keeping JIRA
>>> consistent is
>>> > >>>>>> easier
>>> > >>>>>> since there isn't one view of the resolved issues for each git
>>> > branch
>>> > >>>>>> like
>>> > >>>>>> we have with CHANGELOG, so there's no worry about e.g. master
>>> > having a
>>> > >>>>>> different opinion on solved issues in 1.2.0 than 1.x-branch has.
>>> > >>>>>>
>>> > >>>>>> I think we already have the guideline that only small (e.g.
>>> typo)
>>> > >> changes
>>> > >>>>>> are okay without a JIRA issue. We're already encouraging one
>>> commit
>>> > >> per
>>> > >>>>>> issue, most of the PRs I've seen recently have been squashing
>>> before
>>> > >>>>>> merge.
>>> > >>>>>> Is this not your experience?
>>> > >>>>>>
>>> > >>>>>> I think we have the contributors/committers lists on SVN as
>>> well for
>>> > >>>>>> generating http://storm.apache.org/contribute/People.html at
>>> > >>>>>> https://svn.apache.org/repos/asf/storm/site/_data/. I think
>>> > Jungtaek
>>> > >> was
>>> > >>>>>> suggesting keeping the committers list, and generating the
>>> > >> contributors
>>> > >>>>>> list for each release by either commit authors or JIRA
>>> assignees,
>>> > but
>>> > >> he
>>> > >>>>>> can probably elaborate better.
>>> > >>>>>>
>>> > >>>>>> 2017-07-27 23:06 GMT+02:00 Hugo Da Cruz Louro <
>>> > hlouro@hortonworks.com
>>> > >>> :
>>> > >>>>>>
>>> > >>>>>>> I am +1 for discontinuing CHANGELOG. However, using JIRA to
>>> compile
>>> > >>>>>> this
>>> > >>>>>>> info will only work if contributors are very disciplined and
>>> > >> consistent
>>> > >>>>>>> updating JIRA. That leads to the question, is it any easier to
>>> > >> maintain
>>> > >>>>>>> JIRA consistent then it is to keep CHANGELOG consistent? A
>>> clean
>>> > and
>>> > >>>>>>> consistent JIRA is ideal, as it will also make it easy to
>>> create
>>> > >>>>>> reports
>>> > >>>>>>> for individual components, etc.
>>> > >>>>>>>
>>> > >>>>>>> This discussion touches a proposal I suggested awhile ago, that
>>> > Storm
>>> > >>>>>>> community should have a more strict and consistent Git log
>>> > guideline.
>>> > >>>>>> In
>>> > >>>>>>> short, besides very trivial changes, like typos, or one or two
>>> line
>>> > >>>>>>> changes, every feature or bug should be associated with a JIRA.
>>> > >>>>>>> Furthermore, one commit should correspond to one JIRA, and one
>>> JIRA
>>> > >>>>>> should
>>> > >>>>>>> be solved by one commit. That means, we should focus on
>>> assuring
>>> > that
>>> > >>>>>>> commits are squashed, and their titles really reflect the issue
>>> > they
>>> > >>>>>>> address, etc.
>>> > >>>>>>>
>>> > >>>>>>> Af for the contributors and committers list. If we remove those
>>> > >> lists,
>>> > >>>>>>> where will this information be kept ?
>>> > >>>>>>>
>>> > >>>>>>> Hugo
>>> > >>>>>>>
>>> > >>>>>>>> On Jul 27, 2017, at 1:44 PM, Stig Rohde Døssing <
>>> > >>>>>> stigdoessing@gmail.com>
>>> > >>>>>>> wrote:
>>> > >>>>>>>>
>>> > >>>>>>>> Sorry to necro this thread, but I think it's worth bringing
>>> this
>>> > >>>>>> issue up
>>> > >>>>>>>> again. As Jungtaek mentioned a manual changelog is easy to
>>> break,
>>> > >>>>>> and it
>>> > >>>>>>>> looks like some issues are listed wrong on master and missing
>>> from
>>> > >>>>>> 1.x (
>>> > >>>>>>>> https://github.com/apache/storm/pull/2245)
>>> > >>>>>>>>
>>> > >>>>>>>> I think dropping CHANGELOG is a great idea, and we might use
>>> Kafka
>>> > >>>>>> as an
>>> > >>>>>>>> example for how to do release notes. They have JIRA generate
>>> the
>>> > >>>>>> notes
>>> > >>>>>>> and
>>> > >>>>>>>> put them up alongside each release, for instance
>>> > >>>>>>>>
>>> https://archive.apache.org/dist/kafka/0.11.0.0/RELEASE_NOTES.html
>>> > .
>>> > >>>>>> It's
>>> > >>>>>>> a
>>> > >>>>>>>> much nicer overview of changes than what we have in CHANGELOG
>>> > where
>>> > >>>>>> the
>>> > >>>>>>>> issue types are mixed, and a manual changelog is easier to
>>> get out
>>> > >> of
>>> > >>>>>>> sync
>>> > >>>>>>>> with JIRA. We could probably configure JIRA to generate
>>> something
>>> > >>>>>> similar
>>> > >>>>>>>> with a template (guide:
>>> > >>>>>>>> https://confluence.atlassian.com/adminjiraserver073/
>>> > >>>>>>> creating-release-notes-861253367.html
>>> > >>>>>>>> ).
>>> > >>>>>>>>
>>> > >>>>>>>> 2017-03-10 8:31 GMT+01:00 Jungtaek Lim <ka...@gmail.com>:
>>> > >>>>>>>>
>>> > >>>>>>>>> This propose will make merge process simpler, so I guess
>>> > >>>>>> committers/PMCs
>>> > >>>>>>>>> might not have strong opinions about this. I'm concerning
>>> mainly
>>> > >>>>>> about
>>> > >>>>>>> how
>>> > >>>>>>>>> it will affect release process.
>>> > >>>>>>>>>
>>> > >>>>>>>>> Taylor, I guess you're busy, but could you give your opinion
>>> > about
>>> > >>>>>> this
>>> > >>>>>>> as
>>> > >>>>>>>>> a release manager? Would removing CHANGELOG hurt or break
>>> release
>>> > >>>>>>> process?
>>> > >>>>>>>>>
>>> > >>>>>>>>> And do we need to vote to make progress?
>>> > >>>>>>>>>
>>> > >>>>>>>>> Thanks,
>>> > >>>>>>>>> Jungtaek Lim (HeartSaVioR)
>>> > >>>>>>>>>
>>> > >>>>>>>>> 2017년 3월 10일 (금) 오후 3:08, Xin Wang <data.xinwang@gmail.com
>>> >님이
>>> > 작성:
>>> > >>>>>>>>>
>>> > >>>>>>>>>> LGTM. I give a +1 for the idea.
>>> > >>>>>>>>>>
>>> > >>>>>>>>>> 2017-03-07 9:29 GMT+08:00 Jungtaek Lim <ka...@gmail.com>:
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>> Bump. I think it's not that trivial for code merger and
>>> release
>>> > >>>>>>>>> manager,
>>> > >>>>>>>>>>> and even contributors (how to represent their
>>> contributions.)
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>> 2017년 2월 24일 (금) 오전 9:43, Roshan Naik <
>>> roshan@hortonworks.com
>>> > >님이
>>> > >>>>>> 작성:
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>>> Sounds like a good idea to me.
>>> > >>>>>>>>>>>> -roshan
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> On 2/23/17, 4:41 PM, "Jungtaek Lim" <ka...@gmail.com>
>>> > wrote:
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> Hi devs,
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> I guess we discussed about this before, but didn't move
>>> to
>>> > >>>>>> actual
>>> > >>>>>>>>>>> work.
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> I'd like to propose again removing CHANGELOG file in
>>> > >>>>>> repository,
>>> > >>>>>>>>>> and
>>> > >>>>>>>>>>>> use
>>> > >>>>>>>>>>>> JIRA issue's fixed version(s).
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> Maintaining CHANGELOG to file is really easy to break.
>>> I've
>>> > >>>>>> seen
>>> > >>>>>>>>>>>> several
>>> > >>>>>>>>>>>> times and most of them is about backport. CHANGELOG file
>>> > >>>>>> between
>>> > >>>>>>>>>>>> branches
>>> > >>>>>>>>>>>> are inconsistent.
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> Suppose we would like to backport the issue to 1.0.x
>>> which
>>> > is
>>> > >>>>>>>>> only
>>> > >>>>>>>>>>>> applied
>>> > >>>>>>>>>>>> to 2.0.0, then we should fix CHANGELOG from three
>>> branches.
>>> > >>>>>> Easy
>>> > >>>>>>>>> to
>>> > >>>>>>>>>>>> miss
>>> > >>>>>>>>>>>> and redundant.
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> I'd also like to remove Project leads / Committers /
>>> > >>>>>> Contributors
>>> > >>>>>>>>>> in
>>> > >>>>>>>>>>>> README
>>> > >>>>>>>>>>>> (at least Contributors) since it's also easy to break.
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> For PMC members we're maintaining it to website and I
>>> think
>>> > >>>>>>>>> that's
>>> > >>>>>>>>>>>> enough.
>>> > >>>>>>>>>>>> For contributors I love what other projects are doing:
>>> > >> extract
>>> > >>>>>>>>>> unique
>>> > >>>>>>>>>>>> contributors name from commits or JIRA issues of release
>>> > >>>>>> version
>>> > >>>>>>>>>> and
>>> > >>>>>>>>>>>> mention them from release announce note.
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> What do you think?
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> Thanks,
>>> > >>>>>>>>>>>> Jungtaek Lim (HeartSaVioR)
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>
>>> > >>>>>>>
>>> > >>>>>>
>>> > >>
>>> >
>>> >
>>>
>>