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