Would it fit alongside the other release artifacts in e.g. https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.1.1-rc2/? That seems to be what Kafka is doing as well https://dist.apache.org/repos/dist/release/kafka/0.11.0.0/.
If we could put the change log up along the other artifacts, we could probably get away with not having it included in the src/bin distributions, because people could get the change log from the same mirrors they got the distributions from. 2017-07-31 22:37 GMT+02:00 P. Taylor Goetz <[email protected]>: > A couple thoughts/questions regarding the mechanics of publishing the > resulting HTML file. > > When voting on release candidates, in the past we point to the CHANGELOG > file in git. What would we do in this case? > > My assumption is the release manager would generate the file and post it > to their account on people.apache.org. After a successful vote, the > change log would be published to the storm.a.o website, presumably in a > /changelogs/${version}.html file. > > One could argue we could simply link to a JIRA filter for that release, > but I don’t like the idea of linking to something inherently mutable as a > release artifact. > > Would we include the file in the source and/or binary distributions? If > so, where, and what would be the process? > > I’m interested in hearing others’ thoughts. > > -Taylor > > > > On Jul 31, 2017, at 3:50 PM, Stig Rohde Døssing <[email protected]> > wrote: > > > > Opened JIRA here https://issues.apache.org/jira/browse/STORM-2665 and > took > > a look at adjusting Kafka's script here > > https://github.com/apache/storm/pull/2250 > > > > 2017-07-31 21:02 GMT+02:00 Bobby Evans <[email protected]>: > > > >> So it looks like we all agree, now we just need someone to file a JIRA > and > >> a corresponding pull request. The kafka script looks like a good place > to > >> start, but we can iterate on it in the pull request to try and address > >> Taylor's concern about JIRA not being up to date. I would love to do > it, > >> but I am really overloaded right now so if someone else wants to take > lead > >> on it that would be great. > >> > >> > >> - Bobby > >> > >> > >> On Monday, July 31, 2017, 1:45:14 PM CDT, P. Taylor Goetz < > >> [email protected]> wrote: > >> > >> 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 <[email protected] > > > >> 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 < > >> [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) > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >> > >
