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 <hlo...@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 <stigdoess...@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 <kabh...@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.xinw...@gmail.com>님이 작성: > >> > >>> LGTM. I give a +1 for the idea. > >>> > >>> 2017-03-07 9:29 GMT+08:00 Jungtaek Lim <kabh...@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 <ros...@hortonworks.com>님이 작성: > >>>> > >>>>> Sounds like a good idea to me. > >>>>> -roshan > >>>>> > >>>>> On 2/23/17, 4:41 PM, "Jungtaek Lim" <kabh...@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) > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> > >
