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) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> >
