Maybe we could adapt the script Kafka uses? It looks simple enough https://github.com/apache/kafka/blob/trunk/release_notes.py. I think the release notes they have are very readable.
2017-07-31 16:06 GMT+02:00 Bobby Evans <[email protected]>: > 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) > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> > >>> > >>>> > >>> > >>> > >>> > >> > >>> > > >>> > > >>> > >> >
