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/%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) > -- Regards, Abhishek Agarwal
