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