I like the idea of squashing to a single commit and tagging that commit and PR with the JIRA ID. Agree that limiting duplicate emails would be good.
On 5/13/16, 6:17 AM, "Abhishek Agarwal" <abhishc...@gmail.com> wrote: >1* - Squashing commits is more of a guideline. Committers, specifically, >should ensure that the patches are squashed or volunteer to do that as >merging otherwise :) These guidelines along with 'how to git squash' can >be >added to http://storm.apache.org/contribute/Contributing-to-Storm.html. > >The above page says that for minor changes, there is no need to create a >JIRA. The definition of what is minor, is of course vague. In my >experience, there were very few changes which were made without a >corresponding JIRA so JIRA creation might as well be made mandatory. If >each commit is tagged with a JIRA id, it becomes easier to track that >change. I have also seen cases where there were multiple commits under >single JIRA but none of them were tagged with JIRA id. > >3* - I also get one extra email from notificati...@github.com if I am >participating in a pull request from notificati...@github.com. It will be >great to avoid that as well. By the way, removing notifications from >Github >means that PRs with no JIRA id might go unnoticed for long time. > > >On Fri, May 13, 2016 at 3:43 PM, Jungtaek Lim <kabh...@gmail.com> wrote: > >> 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/%3CCAF510 >>8h9Y-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/%3CCAO5KY >>W-=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) >> > > > >-- >Regards, >Abhishek Agarwal
