Hi devs, I just feel we are following a bit hard way to maintain project. Some of us (including me) pointed out earlier by initiating discussion thread, but it was forgotten. I found some major items which are worth to discuss.
- [DISCUSSION] Squashing commits before merging in <https://mail-archives.apache.org/mod_mbox/storm-dev/201505.mbox/%3CetPan.554d273a.d58469.139cb@HW10843.local%3E> - [DISCUSSION] More convenient way to maintain committer / contributor list and changelogs <https://mail-archives.apache.org/mod_mbox/storm-dev/201512.mbox/%3CCAF5108h9Y-tsHhYukP-A=nai6xmmljzzt_txdzkih22bwxj...@mail.gmail.com%3E> - does anyone else hate the verbose logging of all PR comments in the Storm JIRAs? <https://mail-archives.apache.org/mod_mbox/storm-dev/201509.mbox/%3CCAO5KYW-=kzzs12gd8rr+8rwsllg32fbia6fevqaytxee_ty...@mail.gmail.com%3E> I hope that we can come up with final result. Let me give my opinion about those three items. *1. Squashing commits before merging in* I believe learning from other projects is the best way to evaluate our process and change if others are better. Let's take a look at commits page on some projects - Hadoop <https://github.com/apache/hadoop/commits/trunk>, HBase <https://github.com/apache/hbase/commits/master>, Kafka <https://github.com/apache/kafka/commits/trunk>, Spark <https://github.com/apache/spark/commits/master>, Flink <https://github.com/apache/flink/commits/master>, Calcite <https://github.com/apache/calcite/commits/master>, Zeppelin (incubator) <https://github.com/apache/incubator-zeppelin/commits/master>. You may notice that most of commit logs are started to JIRA ID (which is what some of us are done implicitly), and there's one commit per one issue, which may be squashed. (there seems to be some exceptions but seems minor) Moreover, recently Github includes this feature to UI and many projects are using it. I'm in favor of squashing commits, but some contributors could have hard time to squash by themselves so I think it would be better to squash in merging step. (committers are in responsible to squash, which should be easier with script tool) *2. More convenient way to maintain committer / contributor list and changelogs* For maintaining committer, I don't know how to automatically collect committers / PMCs, but I think managing it from somewhere by hand is completely no problem unless we invite tens of persons in 1 day. ;) I just want to let this handled from wiki or some other place other than code repo so that committers/PMCs could modify it easier. For maintaining contributor, we can extract code contributors from one-liner command. git log --pretty=format:'%an' | sort -u (borrowed from OpenTSDB/AsyncBase <https://github.com/OpenTSDB/asynchbase/blob/master/THANKS>) We may even extract this from JIRA issue. (though I don't know how to do it) I even think mentioning contributors for each release news is more honorable compared to just listing up with README forever. There's also contributors tab so we could even get rid of it. For changelog, projects what I was referred are not having CHANGELOG in their repository. It's really hard to let CHANGELOGs in all branches in sync while we often port back. Please no more maintaining this by hand. 'Commits' page could be our CHANGELOG when we arrange commit logs better. 'Who merged that PR 'also be represented when we squash commits in merging process. *3. verbose logging : github PR activity goes to JIRA comment and trigger new mail* I'm clicking two mails for one new comment from github, which is really bad for me. I strongly agree with Erik, and linking github PR with JIRA is enough for me. Sorry and thanks for reading really long mail. Please let me know if you think it would be better to discuss them separated (each mail thread) so that I can post them. Thanks, Jungtaek Lim (HeartSaVioR)
