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 <stigdoess...@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 <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) > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > >
