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 <[email protected]>님이 작성: > 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 <[email protected]>님이 작성: > >> 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 <[email protected]>님이 >> 작성: >> >>> 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 <[email protected]>: >>> >>> > 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 < >>> [email protected]> >>> > 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 <[email protected] >>> >: >>> > > >>> > >> 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 < >>> > >> [email protected]> 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 >>> <[email protected] >>> > > >>> > >> 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 < >>> > >> [email protected]> 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 <[email protected]>님이 작성: >>> > >>> >>> > >>>> correction: other projects -> *some* other projects, though >>> they're >>> > >>>> popular projects (including in competition) >>> > >>>> >>> > >>>> 2017년 7월 28일 (금) 오전 10:51, Jungtaek Lim <[email protected]>님이 작성: >>> > >>>> >>> > >>>>> 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 < >>> [email protected] >>> > >>> 님이 >>> > >>>>> 작성: >>> > >>>>> >>> > >>>>>> 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 < >>> > [email protected] >>> > >>> : >>> > >>>>>> >>> > >>>>>>> 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 < >>> > >>>>>> [email protected]> >>> > >>>>>>> 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 <[email protected]>: >>> > >>>>>>>> >>> > >>>>>>>>> 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 <[email protected] >>> >님이 >>> > 작성: >>> > >>>>>>>>> >>> > >>>>>>>>>> LGTM. I give a +1 for the idea. >>> > >>>>>>>>>> >>> > >>>>>>>>>> 2017-03-07 9:29 GMT+08:00 Jungtaek Lim <[email protected]>: >>> > >>>>>>>>>> >>> > >>>>>>>>>>> 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 < >>> [email protected] >>> > >님이 >>> > >>>>>> 작성: >>> > >>>>>>>>>>> >>> > >>>>>>>>>>>> Sounds like a good idea to me. >>> > >>>>>>>>>>>> -roshan >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> On 2/23/17, 4:41 PM, "Jungtaek Lim" <[email protected]> >>> > 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) >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>> >>> > >> >>> > >>> > >>> >>
