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 <ev...@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 <kabh...@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 <kabh...@gmail.com>님이 작성: > >> correction: other projects -> *some* other projects, though they're >> popular projects (including in competition) >> >> 2017년 7월 28일 (금) 오전 10:51, Jungtaek Lim <kabh...@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 <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) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>>
